Jump to content

Template talk:Cite Q/Archive 2

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia
Archive 1Archive 2Archive 3Archive 4Archive 5

Linking to Wikisource transcriptions

Chunliang Lyu and Slaporte, thank you for implementing this on The Register-Guard. Great to have an example of how to use it on an article I know well. I followed your example and added a cite q footnote for the Turnbull book, and I figured out how to add a chapter to it (following the example of how you used pages). I was even able to manually link to the chapter on Wikisource. However, I'm curious whether cite q can be made to automatically link to the whole work on Wikisource in the "title" item (which is how I've been linking this book in other Wikipedia articles)? -Pete Forsyth (talk) 20:25, 30 November 2018 (UTC)

@RexxS: Any suggestions? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 11:47, 19 March 2019 (UTC)
@Andy: Currently you have this for History of Oregon Newspapers (Q56862211):
  • {{cite q|Q56862211|chapter=[[s:en:History of Oregon Newspapers/Lane County|Lane County]]}}
  • George Stanley Turnbull (1939), "Lane County" , History of Oregon Newspapers, Binford & Mort, Wikidata Q56862211
Using the sandbox, you could do this:
But I'm not sure of the consequences for pollution of metadata. Obviously you could specify both |title= and |chapter=.
Doing the linking to Wikisource automatically is possible, but do you really want to do that for every citation? What do you want to happen if there's a url to the source? --RexxS (talk) 17:24, 19 March 2019 (UTC)
Just as an afterthought, we have a call that fetches the sitelink from a wiki if the link exists:
  • {{#invoke:WikidataIB |getSiteLink |wiki=enwikisource |qid=Q56862211}} → History of Oregon Newspapers
Compare with:
  • {{#invoke:WikidataIB |getSiteLink |wiki=en |qid=Q56862211}}
That could be used to construct a link to the wikisource entry like this:
So that can be accomplished in the template without changing the module. --RexxS (talk) 18:20, 19 March 2019 (UTC)
@Peteforsyth: That was your question... Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 18:31, 19 March 2019 (UTC)
This is excellent. Thank you Pigsonthewing for nudging it forward and for the ping. RexxS, I think I agree with all your analysis. I don't fully comprehend the part about detecting pages on wikis, but that's OK. For the chapter= and title= examples, do these parameters simply override the parameters {{cite q}} would typically auto-fill for those parameters? If so, that really seems like a "best of both worlds" approach. Much appreciated. -Pete Forsyth (talk) 06:33, 20 March 2019 (UTC)
@Peteforsyth: The detecting part is simply to show how we could automate fetching a link from Wikisource. If you're content to provide the appropriate values for |title= and |chapter= as required on an article-by-article basis, then all we need do is update the template from its sandbox. --RexxS (talk) 17:37, 20 March 2019 (UTC)
Oh, I had missed that your example was in a sandbox. Yes, I think article-by-article is fine (ideal, actually, for the reasons you state). I'll watch to see when it goes live. In the meantime, I've pretty well addressed the specific thing I wanted to do by using {{sfn}}, here. -Pete Forsyth (talk) 20:00, 20 March 2019 (UTC)

With "journal=", add "published in" or "in" between article and journal titles

I'd like to show Q65590332 as "published in" or "in" Q61049071. Here is what Cite Q generates:

John P. Albers; J. H. Stewart, "Precambrian(?) and Cambrian stratigraphy in Esmeralda County, Nevada", Short papers in geology, ...

I expected the word "in" to be between the article title and the journal title, but it only puts a comma there. Unreasonable? Trilotat (talk) 21:06, 16 July 2019 (UTC)

According to the Cite Q template docmentation, it is a wrapper for {{Citation}}. So it just generates parameters which are used to transclude the {{Citation}}. The final presentation to the reader, including the absence of "published in" or "in" is determined by the Citation template.
It isn't realistic to do anything else. If Cite Q had it's own unique style, it would be considered improper to mix it with Citation templates, because articles should have a consistent citation style within a single article, although the style need not be consistent between different articles.
Thus, if Cite Q were inconsistent with Citation, one couldn't use Cite Q unless every single source had a correct Wikidata entry. If it's an existing article, chances are it wouldn't be possible to create a correct Wikidata entry for every source, because some of the sources would be hard to gain access to, and the editor who originally added the source might not be reachable. Jc3s5h (talk) 21:32, 16 July 2019 (UTC)

Bug when bibcode includes "&"

For example, {{cite Q|Q28315126}} returns this for the oldid=888064538 version:

Floor van Leeuwen (2007). "Validation of the new Hipparcos reduction". Astronomy & Astrophysics. 474 (2): 653–664. arXiv:0708.1752. Bibcode:2007A&A...474..653V. doi:10.1051/0004-6361:20078357. ISSN 0004-6361. Wikidata Q28315126. The problem is that the bibcode "2007A&A...474..653V" was recovered from Wikidata as "2007A&A...474..653V". Urhixidur (talk) 20:52, 3 July 2019 (UTC)

Oh, and why is it the code does not at least try to get the first and last name breakdown from the 'author' wikidata value? For example, the author of Q28315126 is Q63615173 and the latter does have first ({{#property:P735 |from={{{1}}}}}) and last name ({{#property:P734 |from={{{1}}}}}) values. Urhixidur (talk) 21:08, 3 July 2019 (UTC)

If I remember correctly, #property actually returns the html entity
  • {{#property:P819 |from=Q28315126}} → 2007A&A...474..653V
Perhaps try replacing the | bibcode = #property with the corresponding Lua function, which I don't think suffers from the same problem. It also doesn't use an expensive parser function:
  • {{wdib |ps=1 |P819 |qid=Q28315126}} → 2007A&A...474..653V
There's also a function to get properties of a property:
  • {{#invoke:WikidataIB |getPropOfProp |fwd=ALL |osd=n |qid=Q28315126 |prop1=P50 |prop2=P735}} → Floor Edit this on Wikidata Edit this on Wikidata
  • {{#invoke:WikidataIB |getPropOfProp |fwd=ALL |osd=n |qid=Q28315126 |prop1=P50 |prop2=P734}}van Leeuwen Edit this on Wikidata Edit this on Wikidata
Hope that helps. --RexxS (talk) 00:18, 4 July 2019 (UTC)
According to #ifeq:, {{#property:P819|from=Q28315126}} and {{wdib|ps=1|P819|qid=Q28315126}} are identical. Inspecting the HTML it seems the substitution of &A for &A is done by module:citeq. However, I made a copy of template:Cite Q and substituting {{wdib |ps=1 |P819 |qid={{{1}}} }} for {{#property:P819 |from={{{1}}} }} does fix the problem! Urhixidur (talk) 15:43, 22 July 2019 (UTC)
Someone better at this should modify module:citeq so it tries to look up firstn and lastn before falling back on authorn. I tried modifying Template:Cite Q to set first when getPropOfProp works but it complains that author1 and last are set. Urhixidur (talk) 16:15, 22 July 2019 (UTC)

<i></i> tags

Wikidata stores italics using <i></i> tags. Accordingly, this template should output text between the tags as italics, but it currently outputs the tags themselves as text. See example at Cryptic myotis#Literature cited. – Finnusertop (talkcontribs) 09:57, 24 August 2019 (UTC)

@Finnusertop: It's a constraint violation to store html tags such as <i>...</i> in the value for title (P1476), so they are likely to be removed.
Nevertheless, if you want to retrieve values that have the markup parsed as usual, then use Module:WikidataIB or its wrapper {{wdib}}:
  • {{#property:P1476 |from=Q61718059}} → Two new cryptic bat species within the Myotis nattereri species complex (Vespertilionidae, Chiroptera) from the Western Palaearctic
  • {{wdib |ps=2 |P1476 |qid=Q61718059}} → Two new cryptic bat species within the Myotis nattereri species complex (Vespertilionidae, Chiroptera) from the Western Palaearctic
Wdib also has the advantage of not being an expensive parser function call, unlike #property. --RexxS (talk) 17:17, 24 August 2019 (UTC)
Thanks, RexxS, but rather than this workaround, is there a way to add italics without violating Wikidata's constraints? Also, I'd expect Wikidata to display an error for this, like it does for other constraint violations, but why doesn't it do so here? – Finnusertop (talkcontribs) 17:31, 24 August 2019 (UTC)
@Finnusertop: It's not a workaround; it's a solution. I've spent six years developing a module that retrieves information from Wikidata in a way that fixes the issues apparent with #property. The whole point of having Lua available is so that we are not limited to one call. If the developers of {{Cite Q}} prefer to use #property, then you'll have the unnecessary problems caused by #property's handling of markup, html entities, etc. when you use Cite Q.
If you want one or two words in a title in italics, you'll need to store some markup to indicate that the word(s) are italic. There's no way around that. So if Wikidata insists on constraining titles to plain text, then you obviously can't have italics without violating those constraints.
Your expectation of Wikidata is accurate: if you look at Two new cryptic bat species within the Myotis nattereri species complex (Vespertilionidae, Chiroptera) from the Western Palaearctic (Q61718059), and scroll down to title (P1476), you'll see an exclamation mark inside a circle next to the value. That is clickable and pops up the following message:

format constraint

The value for title (Two new cryptic bat species within the <i>Myotis nattereri</i> species complex (Vespertilionidae, Chiroptera) from the Western Palaearctic) should match “remove html formatting from title (italics tag)” (regex: (?i)((?!\b(<i>|</i>)).)*).

which is Wikidata's way of telling you that the value violates a constraint for that property. It's not an error message, because it's not an error. You can have a title with italic tags inside it on WIkidata, but you shouldn't be surprised if somebody or somebot removes them. --RexxS (talk) 18:12, 24 August 2019 (UTC)
I've removed the HTML markup from the value on Wikidata. Please raise a WP:Phabricator ticket if you want Wikidata to have HTML content. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 19:03, 24 August 2019 (UTC)

author_link= when using author=

Can someone add description for using author_link= if using author=? Example, if I want to put the author's last name first, I have to use "author=Last, First". If that author also has a wikipedia article, I can only generate the link if I use "author_link=" (correct?). Can someone add that to the template? Trilotat (talk) 19:56, 1 September 2019 (UTC)

I just realized that I have to put the item's url in P856 so that the reference has a link. I thought P953 was the method. I have to do a lot of edits now... Trilotat (talk) 01:17, 7 September 2019 (UTC)

Requested move 11 September 2019

The following is a closed discussion of a requested move. Please do not modify it. Subsequent comments should be made in a new section on the talk page. Editors desiring to contest the closing decision should consider a move review after discussing it on the closer's talk page. No further edits should be made to this discussion.

The result of the move request was: consensus to move the module. Will move momentarily. (closed by non-admin page mover) DannyS712 (talk) 03:50, 1 October 2019 (UTC)



– Modules should have the same name as the templates they implement. * Pppery * it has begun... 01:30, 11 September 2019 (UTC)


The above discussion is preserved as an archive of a requested move. Please do not modify it. Subsequent comments should be made in a new section on this talk page or in a move review. No further edits should be made to this section.

Marking fields for omission

@RexxS, Pigsonthewing, and Mike Peel: Is there a way to mark fields for omission? E.g. For some journal articles, the handling editor is known (example), but doesn't make sense to include in teh citation for a journal article. Is it possible to say implement something like {{cite Q | Q12345 | editor1 = OMIT}}? It might possibly also be useful more broadly (e.g. in Module:WikidataIB). T.Shafee(Evo&Evo)talk 02:41, 24 February 2020 (UTC)

@Thomas: Module:WikidataIB has always had the ability to suppress given fields using the |suppressfields= parameter.
However, if you take the example of The Defensins Consist of Two Independent, Convergent Protein Superfamilies (Q47301333), when you examine author (P50), you find that all of the authors are listed equally, so there is no indication that any of them is a "handling editor":
  • {{wdib |ps=1 |P50 |qid=Q47301333}} → Thomas Shafee, Fung Lay, Mark D Hulett, Marilyn Anderson
Logically, we can only filter if there is a marker that distinguishes them. Wikidata has properties editor (P98) and editor-in-chief (P5769), but nothing that seems to fit the property you're looking for. You could add a qualifier to an author, but the complications of filtering on qualifiers means that WikidataIB lacks that feature. Perhaps others have an idea for a solution? --RexxS (talk) 16:59, 24 February 2020 (UTC)
@RexxS: Thanks for the insight. In this case, I'm referring to wikidata:Q47301333#P98 (indicated right down at the bottom of this page).
{{cite Q|Q47301333}} → Thomas Shafee; Fung Lay; Mark D Hulett; Marilyn Anderson (13 June 2016). Xun Gu (ed.). "The Defensins Consist of Two Independent, Convergent Protein Superfamilies". Molecular Biology and Evolution. 33 (9): 2345–2356. doi:10.1093/MOLBEV/MSW106. ISSN 0737-4038. PMID 27297472. Wikidata Q47301333.
So I guess somewhere in the code of Module:Cite Q it could react to whether an item is a subtype of book or journal article when deciding whether to display P98. Alternatively, some sort of implementation of {{cite Q|Q47301333|suppressfields=P98}}. T.Shafee(Evo&Evo)talk 08:59, 25 February 2020 (UTC)

Marking anchor for omission

Is there a way to remove the creation of a harv anchor? For Cite_Q items that are included in footnotes but not cited inline, an error is displayed for those using any scripts to show harv errors. T.Shafee(Evo&Evo)talk 02:14, 1 March 2020 (UTC)

|ref=none
{{Cite Q|Q15625490|ref=none}}
Jeffrey T. Williams; Kent E. Carpenter; James L. Van Tassell; Paul Hoetjes; Wes Toller; Peter Etnoyer; Michael Smith (21 May 2010). "Biodiversity Assessment of the Fishes of Saba Bank Atoll, Netherlands Antilles". PLOS One. 5 (5). Bibcode:2010PLoSO...510676W. doi:10.1371/JOURNAL.PONE.0010676. ISSN 1932-6203. PMC 2873961. PMID 20505760. Wikidata Q15625490.{{cite journal}}: CS1 maint: unflagged free DOI (link)
Trappist the monk (talk) 02:25, 1 March 2020 (UTC)
Trappist will correct me if I'm wrong, but {{Cite Q}} is designed to directly make use of the {{Citation}} template, so will be capable of using just about all of the functionality of that template (present and future). For example:
You get the same harv error whenever anyone uses the {{Citation}} template itself without a link pointing to it. HTH. --RexxS (talk) 13:16, 1 March 2020 (UTC)
Thank you! Exactly what I was looking for. T.Shafee(Evo&Evo)talk 10:55, 5 March 2020 (UTC)

use P1932 qualifier of P50

If a P50 value has P1932 qualifier, can we show P1932 value instead of P50 label?--Njzjz (talk) 22:47, 5 April 2020 (UTC)

i.e. something like [[P50 link|P1932 value]].--Njzjz (talk) 22:49, 5 April 2020 (UTC)
@Njzjz: We can, but is there any chance of a concrete example? --RexxS (talk) 00:17, 6 April 2020 (UTC)
For example, {{cite q|Q59348150}} shows Don Page[1], but I think it's better to show Don N. Page since Don N. Page is the name which he used on his paper.--Njzjz (talk) 00:52, 6 April 2020 (UTC)
I notice that this feature has been already in the issues section of the document...--Njzjz (talk) 23:48, 20 April 2020 (UTC)

References

  1. ^ Don N. Page (April 1981). "A periodic but nonstationary gravitational instanton". Physics Letters B. 100 (4): 313–315. doi:10.1016/0370-2693(81)90094-0. ISSN 0370-2693. Wikidata Q59348150.

Formatting date based on item type

Citations of journal articles typically only quote the year. What do you think of the draft implementation I've made in the sandbox? T.Shafee(Evo&Evo)talk 12:53, 21 May 2020 (UTC)

I have not looked at your changes to the sandbox. But I disagree with your claim that citation of journal articles typically only quote the year. The month is often given. Also, the distinction between a journal and a magazine is often a matter of opinion.
Until 2015, {{cite magazine}} was just a redirect to {{cite journal}}, so many editors are accustomed to using "cite journal" for all periodicals, and for periodicals other than academic journals, it is certainly customary to cite a more specific date, such as the year and month, or year, month, and day. Jc3s5h (talk) 14:56, 21 May 2020 (UTC)
It might be a sciences versus humanities thing, but >90% of the science journals I read just round to year. Just the year is used by the MLA, APA, Chicago, Harvard styles as well as the the styles used in Nature, Science, PLOS, BMC. As far as I've found, only Vancouver style includes month. Cite Q has the opportunity to do some autoformatting based on item type in addition to date format (e.g. inclusion of editors for books but not journal articles). T.Shafee(Evo&Evo)talk 23:52, 21 May 2020 (UTC)
Chicago Manual of Style 17th ed. pp. 830-1 states "Most journal citations include volume, issue number or month, and year." Of the six examples given, five include both the month and issue number. Jc3s5h (talk) 00:42, 22 May 2020 (UTC)
Definitely true, although inclusion of month (or season) is optional (examples). In journals that use the CMOS, almost all just cite just the year. Since inclusion of month/season is optional, I'd argue the simpler year-only option appears the more relevant choice. Month and season are decreasingly useful, as the exact dates when an item is accepted, published online, and assigned to an issue typically differ, and season is hemisphere-specific, so year + volume, issue, page (and doi if available) are sufficient in almost all cases of citing journal articles. T.Shafee(Evo&Evo)talk 05:07, 22 May 2020 (UTC)

I'd like to give an example of a problem with not giving the month:

Current version of Cite Q:

This is one of those publications that's in between a journal and a magazine. I receive it in paper, and some readers will have access to paper copies in their library or personal collection. I don't remember how it was in February 2014, but the current paper copies do not include an issue number printed anywhere I can find. So a person trying to find an article with only an issue number for a recent story will have to engage in some guesswork about whether issue = 4 means April, or 4th quarter, or perhaps the publication year starts on some date other than January 1.

Could someone add a sandbox version of this article citation; I can't figure out the syntax. Jc3s5h (talk) 11:45, 22 May 2020 (UTC)

{{cite Q/sandbox | Q64386280}}
Eliza Strickland (February 2014). "The deepest dark detector". IEEE Spectrum. 51 (2): 20–20. doi:10.1109/MSPEC.2014.6729364. ISSN 0018-9235. Wikidata Q64386280.
If this discussion is about the 'Improve date formatting options' from Template:Cite Q § Issues then the proposed 'solution' isn't a solution. If it were determined that cs1|2 style for journal citations is best served by removing month (and consequently day if provided) from |date= when rendering those citations, such removal is better accomplished by making the necessary changes to Module:Citation/CS1. I don't think that removing date detail is a benefit for the reader.
Trappist the monk (talk) 14:09, 22 May 2020 (UTC)
To generalize my objection, editors often know better than algorithms. An algorithm doesn't really know if providing both a month and an issue number is a good idea for a particular publication, but the editor who searched the library stacks or her own closet for the issue knows the quirks of the publication and is the best judge of what citation information to include. Jc3s5h (talk) 18:00, 22 May 2020 (UTC)
Thank you for your patience in this. I'd not sufficiently considered the paper journal issue (I'm so used to just using the online version!). Given the opposition to the idea, I'm happy to drop it. T.Shafee(Evo&Evo)talk 02:39, 23 May 2020 (UTC)

brackets in doi

If there are brackets in the DOI, this template converts the bracket to something non-functional. See Coils Creek Limestone. What can I do to resolve? Thank you. Trilotat (talk) 01:58, 27 June 2020 (UTC)

See Template talk:Cite Q/Archive 2 #Bug when bibcode includes "&". I'm reasonably sure it's similar problem (url encoding), but the previous solution won't work. Fetching DOI (P356) from Stratigraphy and Correlation of the Lower Nevada Group (Devonian) North and West of Eureka, Nevada (Q63384738):
  • {{#property:P356 |from=Q63384738 }} → 10.1130/0016-7606(1970)81[127:SACOTL]2.0.CO;2
  • {{wdib |ps=1 |P356 |qid=Q63384738}} → 10.1130/0016-7606(1970)81[127:SACOTL]2.0.CO;2
They look the same; but they are not:
Of course the [ and ] in the doi screw up the wikiparser, so you can't see a proper result. The #property call returns encoded entities (%5B and %5D for [ and ]), so encodes the url acceptably for the link, but unacceptably for the display; while the Lua module (returning [ and ]) does just the opposite.
Anyway:
is the result you're looking for, but it too late at night for me to work out what changes would be needed to arrive at that. --RexxS (talk) 03:14, 27 June 2020 (UTC)
@Trilotat: Having thought about it some more, I checked manually how {{Citation}} handles [ and ]:
And, of course, it handles them fine. So I made a demo in Template:Cite Q/sandbox that replaced the #property with {{wdib}}:
That looks like it solves the issue. It seems the solution for the bibcode also solves this one. --RexxS (talk) 11:43, 27 June 2020 (UTC)
[Update] I've now amended Template:Cite Q with the fix, and Coils Creek Limestone looks okay to me now. --RexxS (talk) 11:55, 27 June 2020 (UTC)
@RexxS: thank you so much. Wonderful work. Trilotat (talk) 14:00, 27 June 2020 (UTC)

fix biorxiv

The biorxiv link should be updated to not cause an error. This should work for both old style (10.1101/123456)and new style links (10.1101/2019.12.11.123456). Headbomb {t · c · p · b} 18:26, 4 July 2020 (UTC)

Para to omit editors

Would it be possible to introduce a parameter to omit the editors? I'm going to start trying to include handling editors for journal articles, but of course it's not common for editors to be included in journal article citations. Example:

What do people think about omitting the "(ed.)" when |editor= is specified as blank? Alternatively including an |omiteditors= parameter? T.Shafee(Evo&Evo)talk 10:15, 14 August 2020 (UTC)

Better I think to use a keyword so that we don't have to support yet-another-damn-parameter-to-tweak-one-thing. Module:Template wrapper uses the unset keyword to accomplish what it is that you want to do here. I have adopted that convention in the module sandbox. Your unsuppressed original:
suppress editor rendering with |editor1=unset
for consistency, |author=unset:
and extending that to any other parameter that you want to suppress; for example, |doi=unset to suppress the doi:
  • {{cite Q/sandbox|Q76846397|doi=unset}}Ignacio L. B. Munguira (17 August 2019). Thomas Shafee; Ian Alexander (eds.). "Lysenin" (PDF). WikiJournal of Science. 2 (1): 6. ISSN 2470-6345. Wikidata Q76846397.
Trappist the monk (talk) 13:35, 14 August 2020 (UTC)
@Trappist the monk: Perfect, thank you! I'd not come across Module:Template wrapper previously. I'll now be able to solve similar issues in future. T.Shafee(Evo&Evo)talk 13:53, 14 August 2020 (UTC)
If there are no objections, I'll implement the sandbox edit to the main template next week. T.Shafee(Evo&Evo)talk 02:08, 16 August 2020 (UTC)

In a recent conversation, I discussed the issue that editors complain that they cannot see the contents of {{Cite Q}} in the wikitext to correct errors or update anything. My response was that the rendered text has a link to Wikidata which is where such changes can be made, but the counter-argument was that it's not actually obvious to an editor that they need to follow that link in order to edit the citation.

So I am wondering if there's any mileage in suggesting that the Wikidata link at the end of the rendered citation should be entirely replaced by the pen icon "edit on wikidata" that is used to indicate an editing link for items in infoboxes that come from Wikidata?

If editors are becoming used to following a pen-icon link to edit the related content on Wikidata in one context, would having the same icon for the same purpose be a sensible change? An incidental bonus might be that when Wikidata Bridge is implemented, the pen icon is ready for use as the trigger for in-place editing of the Wikidata content from within Wikipedia. The Lua code for the subroutine createicon() for the pen icon is around lines 794–811 in Module:WikidataIB.

This isn't a feature request: I just want to canvass opinion on whether folks think it's an improvement or not worthwhile. --RexxS (talk) 14:06, 14 August 2020 (UTC)

@RexxS: I'd support that, especially since they they're shown for infoboxes that draw from WD. At the very least show the edit icon for logged-in users (if it's even possible to implement that distinction). An alternative implementation that's likely even trickier would be that when editing in VE or source, clicking a QID should open that item in a new tab. T.Shafee(Evo&Evo)talk 02:08, 16 August 2020 (UTC)

Wikicite eScholarships to work on a new version of this template?

Hi all. This is an important template to use citation information from Wikidata/Wikicite, but it needs improvement - particularly those points raised during the deletion discussion. Wikicite is currently offering eScholarships to work on things remotely, analogous to how people might work together in person at a hackathon, and improving this template feels like it would fall in scope. I've started a proposal at meta:Wikicite/e-scholarship/Mike Peel (Cite Q improvements), if anyone is interested in joining in then you would be very welcome. It might be up to 4 days of collaborative work (probably at weekends) to improve the code and its documentation. Pinging some of the past editors of the template that might be interested: @Mvolz, Thayts, Jonesey95, Jytdog, Trappist the monk, and Chire: Thanks. Mike Peel (talk) 18:46, 1 September 2020 (UTC)

@Mike Peel: hi there! I'm currently working on Ruwiki's ru:Module:Sources which is a pretty advanced version of this module used on Ruwiki for such purposes. I was looking for a way of translating its templates to Enwiki and eventually was redirected to this template. Maybe we may collaborate and exchange with some best practices? I'd like to join in your activity, but am not really familiar with processes here. Can I be of any help? adamant.pwncontrib/talk 00:44, 2 September 2020 (UTC)
Totally agree that this needs to be moved forwards. In particular when editing a WP page, it should be possible to:
  • click a ref using cite_Q to see all of the fields (ideally in the same format as citoid in VE; image)
  • edit those fields either by the inferface:
    • opening a new tab for the wikidata item (or even just only the citation-relevant fields of the wikidata item)
    • or possibly even editing the wikidata fields directly without leaving the WP editing page
These might be more intuitive to editors than including an edit pencil to each reference in reading mode (see section above), but of course would be harder to implement. T.Shafee(Evo&Evo)talk 08:39, 2 September 2020 (UTC)
@Evolution and evolvability: I would love to see those features, but I don't think they will be possible within the scope of this activity. They would require modifications to MediaWiki itself, while I'm thinking about improvements to the Lua and template code only. If you're interested in Lua and template code improvements, please do sign up to the eScholarship in the next few days, but please do bear in mind the scope of the work. Thanks. Mike Peel (talk) 21:20, 18 September 2020 (UTC)
By the way it seems that Cite Q ignores full work available at URL (P953) and described at URL (P973) properties, is this intended? Also I see that it ignores qualifiers, as for published in (P1433) in Extended application of suffix trees to data compression (Q90427112). Specific pages and publication date can be gathered from there, but Cite Q doesn't do it. Another issue I see is with languages. Like it doesn't choose consistent language for author names and titles in foreign publications, such as:
adamant.pwncontrib/talk 12:05, 2 September 2020 (UTC)
To test the template I've translated one of my articles having full list of surces in Cite Q. You may compare how it look with Cite Q in enwiki and with Module:Sources in ruwiki. Quite different in many details adamant.pwncontrib/talk 05:02, 4 September 2020 (UTC)
@Adamant.pwn: Thanks for the comments and for signing up to the eScholarship on meta! I think your input and work will be very valuable here given your ruwiki experience. I've added more detail to the proposal on meta that includes looking at the different available properties, and testing things in a few articles. Please feel free to add additional points there, and I'm looking forward to working with you. :-) Thanks. Mike Peel (talk) 21:11, 18 September 2020 (UTC)

Last ping for @Mvolz, Thayts, Jonesey95, Jytdog, Trappist the monk, and Chire: - please let me know before the 20th if you are interested. Thanks. Mike Peel (talk) 21:25, 18 September 2020 (UTC)

Hi Mike Peel. Good initiative, but I pass. I'm too busy with a next version of Module:Wd already. :-) Thayts ••• 21:53, 18 September 2020 (UTC)

indicating preprint status in ref?

Is it worth indicating in some way that an article is a preprint if it is instance of preprint (Q580922)? Different journals have different house styles but a simple feature might just be to put "(preprint)" after the title, or maybe after the publisher name? Sometimes it's clear fro tyhe publisher (e.g. arXiv), but sometimes not (e.g. Frontiers journals). T.Shafee(Evo&Evo)talk 10:27, 20 September 2020 (UTC)

Do not corrupt the citation's metadata with extraneous text in |title= or any other parameter. If it is important to indicate that the source is a preprint, use |type=Preprint. The normal preprint templates ({{cite arxiv}}, {{cite biorxiv}}, etc) should not be so marked.
Trappist the monk (talk) 11:40, 20 September 2020 (UTC)
I agree, any information about publication status should be clearly separate from other data fields. The same should probably be true of "(retracted)" or "(superseded)" or other relevant publication status modifiers (I'm looking to try to better cover retractions in wikidata at the moment and hopefully then move to errata and corrigenda etc. - discussion). For the non-CiteQ templates, I like the cite_arxiv etc. templates, though there are dozens of preprint servers so having a separate template for each seems like overkill. T.Shafee(Evo&Evo)talk 09:05, 21 September 2020 (UTC)

Duplicate dates

One for the upcoming edit-a-hack-a-thon:

Updated world map of the Köppen-Geiger climate classification (Q21128894)

{{Cite Q|Q21128894}}

-- Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 19:13, 26 October 2020 (UTC)

Fixed. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 17:28, 7 November 2020 (UTC)

What would the Wikidata look like for

Hi @Pigsonthewing:What would the wkidata look like for Dampiera candicans for the reference <ref name=muell>{{cite journal|author=Mueller, F.J.H. von |date=1876|journal= Fragmenta Phytographiae Australiae |volume=10|issue=85|pages= 86|title= Goodeniaceae|url=https://www.biodiversitylibrary.org/page/762411}}</ref> I have to say I see it as atomised as title=Dampiera candicans|url=url=https://www.biodiversitylibrary.org/page/762411 despite there being no such title in Mueller. MargaretRDonald (talk) 19:42, 27 October 2020 (UTC)

@MargaretRDonald: Based on the data given in your markup above, I have created Goodeniaceae (Q100951786). {{cite Q|Q100951786}} renders that as:
F.J.H von Mueller (1876). "Goodeniaceae". Fragmenta phytographiae Australiae. 10 (85): 86, 10–13, 86–87. Wikidata Q100951786.
I'm not sure why you'd use |title=Dampiera, but if there is a genuine use-case, we could make {{cite Q|Q100951786|title=Dampiera}} over-ride the title - I can imagine, tough, that that might generate objections. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 20:21, 27 October 2020 (UTC)
Or to match the original...F.J.H von Mueller (1876). "Goodeniaceae". Fragmenta phytographiae Australiae. 10 (85): 86. Wikidata Q100951786. Thanks, @Pigsonthewing: MargaretRDonald (talk) 20:54, 27 October 2020 (UTC)
Just checked your lovely wikidata item. Thanks, @Pigsonthewing: MargaretRDonald (talk) 21:03, 27 October 2020 (UTC)
Isn't is Goodenoviaceæ or Goodenoviaceae?
Trappist the monk (talk) 21:06, 27 October 2020 (UTC)
Indeed it is, so possibly we need that as the title of Mueller's work or perhaps the atomistic approach of "title=Dampiera candicans"..... (Meanwhile I am leaving Andy's wikidata item alone.) MargaretRDonald (talk) 22:14, 27 October 2020 (UTC)

Problem when there is more than one value for URL or publication date

This template is causing a citation error at AmaBhungane because there is more than one URL. There was previously more than one publication date, but an editor at Wikidata modified the item to work around that problem. The workaround caused a second problem. This template should probably pull only the first available value for any given qualifier (or whatever the wikidata term is). – Jonesey95 (talk) 05:59, 7 November 2020 (UTC)

Wikidata item in question is Susan Comrie is the 2016 Sanlam Financial Journalist of the Year (Q56219959). Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 10:43, 7 November 2020 (UTC)
Fixed. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 17:27, 7 November 2020 (UTC)
Thanks for the quick fix! The change probably fixed other articles as well. – Jonesey95 (talk) 18:22, 7 November 2020 (UTC)

URL properties

@Pigsonthewing and Mike Peel: The url parameter should also pick up data from the properties full work available at URL (P953) and URL (P2699), as occasionally they might be the most appropriate properties to use. For a Wikidata item about a magazine article, for example, it would make no sense to use official website (P856). ~nmaia d 04:47, 11 October 2020 (UTC)

We're planning a sprint on this template in a couple of weeks; we'll look at this then. Meanwhile I've marked the edit-request template as answered, as you haven't provded any code for implementation. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 09:45, 11 October 2020 (UTC)
NMaia Do you have QIDs for test cases for this? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 10:27, 8 November 2020 (UTC)
Yes. Please look at the references over at Francisco Antônio de Almeida Júnior. But I think someone else has already implemented this improvement in the mean time. ~nmaia d 10:30, 8 November 2020 (UTC)
Indeed, but we need test cases to make sure we don't break it. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 10:55, 8 November 2020 (UTC)
I've added some examples from that article to Template:Cite_Q/testcases - there are some formatting issues we need to fix. Thanks. Mike Peel (talk) 11:15, 8 November 2020 (UTC)
@Mike Peel: Thanks. Do you mind also adding d:Q100160262? Not only is the formatting strange, but it's also not linking to Wikisource, which would be ideal. ~nmaia d 11:53, 8 November 2020 (UTC)
The link to Wikisource is not in {{Cite Q}}; I've added the use case under "issues". Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 11:55, 8 November 2020 (UTC)

DOI vs URL

Hi @Pigsonthewing:Taylor and Francis are putting work that is copyright free behind a paywall so XLVII.—Descriptions of sponges from the neighbourhood of Port Phillip Heads, South Australia, continued gets an automatic and correct doi if we use the cite Q template: H. J. Carter (June 1886). "XLVII.—Descriptions of sponges from the neighbourhood of Port Phillip Heads, South Australia, continued". Annals and Magazine of Natural History. 17 (102): 502–516. doi:10.1080/00222938609460181. ISSN 0374-5481. Wikidata Q56118073.. But I want my readers to go the BHL page (from the url parameter) I don't even want them to see that paywalled doi from Taylor and Francis. I realise I can add parameters and force the omission of others, but for works which are out of copyright and available on BHL I would prefer a default url to the BHL version of the article. I don't think we should be rewarding publishers who paywall copyright free material. MargaretRDonald (talk) 23:22, 27 October 2020 (UTC)

Masking the DOI

I am using {{cite Q}} and I have added the url parameter to take my reader to the BHL page, but I do not wish the reader to be seduced by the paywall DOI for an article which is out of copyright. Is there a possibility of masking the DOI and any other information leading to the paywalled article. MargaretRDonald (talk) 19:47, 28 October 2020 (UTC)

You shouldn't be using Cite Q to begin with since it's a terrible template, but suppressing DOIs shouldn't be done, because this information is useful to the reader. If you have a free link, certainly do provide it, but that's not a reason for DOI suppression. Headbomb {t · c · p · b} 20:40, 28 October 2020 (UTC)
@MargaretRDonald: Technically it's possible by including |suppressfields=doi. I disagree that the template is terrible, but I do think it's valuable to include the doi even though it throws readers at a paywall. Is there an open access version available in some repository? If so, adding full work available at URL (P953) to the wikidata item should make that the link applied to the title (which is what most readers click). Perhaps eventually it'll be useful to enable the option to use https://oadoi.org/... rather than https://doi.org/..., which automatically directs to an OA version if available. T.Shafee(Evo&Evo)talk 23:09, 28 October 2020 (UTC)
Thanks @Evolution and evolvability:. I didn't say that the template is terrible, nor do I think it is or I wouldn't be using it. (I thought I was suggesting improvements) Thanks for the help, because as I said, I do not wish my readers, however few, to be seduced by the paywalled article via the doi. MargaretRDonald (talk) 01:48, 29 October 2020 (UTC)
@Evolution and evolvability: I had a crack at using your suggestion, but clearly misunderstood it as I couldn't make it work. I am hoping you might be so kind as to go to Vosmaeropsis mackinnoni and make the necessary fiddle to <ref name=dendy>{{cite Q|Q64384613|url=https://www.biodiversitylibrary.org/page/31757612}}</ref> Regards, MargaretRDonald (talk) 01:56, 29 October 2020 (UTC)
@MargaretRDonald: Aha, my two errors. First, the command would be |doi=unset and secondly, this seem to have only been implemented in Module:cite Q/sandbox (I'll need RexxS to check if I'm missing why it's not wortking in the main module). See below the worked example that still has to use the sandbox version of the template:
In the meantime, I have gone over to wikidata:Q64384613 to add its full work available at URL (P953) link. T.Shafee(Evo&Evo)talk 04:14, 29 October 2020 (UTC)
Thanks so much. @Evolution and evolvability: The DOI issue was really irking me. But I love the concept of cite Q and it gives me a real motifvation to put up journal articles.. Cheers, MargaretRDonald (talk) 06:01, 29 October 2020 (UTC)
@Evolution and evolvability: Do you think you could also have the template pull URL (P2699)? This can be relevant when citing online magazine or news articles, for instance. ~nmaia d 06:51, 29 October 2020 (UTC)
@Nmaia: That's definitely possible! The only thing that will need to be decided is the priority order. Currently: the priority order is: First check full work available at URL (P953), then official website (P856), then URL (P2699). Now implemented in the sandbox version and main template. T.Shafee(Evo&Evo)talk 08:05, 29 October 2020 (UTC)
Checkmark This section is resolved and can be archived. If you disagree, replace this template with your comment. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 12:19, 8 November 2020 (UTC)

Using the sandbox

If I use {{cite Q/sandbox|Q95996348|pages=580}} will that ultimately work when the sandbox version is established? That is, without further adjustments from me (or anyone else). MargaretRDonald (talk) 19:39, 10 November 2020 (UTC)

It is never a good plan to use the sandbox version of any template in article space because the sandbox can be changed and broken by anyone at any time.
Trappist the monk (talk) 19:47, 10 November 2020 (UTC)
@MargaretRDonald: As Trappist says, it's never a good plan to use the sandbox in article space. That reference renders identically in the sandbox and the main version at the moment (we updated the main version over the weekend), so you should be able to use the main version now? Thanks. Mike Peel (talk) 20:31, 10 November 2020 (UTC)
Thanks. @Mike Peel:, @Trappist the monk: MargaretRDonald (talk) 20:40, 10 November 2020 (UTC)

Wikispecies

I have just tried to import the template to Wikispecies, using Special:Import. It failed with a Import failed: Expected <mediawiki> tag, got message. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 11:54, 11 November 2020 (UTC)

I re-ran the import and it worked on the third attempt! Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 12:21, 11 November 2020 (UTC)

Feature request: legislation, case law and government documents

Are there any plans for expanding Cite Q to allow the citation of legal documents? Specifically, legislation (e.g. the equivalent functionality of {{Cite legislation UK}}), case law (so, Donoghue v Stevenson (Q5296782) would end up being cited appropriately in a footnote), as well as other government documents like Command papers.

Alternatively, given that legal citations are rather different from the usual citation practices used for books, newspapers and academic journals, would it be possible to have a version of Cite Q specifically for these specific use cases, and when specific properties exist (e.g. P1031), Cite Q could delegate to a law-specific equivalent? Cite Q seems like a very sensible approach generally, and it feels like it could be a good approach for dealing with citations in articles that primarily reference primary legal materials (secondary legal sources like academic textbooks/monographs, and articles in law reviews/academic journals can just follow the normal citation rules).

I'm happy to prepare some examples of property mappings, and if nobody objects or has better ideas, hack around a bit with the Lua module either in the Cite Q sandbox or in a separate sandbox for this specific purpose. —Tom Morris (talk) 21:26, 10 November 2020 (UTC)

Tom Morris As you may know {{Cite Q}} wraps {{Citation}}, so if you can cite legal docs using that you can do it with Cite Q. Your example currently renders as:

Donoghue v Stevenson, Wikidata Q5296782

Feel free to drop an example or two into /testcases#Misc (or start /testcases/legal if you need many), and let us know if anything fails to show as desired. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 11:26, 11 November 2020 (UTC)

Hi Tom, there's been so much that's happened since we first worked on Module:Wikidata in your sandbox, but I'm always delighted to see you working on the code that we have. Please feel free to hack away at Module:Cite Q/sandbox and see if you can draw in other Wikidata properties for legal documents. The first section of the module lists the "simple" properties that it processes, and it should be trivial to add extra entries to that table. The optional parameters are:
  • maxvals=1 to only return a single value;
  • linked='no' to suppress any linking of the value to an enwiki article;
  • populate_from_journal=true to enable looking at the property published in (P1433) and retrieving any relevant fields from the journal found there as well.
Have fun! --RexxS (talk) 20:19, 11 November 2020 (UTC)

Not happy with default link to wikipedia article & not to the external source given in wikidata (full work...)

I am not happy with the default link to enwiki (where available) rather than the url for the full work. See {{cite Q|Q2819904|pages=xxiii}} John Lindley (1839), A sketch of the vegetation of the Swan River Colony, pp. xxiii, Wikidata Q2819904 In my view the default must be external to wikipedia. MargaretRDonald (talk) 21:22, 10 November 2020 (UTC)

We thought the opposite, but we'd need to consult more widely before fixing on either. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 11:27, 11 November 2020 (UTC)
I can see valid reasons for both behaviours, but given that URLs are prone to link-rot, that Wikidata is difficult to maintain, and that we are Wikipedia, I would prefer to stay on the safe side and link to our internal page if both are available (which most probably has a link to the publication as well, although not necessarily exactly the same revision that was meant in the citation). In order not to lose the URL info it would be possible to render this as an convenience link after the list of identifiers by automatically appending it to |id=, like:
URL.
However, if someone explicitly specifies an URL in a |url= parameter like
{{cite Q|Q2819904|pages=xxiii|url=https://www.biodiversitylibrary.org/page/6013990}}
the template should actually link the title to the URL even if we have an article about it. Likewise, if the user specifies |title-link=, the template should use this as local link target:
{{cite Q|Q2819904|pages=xxiii|title-link=A sketch of the vegetation of the Swan River Colony}}
Similar, if someone specifies that the corresponding Wikidata value should be ignored, this should be adhered to as well:
{{cite Q|Q2819904|pages=xxiii|title-link=unset}}
would link to the URL (if available), whereas
{{cite Q|Q2819904|pages=xxiii|url=unset}}
would mute the URL.
--Matthiaspaul (talk) 17:11, 12 November 2020 (UTC)

Multiple values in pages, volume, issue

As {{citation}} supports comma- or semicolon-separated lists of values for |pages=(|pp=), |issue=(|number=) and |volume= (see Help_talk:Citation_Style_1#Fixed_evaluation_of_accept-this-as-is_syntax_in_parameters_supporting_item_lists for some corner-cases), I have set the corresponding maxvals value in the sandboxed {{cite Q}} from 1 ("read one") to 0 ("read all"), so that it will pull multiple entries from Wikidata if available. However, so far I found no Wikidata citations making use of this, so I couldn't test it. --Matthiaspaul (talk) 15:52, 12 November 2020 (UTC)

Thanks for contributing. All of your proposed changes do need to be tested. You can see the results so far by examining Template:Cite Q/testcases (and feel free to add examples for s2cid, etc. if you have the chance). If you can't find a Wikidata entity to use for testing, you can construct one in Wikidata Sandbox (Q4115189) or Wikidata Sandbox 2 (Q13406268) or Wikidata Sandbox 3 (Q15397819) or even create d:Wikidata Sandbox 4 if necessary. They get overwritten after a while, but can always be rolled back to the version you were using if you need to return to testing after a break. Sandboxes 2 and 3 get much less use than the first one, so you're much less likely to be disturbed if you use one of those. Hope that helps. Cheers --RexxS (talk) 16:11, 12 November 2020 (UTC)
page(s) (P304), issue (P433) and volume (P478) will each take a single string value (say, i, iv-vi, 1,4-6, 7, 8A for pages), so I think |maxvals=1 is correct. I think multiple issues or volumes would be an error. I can envisage an article published in two or more parts (for example in issue 3 page 200 and issue 4 page 555), but I think that would require an individual item for each part. Do we have any real-world example (not necessarily on Wikidata) to the contrary? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 19:21, 12 November 2020 (UTC)
While I don't have an example handy right now, they exist and led to these parameters supporting value lists.
My rationale for the change was as follows: If there is always only one string entry at Wikidata, only one will be pulled either way. However, if there are multiple such entries (for what reasons ever), who tells us that the first entry is the one actually corresponding with the citation used by the editor? If multiple are available, that would seem like pure luck. So the idea was to pull them all and let the user decide if this happens to be correct or needs to be overridden (possibly using copy & paste). If only the first of possibly many entries will be pulled, the user might never learn about the fact and accept what's pulled as given.
I have no idea if multiple page entries at Wikidata would just reflect the fact that an article was scattered over multiple pages and page ranges, possibly even over multiple issues, or if the different page entries would correspond with different derivations of a work in different publishing formats. In the second case, we would probably need some smart means to filter the pulled data like "pull only pages from the page entry from edition 2" by specifying |edition=2 or |volume=1 or something along this line.
This probably needs more insight to find a generic solution for such queries, but without pulling all data available at Wikidata the issue can be easily ignored and we can't learn from it for a proper solution.
--Matthiaspaul (talk) 22:47, 12 November 2020 (UTC)
A fair point, but unless we can identify valid use cases, then I would rather the template throw an explicit error message in such cases, than display bogus values and lead people to think that that is correct behaviour, which they might then try to emulate at Wikidata. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 23:17, 12 November 2020 (UTC)
That's a good point as well. Throwing an error and adding to a tracking category would be a good solution to keep editors from accidently pulling data not corresponding with what they want to cite and at the same time give us a handle to gain more insight into the problem so that the solution can be refined (either structural at Wikidata, or interface-wise at Wikipedia). --Matthiaspaul (talk) 23:27, 12 November 2020 (UTC)

Other roles

I have added:

to |others= in the sandbox. The test case Constitution of Brazil (Q2386422), which has very many signatories, fails with "Too many Wikidata entities accessed." error (it works for United States Declaration of Independence (Q127912)). Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 22:19, 12 November 2020 (UTC)

@Andy: each of those 588 signatories has a Wikidata entry and so the code here has to look at each of those entries to get its sitelink or label. The Scribunto interface has a hard limit of 400 Wikibase entities and we so can't return linked values when there are more than 400 values for any property. Simply trying to get the values using WikidataIB|getValue gives the same result, although we can work round it by not linking.
For comparison, Constitution of Brazil (Q2386422); property part of (P361):
For Constitution of Brazil (Q2386422); property signatory (P1891):
  • {{wdib |ps=1 |P1891 |qid=Q2386422}} → this gives "Too many Wikidata entities accessed." error
For Constitution of Brazil (Q2386422); property signatory (P1891), unlinked:
  • {{wdib |ps=1 |P1891 |qid=Q2386422 |linked=n}} → this lists all 588, unlinked
Nevertheless we can get some of them linked using #statements:
  • {{#statements:P1891|from=Q2386422}} → this links those with articles.
I'll have to knock up some code to leverage that functionality without it being too costly. That's a job for the next collaboration day. --RexxS (talk) 00:10, 13 November 2020 (UTC)
RexxS Thanks, I suspect that such an extreme number is an edge case, and, while we need to cater for it eventually, is so rare that it need not block our next sync. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 10:15, 13 November 2020 (UTC)

Et al

See: Template_talk:Citation#Et_al --Matthiaspaul (talk) 16:31, 13 November 2020 (UTC)