Help talk:Citation Style 1

Citation templates

... in conception

... and in reality

Unrecognized languages

Would it be possible to set up a Lua table as a final fallback for language checking (or if the table exists already, point me to it) so that we can clear out Category:CS1 maint: unrecognized language (at least the mainspace ones)? I would expect to provide the IETF/ISO code of interest as the key (i.e., support the key only as input in the wikitext of a citation) and the name of the language as the value, so that in the future if MediaWiki comes to support a certain code, we will not be using the wrong name (unless deliberately set in the relevant table that exists as an override). Izno (talk) 03:31, 14 February 2022 (UTC)

The ISO 639-1 code for Irish is supposed to be “ga” but if I use the parameter “lang=ga” in a citation, it shows as “(in Ga).” Using the ISO 639-2 and -3 code of “gle” also fails. Xenophore; talk 00:47, 16 March 2022 (UTC)

That happens because Ga (gaa) is also a language name. I'll think about how best to address this.

—Trappist the monk (talk) 01:02, 16 March 2022 (UTC)

In the meanwhile, this works:

{{cite book |title=Title |language=ga-IE}} → Title (in Irish).

—Trappist the monk (talk) 01:07, 16 March 2022 (UTC)

unfit url maintenance message

I keep seeing more and more of these green maintenance messages and I have been making an effort to fix them as I see them. But there is one type that cannot be fixed and that is url-status=usurped because I can't make the URL stop being usurped, e.g. this is the archive and this is the the original URL which surely meets the definition of "usurped" consisting of both spam and porn. So what do I do to make the green maintenance message go away? Otherwise I or others are going to keep seeing and try and fix it, again and again and again. I think a maintenance message has to be for things that can be fixed and where they can't be fixed, a way needs to exist to suppress the maintenance message to avoid the rework by others. The other thing is that such citations have some extra text appearing at the end of citation which isn't in the citation, which I would like to suppress. In the case of the URL above, it is "OurToowong page for BBC". The citation title is "BBC" and the citation website is "Our Toowong" so what is purpose of this extra text? I see it on the "Archived copy" title citations, where it makes sense (as it is usually a good guess for what the title should be), but I don't see its relevance when there is a genuine title in the citation. I note it appears to me when logged-out so the readers are seeing it too.Kerry (talk) 00:09, 6 March 2022 (UTC)

This is about Brisbane Boys' College and Toowong? Always good to say where you are seeing something so we don't have to guess... On both of those pages the text 'OurToowong page for BBC' has been appended after the cs1|2 template's closing }} and before the reference's closing </reg> tag. That text is not something the the template adds. For Brisbane Boys' College, the 'OurToowong page for BBC' text was added at this edit. Later, you converted the simple external link reference to use {{cite web}} at this edit. Today, you added a reference and the 'OurToowong page for BBC' text to Twoong at this edit.

I think that you are the first to complain about lingering maintenance messaging.

—Trappist the monk (talk) 01:10, 6 March 2022 (UTC)

"green maintenance message" .. I don't see a green message for cites with |url-status=usurped. They don't really need fixing. Also in this edit you added |url-status=deviated but the source URL is "404" - ie. dead, not deviated. -- GreenC 02:03, 6 March 2022 (UTC)

This example template has a green maintenance message:

{{cite web |title= Title |url=//example.com |archive-url=//archive.org |archive-date=2022-03-06 |url-status=usurped}}

"Title". Archived from the original on 2022-03-06.{{cite web}}: CS1 maint: unfit URL (link)

User:GreenC/common.css does not have the css to enable the message display (I did not look at your various skin css pages). Without that css the maintenance messages will be hidden:

<span class="cs1-maint citation-comment"><code class="cs1-code">{{[[Template:cite web|cite web]]}}</code>: CS1 maint: unfit URL ([[:Category:CS1 maint: unfit URL|link]])</span>

The classes cs1-maint and citation-comment are defined in Module:Citation/CS1/styles.css. To show maintenance messaging, see Help:CS1 errors § Error and maintenance messages.

—Trappist the monk (talk) 12:02, 6 March 2022 (UTC)

I see. If by default the green messages are hidden from users, that's good because usurped URLs are not in need of maintenance and we shouldn't encourage users to do anything about it (by default). There might be an argument the cite or URL should be deleted entirely, but there are counter-arguments such as usurped URLs over time revert to 404s once spammers stop funding the domain name. My only thought is maybe we shouldn't green message usurped cites, however it's not a big deal either way. -- GreenC 14:42, 6 March 2022 (UTC)

GreenC, Kerry, Trappist the monk: I don't mind as much the green text next to citations with unfit URL's, which doesn't even appear for users that don't enable it at their common CSS page. What I believe is more of a problem is the warning at the top of the page whenever an edit is previewed for pages containing an unfit URL (regardless of whether maintenance messages are enabled on a user's common page). I don't see any benefit to the warning which I think will just distract / take up the time of a lot of editors. I initially brought this issue up here at Wikipedia:Help desk because I couldn't figure out how to get the maintenances messages to display. The conversation then turned to why the warning is necessary in the first place, upon which Trappist directed me here. So I'm just throwing my 2 cents in on the issue.--Jamesy0627144 (talk) 02:08, 30 March 2022 (UTC)

Bug in Citation/CS1/Date validation

I am currently localizing the CS1 module for Estonian Wikipedia and found a bug. In Module:Citation/CS1/Date validation, in function reformatter:

if t.a then t.y = t.a; end

If the date has two years, as is the case for 'My-My', 'dMy-dMy', 'Mdy-Mdy' formats, it erroneously replaces the first year (y) with the anchor year (a). What you want to do instead is to replace the second year (y2). This works for me:

if t.a and t.y2 then t.y2 = t.a; elseif t.a and t.y then t.y = t.a; end

Kaniivel (talk) 18:49, 12 March 2022 (UTC)

Thanks for that. I've implemented a fix in the sandbox:

Cite book comparison

Wikitext	{{cite book|date=25 December 2020 – 25 January 2021|df=mdy|title=Title}}
Live	Title. December 25, 2020 – January 25, 2021.
Sandbox	Title. December 25, 2020 – January 25, 2021.

Cite book comparison

Wikitext	{{cite book|date=25 December 2020 – 25 January 2021a|df=mdy|title=Title}}
Live	Title. December 25, 2020 – January 25, 2021a.
Sandbox	Title. December 25, 2020 – January 25, 2021a.

Cite book comparison

Wikitext	{{cite book|date=December 25, 2020 – January 25, 2021|df=dmy|title=Title}}
Live	Title. 25 December 2020 – 25 January 2021.
Sandbox	Title. 25 December 2020 – 25 January 2021.

Cite book comparison

Wikitext	{{cite book|date=December 25, 2020 – January 25, 2021a|df=dmy|title=Title}}
Live	Title. 25 December 2020 – 25 January 2021a.
Sandbox	Title. 25 December 2020 – 25 January 2021a.

Cite book comparison

Wikitext	{{cite book|date=December 2020 – January 2021|df=dmy|title=Title}}
Live	Title. December 2020 – January 2021.
Sandbox	Title. December 2020 – January 2021.

Cite book comparison

Wikitext	{{cite book|date=December 2020 – January 2021a|df=dmy|title=Title}}
Live	Title. December 2020 – January 2021a.
Sandbox	Title. December 2020 – January 2021a.

Cite book comparison

Wikitext	{{cite book|date=December 25, 2021|df=dmy|title=Title}}
Live	Title. 25 December 2021.
Sandbox	Title. 25 December 2021.

Cite book comparison

Wikitext	{{cite book|date=December 25, 2021a|df=dmy|title=Title}}
Live	Title. 25 December 2021a.
Sandbox	Title. 25 December 2021a.

Cite book comparison

Wikitext	{{cite book|date=25 December 2021|df=mdy|title=Title}}
Live	Title. December 25, 2021.
Sandbox	Title. December 25, 2021.

Cite book comparison

Wikitext	{{cite book|date=25 December 2021a|df=mdy|title=Title}}
Live	Title. December 25, 2021a.
Sandbox	Title. December 25, 2021a.

Cite book comparison

Wikitext	{{cite book|date=December 2021|df=dmy|title=Title}}
Live	Title. December 2021.
Sandbox	Title. December 2021.

Cite book comparison

Wikitext	{{cite book|date=December 2021a|df=dmy|title=Title}}
Live	Title. December 2021a.
Sandbox	Title. December 2021a.

Cite book comparison

Wikitext	{{cite book|date=2021-12-25|df=mdy|title=Title}}
Live	Title. December 25, 2021.
Sandbox	Title. December 25, 2021.

Cite book comparison

Wikitext	{{cite book|date=2021-12-25|df=dmy|title=Title}}
Live	Title. 25 December 2021.
Sandbox	Title. 25 December 2021.

—Trappist the monk (talk) 20:29, 12 March 2022 (UTC)

cite episode complains about formatting errors that dont exist

For some reason, when defining |format in a cite episode, itll produce the error "|format= requires |url=", even when the |url parameter is defined. Also, the format doesnt even appear anywhere. Is this meant to be disabled for this citation format or something? (Originally found this while editing Evanna Lynch, check reference 12).

Example:

"Title" (Format). Series. (<-- Error in question - url IS defined)

If anyone knows about this, please tell me why or if its intended. Thanks. Aidan9382 _(talk) 18:27, 14 March 2022 (UTC)

When the new lua versions of the templates were created, the goal was to make them render in exactly the same form as their wikitext predecessors. Because the old {{cite episode}} did not support |format=, the new {{cite episode}} did not support |format=. The new {{cite episode}} template was created nearly seven years ago (18 April 2015). I don't recall anyone complaining about |format= not working in {{cite episode}} between then and now. Fixed in the sandbox:

Cite episode comparison

Wikitext	{{cite episode|air-date=23 April 2009|credits=Presenter: [[Ryan Tubridy]]|format=MP3|network=[[RTÉ Radio 1]]|series=[[The Tubridy Show]]|title=Evanna Lynch|url=http://www.rte.ie/podcasts/2009/pc/pod-v-230409-28m27s-tts.mp3}}
Live	Presenter: Ryan Tubridy (23 April 2009). "Evanna Lynch" (MP3). The Tubridy Show. RTÉ Radio 1.
Sandbox	Presenter: Ryan Tubridy (23 April 2009). "Evanna Lynch" (MP3). The Tubridy Show. RTÉ Radio 1.

—Trappist the monk (talk) 19:27, 14 March 2022 (UTC)

Error with url-status=live if no archive-url

The documentation says url-status: this optional parameter is ignored if archive-url is not set. However, if url-status=live is included in a Citation template, the error message {{cite web}}: CS1 maint: url-status (link) is displayed if the mouse is hovered over the citation number, in the "This is only a preview" box, and sometimes in the list of references. I have WP:boldly added a note to that effect in the documentation (it was quickly reverted); either the documentation must be changed, or the template must be changed to allow url-status=live without error message.

I suppose this could conceivably be an artefact of my particular setup, but it definitely happens.

Best wishes, Pol098 (talk) 15:18, 15 March 2022 (UTC)

What you wrote was this:

[Note: as of 15 Mar 22, if url-status=live is included in a citation template without an archive-url, the error message {{cite web}}: Invalid |url-access=live is displayed.]

and that is not correct. It is possible to get a similar message:

{{cite book |title=Title |url-status=Live}} → Title. {{cite book}}: Invalid |url-status=Live (help)

cs1|2 templates emit a lot of maintenance messages. I don't know if it is worth the effort to note each message in the documentation of every parameter where that message might apply, but if we do, then the documentation must be correct.

—Trappist the monk (talk) 15:32, 15 March 2022 (UTC)

Thanks for response. As I've drawn attention to this issue amongst those who know the system, I won't do anything more. My opinion is that "this optional parameter is ignored if archive-url is not set" should be removed from the url-status documentation, as it generates the warning when the mouse is hovered over a ref number in read mode, and as there is absolutely no point in adding url-status=live to a reference without an archive-url. But I'm not going to do anything or to argue, whatever is done. Best wishes, Pol098 (talk) 15:48, 15 March 2022 (UTC)

@Pol098: Note that the red messages are errors, while the green messages are maintenance messages. GoingBatty (talk) 21:26, 16 March 2022 (UTC)

Thanks, that's of course true. I should have made the distinction in my comment. I find it a bit disconcerting to see a maintenance message when hovering over a ref number in read mode, and seeing that maintenance warnings are reported when previewing an edit. But I have nothing else to say. Best wishes, Pol098 (talk) 22:08, 16 March 2022 (UTC)

archive-url and identifier-created urls

When |url= is omitted or empty, |title= in {{cite journal}} will be linked from the value assigned to |pmc= or, alternatively, |doi= (requires |doi-access=free). These identifier-created urls are not |url= so when |access-date= is present, cs1|2 emits an error message:

{{cite journal |title=Title |journal=Journal |pmc=12345 |access-date=2022-03-16}}

"Title". Journal. PMC 12345. {{cite journal}}: |access-date= requires |url= (help)

That same rule should apply to |archive-url= which also requires |url= but, in the live module, it doesn't. Fixed in the sandbox.

Cite journal comparison

Wikitext	{{cite journal|archive-date=2022-03-16|archive-url=//archive.org|doi-access=free|doi=10.4234/sommat|journal=Journal|title=Title}}
Live	"Title". Journal. doi:10.4234/sommat. {{cite journal}}: |archive-date= requires |archive-url= (help); |archive-url= requires |url= (help)
Sandbox	"Title". Journal. doi:10.4234/sommat. {{cite journal}}: |archive-date= requires |archive-url= (help); |archive-url= requires |url= (help)

—Trappist the monk (talk) 19:39, 16 March 2022 (UTC)

I tend to agree that using access-date and archive-url for publications accessed in ways other than through their url is a mistake, so in philosophical terms I don't disagree with this change. But I am curious about two points. (1) We still support access-date when there is a nonempty chapter-url, contribution-url, or other url parameter, not just the main url= parameter, right? Will there be any way to supply an archive-url for those parameters, after this change? (2) Do you have any data on how many articles this will cause errors in? —David Eppstein (talk) 20:22, 16 March 2022 (UTC)

|chapter-url=, |conference-url=, |contribution-url=, |entry-url=, |map-url=, |section-url=, |transcript-url= are not supported by {{cite journal}}. Similarly, these url-holding parameters are not supported by {{citation}} when |journal= is set.

I don't know how many {{cite journal}} templates do not have |url= but do have |doi= and |doi-access=free; or do have |pmc=; and do have |archive-url=. Relatively easy to find templates with something; not so easy to find templates without something. I only discovered this because I found a template that had |pmc= and |archive-url= where the archived url was the url in |lay-url= (which has never been supported by |archive-url=) but wasn't showing the archive-url-requires-url error message. I doubt that that example is the only one of its kind but I cannot say how many more are out there.

—Trappist the monk (talk) 21:37, 16 March 2022 (UTC)

They may not be supported by cite journal, but they are supported by cite book and cite conference, which also allow references to have auto-linked doi but no url. I was assuming that you would want those other citation templates to remain consistent with cite journal. —David Eppstein (talk) 21:41, 16 March 2022 (UTC)

Auto-linking |title= from |pmc= or from |doi= (when |doi-access=free) is only supported by {{cite journal}} and by {{citation}} (when |journal= is set). Here are two {{cite book}} without |url=; one with |pmc= and the other with |doi= and |doi-access=free:

• {{cite book |title=Title |journal=Journal |pmc=12345}}
  • Title. PMC 12345. {{cite book}}: |journal= ignored (help)
• {{cite book |title=Title |journal=Journal |doi-access=free |doi=10.4234/sommat}}
  • Title. doi:10.4234/sommat. {{cite book}}: |journal= ignored (help)

and the same for {{cite conference}}:

• {{cite conference |title=Title |journal=Journal |pmc=12345}}
  • Title. Journal. PMC 12345.
• {{cite conference |title=Title |journal=Journal |doi-access=free |doi=10.4234/sommat}}
  • Title. Journal. doi:10.4234/sommat.

None of the four examples above auto-link |title=. I included |journal= just in case, but the result is the same if your take it away. Can you give examples of any cs1|2 templates other than the cases I've demonstrated that auto-link |title=?

—Trappist the monk (talk) 22:02, 16 March 2022 (UTC)

I take this answer to be a denial of my assumption that you would want those other citation templates to remain consistent with cite journal. —David Eppstein (talk) 22:35, 16 March 2022 (UTC)

My answer was an attempt to show that your statement:

They may not be supported by cite journal, but they are supported by cite book and cite conference, which also allow references to have auto-linked doi but no url.

is inaccurate. If that is not what I have accomplished then I have failed to communicate.

—Trappist the monk (talk) 23:21, 16 March 2022 (UTC)

Suggestion for generic author name

Regarding CS1 errors, I've noticed some incidences of "web master"/"webmaster"/"web-master" (and the capitalised variants). It may be useful to also detect those in the author, etc., fields. --Xurizuri (talk) 04:09, 19 March 2022 (UTC) (please ping me if you respond)

@Xurizuri - I've got BattyBot removing those values from the |author= parameter. Thanks for the suggestion! GoingBatty (talk) 21:37, 21 March 2022 (UTC)

Should argument to via parameter allowed to have a url?

@Izno and Trappist the monk: Given the January update to Module:Citation/CS1, I see that urls supplied to |via= now generate an error. However, common usage (e.g., {{FEIS}} and {{Calflora}} before I fixed them) and the documentation seem to imply that |via= should contain urls. In fact, I'm not sure how you can have non-url arguments?

Can we include |via= in the list of url-enabled parameters? — hike395 (talk) 21:39, 19 March 2022 (UTC)

Umm, common usage is not so common, at least according to these searches:

~700 articles with |via=http...

>219000 articles with |via=<anything> (search times out)

I don't read anything in the documentation that [implies] that |via= should contain urls.

—Trappist the monk (talk) 22:27, 19 March 2022 (UTC)

Via should not contain urls, no. Headbomb {t · c · p · b} 00:02, 20 March 2022 (UTC)

Respectfully, Trappist, that is not the right search query to use. If you look for where editors have used |via=something url-like, you get

>16,000 articles.

A very common pattern is to refer to websites by name: if we look through your second query, you'll see usage like |via=Yahoo News or |via=Google Books (which are also suggested by the documentation). The main example in the documentation is [[Dictionary.com]], which is a wikilink to partial url (a name of a website).

If |via= is being filled with partial URLs or names of external sites, why should links to external sites be excluded? Alternatively, if you want to maintain purity between name parameters and url parameters, I would suggest that we would need a |via-url= parameter. I think allowing URLs in |via= is simpler, but I'm open to either. — hike395 (talk) 00:29, 20 March 2022 (UTC)

The parameter is commonly used when there is an existing |url= in order to clarify the url's provenance (if not at the publishing entity) or the content's format (if different from the published-as-cited version). It may also be used to add clarity to a non-CS1-defined identifier. And it may wikilinked. Providing another url is clutter without obvious benefit. 68.173.76.118 (talk) 00:39, 20 March 2022 (UTC)

Personally, I also use the parameter for clarity in citable self-published works whether |url= exists or not. The publishing provider is inserted and optionally wikilinked. But even in these cases, I don't think a via-based url adds anything useful to the citation. 68.173.76.118 (talk) 01:10, 20 March 2022 (UTC)

If you care about the provenance of a citation, and it's not obvious from the url or publisher string, then it would seem providing an external link to the delivery site would be helpful, yes? That way readers can assess the delivery mechanism. Also, I'm not sure why a wikilink in a via argument would be acceptable while an external link would be clutter? — hike395 (talk) 01:23, 20 March 2022 (UTC)

Not the provenance of the citation, the provenance of the url. A reader who links to the url may be understandably mystified to see the work published by somebody other than the cited publisher. The presence of |via= indicates this is not accidental or erroneous. It is to be presumed that there are no copyvio issues and that the url publisher is at least as trustworthy as the cited publisher. Their treatment should be the same. Izno, below, elaborates. 64.18.9.194 (talk) 02:31, 20 March 2022 (UTC)

|via= as a parameter is essentially |publisher=, in which we do not allow URLs. I see no reason to do so here either. As for your [hike395]'s modified query, no, Trappist's is more correct. Yours finds a whole bunch of domain names with TLDs, when what you want is the URL to show what you think is a certain use. This is more correct than his, but still only some ~1500 uses, so that is not persuasive either.

I also do not see where in the documentation you believe that the documentation promoted using a URL in this parameter. Izno (talk) 01:50, 20 March 2022 (UTC)

My original statement wasn't clear --- I meant to say "website" not a syntactically correct URL. But given that no one wants to implement this, I'll withdraw the suggestion, and leave |via= deleted from the various botany templates. — hike395 (talk) 05:01, 20 March 2022 (UTC)

[u.a.]

Previous discussions:

Help talk:Citation Style 1/Archive 2#What does [u.a] mean?

Help talk:Citation Style 1/Archive 28#|location=Cambridge [u.a.]

I just stumbled across two citations in Dorsolateral prefrontal cortex (references 1 & 25) that use '[u.a.]' in |location=. Apparently '[u.a.]' is an initialism of unter anderem ('among other things') or und andere ('and others').

Also, apparently, '[u.a.]' was at one time used by WorldCat so was copied from there to here by Citoid and/or its predecessors into |location=. At this writing, there are about 2700 articles that have '[u.a.]'.

What to do with '[u.a.]'? Continue to ignore? Should Module:Citation/CS1 add a maint cat when '[u.a.]' is found? If we do that, what is the recommended maintenance? I suspect that we should at least document '[u.a.]' somewhere so that editors can know what it means.

—Trappist the monk (talk) 16:38, 20 March 2022 (UTC)

Assuming this is used exclusively for publisher |location=, I think it should be considered unnecessary and removed. We are well past the age where a publisher subsidiary would differentiate from another subsidiary of the same publisher and language. The primary lication of the imprint in the country of publication is sufficient. If the initialism is used (erroneously) in place of et al., that should be fixed.

Fire up the RfC for the required tracking category. 69.203.140.37 (talk) 18:55, 20 March 2022 (UTC)

SSRN limit increase

There exists a citation with a valid SSRN above the current configured limit of 4000000. See Paleobiota_of_the_Posidonia_Shale citation 89, or see here for a pasted version.

Thanks. Aidan9382 _(talk) 20:59, 23 March 2022 (UTC)

References

Wikidata QID parameter

I have added the Wikidata Q identifier (Q43649390) parameter |q= to the sandbox. m:WikiCite has been adding citations and linked bibliographic data to Wikidata, and linking to them would be useful. Can and should internal_link_id be used? Can and should input be normalized to an uppercase "Q"? int21h (talk · contribs · email) 05:47, 24 March 2022 (UTC) int21h (talk · contribs · email) 06:34, 24 March 2022 (UTC)

How does the Q identifier help a reader discover the citation's source? 71.247.146.98 (talk) 11:46, 24 March 2022 (UTC)

There are several efforts to use QIDs and Wikidata, probably mostly related to m:WikiCite. Using QID Q24316383 as an example, a citation graph has been added using cites work (P2860) to aid discovery, and projects like d:Wikidata:Scholia (WP) can visually explore the same QID e.g. Q24316383. d:Scholia might even be a better link than Wikidata itself. (Scholia was also recently Wikidata Data Reuse Days 2022.) There are also other tools such as m:Reasonator. int21h (talk · contribs · email) 13:58, 24 March 2022 (UTC)

I like building citation graphs as much as the next scientist, but how does that help the reader of an encyclopedia article find the reference they've been told to read? XOR'easter (talk) 17:11, 24 March 2022 (UTC)

QIDs can provide literally thousands of data types (and thousands of data) to a reader to help find the reference they've been told to read, that neither this module nor any of its current external identifiers can provide. Wikidata further links to external id systems that this module and its current external ids do not. A limited selection is at d:Wikidata:List of properties/work. int21h (talk · contribs · email) 20:08, 24 March 2022 (UTC) int21h (talk · contribs · email) 21:20, 24 March 2022 (UTC)

As was pointed out in this section, there have been several discussions about Wikidata. Serious concerns have been raised about the provenance and reliability of Wikidata data, and the potential for circular references or/and self-references. That would be enough to disqualify its use in the verifiability process. Citations are not supposed to be pondered over or dwelled upon; if readers do so, then the citation is probably not exactly right. The point is to provide readers with the minimum of the most relevant metadata in order to easily and quickly verify the text and keep on reading (hopefully with renewed interest following the verification). Not to inundate them (or citation editors) with a bunch of data whose relevance and applicability is rare or uncertain. I don't see the usefulness of the Q identifier in this context. 71.247.146.98 (talk) 12:11, 25 March 2022 (UTC)

Where is the discussion that establishes a consensus for this change? I seem to recall that some sort of wikidata parameter has been discussed here before but no consensus to implement has ever been achieved. Here are some discussions that did not achieve consensus:

• Help talk:Citation Style 1/Archive 34 § Parameter for Wikidata ID
• Help talk:Citation Style 1/Archive 37 § Parameter for Wikidata ID, redux
• Help talk:Citation Style 1/Archive 47 § Wikidata identifier
• Help talk:Citation Style 1/Archive 70 § Wikidata identifiers

—Trappist the monk (talk) 13:53, 24 March 2022 (UTC)

And thus the consensus building continues. I believe my comment above addresses how QIDs aid discoverability and exploration. What other issues came up? int21h (talk · contribs · email) 14:02, 24 March 2022 (UTC)

That is disingenuous. You have already been pointed to other issues with your program of converting references to QIDs very recently, in a discussion that you participated in at Wikipedia talk:Citing sources § Template:Cite Q and WP:CITEVAR —David Eppstein (talk) 16:51, 24 March 2022 (UTC)

The discussion at WT:CITE is about an altogether different template and a different policy issue than brought up in the discussions above, AFAICT. WP:CITEVAR and discoverability are different issues. Did WP:CITEVAR come up in this module re QIDs? int21h (talk · contribs · email) 16:56, 24 March 2022 (UTC)

@Nikkimaria: Please provide a summary of the discussion as of 25 March 2022 00:20 UTC. int21h (talk · contribs · email) 02:46, 25 March 2022 (UTC)

Other than yourself, it does not appear that any participants support inclusion of the proposed parameter. Nikkimaria (talk) 12:15, 25 March 2022 (UTC)

Generic title

Hello, can "Please login" at the start of a |title= be added to the generic title list. Currently about 60 occurrences. Thanks, Keith D (talk) 14:59, 30 March 2022 (UTC)

New CS1 citation template

I'm very pleased to announce the newest addition to the CS1 family, {{Cite bathroom graffiti}}. {{u|Sdkb}} ^talk 08:56, 1 April 2022 (UTC)

Generic author name "By"

A value of "By" in |last= is present in 200+ articles at this time. Marking author/editor names starting with "By " or containing only "By" (but not detecting "Byrd" etc.) might be helpful. I don't think that "By" is a valid surname, but it is a hypothetical edge case. – Jonesey95 (talk) 17:02, 1 April 2022 (UTC)

• John By would likely disagree. As would Oddbjørn By, Sverre By, and Eli Gunhild By. —David Eppstein (talk) 21:17, 1 April 2022 (UTC)

• That person does not appear to be cited anywhere on Wikipedia. I did find Sverre By and Ulrika By cited in about five articles out of about 200. I will let consensus decide whether that ratio is worth implementing error detection at the cost of having to use (()) notation around two authors' last names. – Jonesey95 (talk) 21:41, 1 April 2022 (UTC)

Validity of URLs in inset parameter of cite map

A question that's come up recently and is now a point of conflict in some articles. The inset parameter in {{cite map}} throws up an error if a URL is placed there, which is a common practice for maps that are divided between multiple pages/links (such as those issued by US state governments). Given that insets are analogous to chapters in books, I think we'd benefit from having an inset-url parameter to hold links for insets that do require a separate link for verifiability. I posted about this a few months ago but it didn't gain any traction, so I hope there'd be some feedback this time around. SounderBruce 21:36, 2 April 2022 (UTC)

If we can link a page number for a book, we should be able to link an inset on a map. Imzadi 1979 → 22:12, 2 April 2022 (UTC)

A change like this will resolve the error with no change in visible output (other than removal of the red error message). DrKay (talk) 07:21, 3 April 2022 (UTC)

• Using |at= : Washington State Highways, 2014–2015 (PDF) (Map). Olympia: Washington State Department of Transportation. 2014. Tri-Cities: Richland, Kennewick & Pasco inset. Retrieved September 2, 2021.
• Using |inset= : Washington State Highways, 2014–2015 (PDF) (Map). Olympia: Washington State Department of Transportation. 2014. Tri-Cities: Richland, Kennewick & Pasco inset. Retrieved September 2, 2021. {{cite map}}: External link in |inset= (help)

Given that insets are analogous to chapters in books,... Although this may not be strictly true in the sense that insets are more akin to sections rather than chapters, there is (by design) information in inset maps that does not appear in the base map. This is enough to warrant not only a parameter but also a convenience-link option. In proper software design, the {{cite map}} |inset= would be an alias of (hypothetical base-template) {{cite xxx}} |section=, |inset-url= would be an alias of |section-url=, and so on. In any case the OP's request seems justified, at least for print maps, although perhaps it should be considered for digital/online maps as well. Links: [1] [2] [3].

65.88.88.201 (talk) 15:14, 3 April 2022 (UTC)

eISBN again

Should it be reconsidered as a dedicated identifier? Some data providers require the field from publishers eg JSTOR Metadata Requirements: "Electronic ISBN. We require an eISBN for each book. We can not use the print ISBN as the electronic ISBN." Which means that a citation with the addition of |eISBN= could expedite discovery. 65.88.88.93 (talk) 19:37, 4 April 2022 (UTC)

In case it was not obvious, this concerns works published in digital media (including eBooks), regardless of whether they are also published in print. 65.88.88.93 (talk) 19:55, 4 April 2022 (UTC)

Adding internet image links

Hello. When I expanded the section of an article, I used the cite magazine template to cite an interview and I added direct links to scans of those pages, so the content can be verified. To be honest, however, I'm not entirely sure about this practice and a potential copyright infringement. The magazine is defunct, so it would be very hard to acquire it physically. I suppose that I could simply use the cite magazine template without adding links, but I would rather prefer that the content can be easily checked. I would like to know some inputs about this. - Xexerss (talk) 22:40, 4 April 2022 (UTC)

There is guidance at WP:COPYLINK. – Jonesey95 (talk) 22:52, 4 April 2022 (UTC)

Params transcript & transcript-url

I don't know exactly when or why they disappeared, and whatever nonsense preceded the disappearance is not important. They are not trivial, and are needed now. The hacks and work-arounds have run their course, the parameters themselves should reappear. Citations that traditionally and currently need these parameters are usually input by editors with the following templates:

• {{cite AV media}}
• {{cite conference}}
• {{cite episode}}
• {{cite interview}}
• {{cite podcast}}
• {{cite speech}}

65.88.88.57 (talk) 18:07, 5 April 2022 (UTC)

I think this September 2020 discussion describes the most recent change that is relevant to this question. Here are examples of those six templates (plus {{cite serial}}, whose documentation currently contains |transcript=), showing that at this writing, AV media and episode work fine.

Cite AV media comparison

Wikitext	{{cite AV media|title=Title|transcript-url=http://www.example.com|transcript=Transcript}}
Live	Title. Transcript.
Sandbox	Title. Transcript.

Cite episode comparison

Wikitext	{{cite episode|series=Series|title=Title|transcript-url=http://www.example.com|transcript=Transcript}}
Live	"Title". Series. Transcript.
Sandbox	"Title". Series. Transcript.

Cite interview comparison

Wikitext	{{cite interview|series=Series|title=Title|transcript-url=http://www.example.com|transcript=Transcript}}
Live	"Title" (Interview). Series. {{cite interview}}: Unknown parameter |transcript-url= ignored (help); Unknown parameter |transcript= ignored (help)
Sandbox	"Title" (Interview). Series. {{cite interview}}: Unknown parameter |transcript-url= ignored (help); Unknown parameter |transcript= ignored (help)

Cite podcast comparison

Wikitext	{{cite podcast|series=Series|title=Title|transcript-url=http://www.example.com|transcript=Transcript|url=http://www.example.com/foo}}
Live	"Title" (Podcast). Series. {{cite podcast}}: Unknown parameter |transcript-url= ignored (help); Unknown parameter |transcript= ignored (help)
Sandbox	"Title" (Podcast). Series. {{cite podcast}}: Unknown parameter |transcript-url= ignored (help); Unknown parameter |transcript= ignored (help)

Cite speech comparison

Wikitext	{{cite speech|series=Series|title=Title|transcript-url=http://www.example.com|transcript=Transcript}}
Live	Title (Speech). Series. {{cite speech}}: Unknown parameter |transcript-url= ignored (help); Unknown parameter |transcript= ignored (help)
Sandbox	Title (Speech). Series. {{cite speech}}: Unknown parameter |transcript-url= ignored (help); Unknown parameter |transcript= ignored (help)

I think the next step is to provide examples of actual citations of sources where |transcript= would be used in real articles. – Jonesey95 (talk) 18:38, 5 April 2022 (UTC)

All six templates are used to cite sources originally in non-text media. Is an example really needed to demonstrate the usefulness (re:verification/accessibility etc.) of providing the content in text form in a unique, format-specific parameter? One may very well have a citation of a radio/tv interview with a URL to the stream and a URL to the transcript. Or a speech citation that provides links to both the audio and/or video and the text. 65.88.88.57 (talk) 18:56, 5 April 2022 (UTC)

Templates are generally constructed to meet actual, not hypothetical needs. It should be easy to demonstrate that need, for the record. I believe that you or someone else can do it here with little effort, with the exception that {{cite conference}} is for published proceedings, not for audio/video sources. – Jonesey95 (talk) 20:39, 5 April 2022 (UTC)

The enhanced verifiability a transcript provides is not hypothetical, but actual and actionable. Citations may include multiple content-locators such as doi/pmc/jstor etc. This case is similar. And as things stand, I cannot provide a citation example without generating an error. By the way, conference proceedings may also be published on DVD video. 65.88.88.57 (talk) 21:27, 5 April 2022 (UTC)

{{cite news}} is another template that could use these parameters. Both television/radio and web video/radio news shows may offer transcripts. 4.30.91.142 (talk) 20:23, 6 April 2022 (UTC)

Protected edit request on 7 April 2022

Remove "unique" and add: They have also been found among a Northern Jê speaking people, the Mẽbêngôkre in Central Brazil

I suspect this is in the wrong place. Where might we "Remove 'unique' and ..."? It would be best if you could provide a link like Kinship terminology. Thank you, SchreiberBike | ⌨  19:42, 7 April 2022 (UTC)

 Not done: this is the talk page for discussing improvements to the page Help:Citation Style 1. Please make your request at the talk page for the article concerned. Izno (talk) 20:40, 7 April 2022 (UTC)

For the record, the above request was nominally about {{Cite book}}, but it was misplaced, as indicated by Izno. – Jonesey95 (talk) 21:36, 7 April 2022 (UTC)

References

Category:CS1 maint: ref=harv

Before, we had this category to track ref=harv usage. Apparently now it's been merged to Category:CS1 errors: invalid parameter value

• https://en.wikipedia.org/w/index.php?title=Eulogy_of_King_Prasat_Thong&diff=prev&oldid=1081637277
• https://en.wikipedia.org/w/index.php?title=Daniel_Trotter&diff=prev&oldid=1081637337

However, the prior version of these diffs weren't caught by that category. Is suspect it's because |ref=harv was case sensitive, but really it should be case insensitive. Headbomb {t · c · p · b} 17:41, 8 April 2022 (UTC)

It is probably a good idea to do a NOT search, such as for if exist |ref= then values that do not start with {{harvid| or {{sfnref| etc. And fire up the RfC for the related tracking cat. 74.64.30.159 (talk) 19:48, 8 April 2022 (UTC)

Special-issue title of an ongoing journal

Sometimes journals release a "special issue" on a certain theme, either one issue on their regular release-cycle or an off-cycle release. It sometimes invites guest-editors to participate, invites specific authors to contribute to that special issue, or else selects among the regular submissions at the time to include (rather than for example in order of submission or editorial acceptance). These special issues have a subtitle. Should this subtitle be included in the citation? If so, where does it go in {{cite journal}} (|series=, |journal=, somewhere else)? Does it matter if a journal very often has these sorts of issues (a subtitle of nearly every issue) or only on a rare occasion?

As an example, doi:10.1016/j.chroma.2004.08.072 is in the special theme issue "Food Science" of Journal of Chromatography A. DMacks (talk) 02:37, 11 April 2022 (UTC)

The theme of special issues is bibliographically irrelevant, so no it should not be included. Headbomb {t · c · p · b} 02:47, 11 April 2022 (UTC)

Makes sense to me. Thanks! DMacks (talk) 05:54, 11 April 2022 (UTC)

If you must include it, for an individual article, it might be possible to use the |department= parameter for it. That has the advantage of not being passed on to the machine-readable side of the metadata, and therefore not messing it up. But I tend to agree with Headbomb in not mentioning it at all, for most citations. (If it's in your own cv, then maybe it's relevant information, but not for most other uses of citations, and we don't host cvs here.) If you're including the whole issue among the selected publications of an academic, then you could just use the |title= parameter. —David Eppstein (talk) 06:47, 11 April 2022 (UTC)

I would not call the special issue a "subtitle". It is an issue name. If you are so inclined, you may quote it with |quote=Special issue name. 172.254.222.178 (talk) 11:36, 11 April 2022 (UTC)