Help talk:Citation Style 1/Archive 34

This is an archive of past discussions. Do not edit the contents of this page. If you wish to start a new discussion or revive an old one, please do so on the current talk page.

In its present incarnation, {{

* {{cite encyclopedia
  |title=[[wikisource:fr:Dictionnaire universel d’histoire et de géographie Bouillet Chassang/Spenser (edmond)]]
<!-- |encyclopedia=A well known encyclopedia -->
}}

* {{cite encyclopedia
  |title=[[wikisource:fr:Dictionnaire universel d’histoire et de géographie Bouillet Chassang/Spenser (edmond)]]
|encyclopedia=A well known encyclopedia
}}

value = value:gsub ('<span class="nowrap" style="padding%-left:0%.1em;">&#39;(s?)</span>', "'%1");	-- replace {{'}} or {{'s}} with simple apostrophe or apostrophe-s

Line 177 in

'}} and {{'s

}} templates are part of a cs1|2 parameter value because we don't want all of that extraneous html and css in the metadata.

The bug you found is in the function kern_quotes() in Module:Citation/CS1. There, the ‘ and ’ characters (U+2018 & U+2019) are replaced with simple typewriter quotes, perhaps a bit overzealously. I've tweaked the sandbox to limit that replacement so that only those curly quotes that are the first and last characters to the title are replaced:

{{cite encyclopedia/new |title=[[wikisource:fr:Dictionnaire universel d’histoire et de géographie Bouillet Chassang/Spenser (edmond)]] |encyclopedia=A well known encyclopedia}}

"fr:Dictionnaire universel d'histoire et de géographie Bouillet Chassang/Spenser (edmond)" . A well known encyclopedia.

Your example that 'worked', worked because the title is not rendered in quotes; it was instead rendered in italics. Kerning is only applied to titles that the cs1|2 templates wrap in quote marks.

—Trappist the monk (talk) 13:55, 25 May 2017 (UTC)

When I was trying to understand the example, I was distracted by what I perceived as errors in writing the citation. Maybe the following would be less distracting:

* {{cite encyclopedia |title=[[wikisource:fr:Dictionnaire universel d’histoire et de géographie Bouillet Chassang/Spenser (edmond)| SPENSER (Edmond)]] |encyclopedia = Dictionnaire universel d'histoire et de géographie | last1 = Bouillet | first1 = Marie-Nicolas | last2 = Chassang | first2 = Alexis }}

• Bouillet, Marie-Nicolas; Chassang, Alexis. "SPENSER (Edmond)" . Dictionnaire universel d'histoire et de géographie.

As in PBS's report, Wikisource can't find the article. Note that I intentionally changed the curly single quote (used as an apostrophe) to a straight quote in the encyclopedia parameter. Jc3s5h (talk) 14:35, 25 May 2017 (UTC)

The problem is that it can not easily be solved with redirects on Wikisource because as with this book, the will be hundreds subpages under the main page for many Wikisource sources. See for example:

• wikisource:fr:Dictionnaire universel d’histoire et de géographie Bouillet Chassang/Index alphabétique - A

This also affects links into sections within a page where, unlike Wikipedia, Wikisouce often uses ‘’ “” so potentially we have a problem that to access a section on Wikisource an ASCII single quote 's would be needed in the section header even though the rest of the text uses ’s. -- PBS (talk) 16:40, 25 May 2017 (UTC)

" I've tweaked .. those curly quotes that are the first and last characters to the title are replaced". Given that the links can be to sections this might not be sufficient as like this one s:1911 Encyclopædia Britannica/Great Rebellion#The "Crowning_Mercy" it is possible that a funny quotation mark may be at the end of a title string (or at least before a | or a ]]) — this particular example has been hacked to use strait double quotes in the anchor, but the text has a pair of “”.

This explains why a link using {{cite EB1911}} fails on trying to link to that section, but does link to the one immediately before it.

• "Great Rebellion#The "CrowningMercy"" . Encyclopædia Britannica (11th ed.). 1911.N
• "Great Rebellion#Campaign of Worcester" . Encyclopædia Britannica (11th ed.). 1911.Y

-- PBS (talk) 17:04, 25 May 2017 (UTC)

First things first: the reason that your {{cite EB1911}} example does not work has nothing to do with any kind of quotes. The link doesn't work because a space (or underscore) is missing from between 'Crowning' and 'Mercy'. If I rewrite that example as:

{{cite EB1911|short=x|wstitle=Great Rebellion#The "Crowning Mercy"}}

"Great Rebellion#The "Crowning Mercy"" . Encyclopædia Britannica (11th ed.). 1911.

the link works and takes me to the proper place in the wikisource text.

Now quotes and kerning. cs1|2 renders certain titles inside double quote marks. Sometimes titles, especially news article titles, contain single or double quote marks: Alien abduction survivor: 'They've got Elvis!' Without kerning, the terminal quote mark in my example would be placed directly adjacent to the trailing double quote mark applied by the cs1|2 template; kerning inserts a small amount of space so that the two quote marks can be distinguished. When I originally wrote the kerning code, I deferred support for wikilinked title text that cs1|2 would render in quotes because, in general, there is relatively little need for linking to en.wiki articles about a chapter or news article (if there are any such articles). Of course that ignores interwiki links to WikiSource among others.

The problem with wikilinked quoted title text is that kern_quotes() is looking for a single or double quote mark as the first and/or last character in the title text. With wikilinks, the wiki markup gets in the way and there are two forms of wikilink. For the time being, and until I noodle out an appropriate solution, for wikilinks like the first example below, kern_quotes() shall do nothing because there is no 'label' for that link. In the second example, because there is a label, kern_quotes() does insert the space to separate quote marks:

I have restored the curly quote replacement code because kerning shall not be applied to the link portion of a wikilink. The example above, uses curley quotes in the label part of the wikilink. The example below shows that even with the curley quote replacement code restored, the link to wikisource works:

—Trappist the monk (talk) 17:15, 26 May 2017 (UTC)

The sandbox version of the first "Crowning Mercy" example now has properly kerning.

—Trappist the monk (talk) 19:39, 26 May 2017 (UTC)

Sorry for the mistake, and thanks for pointing it out. "kerning" is nice to have, however not having it is not a show stopper. How soon can the fix to access to "wikisource:fr:Dictionnaire universel d’histoire et de géographie Bouillet Chassang/Index alphabétique - A" be available in production? -- PBS (talk) 12:25, 28 May 2017 (UTC)

I have made an interim change to the live module that permits:

{{cite encyclopedia |title=[[wikisource:fr:Dictionnaire universel d’histoire et de géographie Bouillet Chassang/Spenser (edmond)]] |encyclopedia=A well known encyclopedia}}

"fr:Dictionnaire universel d'histoire et de géographie Bouillet Chassang/Spenser (edmond)" . A well known encyclopedia.

Kerning in this live version is still broken.

—Trappist the monk (talk) 13:38, 28 May 2017 (UTC)

Thanks for the improvement. -- PBS (talk) 09:18, 29 May 2017 (UTC)

Why there is only one category (for first language) added when there are two or more languages entered in para |language=? --Obsuser (talk) 03:03, 3 June 2017 (UTC)

Please link to an example article when raising questions like this. Thanks. – Jonesey95 (talk) 05:10, 3 June 2017 (UTC)

Good catch. Because of an oversight on the part of the programmer. The function add_prop_cat() has a primary purpose of preventing the addition of multiple duplicate categories of the same kind at the end of the rendered citation. When there are multiple languages in |language=, add_prop_cat() receives one of two key values: foreign_lang_source or foreign_lang_source_2. If add_prop_cat() has never seen these keys previously while processing |language=, then the property category is added to the list. Once seen, no more of that kind of property cat will be added.

I have modified language_parameter() append the ISO 639 language code to the property's key to make each key language specific and add_prop_cat() to remove the code for rendering. If you copy this:

{{code|{{cite book/new |script-title=he:Title |language=sr, he, Old English, es, fr, Delaware}}}}

and paste it into article space and click Show preview (don't save) you should see this:

<cite class="citation book"> <bdi lang="he" >Title</bdi> (in Serbian, Hebrew, Old English, Spanish, French, and Delaware).</cite><span title="ctx_ver=Z39.88-2004&rfr_id=info%3Asid%2Fen.wikipedia.org%3AFrank+Speck&rft.btitle=Title&rft.genre=book&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Abook" class="Z3988"><span style="display:none;"> </span></span>[[Category:CS1 uses Hebrew-language script (he)]][[Category:CS1 Serbian-language sources (sr)]][[Category:CS1 Hebrew-language sources (he)]][[Category:CS1 foreign language sources (ISO 639-2)|ang]][[Category:CS1 Spanish-language sources (es)]][[Category:CS1 French-language sources (fr)]][[Category:CS1 foreign language sources (ISO 639-2)|del]]

I think that there is a slightly better way to do this and will pursue that idea a bit later.

—Trappist the monk (talk) 12:07, 3 June 2017 (UTC)

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

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)

I am finding myself in a little edit war with

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)

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)

OK thanks for that background and analysis of this link. I will self-revert. Jytdog (talk) 03:55, 8 June 2017 (UTC)

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)

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

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)

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)

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)

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)

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)

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)

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)

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)

My reply was to the OP. The OP also said "apparently". Boghog (talk) 04:08, 13 June 2017 (UTC)

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)

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)

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)

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)

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)

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)

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)

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

I'm trying to mark the 2nd reference in the article

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)

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)

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)

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)

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)

 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)

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)

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)

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)

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)

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)

@

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)

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)

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)

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)

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)

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)

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

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)

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)

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)

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)

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)

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)

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)

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, "{{#invoke:Citation/CS1|language_parameter|es }}". 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)

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}} → {{#invoke:Sandbox/trappist the monk/bob|lang_render|Spanish}}

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}}}} → {{#invoke:Sandbox/trappist the monk/bob|lang_render|{{ISO 639 name|es}}<!-- Spanish -->}}

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)

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)

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)

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)

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

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)

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)

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)

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)

Real life examples of this condition please? Is it 'broken' on other browsers? What markup-based workarounds?

—Trappist the monk (talk) 03:14, 27 June 2017 (UTC)

I assume that line-breaks as I am describing could happen in all browsers given the right conditions, but I have only observed it with Chrome. Very hard to reproduce because it depends on any of the following: physical screen size/virtual screen size/resolution/font rendering engine/font size/text size. But it does happen. Even if it did not, code should be there that prevents line breaks right after the prepended opening quotation mark and also around the prepended closing quotation mark. That's just good programming, and is easy to do. The workarounds that work add (no-wrap) wiki-template code or html code in the variable field. Ugly. 72.43.99.138 (talk) 13:55, 27 June 2017 (UTC)

Very hard to reproduce because it depends on all of those things; how then to know what it is that needs fixing if indeed fixing is required or possible? That is why I asked for a real life example.

I think that I can contrive an example by writing:

{{cite book |title=Title |quote=Loremipsumdolorsitametconsecteturadipiscingelitseddoeiusmodtemporincididuntutlaboreetdoloremagnaaliqua.}}

and pushing it right a long ways by inserting a continuous string of characters ahead of it. Then, adjust browser window size to see how it wraps.

qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqTitle. Loremipsumdolorsitametconsecteturadipiscingelitseddoeiusmodtemporincididuntutlaboreetdoloremagnaaliqua. 

When I narrow the browser window the entire quote with its quotation marks wraps to the next line. As I continue to narrow the display individual characters wrap one at a time to the next line. I'm guessing that this is your complaint. If so, that happens because all rendered cs1|2 citations have the class "citation". That class has word-wrap: break-word; as one of its properties. I suspect that this property is set this way to support {{reflist}} columns; an unbreakable string of characters would disrupt even columnar display. I could, of course be wrong about this.

—Trappist the monk (talk) 15:34, 27 June 2017 (UTC)

Amongst many other things. People's obsession with not breaking text is really getting a bit out of hand. I'm finding more and more "no-wrap" all over the place. That is BAD. no-wrap is only supposed to be used for very limited pieces of text, in very limited set of cases. By using it all over the place, editors are messing with the flexibility of HTML to dynamically size and position elements, causing problems for mobile, columns, infoboxes etc... Trust the browser to do it as good as possible, and just live with the fact that HTML doesn't deliver perfection, but always DOES deliver. —TheDJ (talk • contribs) 18:45, 27 June 2017 (UTC)

Why are you attacking me? I have made no statement suggesting that this 'issue' can or should be 'fixed'. All I have done is attempt to explain what it is that I think IP editor is complaining about.

—Trappist the monk (talk) 18:58, 27 June 2017 (UTC)

I'm not attacking you, i was making a general statement. —TheDJ (talk • contribs) 06:01, 28 June 2017 (UTC)

To reiterate, this is about hanging quote marks. I noticed rare instances of something like this in citations that employ |quote=:

• [some citation fields]. "

[Quote text]".

And also,

• [some citation fields]. "[Quote text]

".

I didn't realize that fixing this by non-wrapping is so controversial.

Bah!! 100.12.209.91 (talk) 00:09, 28 June 2017 (UTC)

OK, let's not all get worked up. This last description fits the rendering I see when I shrink my window and see what it does to Trappist's citation template with a quote in it. If I shrink the window just right, I can see the single quotation mark after the period being wrapped to the next line, all by itself, as in the second example immediately above.

I view such wrapping, as in the example immediately above, as improper. You would never see such wrapping in a print publication, or even, ideally, on the web. A quotation mark at the beginning of a quotation or title should be stuck to the subsequent character, and a quotation mark at the end of a quotation or title should be stuck to the preceding character. Is it possible to make those quotation marks "stick" to the text immediately adjacent? We don't want to "nowrap" the whole quotation, just the quotation mark and the element immediately following (or preceding, for a terminating quotation mark) it. – Jonesey95 (talk) 05:29, 28 June 2017 (UTC)

They are not improper, non-ideal perhaps. You have long words and lines, that you are forcing the browser to wrap into multiple lines. It has to break it somewhere, so it breaks at the spot where it is least damaging. It's perfectly normal, as a matter of fact, it's all determined by the unicode line breaking algorithm (my texteditor on my desktop breaks it exactly the same). Anyway, the point is. You shouldn't have print type setting expectations on the web. —TheDJ (talk • contribs) 06:35, 28 June 2017 (UTC)

Examining the bit above that follows the sentence "Then, adjust browser window size to see how it wraps." I find that it is

<dd>qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq<cite class="citation book"><i>Title</i>. <q>Loremipsumdolorsitametconsecteturadipiscingelitseddoeiusmodtemporincididuntutlaboreetdoloremagnaaliqua.</q></cite><span title="ctx_ver=Z39.88-2004&amp;rfr_id=info%3Asid%2Fen.wikipedia.org%3AHelp+talk%3ACitation+Style+1&amp;rft.btitle=Title&amp;rft.genre=book&amp;rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Abook" class="Z3988"><span style="display:none;">&nbsp;</span></span></dd>

so the quote marks aren't produced by us, nor is there anythibg that nowrap could sensibly be applied to. The quotemarks are an inherent part of the <q>...</q> element, they aren't physically there (you can test this by copypasting the rendered text qqqqTitle. Loremipsumdolorsitametconsecteturadipiscingelitseddoeiusmodtemporincididuntutlaboreetdoloremagnaaliqua. When I narrow). My experience is that it is wrapped before the first quotemark by my browser (Opera 36). It seems to me that this is variation between browsers, and so largely outside our control: you would need to request your browser vendor for an enhancement. --Redrose64 🌹 (talk) 08:38, 28 June 2017 (UTC)

And yet user markup (either   or the html tag) at the beginning and/or end of the quoted text rectifies this. So something can be done, clumsily. I would add that this has nothing to do with typesetting; this is about the integrity and readability of the citation. Readers should be able to see at a glance where quoted text begins or ends. Hanging quote marks could make the citation easier to misread. 65.88.88.196 (talk) 13:18, 28 June 2017 (UTC)

Are you sure? I've added   to my example above (between the dot and the }}). If what you suggest is working, then one should expect, when carefully narrowing the browser window, that the dot and the quote mark will wrap simultaneously. Instead, they wrap individually; even the   character wraps individually. That result is not surprising to me given that the word-wrap: break-word; property forces the browser to break lines on character boundaries when it can't break them on word boundaries.

—Trappist the monk (talk) 13:51, 28 June 2017 (UTC)

I will try to recreate this with the exact configuration in place when I first saw the problem (I am at a different machine now). I believe I also used {{

nbsp}}. I will post the exact configuration when I am at that machine. 65.88.88.126 (talk

) 13:59, 28 June 2017 (UTC)

The pertinent configuration, per above: Windows 7 pro 32 bit. Radeon 6350 display adapter, v. 8.830, @ 1440x900 resolution. DELL E1911 display, DVI input at 16:9 aspect ratio (native). Chrome v. 58.0.3029.11. Wikipedia window maximised to cover entire screen. I wish I could remember offhand the pages I saw the hanging quotes, but I don't. 24.105.132.254 (talk) 22:09, 28 June 2017 (UTC)

Addendum: also, native fonts only, Windows native font renderer. 24.105.132.254 (talk) 22:14, 28 June 2017 (UTC)

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)

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)

@Jonesey95: That was what sparked my suggestion: instead of making it look like the "official URL" for a book is at Google Books, providing |googleid= would allow a separate link to be displayed using the same logic as {{Google books|plainurl}} and reduce the editing clutter. —Phil | Talk 12:10, 29 June 2017 (UTC)

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)

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

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)

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)

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)

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

C

17:17, 8 June 2017 (UTC)

@

GreenC: "Plain text literal URLs" are horrible for at least two reasons: you need a bot to update them if the target website decides to alter the URL format, and people are prone to simply copy whatever is currently in their URL bar regardless of whatever ridiculous tracking parameters, etc, might be cluttering it up. —Phil | Talk

12:16, 29 June 2017 (UTC)

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)

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)

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)

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)

Some of you may be interested in a discussion on meta-wiki on making some templates, or the Lua modules behind them, work globally (i.e. across all Wikimedia projects). Citation templates have, naturally, been raised as one possible subject. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 11:48, 1 July 2017 (UTC)

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)

Agree I think it's a great idea. Sam Wilson 02:34, 4 June 2017 (UTC)

We should most definitely not draw citation data from wikidata. This is no different than putting data on {{

b

} 13:51, 10 June 2017 (UTC)

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)

My concerns also. And I concur with Headbomb's comment. ~ J. Johnson (JJ) (talk) 20:09, 11 June 2017 (UTC)

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)

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)

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)

And then there are cases like The Plays of William Shakespeare (1765) by Samuel Johnson: a work that has its own Wikipedia article, and hence its own Wikidata ID, which can be used to connect the two even in the absence of an explicit wikilink in |title=. Not a perfect example as our article actually deals with multiple editions of that work, where the wikidata item must be for a single edition, but the general point stands. In citations, more identifiers are generally better; and regardless of any effort for fancy citation integration with Wikidata (which idea I'm significantly ambivalent about), one can view Wikidata as another database of bibliographic data analogous to Worldcat (but better, in many ways, because the data in Worldcat is crap and cannot, in practice, be improved). --Xover (talk) 11:36, 1 July 2017 (UTC)--

Indeed. So can we now do this? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 11:52, 1 July 2017 (UTC)

Citation management tool Zotero now has a Wikidata translator. Not only does it read metadata from Wikidata items about works, so you can add them to your Zotero library, but it can export metadata in a format understood by QuickStatements, enabling users to more easily create Wikidata items about the works already in their Zotero libraries. Since Zotero can already read metadata about works from other websites, or data files such as BibTeX and COinS, it can now be used as an intermediary to import that data. The translator was developed at the recent WikiCite event in Vienna. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 11:03, 6 July 2017 (UTC)

What is the first version number of Zotero to support this feature? Jc3s5h (talk) 12:32, 6 July 2017 (UTC)

Shouldn't the reference to ISBN be changed from isbn=xxx to {{ISBN xxx? I realize that this is change is going to generate a lot of server load, but what's to be done? I certainly am not going to try anything of this magnitude myself. Just asking. TomS TDotO (talk) 11:21, 7 July 2017 (UTC)

No, that would be counterproductive. --Redrose64 🌹 (talk) 11:29, 7 July 2017 (UTC)

Please explain. TomS TDotO (talk) 11:44, 7 July 2017 (UTC)

@TomS TDotO: Why do you think this would be a good change? It might help if you explained why you think this is a good idea, so that we can help correct some incorrect belief you hold. --Izno (talk) 12:27, 7 July 2017 (UTC)

As I understand things, it is now the standard way of giving the ISBN number to use the ISBN template. If one uses the parameter isbn= there is a bot which will change it. TomS TDotO (talk) 12:35, 7 July 2017 (UTC)

Can you show where a bot is changing |isbn= in cs1|2 templates. If there is a bot doing this, it must be stopped.

—Trappist the monk (talk) 12:42, 7 July 2017 (UTC)

The bots doing the conversion are catching ISBN usage in |id=. --Izno (talk) 12:50, 7 July 2017 (UTC)

Everything that the {{ISBN|123456789X}} template does, is done by cs1|2 when you write |isbn=123456789X. In fact, code that originated in cs1|2 is now used in the {{ISBN}} template. In cs1|2 templates, all parameters are named so you can't use the unnamed parameter construct |{{ISBN|123456789X}}. You can, but probably shouldn't, use |id=|{{ISBN|123456789X}} if there is a second ISBN (a second ISBN usually implies a second source and cs1|2 templates are single-source only).

Using |isbn={{ISBN|123456789X}} is bad because the {{ISBN|123456789X}} template drags in a whole lot of wiki markup that just confuses the MediaWiki parser and corrupts the cs1|2 template's metadata:

{{cite book |title=Title |isbn=123456789X |id={{ISBN|123456789X}}}}

Title.

ISBN 123456789X|'"`UNIQ--templatestyles-0000006C-QINU`"'[[ISBN (identifier)|ISBN]]&nbsp;[[Special:BookSources/123456789X |123456789X]]]]. {{cite book}}: Check |isbn= value: invalid character (help); templatestyles stripmarker in |isbn= at position 1 (help

)

The purpose of the {{ISBN}} template is to be a replacement for the plain-text magic link which will be going away. cs1|2 never used the magic link capabilities so have no reason to use the {{ISBN}} template.

—Trappist the monk (talk) 12:40, 7 July 2017 (UTC)

"code that originated in cs1|2 is now used in the {{ISBN}} template" Shouldn't {{ISBN}} and cs1|2 call a single, common, Module:ISBN (or whatever it would be called)? Or am I missing something? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 23:29, 8 July 2017 (UTC)

{{Cite journal |last1=Shea |first1=Christopher |title=A Radical Anthropologist Finds Himself in Academic 'Exile' |journal=[[Chronicle of Higher Education]] |volume=59 |issue=32 |pages=A14–A15 |date=2013-04-19 |url=http://www.chronicle.com/article/A-Radical-Anthropologist-Finds/138499/ |issn=00095982 |via=[[EBSCOhost]] |df=mdy-all }}

• Shea, Christopher (April 19, 2013). "A Radical Anthropologist Finds Himself in Academic 'Exile'".
  EBSCOhost
  .