This is an archive of past discussions about Template:Cite Q. Do not edit the contents of this page. If you wish to start a new discussion or revive an old one, please do so on the current talk page.
I find it impossible to edit an article where all that appears in the wikitext is something like {{Cite Q|Q20668025}}. I need to see the title and authors in the wikitext so I know what source I'm working with. Jc3s5h (talk) 13:50, 23 May 2017 (UTC)
I've no doubt that, in time, tools will address this, with a pop-up view of the data to which you refer. Citations need name attributes, too, so consider <ref name="Smith+Jones">{{.... Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits13:54, 23 May 2017 (UTC)
The new wikicode mode for the visual editor might solve that on the long term (this was pointed out to me today at WikiCite). It enables easy integration of citation tools (such as Citoid) while still displaying wikicode. (If you haven't tried it yet, give it a go, it is awesome.) − Pintoch (talk) 21:10, 23 May 2017 (UTC)
Scope
Having just played with the newspaper example, I'm not convinced we can do everything in one template; we may need to revert to {{Cite journal Q}}; {{Cite news Q}}, etc. Thoughts? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits09:55, 24 May 2017 (UTC)
shouldn't the individual article have its own wikidata entry, and then the label provides the link text? It would be good to be able to locally override "title" and "url" etc. though. ArthurPSmith (talk) 12:50, 24 May 2017 (UTC)
Potential disparity between what editors and readers see
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)
We already have other tools and features that give a (much greater) "disparity between what editors and readers see"; but let's cross that bridge when we come to it. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits14:15, 23 May 2017 (UTC)
I like this much better than the current distinction between Citation Styles 1 and 2 that editors have to maintain consistently, and that gives inconsistent formatting to our articles for no good reason. —David Eppstein (talk) 16:46, 28 May 2017 (UTC)
Authors
Try:
{{ #statements:P50 |from=Q15625490 }} → Jeffrey T. Williams, Kent E. Carpenter, James L. Van Tassell, Paul Hoetjes, Wes Toller, Peter Etnoyer, Michael L. Smith
{{#invoke:WikidataIB |getValue |qid=Q15625490 |P50 |fetchwikidata=ALL |onlysourced=no |noicon=true }} → Jeffrey T. Williams, Kent E. Carpenter, James L. Van Tassell, Paul Hoetjes, Wes Toller, Peter Etnoyer, Michael L. Smith
Does that almost do the trick? (Yes I know you'd prefer not to link authors because it potentially pollutes metadata, but what ya gonna do?) --RexxS (talk) 16:01, 18 May 2017 (UTC)
@RexxS: Thank you for this. The aim eventually will be to have:
|first1=Jeffrey T. |last1=Williams |first2=Kent E. |last2=Carpenter |authorlink2=Kent E. Carpenter |first3=James L. |last3=Van Tassell |first4=Paul |last4=Hoetjes |first5=Wes |last5=Toller |first6=Peter |last6=Etnoyer |first7=Michael |last7=Smith
which is complicated by the lack of separation of first and last names in Wikidata labels. In the interim, we can live with:
|author1=Jeffrey T. Williams |author2=Kent E. Carpenter |authorlink2=Kent E. Carpenter |author3=James L. Van Tassell |author4=Paul Hoetjes |author5=Wes Toller |author6=Peter Etnoyer |author7=Michael Smith
I could make the |first1=, |last1= version if only there were a guaranteed algorithm for parsing names into first, last. But there isn't. Simple ones fails immediately on "James L. Van Tassell". Otherwise I've got to go digging into the given name (P735) and family name (P734) properties of each author - and even that won't work for Van Tassell because the data is missing.
Since the {{sfn}} and {{Harvard citation}} templates use surnames as means of linking the short citation to the full citation, a lack of knowledge of the surname prevents Cite Q working with these templates. Also, lack of knowledge of the surname vs. the given name prevents placing the surname first (e.g. "Stevenson, Robert Louis"). This means the template is not suitable for use in a list of works cited where the list is sorted alphabetically (which is the norm when using short or parenthetical citations). Jc3s5h (talk) 15:13, 23 May 2017 (UTC)
Yes I know. All it would take is for every single author on Wikidata to have family name (P734) set. And then some mechanism for making sure that new entries always have that property set. And some other mechanism for making sure the family name isn't removed from an entry. That's not too much to ask, is it? --RexxS (talk) 16:06, 23 May 2017 (UTC)
It looks like I would have to expand the Lua call to take all of the parameters passed to {{Cite Q}}, fetch all of the others from Wikidata directly and then call frame:expandTemplate to pass them into {{Citation}}, effectively writing the entire Cite Q template in Lua. That's a job for another day. --RexxS (talk) 18:30, 24 May 2017 (UTC)
@Andy: - If you check Template talk:Cite Q/sandbox, you'll see that Trappist the monk has kindly written the Lua module Module:Citeq to do the job for you. It seems to work well. Thank you, Trappist! I can see that it would be trivial to pass another parameter (and simply create a different wrapper) to offer equivalents for all of the CS1 templates as well as {{Citation}}, so have a think about where you're going with this now. I can switch the linked author to author plus authorlink parameters if you wish. --RexxS (talk) 14:59, 25 May 2017 (UTC)
@RexxS and Trappist the monk: Yes, thank you both. That does indeed seem to do the job. The need for Lua is clearly inevitable, but using that language is beyond my (current) skill-set. I'm not sure what you mean, RexxS, by "switch the linked author ...". As for wrappers for other templates, let's see what others think. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits20:09, 27 May 2017 (UTC)
@Andy: The current code in Module:Citeq lines 74 and 81 create a linked value for the author. I assume that tends to pollute the metadata, so I could instead keep track of links in another table, then use that to output |authorlinkN= wherever authorN has an article, and make all the author names unlinked. Does that make sense now? --RexxS (talk) 20:38, 27 May 2017 (UTC)
I've made the changes in the Module:Citeq/sandbox as a demonstration, but of course, you can't detect the difference in the rendered html. Thinking about it, it doesn't really make much difference unless you were ever to use it with a new citation style that handles author/authorlink differently. It's probably not worth worrying about.
The author Kent E. Carpenter is actually linked because the authorlink2 parameter is supplied to {{Citation}}. Not that anybody would notice. --RexxS (talk) 21:19, 27 May 2017 (UTC)
@RexxS: Thank you. Per the documentation of {{Citation}}, and the other templates we might wrap, we should use numbered |authorlink= parameters, so that's a good improvement. The COinS metadata emitted by your sandbox version works well, when exported using Zotero. I'll copy it over. Please feel free to work on the remaining issues! Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits11:29, 28 May 2017 (UTC)
I have boldly pasted Trappist's code above (with two minor modifications) into the template, and it seems to fix this particular problem. I do not know if it causes any new problems. – Jonesey95 (talk) 13:57, 16 July 2017 (UTC)
Is there a reason Module:Citeq uses frame:expandTemplate{title = 'citation', args = citeq_args}; rather than, somewhere or another, require('Module:Citation/CS1')? It would probably save some processing going through the template. --Izno (talk) 22:49, 26 July 2017 (UTC)
Because doing it as it was done requires less thought? Because the purpose of my part of this experiment was to fetch author and editor names from wikidata and hand those names to {{citation}} as individual |authorn= or |editorn= parameters. requiringModule:Citation/CS1 in Module:Citeq is, I think, harder to do without breaking anything because it requires changes to cs1 which seems to me backwards. If anything, and if ever this experiment proceeds, it would seem that whatever is in Module:Citeq and {{cite Q}} could at the proper time be subsumed into Module:Citation/CS1. Or not. I am not, by the way, advocating such a change. The 'extra processing' to do the work as it was done is, I think, negligible. We aren't really suffering from insufficient processing power so cycle counting is not required.
Why does it show full name of author instead of last name and first name. sfn template generally uses last name and it would be difficult to use the two together. -- Pankaj Jain Capankajsmilyo(talk·contribs·count)18:03, 14 August 2017 (UTC)
Because wikidata doesn't provide separate first and last names so all of an author's names go into |authorn=. Same with editor names. And no, the templates cannot be made smart enough to figure out which of an author's names is/are the surname(s). To use {{sfn}} with this template requires |ref={{sfnref|name1|name2|name3|name4|year}}.
The reference list normally used in an article that uses short footnotes should be in alphabetical order, and that order should be made obvious and easy to use by the reader by putting the author names in the last, first format. This is important when the article is printed, since hyperlinks from the short footnote to the reference list don't work in that environment. So I wouldn't recommend using Cite Q in article that employ short footnotes. (And of course, the documentation describes Cite Q as a "prototype", so it isn't ready to be used in articles yet in any case.) Jc3s5h (talk) 19:28, 14 August 2017 (UTC)
You should also be able to switch between first/last and last/first display for authors to match the rest of cites in the article. Keith D (talk) 22:44, 14 August 2017 (UTC)
Sigh. Perhaps this template needs a big red warning when used in article space: {{Cite Q}} is a prototype. Do not use it in article space. because clearly, it is not ready to be used.
Here is the same reference produced by reftoolbar. It isn't much better. The reason that both of these machine-made citations have problems is that the data sources upon which they depend are not reliable; never have been, and perhaps never will be.
Dundas, Paul (2002). The Jains (2. ed. ed.). London [u.a.]: Routledge. ISBN0-415-26605-X. {{cite book}}: |edition= has extra text (help)
It was pointed out in another discussion here that it might be possible to use family name (P734) and given name (P735). The particular example at hand has given name but does not have family name – Q2059352. In the {{cite Q|Q21707170}} example on this template's main page under §Books, the author entry for John Charles Chenoweth McKinsey list John as his given name. Any code that would attempt to extract a family name from that would be left to assume that the family name is 'Charles Chenoweth McKinsey'. That is most probably wrong. If ever this template is to be useful, the data at wikidata must be carefully and correctly curated. I'm not going to hold my breath waiting for that to happen.
Can you provide an example of this sort of failure? When asserting that a template fails to do something that it is supposed to do, an example of such failure is always beneficial.
If you look at Q29581627 on the template page at §Book, you will see that it links the title with a url it fetched from wikidata.
For example, Q36518532 had no url, but Google book id was given. In such a case, url can easily be based on the google book id. PS: I have now added the url. -- Pankaj Jain Capankajsmilyo(talk·contribs·count)01:26, 15 August 2017 (UTC)
Some feedback
This is a very interesting concept that promises to potentially fill the gap left by the deprecation of {{cite doi}}, etc. That said, there are several issues:
Since we have our own Scribunto Lua module Module:Citeq, we should probably move all the {{#property:}} Wikibase parser function calls and related Wikidata functionality to our module proper
We should probably talk to the Module:Citation/CS1 people to have them make changes so we can call them directly instead of depending on frame:expandTemplate
We need to consider every time we depend on arbitrary Wikidata access to non-connected entities, we increment the expense associated with the expensive parser function limit (which in MediaWiki defaults to 99 but seems to be set to 500 here) for any page it is used on. There are some exceptions (currently we have "free" but limited access to the following fields of arbitrary Wikidata entities: label, description, sitelink, and perhaps getEntityUrl) but they are mostly uninteresting (since they include no claims).
I was reading up in what is being done with citations using Wikidata, and I noticed one reference that seems to have broken since it was done in the article Breastfeeding. Nfitz (talk) 08:46, 27 August 2017 (UTC)
| title = {{#if: {{ #property:P1476 |from={{{1}}} }} <!-- is there a title -->
| {{ #property:P1476 |from={{{1}}} }} <!-- use title -->
| {{#if:{{{url|}}}{{ #property:P856 |from={{{1}}} }}
|{{ #invoke:RexxS |getAT | {{{1}}} }} <!-- don't mix |url= and a wikilinked |title= -->
|{{ #invoke:RexxS |getLink | {{{1}}} }} <!-- else use label from Wikidata -->
}}
I'm not sure why the {{{url}}} test is here. Doesn't that belong in the code for |url=?
Regardless, the example citation fails because wikidata is poorly curated and apparently has no standards for what constitutes a minimum data-set for a book. One would think that a book's title would be a critical and required part of that data-set. Apparently not. The fix? Add a title to wikidata for d:Q29581763. You might suggest to Editor Pigsonthewing that his bot, which created the Q29581763 wikidata entry, needs a fix to include a book's title.
Adding a title would fix it. But presumably it worked without a title on June 30th when Pigsonthewing added the reference to the article, and had the discussion User talk:Pigsonthewing/Archive 90#Template:Cite Q (which is what lead me here, after that popped in a search for Wikidata-based citations).
Hmm, the only edit to the template that could have changed the function is diff which ironically has the edit comment Trying Trappist's fix (with minor mod) to title parameter (see talk) by Jonesey95. My day-to-day programming experience is primarily in FORTRAN, so hesitant in changing the code. Nfitz (talk) 15:46, 27 August 2017 (UTC)
@Nfitz: I think I've fixed this through two edits: [1][2]. getAT wasn't fetching the page label, so I've added getTitle that does this (it's a copy-paste of getLink but removing the lines that add the link). Thanks. Mike Peel (talk) 17:51, 27 August 2017 (UTC)
I really intended Module:RexxS to be just a glorified sandbox, where we could do initial testing of Lua calls. When you're satisfied that the fix does the trick, Mike, could you please make a copy of the working code into Module:WikidataIB next to the copies of getAT() and getLink(), please? Calling those functions from WikidataIB rather than from Module:RexxS helps keep the "production" code in one place (and reminds me - or others - to do proper documentation). Cheers --RexxS (talk) 18:07, 27 August 2017 (UTC)
Aah, I didn't realise this was part of WikidataIB. The same code for fixing the issue was already there, so I've just changed the links to point to it. Thanks. Mike Peel (talk) 18:22, 27 August 2017 (UTC)
It did indeed work on 30 June. Since then, I noticed the change in behaviour and have been adding, manually, title parameters (duplicating the existing labels) to the Wikidata items for the series, as I work through them. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits19:27, 27 August 2017 (UTC)
I would suggest that the version of the template that 'worked' on 30 June did not, in fact, work correctly and that that version of the template merely masked the underlying problem of poorly curated data. I would also suggest that the new 'fix' is not the right fix. Granting this template the ability to grasp for a 'title' is poor practice that ignores the problem that this discussion was about: that this template did not render a title because the wikidata did not have a title property to be rendered. Wouldn't a better 'fix' make the template emit a message (and possibly a category) to notify editors when the wikidata are incomplete so that they may fix the underlying data?
That would be better, but unfortunately we suffer from push-back every time we attempt to deal with Wikidata problems by using Wikipedia techniques like messages (even when solely in preview!) or categories to record the issue. Such measures would simply be used as sticks to beat us with by those who are fundamentally opposed to making any use of Wikidata in Wikipedia. It's sad but the biggest difficulties in making progress are not the technical challenges, but the vitriolic opposition of Luddites. --RexxS (talk) 14:24, 28 August 2017 (UTC)
You may be correct when it comes to things like infoboxen that are 'old' and the users of those 'old' things have grown comfortable with the 'old' way of things. But this template is new. It is based on a suite of 'old' templates that do have messaging and categories so it is likely that the neo-Luddites (they aren't that old) won't notice. There is currently a discussion at WT:CS1 proposing to add a wikidata identifier paramenter to cs1|2 templates. One of the consistent comments in its predecessor discussions is "don't take citation data from wikidata" so it would seem that this template is the testbed where we can learn to do it right and by doing it right be proof against the neo-Luddites' torches and pitchforks. It is better to take the trouble here and now while this template is in its infancy because surely this kind of experiment will not succeed at cs1|2.
Yeah, that works. Thanks. Now I scratch my head on how to pull the volume number when P478 is inside P179 rather than on it own. I assume it's simple, and I'm just not familiar enough with the syntax. Here was my guess diff. Nfitz (talk)
(with some trial and error I figured that out in the sandbox (diff) though I'm troubled at where one pulls pval from presumably hard-wiring it isn't an option. I'm not even sure why Pval is necessary ... though no response is necessary, I'll muddle through it eventually). Nfitz (talk) 08:50, 29 August 2017 (UTC)
The reason why it's necessary to supply the value of the property for which you want the qualifier is that most properties can have multiple values. If you just consider the problem of fetching the date of marriage for someone who married more than once, you'll see why we need to know which spouse we want the marriage date for. When you've understood that, you can move on to the problem of Richard Burton (Q151973), who was married five times, but only had four wives. --RexxS (talk) 17:08, 29 August 2017 (UTC)
Not having metadata in the Wikitext
There is previous consensus to move away from using single identifiers as references to having the meta data within the text.[3]
I thus see this current template as against consensus. Can we simple add the wikidata code to "cite journal" and "cite book"?
Support - While identifiers can be useful, cite templates which only provide a code are not very useful to source readers/editors without consulting a third-party resource to resolve them. Citing them without a special tool is even less user-friendly. It makes sense to instead allow standard citation templates to optionally support those identifiers as an extra parameter. The HTML rendering can also be altered when such an ID is provided. —PaleoNeonate – 04:44, 15 September 2017 (UTC)
Oppose - it should eventually be added to cite journal, etc. But it's easier to debug in a separate template until then. Not sure what the issue for editors is. Certainly don't have to use it (as well people know, given the frequent use of just a ‹ref>URL‹/ref>). And if someone else has used it, you just click on the Q number. Looks a heck of a lot easier to edit to me, than trying to read through all the wiki markup for the correct reference, and remember the format, etc. Personally I'm tired of having the same reference in multiple articles, and constantly having to enter each one separately. Nfitz (talk) 23:30, 15 September 2017 (UTC)
Comment Nothing in this template (or by the use of this template) prevents Wikidata code also being added to other citation templates... Thanks. Mike Peel (talk) 23:49, 15 September 2017 (UTC)
In User:Carwil/Cite Q Sandbox, I try to create citations using Cite Q. Result: no authors. (The two examples are the 38th millionth Wikidata entitity and a journal article of mine.) Now, both these articles have "author name string" fields in Wikidata, not whatever Cite Q wants. But, in good faith, I would have just fixed this on Wikidata, except:
There's no documentation on Cite Q for what properties it queries
There's no form/template generated for using a journal article. The basic database functionality I expect is "X(Q38000000) is an instance of Y(journal article)" so here is a list of properties of journal article properties for you to fill out when editing X.
The Zotero-to-QuickStatements script I used to create Q38229173 failed to tell me anything about these properties.
A list of properties used by Cite Q has now been provided. None of the rest of this has anything directly to do with this template, nor indeed Wikipedia, and your concerns are being addressed where you raised them on Wikidata. I suggest we centralise discussion of how to do things on Wikidata there. (I'm also not clear what you expected a Zotero script to "tell" you?) Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits22:22, 19 September 2017 (UTC)
Issue with erroneous links in WhatLinksHere for author and editor names (work-around in place)
This isn't the template causing the problem. The so-called "error" is produced by {{Wikidata}} which supplies references to {{infobox telescope}}. Check:
Module:Wd (lines 639–706) has to check whether an author's name returned from Wikidata can be linked to an article on English Wikipedia. So it examines the object representing Arthur Berry, which it discovers is a dab page, so doesn't link it. However, the act of checking creates a link - see MW:Extension:Scribunto/Lua reference manual#mw.title.new: "The title referenced will be counted as linked from the current page." That's part of the way that the MediaWiki software works, so the solutions are to either file a phabricator report and ask for that behaviour to be changed, or to modify DPL bot to ignore these false positives. Hope that helps.
That's true, Mike. I've now seen that {{Wikidata}} also calls {{Cite Q}} so commenting out the code in Cite Q will solve some of the potential to create spurious links. Nevertheless, the mechanism I described above remains as far as I can see. --RexxS (talk) 15:54, 30 September 2017 (UTC)
Author names missing when not wikidata entities (yet) but "author name string" is used
They are in wikidata ("author name string"), but not displayed here.
As far as I can tell, this requires some major work on the Lua CiteQ module: Some articles may have bothauthor (P50) (linked author entities) and author name string (P2093) fields (authors that do not yet have a Wikidata entity, but are only available as a string) at the same time. Also, the correct order of authors must be ensured, this needs to be done via the series ordinal (P1545) qualifier. Chire (talk) 16:19, 28 September 2017 (UTC)
Ping @Pigsonthewing, RexxS, and Trappist the monk: I modified the module to support author name string (P2093) (but preferring author (P50) if using the same series ordinal), and out-of-order author names with series ordinal (P1545) qualifier. It was a bit easier than expected to access this data; no additional wikidata lookups are needed. Can you have a look and double-check? The test cases looked fine, so I copied the changes to the live module already (because it adds author names to cases where we did not have author names, such as the one at the top of this section). There is a warning (access-date and accessdate) that is unrelated to my changes, and that I could not locate - probably in the underlying citation templates. Chire (talk) 16:22, 10 October 2017 (UTC)
@Trappist the monk: that is an easy change, just remove the "if" statement that checks if a name is already present at the given ordinal. author (P50) is processed first, author name string (P2093) as fallback, and the latter currently does not overwrite. As names and links are two arrays, it would only overwrite the name, which you seem to prefer (my reasoning was that if both author (P50) and author name string (P2093) exist for the same ordinal, probably author name string (P2093) was just not yet removed - so I added an "if" to not overwrite).
Can you give a test case? note that the property description says "Preferably use a specialized property like official website P856, reference URL P854, or archive URL P1065. Otherwise, qualify with P642." Chire (talk) 11:40, 13 October 2017 (UTC)
Google books? I don't think a Google books URL should be in Wikidata as URL (P2699) either (as the book doesn't "own" that URL), but rather you should use Google Books ID (P675). One could then also generate links to Google books (but I don't think we should promote it that much over other services). But you should be able to use {{Cite Q|Q15625490|url=...}} when e.g. you need to even link to a particular page and Google Books is the best/only url you can find. --Chire (talk) 15:19, 13 October 2017 (UTC)
Multiple editions of the same book
E.g. Stuart J. Russell; Peter Norvig (1995), Artificial Intelligence: A Modern Approach, Prentice Hall, OL2896994W, WikidataQ20049394 (and yes, this book has its own Wikipedia article...) of this book there are multiple editions (in particular, ed 2 and 3) that are popular and often cited. For page numbers, the edition makes a big difference. It would be good to allow {{cite Q|Q20049394|edition=2}} and automatically get, e.g., the ISBN from edition 2 rather than 3.
I like the idea of being able to easily refer to the different editions this way, but would prefer something that doesn't require coding a new template for each book with multiple editions. — Preceding unsigned comment added by 89.12.179.16 (talk • contribs) 22:50, 4 November 2017 (UTC)
Now that this module is officially copied to Wikidata, and it is being updated and overwritten there from this source, I guess I need to report errors affecting the Wikidata version here. The problem is that on Wikidata when language is set to something different than English, the P577 reading {{ #property:P577 |from={{{1}}} }} leads to an error. I think this section might need to be replaced by a lua script that reads this property in a language-independent format.--Pzgulyas (talk) 20:37, 19 March 2018 (UTC)
What are the obstacles to displaying last name, first name
I have worked in IT since 1990, the first 1½ decades in software development. I also as a part-time university librarian for 8½ years. I have an MS in Library & Information Science. While I am competent in several scripting languages, I am unfamiliar with Lua.
I positively bristle when ever I see a citation that lists the first name first. That is simply not MLA style, APA style, or typical of most citation templates.
I thus would like to ask then, what are the issues in using the author (P50) to retrieve the author's data item, then to display family name (P734), given name (P735) from that.
My suspicion is that whatever difficulties exist, they are primarily a data problem & not a module coding problem. If that is the case, I want to work to correct things so that we can have a citation module that will conform with how most of the rest of the English speaking world does citations.
Thanks for whatever response or attention that you can give to this.
@Peaceray: As I understand it, there are two issues, one on the coding side the other on the data side. On the coding side, it's computationally cheaper to just fetch the reference item and display info from that; the label and the link for the author come free with that. To fetch P734 and P735 you need to do an extra (expensive) query to fetch those from the author's Wikidata entry. Perhaps @RexxS: can comment more on that - perhaps it would be worth it here (although when there are a lot of references in an article that do this, that could become a problem). On the data side, the main issue is with the family name - as that wasn't ranked very high in the list of suggested properties to add, it isn't in as many entries as would be useful. Given name is less of an issue. For comparison, see commons:Category:Uses of Wikidata Infobox with no family name and commons:Category:Uses of Wikidata Infobox with no given name - the former has 4240 entries at the moment, the latter 645 (out of something like 8,000 in total in this sample right now, although I can't be precise about that number). Thanks. Mike Peel (talk) 21:47, 20 April 2018 (UTC)
Reasons:
This template not widely supported; no one makes claims for its accuracy at this point
Template is presenting author names in the way that Wikidata presents them, which is by item name
It seems less racist / discriminatory to take no action and accept the default than to assume that the second part of a name is the surname. People are less likely to assign blame to a technological default than to a conscious design choice.
There is not strong technological investment in any particular system until and unless community consensus makes a recommendation. There is no foundation of community of discussion for this template yet. You are starting that now.
Wiki is already transgressive with citations. For example, wiki took the shocking position that hyperlinks could be a part of a citation, which used to be an unthinkable taboo. It is within the realm of possibility that Wiki consensus could also promote diversity by using Wikidata entries as they are, which would always the correct presentation of an author's name without having to worry about first or last name order, whether a name is even in Latin text, or other considerations aside from using the preferred name for an individual.
Yes, this template is infrequently used; the question is that it can be made more useful in a way that will encourage its use
Presenting the author name as currently listed in Wikidata is out of sync with other citation templates, plus APA & MLS styles. People are unused to presenting the author first name first, & this template continuing to do so will guarantee that it will not be used. We are simply not going to change the de facto standard of last name first.
I see nothing inherently racist with placing the last name first. There are issues with multi-part surnames, but APA & MLA have developed what I consider to be neutral rules around this.
Yes, I am starting this discussion. The obvious thing about putting a well-formed citation into Wikidata & retrieving it from there via a template/module is that the entry work is done once, the retrieval is relatively trivial, & the result will produce a uniform & informative result in all articles. Yeah, it's the standard relational data model, write once, read many, when modified the change will be reflected everywhere.
The problem is that whatever transgressions that exist with citations in Wikipedia today, we will fail to alter the status quo if we fail to identify the appropriate use cases around this & to develop a consistent approach.
@Peaceray: I misunderstood what you wanted and I gave information which is not the most urgent. I think your question actually is how can we increase adoption of this template. First name / last name is not the barrier to adoption.
meta:Wikicite is a project to host all Wikimedia citations in a database. This project is rapidly accumulating momentum on several fronts and if no one else takes further action then the crowdsourced activity of that project will still force the issue. If you want to expedite the process then engage in any way you like. Developing the conversation here is a great idea.
{{Cite doi}} is the attempt to sort citations prior to Wikidata. There were a series of problems. Instead of only starting new discussions, consider taking what worked from those discussions and use them as precedent.
Wikipedia almost certainly will force a re-think of how a standard citation appears. The traditional citations systems lack URLs and that old way has to go. Probably wiki citations will include identifiers, like dois or PMIDs, or perhaps just a Wikidata item number. Probably wiki citations will include some kind of button to jump to Wikidata so that any user can edit a citation. Prepare the world to be flexible to redesign citations for the digital age, perhaps with the Wikimedia community itself dictating the style that the world should use.
First name change for a transgender author (different or same initials)
Other legal name change not described above. (For example Angelina Jolie Voight-->Angelina Jolie)
Two-part surnames (or multi-part)
Is the middle name a given name or associated with the surname?
Jr., Sr., enumerators, or other suffixes
Single name (instead of last & first names)
Pseudonyms
Representation of original language name & work title, along with translation into the Wikipedia's language, as done currently via the trans-title parameter
MLA style suffers from schizophrenia: for the first authors, it puts the last name first, for the remaining authors it puts the first name first. Putting the last name as sort key first has slight benefits, but these are disappearing with the use of computer technology that can sort data for us, and with full text search in PDF files...
So there just is no "right" way. Some prefer first names first, other last names, other only the first last name first... I am pretty certain that it has been proposed at least once to make the citation style user configurable.
From a technical point of view, the solution of using the name as given by the Wikidata database - usually in the form first name, last name, and not doing any hacks to change this - clearly is the easiest. Chire (talk) 12:50, 23 April 2018 (UTC)
@Chire: Thanks for your response. OK, so just to let you know from where I am coming, my BA is in Psychology & English (hence my preference for the APA style) & my MS is in Library & Information Studies, I was a part-time reference librarian for HPU (my night & weekend job for awhile), & an Instructor for a few cohorts at the University of Phoenix, which requires APA-style citations. It is IMHO that last name, first name (or initials) is the predominant style. While I was not able find an article exactly on this subject using a "citation style" predominating OR prevalence search in Google scholar, a Google search on "citation style" predominating OR prevalencereturns a lot on APA.
But putting aside my bias, academically & professionally prejudiced as it may be, what is the standard in English Wikipedia?
I'd say that gets a resounding "Well, it depends ..." Certainly if one uses most citation templates & puts in the |last= & |first= parameters, it will be displayed as last name, first name. If one neglects those parameters & instead enters first name, last name order in |author= or manually does the citation in first name, last name order, then will see the first name first. Of course, there are a substantial number of citations using the author parameter or are handcrafted that do uses last name, first name order.
In practice, I think we would be accurate to conclude that last name, first name is the a la mode if not the de facto standard in English Wikipedia. In this regard, Template:Cite Q / Module:Citeq together are an outlier.
There is certainly more important things than this (as mentioned above, there is no right way), so I am not going to waste my time on something that takes this much effort (you cannot "just" naively output last name and first name, it will likely still be wrong in 10% of cases) & that gains me nothing. In particular, since I prefer first names first myself. I am certain the subject of the "right" way to cite has been discussed extensively all over Wikipedia, not just in this template: WP:CITESTYLE says "Wikipedia does not have a single house style" and "A number of citation styles exist". If you want, you can follow the rabbit into the hole of style wars.
I agree that for the purpose of having consistent references within each article, there should be an option - preferably an article-wide option, and as a fallback an option to the template - to control the order of names. But as mentioned above, I am not going to do this (I'm fine with inconsistently ordered first and last names, too), and it will require considerable effort to handle all the special cases of naming.
In fact, the use of the first name, last name etc. fields can be even more problematic. Consider the following case: the article was written by author "Arthur Example"; the name as printed on the article is "A. Example", but the author got married afterwards and is now known by the name "Arthur Evil". So just using "last name" + "first name" from the author database will incorrectly cite this as "Evil, Arthur". It's not just a simple fix (it will likely involve adding several new properties to Wikidata, and update the entries of lots of database entries manually) that is necessary here. It's a rabbit hole, and I will certainly not jump into this (in particular, as I do not "know" any Lua really either). I prefer an easy solution, even if it means that some articles get cited "first last", and others "last, first" within the same Wikipedia article. That is just cosmetics and not worth the trouble. Chire (talk) 12:54, 24 April 2018 (UTC)
@Peaceray: it is actually much much worse than I even imagined. Consider, e.g., Jeffrey T. Williams (Q17496406). While we have fields "last name" and "given name", we would lose the middle initial. Both the given name and the last name point to entities (of kind family name, first name), they are not strings. So this adds at minimum two more database roundtrips, and we would then get only "Williams, Jeffrey" not "Williams, Jeffrey T.". Furthermore: we have no idea what the name actually on the article was. It could have been a pseudonym. We would rather want to cite the article as printed on the article: the name data of the author in Wikipedia may have well changed for various reasons mentioned above (e.g., marriage). Now even if we reliably had the exact spelling of the author names on the paper, it would likely be "first last" and not "last, first" in many cases. So we would need a million monkeys to annotate all papers with "author name in last, first order" alternatives for each author name. And we cannot rely even on trained monkeys to do this right, as some cultures (e.g., Kim Jong-un, Ban Ki-moon) seem to default to "last first" with no comma; the last names there are Kim and Ban - most americans would get this wrong... Chire (talk) 11:57, 18 May 2018 (UTC)
masking when both author and author string present
It appears, from my limited experience, that the masking only replaces the author(s). Is there a way to mask the author string? Thank you. -Trilotat (talk) 13:07, 24 October 2018 (UTC)
Example beolow shows "author-mask" and "author name string" present. Note that there is no separation semicolon; perhaps a problem for another comment.
——, Title{{citation}}: |author= has generic name (help)
When there are multiple names to be masked, cs1|2 requires multiple |author-mask= parameters. That there is no author separator when |author-mask= is used is intentional else the rendered citation would not read correctly as here:
{{Cite Q| Q57403877 |author-mask=Longwell, C.R. with |author-mask2=Mound, M.C.}}
I'm confused. It seems the DOI in Cite Q is not the same as in the Wikidata item. See below. The DOI displayed doesn't match the DOI you'll see in the specified QID.
Trilotat, no. It is changing the value in Wikidata, 10.1130/0091-7613(1974)2<5:OPACCO>2.0.CO;2 to 10.1130/0091-7613(1974)2<5:OPACCO>2.0.CO;2, which is invalid.
The DOI value works from the DOI identifier in the Wikidata item Q58819281.
Trappist the monk, so is Wikdata passing the percent encoded string? I can click on the DOI value in Wikidata & it goes to the correct web page. If I click on the percent encoded string hyperlink above, I get a "DOI Not Found" error. Peaceray (talk) 09:53, 21 November 2018 (UTC)
I misspoke: not percent encoding; some characters have been replaced with their html numeric entities.
I don't know, that's beyond my ken. I'm guessing that the code that drives {{#property:}} at MediaWiki(?) has been recently modified to html encode doi values? It seems unlikely that wikidata is doing anything untoward with the doi. wikidata does percent encode the doi value when it makes the url that it displays:
Can we revisit this issue? I see that the template is still converting the greater than and less than into "html numeric entities" as Trappist the monk suggests.
Then you can suppress the pmc field in any article by adding |suppress=pmc, and so on (assuming you use the sandbox version or update the main version). Cheers --RexxS (talk) 18:49, 19 March 2019 (UTC)
