Jump to content

Template talk:Cite Q/Archive 3

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

Import issue

Hi. I tried importing this template and the associated modules to eo.wiki and it was mostly a success, but for some reason I still get the bare URL shown. What could be the problem? ~★ nmaia d 01:26, 10 November 2020 (UTC)

@NMaia: I think this is due to the version of {{Citation}} that is installed there. In particular, in eo:Ŝablono:Citation/core, near the end it has #if: {{{URL|}}}{{{IncludedWorkURL|}}} |&rft_id={{urlencode:{{{URL|{{{IncludedWorkURL|}}}}}}}}, which I think is causing the URL to be shown for a second time (it's also used to link the title). Thanks. Mike Peel (talk) 12:24, 10 November 2020 (UTC)
Confirmed. I added |_debug= to Module:cite Q/sandbox which causes the module to return a nowiki'd version of the {{citation}} template:
{{Cite Q/sandbox|Q15625490|_debug=yes}}
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}}: Unknown parameter |_debug= ignored (help)CS1 maint: unflagged free DOI (link)
I copied that to eo:Uzanto:NMaia/provejo and previewed and got the same extra url. Using {{citation/old}} here gives:
{{citation/old |issn=1932-6203 |others= |author6=Peter Etnoyer |date=21 May 2010 |doi=10.1371/JOURNAL.PONE.0010676 |volume=5 |url=http://europepmc.org/abstract/MED/20505760 |language=en |pmid=20505760 |author4=Paul Hoetjes |ol= |journal=[[PLOS One|PLOS ONE]] |author7=Michael Smith |author5=Wes Toller |issue=5 |title=Biodiversity Assessment of the Fishes of Saba Bank Atoll, Netherlands Antilles |author-link2=Kent E. Carpenter |author1=Jeffrey T. Williams |author2=Kent E. Carpenter |pmc=2873961 |author3=James L. van Tassell}}
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" (in en), PLOS ONE 5 (5), doi:10.1371/JOURNAL.PONE.0010676, ISSN 1932-6203, PMC 2873961, PMID 20505760, http://europepmc.org/abstract/MED/20505760 
—Trappist the monk (talk) 12:52, 10 November 2020 (UTC)
@Mike Peel: Thanks for taking a look. I've updated that template and imported the new dependencies, and now a new, even stranger error has appeared. ~★ nmaia d 13:43, 10 November 2020 (UTC)
Your version of {{hide in print}} is different from ours. This edit by Editor Nemo bis added <span class="noprint">...</span> which, appears to be the cause of your problem. If that <span>...</span> is not needed here, why is it needed at eo.wiki?
—Trappist the monk (talk) 14:58, 10 November 2020 (UTC)
@Trappist the monk: Dankon! I think that fixes it. In the example in my test page, it seems there are two redlinks for templates/modules that don't exist in en.wiki (Module:WikidataIB/i18n and a transclusion of the page PLOS ONE). Regardless of that bug, it doesn't seem to affect the outcome. ~★ nmaia d 00:14, 11 November 2020 (UTC)
@Trappist the monk and Mike Peel: scratch that, I think we're back to square one. Bare URLs once more. ~★ nmaia d 10:17, 11 November 2020 (UTC)
I am guessing here, but I suspect that the reason that the url is rendered is because eo:MediaWiki:Common.css does not have this css: 
/* For linked citation numbers and document IDs, where the number need not be shown
   on a screen or a handheld, but should be included in the printed version */
@media screen, handheld {
	.citation .printonly {
		display: none;
	}
}
The particular snippet of eo:Template:Citation/core that renders the extra url is wrapped in a <span class="printonly">...</span> tag. Without the css in commons.css or in a template styles css page, the url will not be hidden.
—Trappist the monk (talk) 13:05, 11 November 2020 (UTC)
Thanks, I think that finally did it. ~★ nmaia d 23:59, 12 November 2020 (UTC)
@Trappist the monk:, I like this |_debug=yes feature very much (and understand that the name was derived from Module:Template_wrapper), but given that there might be many different debug scenarios in the future and that this particular one is basically a substitution, I propose to rename this parameter to |_subst= here (and possibly also in the wrapper template) so that it can remain a permanent development aid. Perhaps it would also make sense to include it only in the sandboxed version of {{cite Q}}, so that users would not have to worry about any overhead in the wild. (On the other hand, the overhead to make this conditional might be larger than the current overhead of the feature...)
Either way, the feature already helped to spot and eliminate (in the sandbox) the stray empty parameters |others= and |ol= in the expanded form of the {{cite Q}} template.
--Matthiaspaul (talk) 14:32, 13 November 2020 (UTC)
A substitution? I don't think so. It is there to aid in debugging {{cite Q}} and Module:cite Q; it is not there to substitute one thing for another. |_subst= is much, much too close to the subst: prefix.
—Trappist the monk (talk) 15:15, 13 November 2020 (UTC)
This is actually what I had in mind.
|_debug=/|_subst= is not only useful for debugging, but could be used to easily transfer a snapshot of {{cite Q}} and translate it to the equivalent code for {{citation}} that would be necessary to be pasted into an article for those who oppose using {{cite Q}} in articles but still would like to take advantage of it to initially fill citations from there.
And something like |_expand= could work almost identical to |_subst= except for not replacing {{cite Q| by {{|citation| in the dump to the effect that all information pulled from WD would be overridden by local parameters resulting in easy to maintain citations (from a Wikipedia perspective) because all information is readily available for editing, but still using {{cite Q}}. It would also address the often raised concerns about the contents and validity of Wikipedia articles depending on information from Wikidata (with fatal consequences for Wikipedia if Wikidata would fail). Once editors would start to modify the local values, {{cite Q}} would populate maintenance categories for each parameter value deviating from the WD value, so that editors or bots could check and possibly update the information at Wikidata accordingly (or update the local entries if the WD ones' are better). (Ideally, editors would edit Wikidata themselves, but to gain acceptance of this template nobody should be forced to edit Wikidata if they don't want to or simply can not.)
--Matthiaspaul (talk) 17:10, 13 November 2020 (UTC)
" to easily transfer a snapshot of {{cite Q}} and translate it to the equivalent code for {{citation}} that would be necessary to be pasted into an article for those who oppose using {{cite Q}} in articles but still would like to take advantage of it to initially fill citations from there." That's not what this template is for; such functionality is already offered by Citoid and similar tools. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 18:51, 13 November 2020 (UTC)
Which, however, is hardly an argument against providing yet another method (or even something as simple as searching for the most meaningful parameter name describing a feature). ;-)
There is more than one possible way to achieve a goal and not all work for all potential users.
For example, AFAIK Citoid is Javascript-based, therefore it cannot be used by people using browsers with Javascript disabled for security or technical reasons (f.e. very old browsers not supporting Javascript). Also, not everyone can log into Wikidata for technical reasons (I, for one, often can not and then only work as an IP over there - even though I'm logged into my global account and Wikidata is connected to it, it often still shows the "Log in" dialog. This is apparently down to security settings on my side, but I cannot change them for policy reasons). Therefore, don't expect that everyone can edit Wikidata (except for trivial things as an IP). If you want to gain more acceptance for {{cite Q}} and similar nice ideas pulling data from Wikidata into Wikipedia and Wikipedia being a higher quality data pool for Wikidata, it should be designed in a way so that citations won't be invalidated even without Wikidata, hence the idea of "caching" the data in local parameters and decoupling editing a citation in Wikipedia from synchronizing citation contents with Wikidata. Either way, this is going astray the parameter name discussion. ;-)
--Matthiaspaul (talk) 19:46, 13 November 2020 (UTC)

Time to sync?

There have been a number of changes since the last sync.

  1. Are they all tested?
  2. Are they all documented?
  3. Other than #Default limit in number of authors to display, are any of them blockers?

If the answers to the above are satisfactory, I suggest we undo the "Default limit in number of authors to display" change and sync the module.

If not, I suggest we either fix or revert them (keeping copies of relevant code, for later use) so that we are in a position where we can do so. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 17:30, 27 November 2020 (UTC)

@Andy: my thoughts:
  1. No
  2. No
  3. Possibly, but we won't know until they are tested.
I'm disinclined to do partial reverts; and fixes may take time, but we won't know until all the changes are tested. --RexxS (talk) 18:24, 27 November 2020 (UTC)
I guess the changes are all tested on Template:Cite Q/testcases. The sandbox breaks with Constitution of Brazil (Q2386422), which should be fixed, but otherwise it seems to work. However, I don't know if suitable examples have been added to the test page to decide if the new version works OK. My preference would be to review the code at our meeting on the 12th December before syncing it. Thanks. Mike Peel (talk) 19:02, 27 November 2020 (UTC)

S2CID

We may add support for S2CID (P8299).--GZWDer (talk) 20:27, 11 November 2020 (UTC)

GZWDer Semantic Scholar corpus ID (P8299)? That could be added to {{Citation}}; you'd need to ask on its talk page. Or we could add it using |id=, but that's less structured. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 21:12, 11 November 2020 (UTC)
@Pigsonthewing: It was already supported and widely used: [1].-GZWDer (talk) 21:14, 11 November 2020 (UTC)
GZWDer Do you have an example, please? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 19:26, 12 November 2020 (UTC)
I have already added |s2cid= to the sandbox, alongside with |zbl= and |rfc=. Needs testing. --Matthiaspaul (talk) 21:32, 11 November 2020 (UTC)
Added |asin= as well. --Matthiaspaul (talk) 12:12, 15 November 2020 (UTC)
Speaking of |id=, I have modified the sandbox so that the Wikidata link will now be appended at the end of |id= instead of being attached at the end of the citation. This has several advantages:
  • |id= can be used to specify additional identifiers as before.
  • The Wikidata identifier will show up at the end of the list of other identifiers, regardless if {{citation}} will display additional stuff (f.e. a quotation) between the list of identifiers and the end of the citation.
  • The proper determination of a postfix character is now left to {{citation}}, so that the usual methods to modify it using |postscript= and |mode= work properly. Also, it does no longer get confused when |quote= is used.
  • As all other identifier links do, the Wikidata link is now also routed through its corresponding (identifier) redirect rather than being hardcoded into the template. This reduces clutter in "What links here" and improves reverse lookup. Whether WDQ is the best possible name is debatable (I personally would change it to QID), but that's what is used by {{QID}} at present and a request to change it on the redirect's talk page Talk:WDQ_(identifier)#Rename to QID (identifier)? has not gained momentum yet.
--Matthiaspaul (talk) 16:09, 12 November 2020 (UTC)
Thank you. That's much better. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 19:26, 12 November 2020 (UTC)

Suggested logic for preprint servers

Following on from an earlier thread, I through I'd raise the idea of having {{Cite Q}} use the |type=Preprint to automatically indicate preprints (where possible). There are two ways of spotting them in wikidata, and some may also link to the published version, so the pseudocode logic would be something like this:

IF instance of (P31) = preprint (Q580922)
OR
IF published in (P1433) has instance of (P31) = preprint server (Q45787211)
THEN include |type=[[Preprint]]
IF followed by (P156) exists, include |type=[[Preprint]]; published version in <nowiki>''[[doi of published version|journal of published version]]''

For example, {{cite Q|Q56796684}} could yield:

There are certainly ones that might be missed (and some journals like frontiers can blur the boundaries anyway), but I think this would catch the majority of instances and be useful for readers. T.Shafee(Evo&Evo)talk 07:05, 26 November 2020 (UTC)

|type=[[Preprint]]; published version in <nowiki>''[[doi of published version|journal of published version]]'' does not appear to use a valid value for |type=. I do not think we should be polluting parameters with editorial commentary in this manner. Nor should we be linking the title of a journal to the DOI of a paper.
If we do include preprint handling, in some other form, then a tracking category could usefully be added. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 09:43, 26 November 2020 (UTC)
If |type= is not the most appropriate parameter of {{citation}} to use: is there better existing parameter, would {{citation}} need a new parameter(s), or would it be handled outside of {{citation}} parameters? I agree tracking categories would be logical. T.Shafee(Evo&Evo)talk 11:41, 26 November 2020 (UTC)
|type= is the correct parameter to indicate a preprint status, and given that it is a free-text parameter not showing up in COinS metadata, it would be possible to include what you propose, however, I am with Andy here that such editorial commentary would be unusual in this parameter (I have never seen that in the wild in |type=). If it is important to provide the info on the magazine article, I would put that either into a nota bene comment or into another citation following the first citation but still inside the same <ref>...</ref>.
However, assuming that the published version is newer and possibly more accurate than the preprint version, why would you cite the preprint, anyway? Wouldn't it be more appropriate in this "luxury" sitation to use the published version for a citation in Wikipedia then? If it is because the contents of the preprint is publicly available whereas the contents of the published version is hidden behind a paywall, for the convenience of the readers I would cite both, either in separate <ref>...</ref> blocks or both in one (in both cases starting with the published one in the row as the more "official" one). While it would be possible for {{cite Q}} to automatically invoke {{citation}} twice and create the code for this, I wonder if it wouldn't be better/more universal for {{cite Q}} to just emit a message in preview and to populate some special maintenance category (like "Preprints with published versions"), if {{cite Q}} would detect that a published version exists for a preprint, and then leave it to editors to resolve this accordingly. --Matthiaspaul (talk) 13:40, 26 November 2020 (UTC)
You can't assume that there is a published version when the preprint is cited. Consider: user A cites a preprint in January. In March, user B updates the Wikidata item to say that the full version was published in February. That's why a tracking category would be useful. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 18:29, 26 November 2020 (UTC)
Yeah, that's what I meant as well. When a user cites a preprint in March and the template detects that a published version exists since February already, it provides this information via message and category so that the user can check and cite the published version instead or in addition to the preprint. If, however, the user would cite the preprint in January, the template would not find a published version and thus neither emit the message nor populate the category. But another editor in March would see the message for the citation provided by the first user in January. A user citing the published version would not see any message regarding possibly existing preprints, because there's not normally a need for it.
--Matthiaspaul (talk) 19:54, 26 November 2020 (UTC)
A few additional notes on why it would be useful for cite Q to indicate both that the article is a preprint and when a published versiosn is vailable:
  1. if a published version is available, we want editors to check that the statements the ref is supporting is still supported in the published version before changing over the citation (as the article may have changed significantly during peer review)
  2. if an editor hasn't gotten around to this yet, we still want readers to know that a published version is available
  3. this same logic would apply for retracted articles. We want both tracking categories and indication in the footnote that a ref is retracted, and a link to the retraction notice. There may be instances where an editor specifically wants to cite a retracted article even knowing that it is retracted so there should also be a para to shift it to a different tracking category (e.g. 'page deliberately citing retracted articles' or equivalent).
T.Shafee(Evo&Evo)talk 03:56, 27 November 2020 (UTC)

Lua bug

As reported by @Jura1: at d:Template talk:Cite Q, {{Cite Q|Q3345156}} gives "Lua error in Module:Cite_Q at line 117: attempt to index field 'datavalue' (a nil value)." It does that both here and on Wikidata. The same happens with the sandbox, but on line 199. Thanks. Mike Peel (talk) 16:56, 27 November 2020 (UTC)

Perhaps because author (P50) = "unknown value"? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 17:21, 27 November 2020 (UTC)

(edit conflict) @Mike Peel and Pigsonthewing: The issue is that when a value is set to "unknown", it doesn't have a mainsnak.datavalue: 

table#1 {
    table#2 {
        ["id"] = "Q3345156$9d23e2d1-4e17-928d-a174-27bfbcbd5ea0",
        ["mainsnak"] = table#3 {
            ["datatype"] = "wikibase-item",
            ["property"] = "P50",
            ["snaktype"] = "somevalue",
        },
        ["rank"] = "normal",
        ["type"] = "statement",
    },
}

So we can check the snaktype and supply a value for unknown:

How do you want to handle this? I can make this change in the main template if required, once we know what we want to do when author is unknown. Are there any examples of unknown editor? --RexxS (talk) 18:17, 27 November 2020 (UTC)

1,845 results for "author%3Danon" insource:"author=anon". Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 18:56, 27 November 2020 (UTC)
The code should return some text, and maybe a tracking category, rather than an error. Beyond that, I don't know how this should be handled. Thanks. Mike Peel (talk) 19:05, 27 November
[EC] Also, while we need to trap such cases, the item on Wikidata should instead have author (P50)=anonymous (Q4233718). Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 19:07, 27 November 2020 (UTC)2020 (UTC)
I've added a tracking category which adds pages to Category:Cite Q - author unknown. See the bottom of this page to check that it is a hidden category. --RexxS (talk) 21:39, 27 November 2020 (UTC)

@Jura1: it's the same issue, with the same fix:

Unfortunately, Wikidata doesn't store "somevalue" as a datavalue. When the value is unknown, there literally is no mainsnak.datavalue.value for that statement. Instead you have to check the mainsnak.snaktype, which currently can be "value", "somevalue", or "novalue". Only in the first case does Wikidata store a value in mainsnak.datavalue.value for the statement. Hence the errors if the code tries to access a value that isn't there. Compare how Wikidata stores 'somevalue' in author (P50) (above) with how it stores an actual value in instance of (P31) (below): 

table#1 {
    table#2 {
        ["id"] = "Q3345156$C1D98290-1B37-427C-A280-989AAC043B1B",
        ["mainsnak"] = table#3 {
            ["datatype"] = "wikibase-item",
            ["datavalue"] = table#4 {
                ["type"] = "wikibase-entityid",
                ["value"] = table#5 {
                    ["entity-type"] = "item",
                    ["id"] = "Q7725634",
                    ["numeric-id"] = 7725634,
                },
            },
            ["property"] = "P31",
            ["snaktype"] = "value",
        },
        ["rank"] = "normal",
        ["type"] = "statement",
    },
    table#6 {
        ["id"] = "Q3345156$76F6BEBD-EDAD-470A-8590-82FD50B077CF",
        ["mainsnak"] = table#7 {
            ["datatype"] = "wikibase-item",
            ["datavalue"] = table#8 {
                ["type"] = "wikibase-entityid",
                ["value"] = table#9 {
                    ["entity-type"] = "item",
                    ["id"] = "Q1787111",
                    ["numeric-id"] = 1787111,
                },
            },
            ["property"] = "P31",
            ["snaktype"] = "value",
        },
        ["rank"] = "normal",
        ["type"] = "statement",
    },
}

I hope that makes the problem clearer. --RexxS (talk) 13:24, 28 November 2020 (UTC)

  • d:Q56084819#P50 is slightly different as the author isn't unknown, but added as string only. The same is sometimes also done for other properties. I think the ruwiki module just outputs the string when present (even when the value is an item). Jura1 (talk) 15:19, 28 November 2020 (UTC)
    According to Wikidata, the author (P50) has no value in (Q56084819). We would need to make a decision about whether to name the author as "Ann Vibeke Knudsen" in a citation. In my opinion, either we know the author or we don't. If Ann Vibeke Knudsen is the author, then the author is not "unknown". The whole statement is unreferenced, so how do we make any assessment of the reliability of the subject named as (P1810) claim? --RexxS (talk) 18:30, 28 November 2020 (UTC)
    • d:Q56084819#P50 has "somevalue", not "no value". This is displayed as "unknown value". Some contributors use that when they can't find the author in their library catalogue or don't think they know sufficiently about the person to create an item. Some suggest its use also when people don't want create new items. Statements about works aren't necessarily referenced one by one. I don't really have a preference how you handle it in this module. I think the ruwiki infobox generally overwrites items labels with the text in the qualifier. Maybe it does that also when "somevalue" is used. Jura1 (talk) 20:21, 28 November 2020 (UTC)
      @Jura1: No, d:Q56084819#P50 has no value for author (I didn't say "novalue" which is a snaktype, not a datavalue). Wikipedia editors are often confused by the Wikidata interface, but the JavaScript display in the Wikidata is irrelevant; it's not displaying what is actually stored. Look at the structure of what is stored as I've shown you above: there isn't any mainsnak.datavalue.value for P50, and we don't have a value for the property. If contributors don't supply a value, for whatever reason, then they must accept that the statement will be interpreted as "we don't know who the author is". Any unreferenced statements potentially breach WP:V and should not be imported from Wikidata into Wikipedia. That's why I'm not happy with fudging the issue by adding a qualifier to statements which have snaktype = "somevalue", because qualifiers can't be referenced. That entry is a misuse of subject named as (P1810), whose description is "name by which a subject is recorded in a database or mentioned as a contributor of a work". If the contributor who added d:Q56084819#P50 wanted to say "We're not sure who the author was but there is a source that names them as Ann Vibeke Knudsen", then they had better find a way of telling us what that source is. The ruwiki is content to import all sorts of unsourced information, but the enwiki isn't, so the comparison is pointless. Of course we could supply "Ann Vibeke Knudsen" instead of "Author unknown", but how do we then answer an enwiki critic who reasonably asks "how do I verify this information"? --RexxS (talk) 00:04, 29 November 2020 (UTC)

Please add test cases

We have had several additions to the module's sandboxes, recently, which have no corresponding entry on the test cases page.

If you add (or have recently added) a new feature, please add one or more test cases; or at least drop a note here on the talk page so we know that one needs to be found. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 11:01, 12 December 2020 (UTC)

New release

We've been working on the template again today - we've just published a heap of bug fixes, and added several important new features, including tracking categories for replaced or retracted papers. And we're now using "stated as" qualifier, so we'll default to using the name on the work, rather than a current name, if, say, the author subsequently married or divorced.

Please let us know if you spot any issues. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 17:50, 12 December 2020 (UTC)

  • Fix unnecessary piping of author/editor and journal links if link and label are the same, f.e. [[Author|Author]] -> [[Author]], [[Journal|Journal]] -> [[Journal]]

What problem is this seeking to solve?

WikidataIB has always piped its linked results, something like [[Sitelink|sanitised_sitelink or label]. This simplifies the code to sort or do string manipulations, especially when the output is an unbulleted list (e.g. Module:String2, function ucfirst) because the displayed string always follows a pipe character. The code in string manipulations could be amended to look for unpiped links as well, but to what purpose? It's fine to simplify piped links when editors are manually adding them, but nobody sees the wikitext produced by modules and [[Author|Author]] is functionally identical to [[Author]]. --RexxS (talk) 21:45, 15 November 2020 (UTC)

It isn't a problem in the sense of an error, more an issue that could be improved. Given that the template now supports |_debug= (which is useful beyond debugging, see above) the generated code is likely to show up more often and be reused by reembedding it into articles, therefore it would be nice if this redundancy could be removed by reducing this to the canonical form automatically. It's cleaner to read and potentially less work for editors if they want to reuse the output.
--Matthiaspaul (talk) 14:58, 16 November 2020 (UTC)
If an editor using the generated code embeds it into an article and thinks that the redundancy is a problem because it's less clean to read, they will obviously simplify the link themselves. I disagree that the putative extra work for a concerned editor is in any way significant. --RexxS (talk) 22:28, 16 November 2020 (UTC)

We left this in the code in today's revision, but we weren't 100% sure that this wouldn't cause problems in the future, so this needs to be kept an eye on. Thanks. Mike Peel (talk) 19:50, 12 December 2020 (UTC)

Overriding, unsetting and forcing Wikidata values in cite Q

I changed the sandbox so that {{cite Q}} now allows to override and unset author- and editor-related parameters as well. This was needed to address the "et al." issue discussed here: Template_talk:Citation#Et_al.

However, similar to being able to locally override or unset each and any parameter which contains data pulled from Wikidata it is also necessary to have some means to "enforce" Wikidata values while passing them down to {{citation}}. I will give two examples:

  • Wikidata may contain an ambiguous page value of "15-8, 22". This could refer to a single page named "15-8" (perhaps from chapter 15, relative page 8) or this could be a page range in disguise (using an outdated shorthand notation to indicate "15 to 18", and not using a dash instead of a hyphen).
However, in the |pages= parameter, {{citation}} will interpret "15-8" (and even "15-18") as a page range and change it to "15–8" for display purposes (only to convert it back to the ambiguous "15-8" form in metadata). If this would be known to be a single page, it would be better to use |page= rather than |pages=, but AFAIK {{cite Q}} won't do that (and Wikidata does not have an entry dedicated for single pages). However, in the example above even this would not be possible because the page list also contains page 22.
So, if the entry would actually refer to two pages (15-8 and 22) rather than five (15, 16, 17, 18, 22), we can tell {{citation}} to accept the entry "as is" using our special markup for "((15-8, 22))". In {{cite Q}} we would have to overwrite the WD entry by locally specifying |pages=((15-8, 22)).
  • Another example would be one of those rare but correct ISBNs deviating from the standard form like for this book (despite the error message, this ISBN is correct as actually printed on the book):
Holdsworth, Brian; Woods, Clive (2002), Digital Logic Design (4 ed.), Newnes Books / Elsevier Science, ISBN 0-7506-4588-2 {{citation}}: Check |isbn= value: checksum (help)
For {{citation}}, the solution is to use the accept-this-as-written markup to indicate that this ISBN, although failing the test, is correct:
{{citation |title=Digital Logic Design |author-first1=Brian |author-last1=Holdsworth |author-first2=Clive |author-last2=Woods |edition=4 |date=2002 |publisher=[[Newnes Books]] / [[Elsevier Science]] |isbn=((0-7506-4588-2))}}
Holdsworth, Brian; Woods, Clive (2002), Digital Logic Design (4 ed.), Newnes Books / Elsevier Science, ISBN 0-7506-4588-2{{citation}}: CS1 maint: ignored ISBN errors (link)
If this citation could be found at Wikidata, the only solution for {{cite Q}} at present would be to overwrite the ISBN via |isbn=((0-7506-4588-2)) (because Wikidata entries obviously would not include our markup).

What would be helpful here is a general notation for {{cite Q}} to not override a WD entry but to enforce its acceptance by {{citation}}. The CS1/CS2 convention for this is to add the ((...)) markup around that entry. Therefore, I propose to add support for a general syntax enhancement for all {{cite Q}} parameters reflecting {{citation}} parameters to accept a special keyword or syntax denoting "wrap ((...)) around this WD entry before passing it down to {{citation}}".

Trappist (and I) recently added support for an unset keyword to mute a parameter. Similar, we could add a keyword accept, wikidata, :d: or similar to make {{cite Q}} translate WD entries on the fly like:

  • Wikidata Pages "15-8, 22" → {{cite Q|...|pages=accept}} → {{citation|...|pages=((15-8, 22))}} → output: 15-8, 22 (not: 15–8, 22)
  • Wikidata ISBN "0-7506-4588-2" → {{cite Q|...|isbn=accept}} → {{citation|...|isbn=((0-7506-4588-2))}} → output: ISBN 0-7506-4588-2 (without error message)

(At a later time, there could be more keywords for special conditional filters like accept-digits, accept-letters, accept-true, accept-single up to pattern-matching-and-modifying notations to translate from Wikidata conventions to local ones.)

Either way, adding such keywords always carries some risk of clashing with normal free-text input and also might be (more) difficult to remember (than general syntax elements). While it is possible to override the interpretation as keywords using ((free-text-clashing-with-identically-named-keyword)) (as in f.e. ((unset))), it would be nice if we could avoid keywords in cases where the general syntax could be used to indicate the same.

Our established accept-this-as-written markup ((...)) currently leaves one case which could be utilized for a special purpose: (())

Intuitively, this denotes "accept an empty parameter" which could be interpreted as to "unset" this parameter (or to accept it as an empty parameter, but {{citation}} does not have a use case for empty parameters). Alternatively, but already somewhat less intuitive, we could also interpret (()) as "wrap whatever is pulled from WD in ((...))", so the examples above would become:

  • WD Pages: 15-8, 22 → {{cite Q|...|pages=(())}} → {{citation|...|pages=((15-8, 22))}} → output: 15-8, 22 (not: 15–8, 22)
  • WD ISBN: 0-7506-4588-2 → {{cite Q|...|isbn=(())}} → {{citation|...|isbn=((0-7506-4588-2))}} → output: ISBN 0-7506-4588-2 (without error message)

Yet another alternative, if (()) would be more convenient to be used for the "unset" case, we could use ))(( (or :d:) to indicate the acceptance of the WD value... --Matthiaspaul (talk) 16:31, 13 November 2020 (UTC)

@Matthiaspaul: I'm a fan of some =unset ability (see also discussion here). In terms of implementation, a keyword like unset or omit is more intuitive when read and easier to remember wen writing than ((...)). Alternatively some |supresswarnings=isbn could be useful for the ISBN example above? It seems to be functional in the sandbox but not the main {{cite q}} template (e.g. this template has to use the sandbox version of cite Q). Do you know hat the expected timeline is for those features be implemented from sandbox to the main {{cite Q}} template? I'm hoping to make it more common to include handling editor information in journal article wikidata items, but without including their names in the citation. T.Shafee(Evo&Evo)talk 11:58, 26 November 2020 (UTC)

This should really be used as sparingly as possible - if there are issues with the data, then the best solution is to fix them on Wikidata, not to mess around with override parameters. Thanks. Mike Peel (talk) 19:51, 12 December 2020 (UTC)

Default limit in number of authors to display

this sandbox edit apparently removed the default limit on the number of authors displayed. We have items with literally over 100 authors; we do not want to display all of them unless - in some rare and bizarre circumstance - the user explicitly chooses to do so. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 19:57, 12 November 2020 (UTC)

Indeed. Looking at Template:Cite Q/testcases/many names shows the sort of problems that such a change would produce. It is reasonable not to specify a default limit on the number of authors displayed when adding authors manually to a reference as we may expect editors to be sensible when creating citations because of how they are rendered in articles, but Wikidata editors have no such filter on their behaviour, and will inevitably fill up entries with every author name available. That implies that we need a default limit when the data is drawn from Wikidata, and so we deliberately created the code to limit the number of authors before truncating (allowing up to 8 names before automatic truncation down to 3 names plus et al}. We can have a sensible discussion on tweaking those numbers, but it is not sensible to remove the automatic truncation, and I'll oppose any attempt to merge the present sandbox until that is rectified. --RexxS (talk) 21:02, 12 November 2020 (UTC)
I only commented out this piece of code, so it is trivially easy to temporarily readd it for a release.
I see your point, but I don't think it is a problem at all to list all authors. In fact, I think, listing all authors is highly desirable for keeping a neutral point of view (WP:NPOV) and verifiability reasons (WP:V), even if that number is high. After all, WP:NOTPAPER.
It is not up for us (as template developers) to decide which authors should be listed or not, that's up to the publishers, or to the article editors. If a publisher found that someone should be listed among the authors, courtesy dictates that we faithfully reproduce this in our citation. In the rare cases where, despite this, setting a limit appears to be necessary for display purposes because the number is extra-ordinary high (several hundreds of authors, not a mere dozen or less) or if there are many (perhaps 10+) citations in an article containing many (perhaps 50+) authors, we have |display-authors= to be used at the editors' discretion.
Also, setting an arbitrary default limit we risk that the most important authors aren't listed, because names should be listed in the order as provided by the publisher and different publishers have different conventions for the order of authors. While it is often the case that the major participants are listed first, many organizations have other conventions, for example alphabetically sorted, sorted chronologically by time of input, sorted by importance or size of a contribution, or by the "status" of the contributors in ascending or descending order. Therefore, the most important contributors might be listed in the middle or even at the end in a publication. We simply do not know without having insight into the conventions used by a particular publishing organization. The editors of an article might have this insight to set a good |display-authors= limit, but we as template developers have not.
Therefore, we should not set an arbitrary limit as a default, and in particular not one with such an extremely low number - the chances that the important contributors aren't among the first three are high in a citation with dozens or even hundreds of contributors. So, let's leave that to the editors of an article.
--Matthiaspaul (talk) 15:37, 16 November 2020 (UTC)
"It is not up for us (as template developers) to decide which authors should be listed or not," We're not; we're applying a default quantative limit, which is neutral about who the authors are; and which is easily overidden. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 16:32, 16 November 2020 (UTC)
But why should we? I would consider this as "wrong attitude" in regard to our role as developers. There is no technical limit (and if there would be any it would be in the several hundreds of entries), so we should not enforce one.
We can be "proud" if we have a complete citation, so why not display it in its completeness, unless, in rare cases, an editor of an article (after seeing the full entry) finds that unsuitable by setting |display-authors=. Setting a default limit, editors never see the full entry, and since most editors are lazy, the addition of |display-authors= to a higher value will not happen in most such cases (and is more complicated because the editor would first have to set a very high value (which one?) to see and evaluate the complete list in order to derive a good limit in the next iteration - so much easier to do it the other way around).
Limiting the number of displayed editors also makes it more difficult to evaluate a source ("Are there known experts on a subject among the authors?", "Is there an author among the authors I already know?", "What are the authors' affiliations?") and use the list as a starting point for further research ("What further work have they done?"). It also makes it impossible in Wikipedia to find contributions of an author by searching for the name. Checking the details of the authors not listed is also more complicated, thereby making it more difficult to improve and/or correct citation information.
There is one case where, I think, the automatic detection of a reasonable limit would be possible with reasonable accuracy: If the template would scan through the complete list of authors and finds that they are sorted alphabetically in several larger ranges, than the first such range will in most (though not all) cases list the most important authors, so that, if that first range is significantly shorter than the complete list, it might be a good breakpoint. Otherwise, I don't see that.
--Matthiaspaul (talk) 18:45, 16 November 2020 (UTC)
Nowadays, articles can have hundreds of authors (see Template:Cite Q/testcases/many names linked to above). The norm when referencing them from a journal article is to limit the number of authors listed, in astronomy the default tends to be only showing the first 5 if it's over 8 authors. There is rarely much point to listing every single author, as it just clutters up the reference list, making references with fewer authors much less noticeable (eyes glazing over while reading the list), plus it slows the loading time down. It is rare that a reader has sufficient familiarity with the topic to evaluate a source using the author list (if they do, then they probably already know the article anyway). What we could do is change 'et al.' to 'et al. (150 more authors)', which is similar to what arxiv does, and hides most of the clutter while letting readers know how many authors the paper has. Thanks. Mike Peel (talk) 20:22, 16 November 2020 (UTC)
If we do that, I'd prefer something like {{abbr|et al.|150 other authors}}. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 20:34, 18 November 2020 (UTC)
Although not as a solution for a "cut after 3" approach, I like this "x more authors" proposal in general, but (unless {{cite Q}} would suppress authors from being passed down to {{citation}}) this is something that could only be done in {{citation}}, not here. Similarly, I was also thinking about listing the remaining authors in a tooltip above the "et al.". However, both approaches make it impossible to search Wikipedia for a name and find it in a citation when the author would happen to be listed above the |display-authors= limit. I am also thinking if it would be possible to display the remaining authors in a different CSS class which could be set to invisible by editors who do not want to see them. This way, they should at least remain searchable. Either way, these are possible options for {{citation}}, not for a wrapper like {{cite Q}}. --Matthiaspaul (talk) 21:57, 18 November 2020 (UTC)
"so why not display it" Wikipedia does not, in the main, use its existing citation templates to display hundreds of authors in a single citation. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 20:32, 18 November 2020 (UTC)
But among the millions of citations hundreds of names are a rare event. There are, by far, more citations with perhaps 10 or 20 authors which would now by artifically truncated down to 3 after that 2020-11-08 change. While I could at least see the argument for extreme case such as 100 or more names, there is no reason to truncate the list if it is considerably shorter. 20 or 30 authors, still a comparably seldom event, are IMO no clutter, they are just a reflection of reality and nothing that could be considered unbearable. After all, we provide citations for our readers to use them, and they aren't of much worth if they are incomplete.
It is not our business as developers to introduce unnecessary and arbitrary limits. If an editor in an article decides that not all authors should be listed, that's a completely different story, as he or she then used editorial judgement in the context of that article. However, to maintain the integrity of the template in regard to WP:NPOV and to allow easier WP:V of citations our role here is to make available what is technically possible by default and to stay clear of any form of "manipulation".
As a compromise I could accept a "technical" limit at 100 (although we know that there is no such technical limit).
--Matthiaspaul (talk) 21:57, 18 November 2020 (UTC)
Again, it is not a limit, it is a default value. Neither WP:NPOV nor WP:V are relevant in this matter. And please avoid pejorative hyperbole such as "manipulation". Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 22:12, 18 November 2020 (UTC)

We discussed this today, and came back in favour of having a default limit for the number of authors in the template. If really necessary then this can be overridden with a local parameter, but in general the current setting should work OK. Thanks. Mike Peel (talk) 19:54, 12 December 2020 (UTC)

Activity this weekend

Hi all. Following from the discussion in September, the eScholarship to improve this template was approved, and we'll be working on it this weekend. The rough plan is here (currently a google doc, will turn into a wikipage report after the event), feel free to suggest additions either there or here. Thanks. Mike Peel (talk) 18:49, 6 November 2020 (UTC)

Here's a Twitter thread, using the hashtag '#CiteQ' - https://twitter.com/pigsonthewing/status/1325023548084281344 -- Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 11:40, 7 November 2020 (UTC)
OK, we have now published changes from the first day's work - let us know what you think. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 17:26, 7 November 2020 (UTC)
We're back on Twitter, in the same thread, with the same hashtag. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 10:33, 8 November 2020 (UTC)
We've just published another big batch of changes - including lots of language-handing (for non-English works on en.Wikipedia; but the code will function equally for non-Portuguese works on pt.Wikipedia, and so on). Also handling for papers with many authors, and handling for values in qualifiers. Not to mention bug-fixes. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 15:37, 8 November 2020 (UTC)
And with one final bugfix, that's a wrap for today. We've yet to set a date for our follow-up meeting, but no doubt work on the template will continue in the meantime - perhaps you can contribute? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 17:15, 8 November 2020 (UTC)
Hi all. The other two days of this work will take place on 8 December, when we'll be running a Wikidata Lab on how to use the module, and 12 December which will be the last day to finish development and wrap everything up. I'll post a link for the lab when it's announced by Wikimedia Brazil, if anyone's interested in joining on the 12th December then please let me know. Thanks. Mike Peel (talk) 12:40, 23 November 2020 (UTC)
Apologies, I forgot to post the Wikidata Lab link here, but if you're interested then the recording is available at [3]. Thanks. Mike Peel (talk) 19:55, 12 December 2020 (UTC)

Editor-in-chief

The current sandbox code seems to get editor-in-chief from WD only if it fails to get editor. Shouldn’t it be the other way around? If both are entered and only one can be displayed, the preference should be only chief editor, and not only subeditors, I think. —Michael Z. 18:40, 10 December 2020 (UTC)

And something’s broken with that anyway: template:Cite_Q/testcases#Editor-in-chief. —Michael Z. 15:23, 11 December 2020 (UTC)
Looks fixed now. Thanks! —Michael Z. 15:29, 12 December 2020 (UTC)
@Mzajac: During today's session we fixed the bug, and also changed it so that the editor-in-chief comes first and then the other editors are displayed, does that look OK to you now? Thanks. Mike Peel (talk) 19:47, 12 December 2020 (UTC)
Looks really good. I’d like to show only main editor and omit the entire staff. I can use display-editors=1, but that still shows “et al.” (I can live with it) and plural “(eds.)” (should be fixed). I guess the inconsistency of single ed. after a comma but plural eds. in parentheses is inherited from {{citation}}. —Michael Z. 21:16, 12 December 2020 (UTC)
Hm, that’s not it. {{citation}} ends a list of multiple editors with comma + eds., no parentheses. —Michael Z. 23:18, 12 December 2020 (UTC)

Exporting

Was: "any already existing solution to export existing references on wikipedia to wikidata then use this template instead?"

the title. talk@TRANSviada 18:52, 8 December 2020 (UTC)

d:Wikidata:Zotero. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 20:30, 10 December 2020 (UTC)
oh good thing i do have Zotero installed. Going to try it out and later I'll report back. Thank you! talk@TRANSviada 12:28, 11 December 2020 (UTC)
oof it took more time than I had anticipated for me to figure this out mainly the browser extension and then the hidden Coins references importation from a wikipedia article. For real, there should be a better guide for this, like even a video. Now I'll try to get the works into Wikidata somehow. talk@TRANSviada 13:31, 11 December 2020 (UTC)
@TRANSviada: Andy did a video demo as part of this week's Wikidata Lab. Thanks. Mike Peel (talk) 14:02, 12 December 2020 (UTC)
That was of use, not installation, and Zotero was not cooperating. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 14:16, 12 December 2020 (UTC)
@Mike Peel: and @Pigsonthewing: That's great already because it shows the usage process. That's exactly what I need now. I myself may (not promising anything tho) do a video focusing on Wikipedia references importation to Wikidata through Zotero and QuickStatements and then referencing then back on Wikipedia. Still, I think this ultimately should be fully automated to be able to transform all wikipedia referenced works into Wikidata items. talk@TRANSviada 14:29, 13 December 2020 (UTC)

Any idea of when archive URL will be supported?

This is the feature that I'm waiting the most! User:Tetizeraz. Send me a ✉️ ! 07:20, 13 December 2020 (UTC)

@Tetizeraz: It's top of the list for the next fix. --RexxS (talk) 23:38, 14 December 2020 (UTC)
@RexxS: Does this "fix" roll-out for all the Cite Q from other Wikipedias? User:Tetizeraz. Send me a ✉️ ! 01:27, 18 December 2020 (UTC)
@Tetizeraz: we have Ederporto and Adamant.pwn who are able to translate the module into some other languages. The idea is, of course, to write the code to minimise any internationalisation, but there are bound to be some languages that need some translations. Nevertheless, it ought to be possible for a language Wikipedia to update their version from the latest version on enwiki quite easily, but you probably would get a more precise answer from Éder and Adamant.pwn from their own perspectives and experiences. Cheers --RexxS (talk) 02:17, 18 December 2020 (UTC)

Easily generate the needed Wikidata objects?

This template looks very useful, but only inasmuch as the needed Wikidata objects can easily be found if they exist, or created if they don't. For easily generating citations in Wikipedia from DOIs, URLs, etc, there are very convenient citation tools. Are there similar tools for generating Wikidata objects? Sylvain Ribault (talk) 22:03, 15 December 2020 (UTC)

@Sylvain Ribault: The Wikidata entities are already on Wikidata for a huge number of citations and bots tend to add them regularly, so much of the time you don't need to create anything on Wikidata. Usually the main work is in finding an already-existing citation on Wikidata, but a search on Wikidata for an article title (or part of it) is quite intuitive and at worst will produce a short-list of possible matches. Then you only need to copy and paste the Q-number from Wikidata into {{Cite Q}} to get a citation. One day, we'll have automated gadgets to do the job for us, but I'm hoping that the work being done on mw:Wikidata Bridge will create a lot of the routines needed and save us having to do the whole thing in JavaScript. --RexxS (talk) 02:28, 18 December 2020 (UTC)
@RexxS: Thank you, I had no idea that so many articles were already there! Still, I looked up all 14 references for Conformal field theory in Wikidata, and found only 5 of them. This is too few for making it practical to systematically use CiteQ. Unless I can tell the bots to deal with the relevant journals in my field. And while they are at it, why not grab all of arXiv? Sylvain Ribault (talk) 20:45, 18 December 2020 (UTC)
@Sylvain Ribault: I think there are maybe 25 million scientific articles on Wikidata, and there's room for a lot more, especially in niche fields. But you really want to ask questions like "can you import this database" at d:Wikidata:Project chat or directly at d:Wikidata:Bot requests. The folks there are the experts on putting information into Wikidata; I merely concentrate on how we can get it back out again. --RexxS (talk) 21:39, 18 December 2020 (UTC)
@Sylvain Ribault: For anything that has a DOI but isn't yet in wikidata, the easiest way to add it is probably to use the old SourceMD tool. Sadly it only includes author name strings rather than author items. More broadly, the WikiCite/Shared_Citations proposal would likely be the thing to introduce Cite_Q into the citoid reference adding tool. T.Shafee(Evo&Evo)talk 02:13, 19 December 2020 (UTC)
Thank you RexxS and T.Shafee(Evo&Evo). I have asked for confirmed rights on Wikidata in order to be able to try QuickStatements, and suggested the import of articles from arXiv in d:Wikidata:Project_chat. Sylvain Ribault (talk) 20:32, 19 December 2020 (UTC)

Publisher bug

If the publisher is not something that exists as an item in Wikidata, it will commonly be encoded in Wikidata as "publisher: unknown value; stated as: XXXX" (for example [4]). Cite Q outputs this as "Unknown", but it should probably output "XXXX" instead (as the publisher is known, it just doesn't have a Wikidata item). For example, if the publisher is encoded as "publisher: unknown value; stated as: Chicago Natural History Museum", Cite Q should output "Chicago Natural History Museum". (And yes, this is probably an abuse of "unknown value", but that's how some people are setting publishers that don't have items.) Kaldari (talk) 22:03, 16 December 2020 (UTC)

@Kaldari: we've already implemented the word "Anonymous" (actually the label fetched from anonymous (Q4233718) to internationalise it) when the author is an unknown value or is a value set to anonymous (Q4233718), although values for qualifiers object named as (P1932) or subject named as (P1810) will override that. It shouldn't be too difficult to re-use the corresponding logic for publisher. I think we all recognise that code for retrieval is always going to have to cope with abuses of the database structure and values, and we just have to suck it up and deal with it. I'll get that onto the to-do list. Cheers --RexxS (talk) 02:43, 18 December 2020 (UTC)
That’s an old name for the Field Museum. I’ve updated the two WD items. Yup, named as should still override the display. I understand it is normal practice to cite names as stated in the source, so they can be found in library catalogues, etcetera.
 —Michael Z. 22:57, 18 December 2020 (UTC)
Even in cases where the publisher is set to an item, as Phalangida from tropical America (Q51517665) is now, we should still prefer the "stated as" value, as Wikipedia citations are supposed to reflect the metadata as it is actually written in the original source (within reasonable limits). Kaldari (talk) 22:59, 21 December 2020 (UTC)
That's exactly what we implemented for author and editor, so I'm grateful for a confirmation that it is the preferred behaviour. As I said, that should be easy to re-use for publisher. --RexxS (talk) 23:03, 21 December 2020 (UTC)

Added more visibility for {{Cite Q}} template

Kazkaskazkasako (talk) 01:34, 18 December 2020 (UTC)

I have modified the former addition with the following caveat: "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." – Jonesey95 (talk) 18:14, 22 December 2020 (UTC)
@Jonesey95: that is completely untrue and you should make sure of your facts before writing such nonsense. {{Cite Q}} fully supports both CS1 and CS2, and also fully supports every style of author name that {{Citation}} supports (as well as every other parameter recognised by the common Module:Citation/CS1), because it passes all of its arguments through {{Citation}}. In addition, you should recognise that any article's citation style may be changed by consensus. --RexxS (talk) 21:24, 22 December 2020 (UTC)
I stand corrected about CS1.
Please demonstrate how Cite Q supports conversion of author names to a "Last, First" or Vancouver name format in order to maintain compliance with an article's existing citation style, and also how it maintains compatibility with sfn/harv templates that link to full citations. I looked through the documentation here and at Wikidata but was unable to find any of this functionality. There has been a rash of Cite Q additions to articles that conflict significantly with existing citation styles, perhaps inspired by these new instructions, so I wanted to ensure that activity was nipped in the bud. – Jonesey95 (talk) 21:34, 22 December 2020 (UTC)
Retrieved from "https://wiki.riteme.site/w/index.php?title=Template_talk:Cite_Q/Archive_3&oldid=1001558979"