Jump to content

Help talk:Citation Style 1

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia

This is an old revision of this page, as edited by 72.43.99.146 (talk) at 00:55, 27 June 2017 (→Module edit request: set(Quote): new section). The present address (URL) is a permanent link to this revision, which may differ significantly from the current revision.

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)[reply]

@Trappist the monk: Any way we can get this bundled in the weekend's update? Headbomb {t · c · p · b} 05:29, 26 April 2017 (UTC)[reply]
The purpose of this interstitial period is to have a last chance to find and fix bugs; to create or modify supporting documentation, categories, templates, etc. – housekeeping preparatory to the update. It is not the time for new development or new features.
—Trappist the monk (talk) 11:28, 26 April 2017 (UTC)[reply]
Yeah well this has been requested a long while ago, is an easy fix, and we have over half a week left. WP:BURO applies here. Headbomb {t · c · p · b} 11:57, 26 April 2017 (UTC)[reply]

Can we now implement this? Headbomb {t · c · p · b} 00:27, 2 May 2017 (UTC)[reply]

De-archived because discussion is ongoing/unresolved. @Trappist the monk:. Headbomb {t · c · p · b} 17:20, 23 May 2017 (UTC)[reply]
@Trappist the monk and Jonesey95: pinging. Headbomb {t · c · p · b} 19:13, 12 June 2017 (UTC)[reply]
It makes sense to me to have allegedly broken DOIs linked, since the doi-broken-date is checked by a bot and (a) could have been wrongly applied or (b) could have been a temporary problem or (c) both. There are plenty of links that don't work and are not flagged as such. That's just the state of the web, and always has been. – Jonesey95 (talk) 02:00, 13 June 2017 (UTC)[reply]

Parameter for Wikidata ID

As Headbomb notes, above, it would be useful for this template to have a parameter, |wikidata= for the identifier for a cited work, on Wikidata. While this will be essential for drawing metadata from Wikidata, it will be useful independently, also. Can we add one now? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 20:22, 27 May 2017 (UTC)[reply]

Agree I think it's a great idea. Sam Wilson 02:34, 4 June 2017 (UTC)[reply]
We should most definitely not draw citation data from wikidata. This is no different than putting data on {{cite doi}} subpages Too much potential for things to go wrong. Headbomb {t · c · p · b} 13:51, 10 June 2017 (UTC)[reply]
The legitimate use for this parameter that I can imagine is if a reader comes across a claim in a Wikipedia article which the reader wants to add to Wikidata. Knowing the Wikidata item associated with the source would expedite the process of adding the claim to Wikidata (and of course providing a proper citation over there).
My fears are (1) not many Wikipedia editors will use the parameter, so it will have little practical usefulness, and (2) editors who love to run bots will run massive campaigns to add the parameter automatically, with little concern about different works with the same title, different editions of work, and the like. Jc3s5h (talk) 14:13, 10 June 2017 (UTC)[reply]
My concerns also. And I concur with Headbomb's comment. ~ J. Johnson (JJ) (talk) 20:09, 11 June 2017 (UTC)[reply]
My point was that "[this] will be useful independently". There are no cogent arguments for not using Wikidata IDs as identifiers in citations, as we do for, for instance OL iDs. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 09:24, 12 June 2017 (UTC)[reply]
Perhaps you would explain how this would be useful. Given that a citation should contain full bibliographic details, what does a wikidata record add? ~ J. Johnson (JJ) (talk) 22:53, 12 June 2017 (UTC)[reply]
It adds a unique identifier for the source cited, just as ISBN, DOI, OL and others do. It does so even where no other unique identifier (and indeed, even where no other online resource) exists. Furthermore, that identifier can in turn be used to fetch identifiers and other metadata for the publication, the author, publisher et al. It thereby makes each citation a starting point for the linked web of data. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 23:35, 12 June 2017 (UTC)[reply]

Add parameter for Google Books id

It would be nice if we could enter the Google Books id for a work into a dedicated parameter, say |googleid= (which I understand existed long, long ago for different purpose but has been deprecated long enough that none should survive). Then if |page= is supplied, the proper url for the page could be wrapped around the page number in a sensible fashion; if no page number is supplied then either the title of the book could be linked in the absence of an explicit |url= or a separate link like we do for |doi=, etc. It would be nice if we could also cope with |pages= and/or pages specified with roman numerals but just the basic functionality would help for now. TIA HAND —Phil | Talk 16:16, 5 June 2017 (UTC)[reply]

I have seen people use {{Google books}} with |plainurl= in the CS1 |url= parameter. See Example 2 on the template's documentation page. Have you tried it? – Jonesey95 (talk) 17:50, 5 June 2017 (UTC)[reply]
It might be worth adding |Google Scholar id= at the same time; Wikidata has just created Google Scholar paper ID (P4028) for this. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 23:10, 5 June 2017 (UTC)[reply]
@Pigsonthewing: It was a horrible mistake to add this as a property to Wikidata and it would compound the mistake to import this mess from Wikidata to Wikipedia. These are not id's of papers. Their full urls on Google scholar clearly identifies them as "clusters"; at best they are clusters of closely related publications, and at worse they are garbage caused by Google Scholar being more or less entirely automated and uncurated. Keep them as far away as possible. Google scholar identifiers for individual people may be ok (at least the ones that are well-curated by their subjects) but that doesn't make the rest of Google scholar's structure valid for import to Wikidata or anywhere else. —David Eppstein (talk) 20:57, 11 June 2017 (UTC)[reply]
David Eppstein I think there is a difference between the identifiers we want to have in Wikidata and the ones we want to display in Wikipedia.
  • In Wikidata, it does not really hurt to create new properties for particular bibliographic databases. As a Wikidata contributor or consumer, it is easy to ignore a property if you do not find it useful. The statements using these new properties will just be ignored by other Wikimedia projects by default. They will not affect the result of existing SPARQL queries, and so on. So yes, I also find it quite useless to have a property for Google Scholar cluster ids, not because of quality concerns (we know how to deal with that) but rather because I do not see how we could add enough statements with this property to make it useful. But it does not matter, and if someone thinks it is a good use of their time to add cluster ids to items manually I am very happy to let them do that.
  • In the Wikipedia citation templates, adding an identifier means adding a short snippet of text at the end of citations. That is directly visible for readers and not easy to ignore. So I think we should really restrict these to well established bibliographic databases (which are widely used to cite works, and not just to link to them). Just use |url= or |id= for the others.
Overall I think we need to stop trying to promote every URL to the sacred status of identifier. Yes, from https://scholar.google.com/scholar?cluster=17269205842348980774 we can extract 17269205842348980774. And we can do that for many other services. But the only useful thing we can do with that number is to construct back the URL where we got it from. So why on earth should we display that number on an article? The fact that we can technically do it does not mean that we should do it! Do we really want to see something like that:
Amodio, David M; Hamilton, Holly K (2012). "Intergroup anxiety effects on implicit racial evaluation and stereotyping". Emotion. 12 (6): 1273. Google Scholar: 17269205842348980774.
Instead of, simply:
Amodio, David M; Hamilton, Holly K (2012). "Intergroup anxiety effects on implicit racial evaluation and stereotyping". Emotion. 12 (6): 1273.
− Pintoch (talk) 13:55, 14 June 2017 (UTC)[reply]
I don't think these IDs deserve separate links at the end of citations. As a reader I would find it quite annoying to see these opaque identifiers popping up: they don't mean anything to me (and they don't mean much to machines either because at least Google Scholar has no public API). Using them to fill |url= without adding anything at the end seems more acceptable, but do the benefits really outweigh the added complexity?
I can see the point of separate rendering for things like |arxiv= or |doi=, because they are genuinely used as identifiers by many people. But for Google Books or Google Scholar, as far as I know these are just internal identifiers, and it would be a bit weird to cite a book by its Google Books ID. The ID exists and can be seen in the URL, sure (that's how all these websites work) but that does not mean readers should care about this particular string, I think.
As to the problem of rendering Wikidata items as citations, I think it would be fairly simple to convert identifiers which are present on Wikidata and absent in CS1/2 to URLs on the fly, and pick the "best" of these URLs based on a priority ranking. − Pintoch (talk) 09:13, 8 June 2017 (UTC)[reply]
I assume that a Google ID parameter could replace the url parameter. A Google ID parameter can be both a pointer to content such as doi or arxiv (when Google publishes all or part of the work), and a pointer to classification such as ISBN or ISSN (these are actually marketing ids). I don't know what you mean by "internal identifiers". When an id genuinely and uniquely identifies to a work, can be publicly retrieved, and has no legal ramifications, it is a usable identifier for the purpose of discovering the source cited, and (in the case of published content) directly support the wikitext. Btw, all identifiers can seem "opaque" to readers. As they should: they are not there to be "understood", but to stand in for something else, that must be researched if the reader wants to verify the citation.
Wikidata items as citations is problematic. There are reliability questions, and also questions of cyclical references or self-references. Wikidata items are "supported" by Wikipedia references. Apart from the fact that the validity of the underlying references is not declared in any way, Wikipedia itself fails the WP:RS tests, and should not be used as a reference. 72.43.99.146 (talk) 14:30, 8 June 2017 (UTC)[reply]
I'm going to go with a "treat Google-ID" like ASIN. It's an identifier of last resort. Headbomb {t · c · p · b} 14:57, 8 June 2017 (UTC)[reply]
Plain text literal URLs are best IMO. Adding layers of abstraction has a downsize and unclear what it gains in return is worth it. These types of things make it really difficult for bot writers and they usually just get skipped and thus not maintained and so are more error prone over time to link rot and other problems. -- GreenC 17:17, 8 June 2017 (UTC)[reply]
In response to the IP:
First, what is an internal identifier? It is an ID that has many of the following characteristics:
  • not exposed by any public API ;
  • without any stability guarantees (e.g. Google Scholar can change the cluster id of a paper freely, that should not break any other system. If Crossref suddenly decides to change its DOIs, people can rightly complain) ;
  • not designed to be looked up manually by users (e.g. on Google Scholar you will not find a form where you can input a cluster id, whereas you will find the equivalents on doi.org and hdl.handle.net );
  • not exposed in the user interface of the platform (because it is not intended to be used outside the platform).
In other words, it is an ID that is used in a system because of technical reasons (most databases need to rely on one), but is not used to communicate with other systems.
About Wikidata items as citations, I am not sure you understand the use case correctly. I invite you to have a closer look at the wonderful {{cite Q}}. Using a Wikidata item with {{cite Q}} does not mean that you are citing that item, it means that you are citing the work represented by that item. So there is no issue of cyclical references at all! For instance, if I edit the article on Formaldehyde, I am not going to use {{cite Q}} with formaldehyde (Q161210) (some of the information there is indeed likely extracted from that Wikipedia article) but rather with an item that represents a scientific article about that topic, such as An Investigation on Formaldehyde Emission Characteristics of Wood Building Materials in Chinese Standard Tests: Product Emission Levels, Measurement Uncertainties, and Data Correlations between Various Tests (Q30000011).
Finally, it is wrong to say that "Wikidata items are "supported" by Wikipedia references". Many references in Wikidata do not rely on Wikipedia at all! Some statements were imported from Wikipedia, but in principle Wikidata can work independently of any Wikipedia, as an autonomous database. In fact, many Wikidata items are not linked to any Wikipedia article.
If anything is still unclear please let me know! − Pintoch (talk) 20:05, 8 June 2017 (UTC)[reply]
The technicalities behind an identifier are immaterial. They are included in citations in order to discover a source. If the identifier can fulfill this requirement, that is sufficient. The only thing that matters, where citations are concerned, is to verify claims in an article. Everything else is secondary. Because everything that is produced by anonymous or pseudonymous writers/editors is inherently unreliable. This includes, articles, bots, scripts, templates, and entire platforms. As far as anything produced by such actors, there is no formal quality control, whether that is verifiability/reliability checking for wikitext or version testing/control for wikiscript. So I am not discussing whether an identifier in an a priori unreliable reference can communicate with a potentially unreliable platform through a potentially unreliable API. It is unimportant. Can this id assist a non-expert user in determining whether a reference is valid or not?
I've no idea how stable Google IDs are relative to other identifiers (they may all change). I don't know what Google's policy is in backlinking changed IDs, relative to similar policies of other id providers. I do know that Google IDs, and the items they identify, are fairly easy to track and use. This ease of use makes a reference more likely to be verifiable than a reference that omits a similar id, or that instead offers more restrictive systems. In an unreliable platform such as Wikipedia, ease-of-reliability gets my vote.
For the same reasons, it is unimportant to me what Wikidata (or Wikipedia) can be "in principle". In principle, anything will be perfect. But my experience with Wikidata is that the "data" part is often inscrutable, and there is no mechanism to verify anything from within the platform. Additionally, the majority of Wikidata statements I have seen come from similar, inherently unreliable sources such as Wikipedia. 72.43.99.146 (talk) 00:55, 9 June 2017 (UTC)[reply]
The technicalities behind an identifier are not unimportant at all. Stability and interoperability do matter. If all you care about is whether "this id assist a non-expert user in determining whether a reference is valid or not", then just use the URL, that is what they are for!
Again for Wikidata you clearly do not understand how it is being used in {{cite Q}}. There are absolutely no concerns about the verifiability of the statements of items used with {{cite Q}}, because these statements are just metadata about the article. Please just try for yourself and you will see why. This is a very different use case than for infoboxes, for instance. − Pintoch (talk) 06:28, 9 June 2017 (UTC)[reply]
No, imo the technicalities are secondary. When wikitext may be unreliable, stability and interoperability of the underlying mechanism is enhancing such unreliability. First, make sure that the reference is correct. We know that the URL can be inserted, however the OP asked very specifically for a parameter based on the id. The first criterion: is this param going to make reference checking easier? If not, the matter is closed. If yes, the question shifts to the programming cost. If the addition of this parameter has a significant effect on existing code, it can be rejected, since there is an alternative. If the addition of a helpful parameter has trivial effect, it should be included. That is the purview if the citation system. Whether, and how well, it links to external systems has nothing to do with a citation's purpose.
My opposition to blind insertion of Wikidata is not related to any one template, and how well it is implemented. It is about the reliability of the Wikidata statements themselves. Statements based on metadata from unverified, possibly misleading, unreliable, or irrelevant citations are bad data. I would certainly not consider the determining factor for the introduction of any CS1 parameter (such as Google ID), to be Wikidata interoperability, or any other interoperability. 72.43.99.138 (talk) 15:41, 9 June 2017 (UTC)[reply]

CS1 maint: English language specified

Just wonder what happened to Category:CS1 maint: English language specified? Why was it removed? – Danmichaelo (talk) 04:30, 6 June 2017 (UTC)[reply]

Fishing lesson: Scroll to the top of this page, find the "Search archives" box, type "English language specified", and you will get this result. The discussion is in Archive 8. – Jonesey95 (talk) 04:57, 6 June 2017 (UTC)[reply]

hdl - OAbot - ELNEVER?

I am finding myself in a little edit war with User:Waldir , who added a "hdl" parameter to a ref in this dif with edit note: Added free to read links in citations with OAbot #oabot). The specific handle added here was hdl:10722/198790, which I hesitate to post, but I guess we need it for the discussion. There is a full-text link to the article on that webpage. I do not see any indication that this is a non-copyright-infringing copy.

My removal was reverted in this dif, with edit note Undid edit 784333522] -- restore link to full text, as existing DOI/PMID link to paywalled sources. and I again reverted.

So -

  • are people using hdl to violate WP:ELNEVER?
  • Is there a bot that is being used to violate WP:ELNEVER?

I've posted a link to this at the article talk page and may post other places to broaden this, depending on how this goes...who knows I may have something to learn here. Jytdog (talk) 03:15, 8 June 2017 (UTC)[reply]

I think it's an author copy, not a copyvio. An earlier version of OAbot had a problem with ELNEVER — it was posting citeseerx links, and those are often violations. But this one (as with all hdl OA links I have looked at) appears to be legitimate. More specifically, I think it's something one of the authors posted at their home institution, so I don't think it is problematic. I can't tell precisely which author did it, but three of them are listed as having the same institution as the preprint server (HKU). —David Eppstein (talk) 03:22, 8 June 2017 (UTC)[reply]
OK thanks for that background and analysis of this link. I will self-revert. Jytdog (talk) 03:55, 8 June 2017 (UTC)[reply]
For clarification, OAbot still uses |citeseerx= but is not run as a bot anymore (the BRFA was withdrawn). It has become a semi-automated tool where users are asked to check the links they add (https://tools.wmflabs.org/oabot/). Checking if a copy is legal can be genuinely hard even for librarians (it is not just whether it is an author manuscript or not! Very often, you need to take into account policies from publishers, from universities and funders, to assess the status of these copies). These considerations have little to do with the nature of the identifier used to insert the link (for instance, it is possible that a |doi= links to a copyvio, because some preprint servers can issue DOIs). − Pintoch (talk) 07:57, 8 June 2017 (UTC)[reply]

Identifier order messed up.

Why is bibcode displaying before arxiv in?

Identifiers should be listed in alphabetical order. Headbomb {t · c · p · b} 13:49, 10 June 2017 (UTC)[reply]

The identifier labels are sorted with a case sensitive sort. 'B' has an ascii numerical value of 66 (0x42) and 'a' has an ascii numerical value of 97 (0x61). Proof for that is here, where I've added |eissn=1365-2966 and |issn=0035-8711 from the journal's wikipedia article:
"The extended rotation curve and the dark matter halo of M33". Monthly Notices of the Royal Astronomical Society. 311 (2): 441–447. 2000. arXiv:astro-ph/9909252. Bibcode:2000MNRAS.311..441C. doi:10.1046/j.1365-8711.2000.03075.x. eISSN 1365-2966. ISSN 0035-8711. {{cite journal}}: Unknown parameter |authors= ignored (help)CS1 maint: unflagged free DOI (link)
—Trappist the monk (talk) 14:42, 10 June 2017 (UTC)[reply]
Well, that ought to be fixed then, either with case-insensitive sorting, or by putting the sortkey in a {{lc:IDENTIFIERNAME}} type of thing. Because it wasn't like that before. Headbomb {t · c · p · b} 15:18, 10 June 2017 (UTC)[reply]
There have been no changes to the identifier sorting since at least this version (April 2013) of Module:Citation/CS1.
—Trappist the monk (talk) 15:59, 10 June 2017 (UTC)[reply]
I distinctly remember those to be sorted correctly as late as this spring. But even if my memory somehow fails me, those should be sorted alphabetically, regardless of casing. Headbomb {t · c · p · b} 17:02, 10 June 2017 (UTC)[reply]

NO ONE uses "access-date"

[Approximately] no one uses access-date. accessdate is the norm; access-date is the alternate.

I changed this documentation page to reflect this [de-facto] usage. Someone changed it back, saying "the canonical parameter names are hyphenated".

1) Both forms are listed, and they function identically. Therefore both forms are canonical. Or, whichever form is listed first is canonical. I changed the order here, thus changing the canon. Is that a problem? 2) I thought that this instruction page, not linking to any policy page, was the only guideline for this parameter. Does this parameter have a canon? Citation needed. (Let's change it too.) 3) If usage is 99% "accessdate" and 1% "access-date", then an unwritten rule or tradition supersedes the examples here. Thus these examples make fools of people, and they need to be corrected. If there is a canon, it also needs to be revised. 4) "is" does not mean "forever shall be. It would be hard to excuse not changing this. -A876 (talk) 13:48, 11 June 2017 (UTC)[reply]

It was I who reverted your edits.
See this RFC. Note that the RFC says: The documentation is to show this lowercase, hyphenated version as the one for "normal use". What I wrote in the edit summary that accompanied the reversions of your edits is correct: the canonical forms of multi-word cs1|2 parameter names are the hyphenated forms.
Answering your questions:
  1. yes, changing the order is a problem because the RFC specifically states that hyphenated parameter names are to be the 'normal use' parameter names.
  2. the 'canon' is the documentation page for each template which derives from Template:Citation Style documentation which is the centralized parameter documentation.
  3. usage may well be as you describe. The decision taken in the RFC (2014) came long after the introduction of |accessdate= (c. 2006). Because the parameters |access-date= and |accessdate= are aliases of each other, there can be no mass change by robot to convert |accessdate= to |access-date= because such a change is merely cosmetic. Cosmetic-only changes by robot are prohibited. See WP:COSMETICBOT.
  4. because an RFC made the decision to prefer hyphenated names, I suspect that there is little justification for a change away from that RFC's decision.
—Trappist the monk (talk) 14:46, 11 June 2017 (UTC)[reply]
One minor point in response to the OP: I patrol the CS1 unsupported parameters category, and I occasionally see a well-meaning editor incorrectly "correct" "accessdate" to "access date", which introduces an invalid parameter. I have never seen anyone change "access-date" to "access date". – Jonesey95 (talk) 02:53, 12 June 2017 (UTC)[reply]
That to me indicates that some editors are reading "accessdate" as text rather as a parameter label. This would likely fall under careless/lazy editing. Isn't it obvious from the context that "accessdate" is part of a script?! 65.88.88.75 (talk) 18:20, 12 June 2017 (UTC)[reply]
If I have autocorrect turned on in my OS, my browser will correct "accessdate" to "access date" for me while I"m typing, but it will leave "access-date" alone. Spell checkers in software don't have that same context you describe, so they'll correct what they see as a typo by inserting a space between what is otherwise separate words in the English language. Imzadi 1979 → 00:54, 13 June 2017 (UTC)[reply]
Well, the comment was about human editors. With machine editors such as autocorrection routines, gigo applies, I suppose. 65.88.88.208 (talk) 17:52, 13 June 2017 (UTC)[reply]

Order of authors in COinS metadata

I have just tried an experiment, at User:Pigsonthewing/Zotero-test, where I imported a citation to Zotero, from a Wikipedia citation template, using its COinS metadata. I then exported that citation from Zotero as a Wikipedia citation template,

The order of the author names was not preserved (instead, they were apparently sorted alphabetically by first name in the COinS output of the original template).

Is that deliberate? Can the behaviour be changed, so that the order is preserved in a round-trip? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 23:39, 12 June 2017 (UTC)[reply]

The OP omitted that the above citation uses the experimental {{Cite Q}} wikidata template. I tried to substitute the Cite Q template to reproduce the problem, but it's a Lua module, and I couldn't figure out how to substitute it. So I rewrote the citation in my sandbox, like so:
{{Cite journal| doi = 10.1371/JOURNAL.ONE.0010676| volume = 5| issue = 5| last3 = Tassell| first3 = James L. Van| last1 = Williams| first1 = Jeffrey T.| last2 = Carpenter| first2 = Kent E.| last7 = Smith| first7 = Michael| last4 = Hoetjes| first4 = Paul| last6 = Etnoyer| first6 = Peter| last5 = Toller| first5 = Wes| title = Biodiversity Assessment of the Fishes of Saba Bank Atoll, Netherlands Antilles| journal = PLOS ONE| date = 2010-05-21}}
which renders like this:
Williams, Jeffrey T.; Carpenter, Kent E.; Tassell, James L. Van; Hoetjes, Paul; Toller, Wes; Etnoyer, Peter; Smith, Michael (2010-05-21). "Biodiversity Assessment of the Fishes of Saba Bank Atoll, Netherlands Antilles". PLOS ONE. 5 (5). doi:10.1371/JOURNAL.PONE.0010676.{{cite journal}}: CS1 maint: unflagged free DOI (link)
When I look at the HTML source, I see the authors alphabetized by last name. The relevant portion of the citation looks like this: 
rft.au=Carpenter%2C+Kent+E.&rft.au=Etnoyer%2C+Peter&rft.au=Hoetjes%2C+Paul&rft.au=Smith%2C+Michael&rft.au=Tassell%2C+James+L.+Van&rft.au=Toller%2C+Wes&rft.aufirst=Jeffrey+T.&rft.aulast=Williams
I do not know where this alphabetization happens, assuming that it is not coincidence. I looked through a few different specs linked from COinS, and none of them referred to any ordering of author parameters when there is more than one author. That surprises me, given the importance that journals and academics ascribe to the order of authors of papers, but it looks like you may be trying to do something that is not possible. – Jonesey95 (talk) 02:35, 13 June 2017 (UTC)[reply]
Are you sure that Zotero is not sorting the author list on import? Also it is trivial to sort by the first authors last name in Zotero by clicking on the sort arrow in the Creator column header. Boghog (talk) 03:21, 13 June 2017 (UC)
I did not do anything with Zotero. As the OP said, "they were apparently sorted alphabetically ... in the COinS output of the original template". – Jonesey95 (talk) 03:35, 13 June 2017 (UTC)[reply]
My reply was to the OP. The OP also said "apparently". Boghog (talk) 04:08, 13 June 2017 (UTC)[reply]
Sorry, I misread the OP. The sorting was within a citation, not between citations. Just to be clear, I agree that the oder of authors within a citation should be preserved. Boghog (talk) 04:18, 13 June 2017 (UTC)[reply]
As a test, I have commented out one line of "table.sort" code in the CS1 module sandbox. Now the citation in my sandbox looks like this:
{{Cite journal/new| doi = 10.1371/JOURNAL.PONE.0010676| volume = 5| issue = 5| last3 = Tassell| first3 = James L. Van| last1 = Williams| first1 = Jeffrey T.| last2 = Carpenter| first2 = Kent E.| last7 = Smith| first7 = Michael| last4 = Hoetjes| first4 = Paul| last6 = Etnoyer| first6 = Peter| last5 = Toller| first5 = Wes| title = Biodiversity Assessment of the Fishes of Saba Bank Atoll, Netherlands Antilles| journal = PLOS ONE| date = 2010-05-21}}
which renders like this:
Williams, Jeffrey T.; Carpenter, Kent E.; Tassell, James L. Van; Hoetjes, Paul; Toller, Wes; Etnoyer, Peter; Smith, Michael (2010-05-21). "Biodiversity Assessment of the Fishes of Saba Bank Atoll, Netherlands Antilles". PLOS ONE. 5 (5). doi:10.1371/JOURNAL.PONE.0010676.{{cite journal}}: CS1 maint: unflagged free DOI (link)
When I look at the HTML source now, I see the authors listed in the numerical order given in the citation. In other words, the "|last1=" author is correctly listed first, etc., even though he is listed second in the citation template above. The relevant portion of the citation looks like this: 
rft.aulast=Williams&rft.aufirst=Jeffrey+T.&rft.au=Carpenter%2C+Kent+E.&rft.au=Tassell%2C+James+L.+Van&rft.au=Hoetjes%2C+Paul&rft.au=Toller%2C+Wes&rft.au=Etnoyer%2C+Peter&rft.au=Smith%2C+Michael
I have not looked at the rest of the COinS output to see if there are undesirable side effects of this change, but it appears to explain what the OP was seeing. The CS1 module appears to be sorting the author names in the COinS data. Andy, what happens if you export that citation to Zotero? – Jonesey95 (talk) 03:47, 13 June 2017 (UTC)[reply]
Thank you. Zotero exports your sandbox version as {{Cite journal| doi = 10.1371/JOURNAL.PONE.0010676| volume = 5| issue = 5| last1 = Williams| first1 = Jeffrey T.| last2 = Carpenter| first2 = Kent E.| last3 = Tassell| first3 = James L. Van| last4 = Hoetjes| first4 = Paul| last5 = Toller| first5 = Wes| last6 = Etnoyer| first6 = Peter| last7 = Smith| first7 = Michael| title = Biodiversity Assessment of the Fishes of Saba Bank Atoll, Netherlands Antilles| journal = PLOS ONE| date = 2010-05-21}}, which maintains the original ordering. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 09:12, 13 June 2017 (UTC)[reply]
While it's conceivable that Zotero also applies sorting (I've not yet tested that), in this case the reordering is already present in our COinS metadata. I used the word "apparently" because I can't rule out some other algorithm that coincidentally applied alphabetical sorting. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 09:08, 13 June 2017 (UTC)[reply]
The original cite was produced by {{Cite Q}} which gets its parameter values from WikiData. {{Cite Q}} uses |authorn= parameters and WikiData provides author names first-name-first. As Editor Jonesey95 correctly points out, Module:Citation/CS1/COinS sorts the metadata. When the cite does not use |last1= and |first1= all author-names are assigned to &rft.au keys. When the metadata are sorted, the sort compares the whole key/value string. Because author-names in this example are fist-name-first, that is how they were sorted.
The change to Module:Citation/CS1/sandbox that added the sorting was done here and appears to have been done for the convenience of the editor.
—Trappist the monk (talk) 10:17, 13 June 2017 (UTC)[reply]
As noted above, the issue occurs when {{Cite journal}} is used, also - albeit sorted by last name. I've added some more analysis to User:Pigsonthewing/Zotero-test, using both {{Cite journal}} and {{Citation}}. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 16:38, 13 June 2017 (UTC)[reply]
Yes. {{Cite Q}} calls {{citation}} and {{citation}} uses the same Module:Citation/CS1/COinS as does {{cite journal}}. The sorting differences that you see in the above examples occur because {{Cite Q}} feeds |authorn= parameters to {{citation}} but the example {{cite journal}} uses |lastn= and |firstn=. The module concatenates the value assigned to |lastn= with a comma and a space and with the content of |firstn= when it creates a &rtf.au=lastn, firstn key/value pair. There is no concatenation when the author name is contained wholly in |authorn=; the module does not attempt to rearrange such names into last-first order. When the cs1|2 template uses the first author parameters |last1= and |first1=, the values from these parameters are assigned to the &rft.aulast and &rft.aufirst keys respectively. Because there can only be one 'first' author, only one of each of these keys is allowed in the metadata; all other authors are placed in individual &rft.au keys.
—Trappist the monk (talk) 10:33, 14 June 2017 (UTC)[reply]

Hello. {{Link language}} is a template for use with external links, to highlight that the linked resource is in a foreign language.

Recently, a consensus on a change to that template has been reached, and its appearance is now consistent with the various "cite" templates, e.g. "Invalid language code.".

As a next step, I would like to "interlock" the two, so that the appearance of {{Link language}} cannot be changed without also changing the rendering of the language parameter of the cite templates—and vice versa. The goal is to somewhat enforce a consistency in styles, which I believe is already happening between the various cite templates.

Before I raise a formal RfC, could you please help me:

  1. Identify the best way to implement this - I couldn't find the common template where the common appearance on the "cite" side is centralised, if there is such a thing
  2. Identify the best forum/fora where a RfC should be raised

Thanks! 2A02:C7D:DA0A:DB00:6C22:2CCB:28CB:25A2 (talk) 21:41, 19 June 2017 (UTC)[reply]

The output for |language= is defined at line 84 in Module:Citation/CS1/Configuration (search for ['language']). It is used at line 1465 of Module:Citation/CS1 (search for wrap_msg ('language', name)). The result is then included in the various template outputs at lines 3231–3270 in Module:Citation/CS1 (search for , Language).
As you can see, cs1|2 does not apply any unique styling to the language parameter rendering. I don't know what, if any, styling the class languageicon adds to the {{link language}} rendering.
—Trappist the monk (talk) 22:29, 19 June 2017 (UTC)[reply]
Thanks for the pointers, very helpful! I take it this is the right place to have this preliminary discussion :-)
Why do you say that "cs1|2 does not apply any unique styling"? I do not see any styling anywhere, sorry, could you please point me to it? <<< Sorry, I misread!
As for the class languageicon, I don't know either, but I suspect it's just there so that users can have custom CSS overrides on their clients, as opposed to this existing in some global Wikipedia CSS file. Is there a way we can find for sure?
One comment I have is that local function language_parameter (lang) seems to have two distinct responsibilities (code/name lookup, categorisation), and so it should probably split out in two separate functions, because {{link language}} may not need the latter, or may need a different version of it. But this is a detail that we can flesh out later.
I take it this code is Lua, by the way. Excuse my ignorance, but how do I interface a template to invoke a Lua function please? (Feel free to send me to a tutorial) Specifically in our case, we will want something like
<span class="languageicon"><callLua function="wrap_msg ('language', {{{1}}})"></callLua></span> <!-- Do not use this line, I just made it up! -->
Thanks! 2A02:C7D:DA0A:DB00:5518:37F7:4E4C:B1FF (talk) 06:56, 20 June 2017 (UTC)[reply]
It is hard to point to something that does not exist. There is no styling (font, color, whatever) for |language=.
The purpose of language_parameter() is to consolidate all required work necessary in a single place. Were the presentation portion of that a matter of some complexity, I might agree that it should be split out. As it is, presentation is trivial so leaving it where it is does no harm. I certainly would have considered separate functions for the various tasks needed to support |language= if there were other parameters that needed the exact functionality so that duplicate code would be unnecessary. There are none so I did not.
Yes, Lua. See WP:LUA.
I guess I must wonder why it is necessary to interlock the cs1|2 templates with other unrelated templates. Still, if you must, this, as a module, might do the trick:
p={}
cfg = mw.loadData ('Module:Citation/CS1/Configuration');

function p.lang_render (frame)
	local lang = frame.args[1];
	return lang and mw.message.newRawMessage( cfg.messages['language'], lang ):plain() or 'no language specified';
end

return p;
You would then modify your example to call that module (named Bob here for lack of a better name) this way:
<span class="languageicon">{{#invoke:Bob|lang_render|{{{1}}} }}</span>
—Trappist the monk (talk) 10:31, 20 June 2017 (UTC)[reply]

The consensus at Template talk:Link language was to remove all the special styling that other template used to have. So why do you want to add extre processing to this template to reintroduce special styling for language links? —David Eppstein (talk) 07:03, 20 June 2017 (UTC)[reply]

I don't want to reintroduce any special styling. I want to ensure that *if* any styling is introduced for one or another, they are introduced in both. 2A02:C7D:DA0A:DB00:7D59:CF97:3A02:EA20 (talk) 21:28, 20 June 2017 (UTC)[reply]
Thanks Trappist.
"Why interlock with unrelated templates?" It is true that {{link language}} is currently unrelated to cs1|2, but in my view that's a mistake. The consensus reached at language link favoured the reconciliation of what used to be two separate presentations of the exact same concept, i.e. the language of an external resource. With this change I seek to cement this consensus, so that any future changes to one or the other are applied to both. (In fact, I would favour the removal of the CSS class, because it currently does nothing by default, and I found no discussion about its introduction, anywhere. But that's another story.)
Thanks for the snippet, but actually I don't think it does what is required. The input to {{link language}} is a language code, and so we also need to look up the language name, just like cs1|2. How about the following, for maximum reuse
<span class="languageicon">{{#invoke:Citation/CS1|language_parameter|{{{1}}} }}</span> <!-- <<< Fix me please -->
There is unfortunately something wrong though, because this yields, for example, "Script error: The function "language_parameter" does not exist.". Perhaps it needs to be exported? Thanks for help.
Anyway, assuming we can make this work, here is my assessment:
  1. There is an extra space at the beginning of the string, but it will get collapsed in most uses of the template – in the recommended use anyway. If this is deemed unacceptable (rolleyes), we can work around it.
  2. As mentioned above, the function will add all transcluding articles to various categories. *If* this side effect is deemed undesirable (me, I think it's fine), we will need to refactor the function to separate the two concerns, which I would be happy to do.
  3. If the argument is the same as the site language, currently the template does show "(in English)". This differs from the cs1|2 behaviour. The documentation makes a good case for this use: "[if] there is a reason the reader would assume the link to be in a foreign language (e.g. a foreign title)". If extending this behaviour to cs1|2 is undesirable (would be interested to know why), and we want to keep the status quo for {{link language}}, it can be either special-cased in a {{link language}} wrapper like the one you were suggesting, albeit with some code duplication, or we could add an optional flag to the existing function to control this behaviour (my preference).
Anything I missed?
Cheers. 2A02:C7D:DA0A:DB00:B87F:E46F:7AF2:16AC (talk) 20:00, 21 June 2017 (UTC)[reply]
The purpose of the code snippet was to show how one might use the cs1|2 |language= parameter rendering in an unrelated template. It does work as intended if the {{{1}}} (which I took from your example) is replaced with a language name. I have put the module snippet in a sandbox Module:Sandbox/trappist the monk/bob. It works:
{{#invoke:Sandbox/trappist the monk/bob|lang_render|Spanish}} → Script error: The function "lang_render" does not exist.
From there it is a simple matter of using what {{link language}} already does to get this:
{{#invoke:Sandbox/trappist the monk/bob|lang_render|{{ISO 639 name es}}}} → Script error: The function "lang_render" does not exist.
Answering your individual points:
  1. where is the extra space? There is one at the end of my first template example but not at the beginning
  2. the cs1|2 categories shall not be used by {{link language}}; a couple of years ago I took the trouble of disentangling cs1|2 from the foreign-language external link categories so I stand opposed to allowing them to intermix
  3. cs1|2 only shows English as a source language in the rendered citation when it is one of a list of multiple languages but never when it is the only language
—Trappist the monk (talk) 22:38, 21 June 2017 (UTC)[reply]
Ah OK, I guess we could still use {{ISO 639 name xx}} (why is that template family not parametric??), but I think it would be a missed opportunity to reuse code for the lookup logic (including quirky cases such as the Bengali override), as well as the presentation. Current state is essentially code duplication, which I'm sure you know leads to poor maintainability and violates the principle of least astonishment for the user, which has to deal with two deceptively similar, but not identical interfaces and behaviours.
I don't know what your disentanglement work entailed, but from a Software Engineering standpoint sharing a common module/function and reusing it from multiple dependents should be encouraged and I don't see a problem. It can be done cleanly and effectively. Could you please elaborate on your concerns? I am happy to show you the refactoring I envisage if you are open to it.
Anyway, if we are to stick to presentation only, as an alternative to the Bob module, why not expose a wrapper for wrap_msg ('language', language_name), and reuse it in both cases? Thanks. 2A02:C7D:DA0A:DB00:2D9B:C031:27B7:C1C1 (talk) 07:02, 22 June 2017 (UTC)[reply]
I cannot say why the {{ISO 639 name xx}} templates are the way they are. It appears that there once was a move to convert some or all of the 1200-ish templates to a module but that seems to have never happened (see this discussion).
Language support in cs1|2 is not as great as you seem to think it is. For convenience, it uses the built-in MediaWiki language support which is limited in its scope but works in most cases.
The disentanglement was a code change and the creation of 180-ish categories in Category:CS1 foreign language sources. This change was appropriate because not all cs1|2 citations refer to on-line sources.
I am not enthusiastic about opening cs1|2 to use by unrelated projects which might get broken by changes made here. I am not enthusiastic about the prospect of cs1|2 maintainers being responsible for other projects which they will necessarily be were we to open cs1|2 as you desire.
—Trappist the monk (talk) 10:10, 23 June 2017 (UTC)[reply]
I don't see {{link language}} as "another project". There is more overlap than not. I am proposing to add it to the fold. Yes, the complexity of the Lua project will increase (marginally), but much better than having code duplication, and the overall entropy of Wikipedia will decrease. Anyway I guess I'll table this one for now and just bind the wording/styling. 2A02:C7D:DA0A:DB00:D104:5E1E:4FA4:87D7 (talk) 14:49, 23 June 2017 (UTC)[reply]

{{Skeptoid}}

Discussion has started to expand this template to display the author and to support a date. However, this template also accepts ordered parameters, although the documentation makes no mention of it. I wonder if there's an easy way to verify that no ordered-parameter usage exists (and to list these, if any). If there are none, it may also be best to not support ordered parameters anymore for this template. If there are, the date field would unfortunately be positioned after the accessdate one to not break existing usage (of course not affecting named parameter usage). The discussion started on the template's talk page and there is a working potential replacement in a sandbox that is linked there. Thanks, —PaleoNeonate - 00:40, 20 June 2017 (UTC)[reply]

This insource: search seems to indicate that there are none. Still, there are only a hundred-ish articles that use that template so it wouldn't be too onerous to add a snippet of code to the template that renders an error message when the template is used with positional parameters. Wait a few days and then search for the error message. Fix those templates and then remove support for positional parameters.
—Trappist the monk (talk) 01:12, 20 June 2017 (UTC)[reply]
Insource was what I was looking for, thank you very much. I also thought that to detect errors this way a category needed to be used, but it's also nice to know that error messages can be enough. I'll experiment with this idea in my sandbox. Thanks again, —PaleoNeonate - 01:38, 20 June 2017 (UTC)[reply]

 Done Thanks to Trappist the monk and Jonesey95, the template was successfully improved, errors also cause preview warnings and pages to be added to a category. —PaleoNeonate - 07:40, 22 June 2017 (UTC)[reply]

Use of dead-url for non-archived {{cite web}}

How do I mark a dead-url without an archive-url ?

I'm trying to mark the 2nd reference in the article Common moorhen as a dead link. I can't find an archive on Archive.org or webcite so don't have an archive-url. When I add dead-url=yes to the cite template nothing changes. I was expecting a dead-link marker to be displayed in the References section.

The dependancies for dead-url is listed as just 'url', but it actually seems to depend upon archive-url (and url and archive-date). Well, I don't get an error, but I don't get any effect either.

Platinke (talk) 10:29, 20 June 2017 (UTC)[reply]

I've tweaked your heading.
The cs1|2 templates do not provide the functionality you seek. To mark a citation's url as dead, use the template {{dead link}}. |dead-url= has a default value of yes. When set to no, it causes the template to select the value in |url= when linking the value in |title=; otherwise |title= is linked with |archive-url=.
—Trappist the monk (talk) 10:39, 20 June 2017 (UTC)[reply]

New tracking category needed

Can someone add a tracking category for "Id parameter with ISBN tempate"? Is that easy or requites extra coding? -- Magioladitis (talk) 06:22, 22 June 2017 (UTC)[reply]

Perhaps a clearer request: it may be useful to track usage of id = ISBN or id = {{ISBN in a maintenance category. Editors sometimes put redundant ISBNs in the |id= parameter. Redundant ISBNs can typically be removed with no harm, and ISBNs in the id= parameter without an ISBN present elsewhere in the citation template should probably be moved to |ISBN=. – Jonesey95 (talk) 06:47, 22 June 2017 (UTC)[reply]
Is it necessarily 'wrong' for cs1|2 templates to use |id= to hold isbns? This insource search finds less than 700 instances of |id={{isbn|...}} so it doesn't seem to be a widespread 'problem'. Certainly, as Editor Jonesey95 points out, redundant isbns in |id= can be removed. Are there not cases where a second, supplementary isbn would be appropriate?
@Magioladitis: I think that you need to explain why your requested change is necessary.
—Trappist the monk (talk) 11:49, 22 June 2017 (UTC)[reply]
Trappist the monk To track and fix. I would be OK with a list too. As said the cases should be checked manually. -- Magioladitis (talk) 12:04, 22 June 2017 (UTC)[reply]
If a list is all that you need, the insource search linked above should answer your requirement. Right?
—Trappist the monk (talk) 12:48, 22 June 2017 (UTC)[reply]
@Trappist the monk: Absent a dedicated |eISBN= (or functional equivalent) (see 1; I was sure there was another thread, but I can't find it now), adding supplementary ISBNs to |id= is a necessary safety valve. The prime example, that I thought I'd posted previously, being things like Cambridge Core, that publishes digital copies of print books. In most cases (at least for now) the print and digital versions are identical in all the ways that matter for citation purposes, but each has a separate ISBN (often called "eISBN" or "Online ISBN"; it's analogous to |eISSN=). In terms of citations, each are equivalent but there are two ways to access the same source. For instance, your institution (school, library, whatever) may not be able to afford the online service (they are expensive!), but have the print book in its collections. Or in my case, I have access to the online service through The Wikipedia Library, but my local uni library has a very limited selection of the reference works I need. --Xover (talk) 15:53, 22 June 2017 (UTC)[reply]
You should give only one ISBN: the one for the edition which you actually consulted. This has been discussed before, several times. --Redrose64 🌹 (talk) 20:45, 22 June 2017 (UTC)[reply]
You are, of course, entitled to your opinion. However, I suspect that in your reasoning you are conflating the number of ISBNs with the number of editions involved. When there are multiple valid ISBNs for the work cited, that have differing qualities unrelated to the verifiability of the cite (e.g. method of access; service provider; or similar), multiple ISBNs would make the citation more robust and verification more convenient (or, in some cases, possible at all; both desirable properties). --Xover (talk) 05:21, 23 June 2017 (UTC)[reply]
Having looked manually at many ISBNs while replacing the magic word with the template, I can say that it is not at all uncommon to see an ISBN in an id, or as a postscript to the template entirely, when there is another isbn using the isbn= parameter. The template really ought to reflect this common usage, rather than trying to change it. It's also common to add ISBNs to existing citations, when there is no way to tell which edition was originally consulted, of course. — Carl (CBM · talk) 20:49, 22 June 2017 (UTC)[reply]
If a citation lacks an isbn, find an edition that verifies the reference and add that edition's isbn. Citing more than one isbn is looking for trouble: "The purpose of the ISBN is to establish and identify one title or edition of a title from one specific publisher and is unique to that edition". From the FAQ at isbn.org [1]. Basically, a citation with more than one isbn obfuscates the cited edition. Multiple isbns in citations should be discouraged, and if present, removed. An allowance could perhaps be made for eISBNs if the content is exactly the same as the print version. But even there, there are issues with pagination etc. 72.43.99.146 (talk) 00:30, 23 June 2017 (UTC)[reply]
That's not how things work in practice, though. In practice, references are often added with no ISBN. Later in the article's development, someone looks up ISBNs for the works and adds them, as in [2]. It would be foolish to assume in any strong way that the ISBN in an article matches the version originally consulted, although in practice it seems to cause no problems for ISBNs to be added afterwards, because the other purpose of citations is simply to help readers find the references to learn more. I think it's a losing effort to try to educate every editor that they should manually verify every reference when they add an ISBN. Perhaps this is just another example of how the isolated discussions at these templates can fail to match the wider wiki - and another reason to consider not using citation templates. — Carl (CBM · talk) 00:49, 23 June 2017 (UTC)[reply]
In spite of my argument above (re to Redrose64), I disagree with your position here. One should not add an ISBN to a cite lacking it without reverifying the claim it supports, in which case you do not need multiple ISBNs, just the ISBN of the specific edition consulted. And you should certainly not change an existing ISBN without reverifying the claim. In these scenarios, having a single cite contain the ISBNs of multiple editions (which may in fact say the complete opposite of each other on the point cited!) is not just confusing but even plain wrong. That there are editors who do this in practice is not an argument for specifically supporting the practice in the implementation. Any argument for support of multiple ISBN must rest on the existence of multiple valid ISBNs that do not compromise verifiability (including WP:SAYWHEREYOUGOTIT).
@72.43.99.146: Pagination and other differences are an issue, sure, but much like reverifying claims when adding a missing ISBN, this is a reasonable responsibility to place on the editor to handle. For instance, I'm currently working with two examples: one is a simple PDF scan of a paper book (it is literally identical, except for the highly theoretical possibility of cosmic rays and scan error), and the other is a more complete digital version (HTML, selectable text, footnotes displayed in a popup on hover, etc.) but where the provider has taken pains to maintain pagination (they mark the page transitions from the paper version visually in the digital text). In both these cases, the paper and digital books are the same edition they just have different access methods. However, I also have a counter-example, in a third book I'm working with: the text of the print book is provided in modern form (selectable text etc. etc.), but original pagination from the print version is not preserved, making this a separate edition of the work. The latter case also has a separate "Online" publication date, and other signs that indicate it might be being independently updated, and so differ from the print edition in substantive ways. I would hesitate long, and consider well, before adding the "Online ISBN" of this latter case to the same citation as the print edition. These are, ultimately, up to editor discretion and judgement, to decide how to handle. --Xover (talk) 05:21, 23 June 2017 (UTC)[reply]

Part of URL is prepended to title. Possible regex bug?

I added a citation to an article just now, in this edit. As you can see if you look at the footnote it generated, part of the URL has been prepended to the article's title. I am guessing that this is due to the first double quote mark in the URL (as copied and pasted from the browser's address bar) being misinterpreted by the template as the first double quote mark delineating the start of the title.

I can't seem to find the source of the CS1 template anywhere, so cannot confirm my hunch. Please could someone reply with (a) a link to the CS1 template source, (b) a WP:PING to me, and (c) a fix for the issue, if possible. Thanks! zazpot (talk) 14:08, 26 June 2017 (UTC)[reply]

Not a cs1|2 problem but is a MediaWiki 'issue'. If I write the google books url and the book title as an external link:
[https://books.google.co.uk/books?id=HF4hAQAAMAAJ&dq="metrically+compatible"&hl=en&sa=X&ved=0ahUKEwiO8uy1xNvUAhUD6RQKHXllCyoQ6AEINTAH Monotype releases New Media Core Fonts]
I get:
"metrically+compatible"&hl=en&sa=X&ved=0ahUKEwiO8uy1xNvUAhUD6RQKHXllCyoQ6AEINTAH Monotype releases New Media Core Fonts
If I replace the double quotes with their percent encoding equivalents (%22):
[https://books.google.co.uk/books?id=HF4hAQAAMAAJ&dq=%22metrically+compatible%22&hl=en&sa=X&ved=0ahUKEwiO8uy1xNvUAhUD6RQKHXllCyoQ6AEINTAH Monotype releases New Media Core Fonts]
I get:
Monotype releases New Media Core Fonts
This is documented at Template:Cite magazine#URL.
—Trappist the monk (talk) 14:47, 26 June 2017 (UTC)[reply]
Apart from the technical explanation, the use of the URL is misleading: It doesn't seem to land the user on the article, the article title, or a contents page where the article is listed. We have to take it on faith that such article exists in volume 10 of this magazine. I would remove the URL altogether. 65.88.88.203 (talk) 15:00, 26 June 2017 (UTC)[reply]
I have to explain further: It is misleading because the pertinent info is in a search- result window. According to guideline, such links should be used only when necessary, and they should be expressly declared as query results. 65.88.88.203 (talk) 15:09, 26 June 2017 (UTC)[reply]

Module edit request: set(Quote)

I am asking here because apparently the talk page for the module internals redirects to the talk page for the style externals. Because dada, I guess.

Module:Citation/CS1 lns 3110-3116. set(Quote) is used to format |quote= and |postscript=.

I have noticed several instances in Chrome for Windows (versions 59.x and 58.x) where said function breaks the opening quotation mark from the quoted text. The markup-based workarounds (they do exist) are clumsy. Please add relevant no-wrap code between the opening quotation mark and the adjacent text. No-wrapping should be added after the closing quotation mark too, for the cases where the quote does not terminate. For style-conformance, a full-stop should be added right after the utilized template, and that stop might be left hanging. Thanks. 72.43.99.146 (talk) 00:55, 27 June 2017 (UTC)[reply]

Retrieved from "https://en.wikipedia.org/w/index.php?title=Help_talk:Citation_Style_1&oldid=787701712"