Help talk:Citation Style 1

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)

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 {{cite doi}} subpages Too much potential for things to go wrong. Headbomb {t · c · p · 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)

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)

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)

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)

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)

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

Consistent language style for {{Link language}}

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

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, "". 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}} →

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}}}} →

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)

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

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)

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)

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)

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

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

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)

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)

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)

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 {{nowrap}} (around the first character of the quote) and {{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)

Bug when title ends with single quote

{{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'". Chronicle of Higher Education. 59 (32): A14–A15. ISSN 0009-5982 – via EBSCOhost.

Add |url-access=subscription:

• Shea, Christopher (April 19, 2013). "A Radical Anthropologist Finds Himself in Academic 'Exile'". Chronicle of Higher Education. 59 (32): A14–A15. ISSN 0009-5982 – via EBSCOhost.

I.e., title displays as "A Radical Anthropologist Finds Himself in Academic 'Exile<span style="padding-right:0.2em;">'"

(Not watching—please {{ping}} me with your responses.) czar 16:23, 29 June 2017 (UTC)

This discussion may be related. If the CS1 module calls Module:URL, the fix for both problems might be to modify that module. This is pure speculation, but it looks similar. – Jonesey95 (talk) 19:09, 29 June 2017 (UTC)

Not the same problem because cs1|2 does not use Module:URL.

Our problem is a conflict between the need to kern quote marks and the need to prevent the access signal from wrapping to the next line. In this simpler example you can see how we kern the opening quote mark. The closing quote mark is supposed to be similar but the access signal no-wrapping (which occurs later) interferes:

{{Cite journal |title='Title' |url=http://www.example.com |url-access=subscription}}

"'Title'". {{cite journal}}: Cite journal requires |journal= (help)

'"`UNIQ--templatestyles-00000041-QINU`"'<cite class="citation journal cs1"><span class="id-lock-subscription" title="Paid subscription required">[http://www.example.com "<span class="cs1-kern-left"></span>'Title'<span class="cs1-kern-right"></span>"]</span>.</cite><span title="ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Ajournal&rft.genre=article&rft.atitle=%27Title%27&rft_id=http%3A%2F%2Fwww.example.com&rfr_id=info%3Asid%2Fen.wikipedia.org%3AHelp+talk%3ACitation+Style+1" class="Z3988"></span> <span class="cs1-visible-error citation-comment"><code class="cs1-code">{{[[Template:cite journal|cite journal]]}}</code>: </span><span class="cs1-visible-error citation-comment">Cite journal requires <code class="cs1-code">&#124;journal=</code> ([[Help:CS1 errors#missing_periodical|help]])</span>

I'll think on it.

—Trappist the monk (talk) 19:54, 29 June 2017 (UTC)

I think I have a fix; not pretty, but I think it works. There are several kerning conditions that we need to worry about. These only apply to quoted titles (journal article, website titles, etc):

1. multi-word titles:
   1. title has leading and trailing quote marks:

      {{cite journal/new |title='multi-word title' |url=//example.com |url-access=registration}}

      "'multi-word title'". {{cite journal}}: Cite journal requires |journal= (help)

   2. title has trailing quote mark:

      {{cite journal/new |title=multi-word 'title' |url=//example.com |url-access=registration}}

      "multi-word 'title'". {{cite journal}}: Cite journal requires |journal= (help)

   3. title has leading quote mark (not an issue but proof that this form isn't broken):

      {{cite journal/new |title='multi-word' title |url=//example.com |url-access=registration}}

      "'multi-word' title". {{cite journal}}: Cite journal requires |journal= (help)

2. single-word titles:
   1. title has leading and trailing quote marks:

      {{cite journal/new |title='title' |url=//example.com |url-access=registration}}

      "'title'". {{cite journal}}: Cite journal requires |journal= (help)

   2. title has trailing quote mark:

      {{cite journal/new |title=title' |url=//example.com |url-access=registration}}

      "title'". {{cite journal}}: Cite journal requires |journal= (help)

   3. title has leading quote mark:

      {{cite journal/new |title='title |url=//example.com |url-access=registration}}

      "'title". {{cite journal}}: Cite journal requires |journal= (help)

and OP's original:

Shea, Christopher (April 19, 2013). "A Radical Anthropologist Finds Himself in Academic 'Exile'". Chronicle of Higher Education. 59 (32): A14–A15. ISSN 0009-5982 – via EBSCOhost.

—Trappist the monk (talk) 13:44, 9 July 2017 (UTC)

Question on the use of the "language" field

Recently I've been running across instances (in English Wikipedia) of the language field being used to denote that the source is in English. E.g., "|language=english-US" and "|language=eng-GB". Is this (now) recommended? To me it seems redundant, that the field should be used to denote non-English sources. Comments? —DocWatson42 (talk) 09:36, 1 July 2017 (UTC)

Commonly an artifact of VisualEditor. cs1|2 does not render the language parameters when the only language specified in |language= is the language of the local wiki. So at en.wiki, |language=en or |language=English does not render. At one time, cs1|2 emitted an error message but because so many cs1|2 citations are exported to other wikis |language=en will be rendered and may be helpful to readers and editors there. Adding |language=en is neither recommended nor discouraged.

cs1|2 does not recognize the two examples that you give. The form for languages that cs1|2 recognizes is <ISO 639-1 code><hyphen><ISO 3166 alpha 2 country code> so: en-US, en-GB. I found and fixed four |language=eng-US but found none of the |language=eng-GB or |language=english-XX form.

—Trappist the monk (talk) 11:20, 1 July 2017 (UTC)

See also Help talk:Citation Style 1/Archive 30#Misuse of language parameter. --Redrose64 🌹 (talk) 13:30, 1 July 2017 (UTC)

Globalised templates

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)

Book edition vs series edition

When both |series and |volume are specified in a book citation, it can give the impression that the edition pertains to the series name, rather than the book itself, as in:

Book Title. Book Series (4th ed.)

Is there a reason why this format is preferable to placing the edition between the book title and the series name? E.g.,

Book Title. (4th ed.) Book Series.

—Ringbang (talk) 22:52, 3 July 2017 (UTC)

I have no opinion really. I will just note that the current templates render in the same way that the old templates did so the ordering decision predates the Lua implementation:

Cite book comparison

Wikitext	{{cite book|edition=4th|series=Book Series|title=Book Title}}
Live	Book Title. Book Series (4th ed.).
Sandbox	Book Title. Book Series (4th ed.).

—Trappist the monk (talk) 00:53, 4 July 2017 (UTC)

Book series do appear in new editions, with new identifiers. Regularly, [volume edition]=[series edition]. Conceivably, editions of individual volumes could differ from the overall series edition, but I would think this would be rare, perhaps too rare to justify changes in code. 72.43.99.138 (talk) 13:04, 6 July 2017 (UTC)

I agree with 72's conclusion, but will note stuff like The Arden Shakespeare (the series) that is currently in its third series (the series edition), where individual books in the series have multiple editions (sometimes with significant changes, like their latest edition of The Tempest). It leads to slightly awkward workarounds like concatenating the series and the series edition and using the result as the |series=The Arden Shakespeare, third series to free up |edition= for the volume edition. It's a minor issue. Slightly more annoying, but still very minor, are books with multiple volume numbers. For instance, a specific reference work published in four volumes, that also happens to belong to a series of related reference works where each overall work has a series volume number. Or works which belong to multiple series, but is a different volume in each series (one is perhaps a subset of the other: Cambridge Companions to Literature, v. 123 and Cambridge Companions to Shakespeare, v. 4). None of these issues are worth expending code over, unless it happens as part of some larger generalization of the code which happens to allow for such things to be handled where needed as a side effect. I'd be all for it, except I don't think publishers are sufficiently consistent in their usage for it to be possible to handle in any sensible way in these templates. --Xover (talk) 13:27, 6 July 2017 (UTC)

@72.43.99.138: Could you list the examples you found of series that have editions? They could make for useful test cases. After considering any test cases and the ambiguity of the current parameter order, template maintainers can assess the level of effort and the regression risk of swapping the placement of these two parameters. Trappist the monk, if you're in a position to comment on LoE and risk, that would be helpful. —Ringbang (talk) 18:14, 9 July 2017 (UTC)

Minimal for both. The most difficult task is yours: convincing others that your proposed change is worth the doing.

—Trappist the monk (talk) 00:43, 10 July 2017 (UTC)

Offhand, I cannot list any examples, but I believe Xover presented some. AFAIK series volumes normally have individual ids (ISBNs) in addition to (or in the absence of) a series ISBN (or ISSN). For citation purposes, an editor can use the volume ISBN. The series info would then be a convenience. Obviously in rare (I think) cases a series may need to be cited. In that case the series identifier and edition are pertinent. None of these cases needs any changes in code, imo. 72.43.99.138 (talk) 14:43, 11 July 2017 (UTC)

The primary raised I raised the issue was that placing the edition number after the book title, rather after than the series name, seems the clearest, most conventional place for this information. Since the cost to implement is negligible, the question becomes: Is there any reason to prefer putting the edition after the series name? If we were designing this template for the first time, which would we choose? If there is no reason to prefer the post-series placement, and since the improvement is so simple and devoid of risk, why not do it? —Ringbang (talk) 15:07, 11 July 2017 (UTC)

In principle, I agree. It would be a small if …then … else routine as in the following pseudocode:

If exist book-ed. show after book-title

else

If exist series-ed. show after series-title

Assuming a proper identifier is present, do you agree that citing both a book edition and series edition would be redundant? 65.88.88.214 (talk) 17:16, 11 July 2017 (UTC)

Note that the above was proposed without examining that area of the code. For all I know there may be dependencies. 65.88.88.214 (talk) 17:18, 11 July 2017 (UTC)

There is no conditional logic. The |edition always applies to the book and never to the series. That's the way the template works now, and that's the way it would continue to work. Only the sequence changes, for clarity and to agree with convention. If a series has a salient edition number that differs from the publication edition, that number can be included with the series name in the |series parameter. I don't advocate a "series edition" parameter. —Ringbang (talk) 17:59, 11 July 2017 (UTC)

Ok, your proposal makes sense to me. 65.88.88.126 (talk) 13:03, 12 July 2017 (UTC)

Zotero now has a Wikidata translator

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)

e-book location

How do I cite an e-book with locations instead of page numbers? citing e-book got redirected to citing book, but I can't find any format for putting in location= instead of p= or pp=

Marcus Pedersen (talk) 23:41, 6 July 2017 (UTC)

|at= might work. Such documentation as there is for that parameter is at Template:Cite book#In-source locations.

—Trappist the monk (talk) 00:14, 7 July 2017 (UTC)

I tried that but it didn't work:

Comes up as in the notes: 1.^Title 2017.

Whereas comes up 1.^ Title 2017, p. 5189.

I would like the end result to look more like this: 1.^ Title 2017, loc. 5189.

@Marcus Pedersen: {{sfn}} isn't strictly a CS1 template, per se. Instead of |At= 5189 or |p= 5189 try |loc=loc. 5189, which would give you:

That should work for you. Imzadi 1979 → 01:17, 11 July 2017 (UTC)

Yes that works very well, thank you! Marcus Pedersen (talk) 01:50, 11 July 2017 (UTC)

References

ISBN

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 [[Special:BookSources/ISBN 123456789X|'"`UNIQ--templatestyles-00000068-QINU`"'[[ISBN (identifier)|ISBN]]&nbsp;[[Special:BookSources/123456789X |123456789X]]]]. {{cite book}}: Check |isbn= value: invalid character (help); Unknown parameter |no-cat= ignored (|no-tracking= suggested) (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)

script-title needs error message

If a cite only contains a |script-title=, without |title= or |trans_title=, should we get an error message that either |title= or |trans_title= is missing from the reference as there should always be an English translation of the title.

Thus I would have expected an error from the following -

{{cite news|script-title=英投资方决定成都谢菲联不出售 尽快解决欠薪稳军心|url=http://sports.sina.com.cn/s/2010-12-09/06071693872s.shtml}}

Keith D (talk) 00:19, 10 July 2017 (UTC)

There is no rule requiring an English translation of the German |title=Die Zauberflöte. Why then should there be a rule requiring an English translation for |script-title=zh:英投资方决定成都谢菲联不出售 尽快解决欠薪稳军心? The purpose of |script-title= is to render non-Latin scripts without italics and to correctly handle those scripts that are written right-to-left. I have thought that cs1|2 might emit an error message when |script-title= is missing its language code.

—Trappist the monk (talk) 00:41, 10 July 2017 (UTC)

Regnal numbering (Roman numerals) in names

Documentation:

first: Given or first names of author; for example: ... Firstname M., Sr.

Doesn't it screw up the metadata to put Jr., Sr., II, III, etc. into the "first" param? Or is it automatically trimmed out and reformatted? If the latter, would be nice to note in the documentation.  czar 18:34, 10 July 2017 (UTC)

Are you asking about generational suffixes or regnal numbers? I'm not sure that the two are the same thing.

COinS has a a keyword for generational suffixes: rft.ausuffix. That keyword applies only to the first author name and, like rft.auinit, rft.auinit1, and rft.auinitm, has never been supported in cs1|2. For us to use those keywords would require extra work on the part of editors and programmers.

—Trappist the monk (talk) 19:05, 10 July 2017 (UTC)

"Chapters" in web pages

I believe it would be helpful if chapter or section entries could be made in the cite web environment, in particular if one wishes to refer to an anchor which has its own sub-heading within a web page. While including the sub-heading in the title parameter works after a fashion, the use of the chapter parameter (or an appropriately named alternative) seems more logical. --Schlosser67 (talk) 07:23, 12 July 2017 (UTC)

Which web pages have chapters? If you're citing an online book, use {{cite book}} with |chapter= and |chapter-url=. --Redrose64 🌹 (talk) 08:54, 12 July 2017 (UTC)

"in particular if one wishes to refer to an anchor which has its own sub-heading within a web page." -- PBS (talk) 11:31, 12 July 2017 (UTC)

Use |at=§ page-section? Though it seems clumsy. 65.88.88.126 (talk) 13:10, 12 July 2017 (UTC)

@Schlosser67: There is a convention you can use when the link contains an anchor: the section sign (§). You can generate this character using the "Insert" menu that's directly beneath the pane of the source editor, or the Ω menu that's above the pane in VisualEditor.

{{cite web |url=http://lor.em/ipsum#foo |title=Web Page Name § Section Name}}

For anchoring in a web page, I think this is preferable to a "chapter" designation (unless you really are linking to a chapter heading in a book). A chapter can have many pages, but we don't think of a "page" as having chapters. The section sign is a good way to express in a citation that a link has an anchor, and Wikipedia uses this convention.

If you want to refer the reader to a section but you can't use an anchor, indicate the section in the |at field:

{{cite web |url=http://lor.em/ipsum |title=Web Page Name |at=section "Section Name"}}

I disagree with 65.88.88.126's suggestion to link within |at. Since |url must be populated, there would be two links. Should the reader expect the link in |at to anchor and the link in |url not to anchor? My feeling is that if the link in |url anchors, we should communicate that in the link label, because that is where the link leads. But if only the |at link anchors, then that is a problem because nearly everyone will click the |url link. —Ringbang (talk) 14:22, 12 July 2017 (UTC)

One could always use "§" or ":" in any book title, so why not dispense with the chapter parameter in {{cite book}}? For that matter we could probably make do with a lot less parameters. As an example why bother with "location" just include the location information in the "publisher" parameter, and why bother a volume parameter as the volume information can be included as part of the title? -- PBS (talk) 14:47, 12 July 2017 (UTC)

@Schlosser67 as an alternative consider using {{citation}} with the parameter mode=cs1 set, you should then find that you can use chapter. -- PBS (talk) 14:47, 12 July 2017 (UTC)

Hi PBS, If you want to ask why certain parameters are useful and desirable, please create a new thread. —Ringbang (talk) 16:59, 12 July 2017 (UTC)

I was making a point! -- PBS (talk) 06:27, 13 July 2017 (UTC)

Thanks for all the suggestions. I'll have to see which works best. My point was that there are some long web pages with anchored sub-headings that could well be chapters in a thin book, and if the link in |url points to an anchor, then it makes sense to have the appropriate heading, too, no matter how long the work in question is. I did not expect to open such a can of worms ;-) --Schlosser67 (talk) 17:23, 12 July 2017 (UTC)

Please consider the rationale for structuring citations: ideally one would want a source that is as easily accessible/discoverable as possible. In the case of http-based sources, the accessible/retrievable entity is the page, just as in the case of book-based sources the relevant entity is the title. This is how users will retrieve the source, therefore that would be the primary (citation) index. To also make it easy to verify, we use the in-source locations within the accessible source, such as chapters, page-numbers or sections. Even when a webpage section is the verification target, the retrievable source is still the webpage. So imo, the source (the webpage) must be clearly distinct from any navigation target. I believe that users must know unambiguously and at a glance where the info comes from. Adding the section info to the title/page info is not a best practice, imo. 65.88.88.69 (talk) 20:26, 12 July 2017 (UTC)

"Adding the section info to the title/page info is not a best practice, imo".While you can argue that https://en.wikisource.org/wiki/1911_Encyclop%C3%A6dia_Britannica/Great_Rebellion#The_Invasion_of_Scotland is page based (although sections is another way to access the data), but this is not always so https://en.wikisource.org/wiki/Final_Act_of_the_Congress_of_Vienna/General_Treaty#ART.LIII Being able to access specific articles in a treaty is useful here is another example http://avalon.law.yale.edu/19th_century/hague01.asp#art57 -- PBS (talk) 06:44, 13 July 2017 (UTC)

The comment was about how the info would be presented to the reader, not how the navigation would be structured by the editor.

This

{{cite web|title=PageTitle|at=PageSection|website=Website|url=http://www.page.com#section}}

"PageTitle". Website. PageSection.

Versus this

{{cite web|title=PageTitle PageSection|website=Website|url=http://www.page.com#section}}

"PageTitle PageSection". Website.

Obviously, the first example is not entirely correct as the title-url navigates to the section-url. But I believe it is more reader-friendly. 72.43.99.146 (talk) 15:03, 13 July 2017 (UTC)

Proposal to default references element to column mode

I have started a proposal to switch the default behaviour of <references /> to automatic column mode. —TheDJ (talk • contribs) 09:22, 13 July 2017 (UTC)