Jump to content

Help talk:Citation Style 1

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

This is an old revision of this page, as edited by 72.43.99.146 (talk) at 00:55, 9 June 2017 (→‎Add parameter for Google Books id: Not really.). The present address (URL) is a permanent link to this revision, which may differ significantly from the current revision.

Any update on doi-broken-date?

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

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

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

De-archived because discussion is ongoing/unresolved. @Trappist the monk:. Headbomb {t · c · p · b} 17:20, 23 May 2017 (UTC)[reply]

ISBNs in mw:Citoid

Hey All; at the WMF we have been working with OCLC to make ISBN generated citations available, through using their ISBN database. We have deployed the feature on all language Wikipedias: you can learn more about it on the Wikimedia blog. Astinson (WMF) (talk) 19:29, 11 May 2017 (UTC)[reply]

How do we downtrammeled logged-in editors use this without switching to VE? EEng 19:46, 11 May 2017 (UTC)[reply]
@EEng: You are unable presently. If you don't want to visually edit, but are willing to stomach the same kinds of interfaces (and associated Javascript heaviness on edit), you should try the New wikitext mode--you can access the citation tools there. --Izno (talk) 20:34, 11 May 2017 (UTC)[reply]
(edit conflict)@EEng: The mw:2017_wikitext_editor supports this feature as well (I am editing in that editor right now, and use it for most of my non-content editing in my volunteer capacity. I am not sure if there are other gadgets/tools that support Citoid in the older Wikitext editor. @Whatamidoing (WMF): might know. Astinson (WMF) (talk) 20:43, 11 May 2017 (UTC)[reply]
Why can't you give us a {ISBN-to-citebook} template, so we can code something like {subst:ISBN-to-citebook|978-0399594496} and get the same result, without demeaning ourselves by using these toolbars and visual editing and other paraphernalia of the Wikiediting welfare state? This would often require a second edit to clean up what the subst returns, but I for one would be most happy to use facility like that. EEng 20:52, 11 May 2017 (UTC)[reply]
How about me, Astinson (WMF)? Can I have a bug report too? EEng 01:34, 12 May 2017 (UTC)[reply]
@Astinson (WMF): I note that the WikiEditor icw Reftoolbar (enabled by default for everyone on English Wikipedia) has supported using ISBNs to import reference information for years already now. However that is specific to English Wikipedia editors of course. —TheDJ (talk • contribs) 21:07, 12 May 2017 (UTC)[reply]
The what? Where would I find that? EEng 23:03, 12 May 2017 (UTC) (Repinging TheDJ EEng 13:20, 15 May 2017 (UTC))[reply]
If, at Special:Preferences#mw-prefsection-editing, you have checked Enable enhanced editing toolbar, in the source editor choose the Cite dropdown. From the Templates dropdown choose cite book and enter an isbn in the ISBN field and click the magnifying glass. Here's an isbn to try it with: 9783161484100
—Trappist the monk (talk) 14:21, 15 May 2017 (UTC)[reply]
@Astinson (WMF): The example citation on your blog post uses YYYY-MM-DD format for the publication date, while most citations on Wikipedia use Month DD, YYYY or DD Month YYYY depending on US/UK variations. To me this suggests that some of us are going to be forced by your change to spend a lot of time making the dates of references added by users of this tool more consistent with the other dates in our articles. Is there any way that you could detect the date format used by an article and use that, please? Also, it appears that for many books, you are using dates like 1993-01-01 where the "01-01" part has no actual meaning (the book was not actually published on January 1) but is instead just a default value for when the date is unknown. Is there some way of preventing your tool from inserting this fake data into our citations? —David Eppstein (talk) 20:28, 11 May 2017 (UTC)[reply]
@David Eppstein: You can use |df= for the first problem, if you don't simply want to use a script such as the one that Ohconfucius provides. The WMF developer team is unwilling to let us get the dates in the format we wish. As for the second problem, using ISO dates allows for ambiguity in the form of 1993-00-00 to indicate that the year is known but not the month nor day, as well as 1993-01-00 to indicate that year and month are known, but not the day--I do not know why they use 01 instead. (It impacts Wikidata too, but I haven't thought to comment there yet.) --Izno (talk) 20:32, 11 May 2017 (UTC)[reply]
(Erm, not quite right regarding the 0s, but the intent is similar: review ISO 8601#Calendar dates.) --Izno (talk) 20:39, 11 May 2017 (UTC)[reply]
1993-00-00 is clearly a nonsense date. But can we not instead use a |year= field, where only the 4-figure year is inserted? -- Ohc ¡digame! 21:50, 11 May 2017 (UTC)[reply]
Tracked in Phabricator
Task T165116
@Ohconfucius, Izno, and David Eppstein: We filled at bug at phabricator:T165116. I agree: their are going to be very rare occasions when the precision of something tracked via an ISBN has a publication date more precise than a year. Astinson (WMF) (talk) 01:22, 12 May 2017 (UTC)[reply]
In the examples given at the blog, is ISBN 9783161484100. Follow that link through Special:BookSources to WorldCat. Several different titles apparently use that isbn. I would guess that sometimes WorldCat is correct and that this tool may return correct information. But I'm not holding my breath; I've seen a lot of strange stuff in WorldCat listings.
I also notice, as others have pointed out, that the date format is rather incorrect for books which, for the most part are year-only. Further, WorldCat and citoid don't seem to care about extraneous punctuation; Gallery has an extra trailing comma. The Boris citation left out |location=Ljubljana; the Gallery Citation left out both |location= and |publisher=.
Like so many 'magic' tools, I fear that editors will assume that whatever is returned by the tool, because it's a tool, must be correct. It came from a database, right? The machine got the data for me, right? It therefore must be correct, right? I think that there is too much weirdness in WorldCat (akin to the weirdness in Google Books metadata) to make this tool very reliable. Handy perhaps, for those who will massage what the tool returns, but detrimental to the project in the hands of lazy editors.
—Trappist the monk (talk) 00:46, 12 May 2017 (UTC)[reply]
It's unfortunate, then, that it is deployed only to the VE users and not to the users who can actually see the template coding to massage it. —David Eppstein (talk) 00:56, 12 May 2017 (UTC)[reply]
Change unfortunate to incompetent and I'll agree with you. I can't think of one thing WMF has done in the 9 years I've been editing that's actually made editing easier. Honestly and truly, the one best thing that's happened is the Thank feature. EEng 01:01, 12 May 2017 (UTC)[reply]
@EEng: The comms tech team and Cyberpower put together the magical archive every URL on a single page tool that just rolled out. You should try it. This diff was cathartic, to be honest. --Izno (talk) 02:21, 12 May 2017 (UTC)[reply]
Well, I tried it, but I can't get it to do anything other than produce some statistics on various articles. Is there some magic button that makes it do something. EEng 02:46, 12 May 2017 (UTC)[reply]
It should be noted that this functionality has been available in Reftoolbar for years now (also using worldcat). So it's not exactly that it wasn't available to users before (maybe a lot more hidden, but its there). And I find irony in the fact that we keep setting so much higher bars than we set for our own project. Apparently we are the only website in the world that should be allowed to have the occasional error in it's data. No. I see this as an opportunity to make sure data quality of worldcat and ourselves improves, so that better crossover knowledge and insight can be generated, be it within (meta:WikiCite) or outside of our movement. —TheDJ (talk • contribs) 21:07, 12 May 2017 (UTC)[reply]
Yes, I know. That tool is just as bad as the new tool because it relies on what WorldCat has in its database which doesn't appear to be curated very well. Here is what the old tool retrieved when given the same isbn as the blog's Gallery example:
{{cite book|last1=Maps|first1=Peekaboo|title=Berkeley, Oakland : Albany, Emeryville, Alameda, Kensington|date=2009|publisher=Peek A Boo Maps|location=[Berkeley?]|isbn=9783161484100|edition=1st ed.}}
Maps, Peekaboo (2009). Berkeley, Oakland : Albany, Emeryville, Alameda, Kensington (1st ed. ed.). [Berkeley?]: Peek A Boo Maps. ISBN 9783161484100. {{cite book}}: |edition= has extra text (help)
Here we have: publisher as author, uncertain location (but we did get that), malformed edition; but, date is in the proper form. Looking at the dates in the entries on that WorldCat page, there are a variety of year styles; some are plain years: 2013; some are bracketed: [2016]; some include the copyright mark: ©2016, some have combinations of these three, which to choose?
Certainly, both tools cannot fix bad data. Maybe they can be made to be more clever in how they handle multiple different author, and multiple different title returns from the data base using the same isbn key. Still the basic and enduring problem is dubious data fetched by the 'magic', officially sanctioned, tool so it must be right, right?
—Trappist the monk (talk) 21:59, 12 May 2017 (UTC)[reply]
Perhaps a new parameter for Citoid to spit out when it is run on a reference (spitball name: |citoid=) which when equal to oclc, creates a green maintenance category message with some text of the sort: "CS1 maintenance: Citations imported from OCLC", if we believe that OCLC is so poor a quality of reference and that no-one will go back to fiddle with parameters. For reference, I know I use Citoid now for other websites and its hit-or-miss-enough in general such that I always check the imported citation, so I'm not sure if such a parameter is even necessary, since I would guess most others who use the service have a similar workflow. --Izno (talk) 22:06, 12 May 2017 (UTC)[reply]
So let's see:
Badly implemented (the date issue), also limiting editor choice
Contravenes established Wikipedia content guidelines (WP:CITEVAR) by limiting the citations to Style 1, also misleading by not pointing this out. This is a problem with Citoid documentation, and examples, in general.
May possibly result in ambiguous citations that editors may accept at face value as correct.
Conclusion: at present, nothing to see here.
72.43.99.146 (talk) 13:50, 12 May 2017 (UTC)[reply]

On a related issue, Mediawiki's refusal to use any date format other than YYYY-MM-DD in their cites (because they don't want to go through the hassle of full internationalization): in response to this, we could always be passive-aggressive about it and modify the cite templates to put up big red edit-time warnings when they see dates in this format in the date field (not the accessdate where they are ok): "Warning: Numeric date format detected. Please convert all dates to the prevailing style of the article." Because unless the users of the citoid template see it as not properly working, they won't notice the work it causes the rest of us and won't be motivated to do anything about the problem. —David Eppstein (talk) 16:30, 12 May 2017 (UTC)[reply]

Tracked in Phabricator
Task T132308
This silly date bug is tracked at T132308. The bug above has been closed as a duplicate of T132308, which was the same bug submitted earlier. It's hard to understand why this tool was rolled out with this bug unfixed; the results of the bug are even prominently featured in step 6 of the demonstration in the blog post linked above. The explanation for why it hasn't been fixed is unpersuasive at best. I do not understand why WMF puts its credibility on the line by being in the business of automating the addition of untrue data to Wikipedia. – Jonesey95 (talk) 17:52, 12 May 2017 (UTC)[reply]
Hey all, brief update: User:Mvolz (WMF) has pushed a fixed for the polluted year-level accurate-date issue in the ISBN generator, and is looking into a way to generate better human-readable dates via Citoid: https://phabricator.wikimedia.org/T132308 . Thank you for all the feedback on the bug, and it is helping generate ways to deliver a better date format to each Wiki. Continue giving feedback on phabricator as patches get published. Astinson (WMF) (talk) 14:24, 18 May 2017 (UTC)[reply]

edtf date formats as cs1|2 date parameter values

Related to the discussions at Help_talk:Citation_Style_1#ISBNs_in_mw:Citoid and T132308.

Because WP:DATE does not allow year initial numeric dates in the form YYYY-MM but does allow YYYY–YY (with an en dash), and because cs1|2 emits an error when the MM or YY portion of those dates is in the range 00–12 inclusive, and because citoid needs to be able to transfer dates to all of the different language wikis, it has been suggested that citoid use the Extended Date/Time Format (EDTF). A draft of the standard is here.

For us, the immediate issue is the YYYY-xx date form. EDTF provides an alternate way to encode that kind of date. Similar in form to YYYY-MM-DD, EDTF allows for portions of the date string to be declared as 'unspecified'. When citoid needs to send en.wiki a month and year date, it can take the form |date=YYYY-MM-uu. That date format would surely violate WP:DATE so needs to be transformed into a more appropriate form. I have hacked the module sandbox to accept and transform dates that are provided in this style:

{{cite book/new |title=Title |date=2000-06-uu}}
Title. 2000-06-uu. {{cite book}}: Check date values in: |date= (help)

Similar to the transformations preformed for |df= and for auto-changing hypens to dashes, if there are any date errors in the citation, even in unrelated parameters, the module will not do any transformations. Here, using the same format for |access-date=, causes an error because |access-date= requires a day:

{{cite web/new |url=//example.com |title=Title |date=2000-06-uu |access-date=2017-05-uu}}
"Title". 2000-06-uu. Retrieved 2017-05-uu. {{cite web}}: Check date values in: |access-date= and |date= (help)

—Trappist the monk (talk) 16:45, 18 May 2017 (UTC)[reply]

That's all well & good, but I don't think the problem here is WP:DATE. After all, that is just a style guideline, so theoretically any hack is acceptable if the result conforms to the style. I think there should be an effort to integrate EDTF as a native format in MW. If this is to be a universal biblio standard, surely WMF should take a proactive role. 107.19.188.204 (talk) 22:39, 18 May 2017 (UTC)[reply]
EDTF isn't meant to be a "universal biblio standard". It is meant to trim out the less useful features of ISO 8601 (in that sense it's a profile) and to provide some extensions for things like uncertainty and seasons. One thing that hasn't been extended is the calendar; like ISO 8601, EDTF only supports the Gregorian calendar. That makes it ok for recently published works, but it isn't suitable for older works with publication dates stated in the Julian calendar. Nor would it be suitable for works with publication dates stated in some other calendar, which wouldn't even have the same names for months. This would be especially true if the dates can't be precisely converted, as happens with religious calendars whose dates depend on religious officials making an actual observation of the new moon. Jc3s5h (talk) 01:10, 19 May 2017 (UTC)[reply]
Relevant: [1]. —David Eppstein (talk) 05:31, 21 May 2017 (UTC)[reply]

License information

For some reason I was under the impression that the "cite journal" would accept a "license" parameter where one could indicate, e.g., "CC BY". I do not see it. Is there any (other?) way to indicate this? — fnielsen (talk) 12:39, 20 May 2017 (UTC)[reply]

Recent discussion on the topic of a license parameter is here.
—Trappist the monk (talk) 12:46, 20 May 2017 (UTC)[reply]

Drawing citation metadata from Wikidata

In preparation for the WikiCite event, currently taking place in Vienna, I have built a demonstrator template, {{Cite Q}}. Much work remains to be done, to deal with more complex use cases, and to resolve the issues listed there. Hopefully that will be addressed during the WikiCite hackathon, on Thursday (CET time, GMT +2). Your comments and remote participation will be welcome. Please use the template's talk page. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 13:09, 23 May 2017 (UTC)[reply]

The documentation for this prototype states
  • Eventually, each signed-in reader should be able to set, under their "Preferences", the style in which they wish to see citations rendered. No more CiteVar wars!
This is the same concept that date linking tried to accomplish for dates. There was a huge battle over this (if I recall correctly a few editors were banned by the community). The biggest issue that would apply to this proposal is that most people who read Wikipedia are not editors and are not logged in. So the people maintaining articles, if they are foolish enough to log in and set a citation preference, will be seeing something different than the majority of readers, and may fail to see problems with the way the citations are presented to the majority of readers. I think a well-advertised RfC at WT:CITE would be appropriate before going in this direction. Jc3s5h (talk) 13:31, 23 May 2017 (UTC)[reply]
Please use the template's talk page.. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 13:56, 23 May 2017 (UTC)[reply]
(edit conflict)
Is it even possible for a template to know a logged-in user's preferences? Not possible, so far as I know. Were it possible, no doubt, there would have been discussion here suggesting, or perhaps demanding, that cs1|2 be modified to accommodate user preferences.
—Trappist the monk (talk) 13:58, 23 May 2017 (UTC)[reply]
Since this will allow data reuse without dealing directly with the source, the quality of the underlying citations is more important AFAIC. Isn't reliability an issue here? How does this reflect/impact on citation reuse? People have a tendency to conflate automation & reliability. 72.43.99.146 (talk) 14:54, 23 May 2017 (UTC)[reply]
Yes it is. That is exactly the argument I was trying to make in the ISBNs in mw:Citoid discussion. It is perhaps more insidious because WikiData can be edited by anyone whereas WorldCat, as I understand it, is a rather more closed system.
—Trappist the monk (talk) 15:07, 23 May 2017 (UTC)[reply]
Templates shouldn't pull from Wikidata, and {{cite Q}} templates would be even more problematic and editor-unfriendly than the now-killed {{cite doi}}. A |wikidata=Q15625490 parameter however, would be pretty great. Headbomb {t · c · p · b} 15:21, 23 May 2017 (UTC)[reply]
It seems to me the biggest problem with reusing cited data is the lack of consensus that the editor who copies a claim, with a citation, from one article to another must look at the source to see if it really supports the claim. Without such a consensus, all is lost. Jc3s5h (talk) 15:34, 23 May 2017 (UTC)[reply]

Protected edit request on 23 May 2017

I would like to make an edit request adding a new lastnamefirst parameter. It changes the name order in citations, defaulting to yes. Change it to no for Icelandic names. Numberguy6 (talk) 15:54, 23 May 2017 (UTC)[reply]

Not done: please establish a consensus for this alteration before using the {{edit protected}} template. This may be a valuable discussion to have but it certainly does not have a consensus at this time. What reason do you propose to make this change? Izno (talk) 16:13, 23 May 2017 (UTC)[reply]

single quote for an ASCII quote

As the Module talk:Citation/CS1/COinS seems to be moribund, I decided to post here.

It took me a hour or more to work out that this was the cause of a problem that I have, because I read Help:CS1 and could not see that it was an obvious feature (so I assumed it was some sort of hidden character in the string or a fault in my scripting): 

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

Works 

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

Does not work because the ’ has been replaced with '

The reason for this substitution is in Module:Citation/CS1/COinS line 177: 

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

What is the thinking behind this line? -- PBS (talk) 12:57, 25 May 2017 (UTC)[reply]

HO-hum it seems that is unlikely to be the line as &#39; is an ordinary ASCII single quote ' so presumably the conversion is elsewhere. -- PBS (talk) 13:13, 25 May 2017 (UTC)[reply]

Line 177 in Module:Citation/CS1/COinS is not the problem. That line is looking for all of the styling that is transcluded when the {{'}} 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)[reply]

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

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:
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)[reply]
" 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.
-- PBS (talk) 17:04, 25 May 2017 (UTC)[reply]

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:

Cite encyclopedia comparison
Wikitext {{cite encyclopedia|encyclopedia=Encyclopædia Britannica|title=[[Wikisource:1911 Encyclopædia Britannica/Great Rebellion#The "Crowning Mercy"]]}}
Live "1911 Encyclopædia Britannica/Great Rebellion#The "Crowning Mercy"" . Encyclopædia Britannica.
Sandbox "1911 Encyclopædia Britannica/Great Rebellion#The "Crowning Mercy"" . Encyclopædia Britannica.
Cite encyclopedia comparison
Wikitext {{cite encyclopedia|chapter=[[Wikisource:1911 Encyclopædia Britannica/Great Rebellion#The "Crowning Mercy"|The “Crowning Mercy”]]|encyclopedia=Encyclopædia Britannica|title=Great Rebelion}}
Live "The "Crowning Mercy"" . Great Rebelion. Encyclopædia Britannica.
Sandbox "The "Crowning Mercy"" . Great Rebelion. Encyclopædia Britannica.

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:

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

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

The sandbox version of the first "Crowning Mercy" example now has properly kerning.
—Trappist the monk (talk) 19:39, 26 May 2017 (UTC)[reply]

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

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)[reply]
Thanks for the improvement. -- PBS (talk) 09:18, 29 May 2017 (UTC)[reply]

Licensing

Is there a way in this family of templates to be able indicate the licensing of the cited material? I am particularly interested in being able to mark a citation as being Creative Commons licensed so that the reader can see if it can be re-used. As Wikipedians, we are generally in favour of information being open and reusable. While I can see that we support expressing whether a source is free/subscription/etc (which affects "open"), I cannot see a similar way of expressing the source's potential for re-use. As a writer of Wikipedia, I would love to be alerted to CC-licensed materials (particularly the ones that enable re-use on Wikipedia itself). I write a great deal about Queensland, Australia, and there are a lot of government resources that people don't realise are CC-BY licensed and I'd like to alert readers (and other writers) to this when citing them. Is there a way to do it? Or do I have to do it after the cite template and before the closing ref tag as I did at State Strategic Touring Route. Thanks Kerry (talk) 08:18, 27 May 2017 (UTC)[reply]

Previous discussion on this topic is here.
—Trappist the monk (talk) 09:41, 27 May 2017 (UTC)[reply]

Parameter for Wikidata ID

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

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

|ol= prefix

In its present incarnation, {{cite Q}} is a meta-template using {{citation}}. It uses parameter values obtained from wikdata. Wikidata holds OpenLibrary identifiers that begin with an 'OL' prefix. cs1|2 emits an error message when the value assigned to |ol= has an 'OL' prefix. Because this situation is reminiscent of this discussion, I have modified the |ol= error checking to quietly accept OL identifiers with the OL prefix. The appearance of the rendering has not changed:

Cite book comparison
Wikitext {{cite book|ol=OL7130221M|title=Treasure Island}}
Live Treasure Island. OL 7130221M.
Sandbox Treasure Island. OL 7130221M.

—Trappist the monk (talk) 10:19, 28 May 2017 (UTC)[reply]

Thank you for this. It is a good application of Postel's Law. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 14:24, 28 May 2017 (UTC)[reply]
Thanks from me also. What's old is new again (link to previous discussion, September 2014). – Jonesey95 (talk) 14:35, 28 May 2017 (UTC)[reply]

Categorization for multiple languages in para language

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

Please link to an example article when raising questions like this. Thanks. – Jonesey95 (talk) 05:10, 3 June 2017 (UTC)[reply]
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)[reply]

Add parameter for Google Books id

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

I have seen people use {{Google books}} with |plainurl= in the CS1 |url= parameter. See Example 2 on the template's documentation page. Have you tried it? – Jonesey95 (talk) 17:50, 5 June 2017 (UTC)[reply]
It might be worth adding |Google Scholar id= at the same time; Wikidata has just created Google Scholar paper ID (P4028) for this. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 23:10, 5 June 2017 (UTC)[reply]
I don't think these IDs deserve separate links at the end of citations. As a reader I would find it quite annoying to see these opaque identifiers popping up: they don't mean anything to me (and they don't mean much to machines either because at least Google Scholar has no public API). Using them to fill |url= without adding anything at the end seems more acceptable, but do the benefits really outweigh the added complexity?
I can see the point of separate rendering for things like |arxiv= or |doi=, because they are genuinely used as identifiers by many people. But for Google Books or Google Scholar, as far as I know these are just internal identifiers, and it would be a bit weird to cite a book by its Google Books ID. The ID exists and can be seen in the URL, sure (that's how all these websites work) but that does not mean readers should care about this particular string, I think.
As to the problem of rendering Wikidata items as citations, I think it would be fairly simple to convert identifiers which are present on Wikidata and absent in CS1/2 to URLs on the fly, and pick the "best" of these URLs based on a priority ranking. − Pintoch (talk) 09:13, 8 June 2017 (UTC)[reply]
I assume that a Google ID parameter could replace the url parameter. A Google ID parameter can be both a pointer to content such as doi or arxiv (when Google publishes all or part of the work), and a pointer to classification such as ISBN or ISSN (these are actually marketing ids). I don't know what you mean by "internal identifiers". When an id genuinely and uniquely identifies to a work, can be publicly retrieved, and has no legal ramifications, it is a usable identifier for the purpose of discovering the source cited, and (in the case of published content) directly support the wikitext. Btw, all identifiers can seem "opaque" to readers. As they should: they are not there to be "understood", but to stand in for something else, that must be researched if the reader wants to verify the citation.
Wikidata items as citations is problematic. There are reliability questions, and also questions of cyclical references or self-references. Wikidata items are "supported" by Wikipedia references. Apart from the fact that the validity of the underlying references is not declared in any way, Wikipedia itself fails the WP:RS tests, and should not be used as a reference. 72.43.99.146 (talk) 14:30, 8 June 2017 (UTC)[reply]
I'm going to go with a "treat Google-ID" like ASIN. It's an identifier of last resort. Headbomb {t · c · p · b} 14:57, 8 June 2017 (UTC)[reply]
Plain text literal URLs are best IMO. Adding layers of abstraction has a downsize and unclear what it gains in return is worth it. These types of things make it really difficult for bot writers and they usually just get skipped and thus not maintained and so are more error prone over time to link rot and other problems. -- GreenC 17:17, 8 June 2017 (UTC)[reply]
In response to the IP:
First, what is an internal identifier? It is an ID that has many of the following characteristics:
  • not exposed by any public API ;
  • without any stability guarantees (e.g. Google Scholar can change the cluster id of a paper freely, that should not break any other system. If Crossref suddenly decides to change its DOIs, people can rightly complain) ;
  • not designed to be looked up manually by users (e.g. on Google Scholar you will not find a form where you can input a cluster id, whereas you will find the equivalents on doi.org and hdl.handle.net );
  • not exposed in the user interface of the platform (because it is not intended to be used outside the platform).
In other words, it is an ID that is used in a system because of technical reasons (most databases need to rely on one), but is not used to communicate with other systems.
About Wikidata items as citations, I am not sure you understand the use case correctly. I invite you to have a closer look at the wonderful {{cite Q}}. Using a Wikidata item with {{cite Q}} does not mean that you are citing that item, it means that you are citing the work represented by that item. So there is no issue of cyclical references at all! For instance, if I edit the article on Formaldehyde, I am not going to use {{cite Q}} with formaldehyde (Q161210) (some of the information there is indeed likely extracted from that Wikipedia article) but rather with an item that represents a scientific article about that topic, such as An Investigation on Formaldehyde Emission Characteristics of Wood Building Materials in Chinese Standard Tests: Product Emission Levels, Measurement Uncertainties, and Data Correlations between Various Tests (Q30000011).
Finally, it is wrong to say that "Wikidata items are "supported" by Wikipedia references". Many references in Wikidata do not rely on Wikipedia at all! Some statements were imported from Wikipedia, but in principle Wikidata can work independently of any Wikipedia, as an autonomous database. In fact, many Wikidata items are not linked to any Wikipedia article.
If anything is still unclear please let me know! − Pintoch (talk) 20:05, 8 June 2017 (UTC)[reply]
The technicalities behind an identifier are immaterial. They are included in citations in order to discover a source. If the identifier can fulfill this requirement, that is sufficient. The only thing that matters, where citations are concerned, is to verify claims in an article. Everything else is secondary. Because everything that is produced by anonymous or pseudonymous writers/editors is inherently unreliable. This includes, articles, bots, scripts, templates, and entire platforms. As far as anything produced by such actors, there is no formal quality control, whether that is verifiability/reliability checking for wikitext or version testing/control for wikiscript. So I am not discussing whether an identifier in an a priori unreliable reference can communicate with a potentially unreliable platform through a potentially unreliable API. It is unimportant. Can this id assist a non-expert user in determining whether a reference is valid or not?
I've no idea how stable Google IDs are relative to other identifiers (they may all change). I don't know what Google's policy is in backlinking changed IDs, relative to similar policies of other id providers. I do know that Google IDs, and the items they identify, are fairly easy to track and use. This ease of use makes a reference more likely to be verifiable than a reference that omits a similar id, or that instead offers more restrictive systems. In an unreliable platform such as Wikipedia, ease-of-reliability gets my vote.
For the same reasons, it is unimportant to me what Wikidata (or Wikipedia) can be "in principle". In principle, anything will be perfect. But my experience with Wikidata is that the "data" part is often inscrutable, and there is no mechanism to verify anything from within the platform. Additionally, the majority of Wikidata statements I have seen come from similar, inherently unreliable sources such as Wikipedia. 72.43.99.146 (talk) 00:55, 9 June 2017 (UTC)[reply]

CS1 maint: English language specified

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

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

hdl - OAbot - ELNEVER?

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

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

So -

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

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

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