Help talk:Citation Style 1/Archive 90

Archive 85

←

Archive 88

Archive 89

Archive 90

Archive 91

Archive 92

→

Archive 94

Category:CS1 maint: numeric names: authors list

I'd like to bump this series up to an error. The non-authors categories are routinely at 0 and the authors category is in the realm of 1k currently but also being poked at (by a couple people).

Are there any concerns with that? Izno (talk) 22:31, 25 August 2023 (UTC)

@Izno: No concerns, but are there patterns that a bot could fix before bumping to an error? GoingBatty (talk) 02:22, 26 August 2023 (UTC)

There's a couple patterns in this group, but I don't think any are particularly suitable to a bot:

1. Users using dashes instead of |author-mask= or |display-authors=.
2. Citoid doing a bad job (usually because it has a bad Zotero translator) getting info from news websites and dumping blobs into the author group that shouldn't be there, usually dates of publication or ID numbers.
3. Citoid getting bad data from Worldcat/OCLC, which likes to add the years of birth/death to author information and Citoid doesn't know how to plop those in (it shouldn't).

The second case can have bugs filed upstream on Phab which usually make their way over to Zotero's collection.

The third case might be something to file a bug on Phab for. These are probably the easiest for a bot to ID, because they most often have a |url= that duplicates the |oclc=. I think I might prefer a human to clean these up anyway because they sometimes have the Category:CS1 maint: others issue as well (though that seems to have improved given the size of that category has not increased significantly in a while, so maybe a bot running over that one to get citation data again from Citoid would be a good idea -- Citation bot might already have the right stuff to do something there).

For the first group, a bot won't have the context to know which is the correct fix. Izno (talk) 02:35, 26 August 2023 (UTC)

Ah, the fourth case is {{cite Twitter}} and similar where the only identifiable author information is/includes a number. The correct fix for which is the (()) syntax (or building that in to the template). Trappist was working on that at one point but seems to have dropped it? Izno (talk) 02:42, 26 August 2023 (UTC)

That would be this discussion. I offered a possible solution. I do not get the sense that other editors cared enough to use that possible solution as a remedy for the problem – the conversation died from lack of participation (indifference) as so many do.

—Trappist the monk (talk) 14:09, 26 August 2023 (UTC)

I would love to see this elevated to error status as previously disclosed. Mobile users are not able to see error maintenance messages. This will allow me to help clean out the category, which I've touched briefly before but had to peruse the full source to find the problem citations. Folly Mox (talk) 12:48, 26 August 2023 (UTC) corrected 14:45, 26 August 2023 (UTC)

If Mobile users are not able to see error messages changing maintenance messaging to error messaging will not benefit them. Are you sure that mobile users cannot see error messages?

—Trappist the monk (talk) 14:09, 26 August 2023 (UTC)

Sorry I misspoke. I meant mobile users are unable to see maintenance messages. My space is extremely distracting today. Folly Mox (talk) 14:44, 26 August 2023 (UTC)

Just for clarity, and as a mobile users, yes they can. The mobile view won't show them, but that's the least of its problems. -- LCU ActivelyDisinterested ∆transmissions∆ °co-ords° 14:52, 26 August 2023 (UTC)

If we do this, all of the numeric names messaging and categories would shift to error messages:

Category:CS1 maint: numeric names: authors list (58,530)

Category:CS1 maint: numeric names: contributors list (0)

Category:CS1 maint: numeric names: editors list (9)

Category:CS1 maint: numeric names: interviewers list (0)

Category:CS1 maint: numeric names: translators list (0)

I support that.

—Trappist the monk (talk) 14:09, 26 August 2023 (UTC)

Made the minimal adjustment in the sandbox, feel free to adjust emitted error text or category name.

Cite book comparison

Wikitext	{{cite book|author=1234|title=Title}}
Live	1234. Title. {{cite book}}: |author= has numeric name (help)
Sandbox	1234. Title. {{cite book}}: |author= has numeric name (help)

Cite book comparison

Wikitext	{{cite book|editor=1234|title=Title}}
Live	1234 (ed.). Title. {{cite book}}: |editor= has numeric name (help)
Sandbox	1234 (ed.). Title. {{cite book}}: |editor= has numeric name (help)

Cite book comparison

Wikitext	{{cite book|author2=1234|author3=5678|author=One|title=Title}}
Live	One; 1234; 5678. Title. {{cite book}}: |author2= has numeric name (help)
Sandbox	One; 1234; 5678. Title. {{cite book}}: |author2= has numeric name (help)

It would probably be nice if the number (editor number 5) could be in the error instead. I think there was some discussion of similar elsewhere for another error at some point?

Do we think we'll need a category for each kind of author going forward, with so few as we have now? Izno (talk) 20:22, 26 August 2023 (UTC)

History: Help talk:Citation Style 1/Archive 64 § Check author names are not numeric for Cite web

I suspect that I created separate name-list categories because we have separate name-list maintenance categories for multiple-names-in-a-name-parameter.

I tweaked your change to specify a single category: Category:CS1 errors: numeric name. Also tweaked the error messaging so that it is roughly the same as the generic name message (one message per template that names the offending parameter). Is that what you meant by [it] would probably be nice if the number (editor number 5) could be in the error instead?

—Trappist the monk (talk) 22:02, 26 August 2023 (UTC)

Since most of these errors are going to be generated from Citoid putting dates into author fields, I wonder if a better message might be numeric data in |author=. Folly Mox (talk) 22:17, 26 August 2023 (UTC)

The issue is not some numbers in the field (which is not presently detected), it's all non-numeric-characters in the field. Izno (talk) 22:20, 26 August 2023 (UTC)

Oh I was under the impression that any numeric data would add the article to the appropriate maintenance → error category. My mistake. Folly Mox (talk) 22:39, 26 August 2023 (UTC)

I would prefer something closer to the previous suggested text displayed, since it's not numerics that are detected but non-alphabetic characters (which include punctuation and other symbols). The category name is pretty irrelevant to me otherwise.

But yes, the error messaging naming the offending parameter is what I had in mind, as you've now added. Izno (talk) 22:23, 26 August 2023 (UTC)

I got to wondering about numbers-in-names. Here are a some searches (in these the search expects alphabetic characters to precede numbers):

|author<n>= and |last<n>=: ~6700 times out

|contributor<n>=, |contributor-last<n>=: no results timed out

|editor<n>=, |editor-last<n>=: ~240 times out

|interviewer<n>=, |interviewer-last<n>=: ~10 times out

|translator<n>=, |translator-last<n>=: ~300 times out

Here is another with numbers preceding alphabetic characters:

|author<n>= and |last<n>=: ~1100 times out

There are false positives in these searches because cs1|2 templates are not the only ones to use |author=, |editor=, |last=, etc.

Still, it might be worthwhile to retain the CS1 maint: numeric names <name> list categories. Because we are already looking at names in the name-holding parameters, adding a couple of test isn't too much extra work.

—Trappist the monk (talk) 17:25, 28 August 2023 (UTC)

So I hacked the sandbox. Here are two templates from the author search:

Cite book comparison

Wikitext	{{cite book|edition=6th|first=Frank P. 1 David P. 2 Theodore L. 3 Adrienne S. 4|isbn=9780471457282|language=English|last=Incropera 1 Dewitt 2 Bergman 3 Lavigne 4|location=Hoboken, NJ|oclc=62532755|pages=941–950|publisher=John Wiley and Sons, Inc.|title=Fundamentals of heat and mass transfer.|url=https://www.worldcat.org/oclc/62532755|year=2007}}
Live	Incropera 1 Dewitt 2 Bergman 3 Lavigne 4, Frank P. 1 David P. 2 Theodore L. 3 Adrienne S. 4 (2007). Fundamentals of heat and mass transfer (6th ed.). Hoboken, NJ: John Wiley and Sons, Inc. pp. 941–950. ISBN 9780471457282. OCLC 62532755.{{cite book}}: CS1 maint: numeric names: authors list (link)
Sandbox	Incropera 1 Dewitt 2 Bergman 3 Lavigne 4, Frank P. 1 David P. 2 Theodore L. 3 Adrienne S. 4 (2007). Fundamentals of heat and mass transfer (6th ed.). Hoboken, NJ: John Wiley and Sons, Inc. pp. 941–950. ISBN 9780471457282. OCLC 62532755.{{cite book}}: CS1 maint: numeric names: authors list (link)

Cite web comparison

Wikitext	{{cite web|access-date=2021-10-05|first1=Carter|first2=KSL com | Updated-|first3=2021 at 11:04 a m | Posted-|first4=2021 at 6:07|language=en|last1=Williams|last2=July 2|last3=July 1|last4=P.m|title=Rare wolverine sighting in Layton may be same animal spotted in May|url=https://www.ksl.com/article/50197410/rare-wolverine-sighting-in-layton-may-be-same-animal-spotted-in-may|website=www.ksl.com}}
Live	Williams, Carter; July 2, KSL com | Updated-; July 1, 2021 at 11:04 a m | Posted-; P.m, 2021 at 6:07. "Rare wolverine sighting in Layton may be same animal spotted in May". www.ksl.com. Retrieved 2021-10-05.{{cite web}}: CS1 maint: multiple names: authors list (link) CS1 maint: numeric names: authors list (link)
Sandbox	Williams, Carter; July 2, KSL com | Updated-; July 1, 2021 at 11:04 a m | Posted-; P.m, 2021 at 6:07. "Rare wolverine sighting in Layton may be same animal spotted in May". www.ksl.com. Retrieved 2021-10-05.{{cite web}}: CS1 maint: multiple names: authors list (link) CS1 maint: numeric names: authors list (link)

Keep? Discard?

—Trappist the monk (talk) 21:52, 28 August 2023 (UTC)

I'd say keep for now. Izno (talk) 22:30, 30 August 2023 (UTC)

Lua script error fix

I discovered a flaw in the coding for |display-translators= when that parameter's value came from a {{cs1 config}} template. The flaw was the omission of a variable in a function call. Fixed in sandbox and live modules.

—Trappist the monk (talk) 20:00, 30 August 2023 (UTC)

And sort of related: fixed a bug that caused the module to emit an error message that isn't intended to be emitted. The error message 'Invalid |cs1 config=3 ' occurred because the module did not remove the extraneous space characters between the parameter's assigned value and the closing }}: {{cs1 config |display-authors=3 }}. This was only an issue with |display-<name list>= parameters. |cs1 config= is an unsupported parameter name used as a flag to prevent the module from emitting an Invalid |display-authors=<n> (and the like) when <n> is equal to or greater than the number of names in the author name list when a global |display-<name list>= is controlling the name list display.

Fixed in sandbox and live modules.

—Trappist the monk (talk) 22:22, 30 August 2023 (UTC)

improve global configuration handling

I have changed how the module sandbox handles global |display-authors=<n> when a cs1|2 template has |display-authors=etal. This change also applies to all of the other name list display parameters

The live module emits a maintenance message whenever a template has |display-authors=<anything>. The sandbox is more discriminating.

When a template has |display-authors=etal, there are other authors who are not named in the template so Module:Citation/CS1 should always add the 'et al.' static text. When the template lists more names than are specified by the global |display-authors=<n> (four named authors but global |display-authors=2 for example), the live template correctly renders two names with the 'et al.' static text and emits the overridden setting maintenance message. However, when the number of authors listed in the template is the same or fewer than the number specified by the global |display-authors=, the module correctly displays the author names but incorrectly omits the 'et al.' static text which makes it appear that there are no more authors associated with the cited work.

The sandbox remedies this. When the number of authors listed in a template that has |display-authors=etal is less-than-or-equal to the number of authors specified in the global |display-authors=, the module applies the 'et al.' static text. Examples comparing the live v. sandbox module renderings for all name lists are shown in this version of my sandbox.

—Trappist the monk (talk) 16:49, 31 August 2023 (UTC)

doi problem

I got this error message:

{{cite book}}: Check |doi= value (help)

after I added this doi to a cite book template in the article Metre:

doi=/10.6028/NBS.SP.447

If I click the doi in the rendered bibliography it downloads the pdf just as it should. The publisher is the National Institute of Standards and Technology. Jc3s5h (talk) 13:39, 1 September 2023 (UTC)

DOIs do not begin with a solidus. The error message is correct.

—Trappist the monk (talk) 13:43, 1 September 2023 (UTC)

Thanks, that fixed it. Jc3s5h (talk) 13:46, 1 September 2023 (UTC)

"Latin" Language Name Issue When Porting to other wiki

I have ported over the citation and language templates for use on another MediaWiki wiki. It all seems to be working well with the strange (and very specific) exception of the ISO 639-1 name that the CS1 citation template pulls for the "la" language code (Latin) returns "Latina" instead of "Latin". This causes the Category:CS1 Latin-language sources (la) that is generated on the article page contains an of the citations tagged with the "la" language code to be incorrect (it generates "Category:CS1 Latina-language sources (la)"). The Template:Citation Style documentation/language/doc on my wiki returns everything fine as well with the singular exception of "Latin" which also returns "Latina". Does anyone know how or where to fix this? I have re-ported over all the templates and modules that make up the various citation components, as well as all the ISO templates and modules, but I can't find where or how it is converting "Latin" to "Latina". – Lestatdelc (talk) 22:38, 13 August 2023 (UTC)

Which wiki? If, at en.wiki, you write {{#language:la|xx}} (where xx is the 2-or-3-digit language tag for the other wiki's language), MediaWiki should return that language's name for Latin. You can also try, at the other wiki, {{#language:la}}. If either test returns 'Latina' then the problem is at MediaWiki and perhaps further upstream at Unicode CLDR.

Certainly fixable locally though it would be best to make the fix at MediaWiki.

—Trappist the monk (talk) 22:57, 13 August 2023 (UTC)

Sorting drafts to back of categories

I think in the general users working on errors and maintenance categories tend to avoid draft space as they're obviously not in mainspace (and perhaps for some, they don't want to reset the 6 month clock). In another discussion, someone identified that some templates categorize their drafts to the Δ key (still with ABC order), which places it (on en.wp at least) at the back of the category list. I'd like to suggest that CS1 do this also. Izno (talk) 22:36, 25 August 2023 (UTC)

@Izno: Support for categories with more than 200 pages. Don't know if it's worth it for categories that are well maintained. GoingBatty (talk) 02:21, 26 August 2023 (UTC)

I think it's much less worth to make the code depend on the size of the category. :) Izno (talk) 02:25, 26 August 2023 (UTC)

@Izno: Sorry - I wasn't suggesting implementing code that looks at the number of pages in the category. I was suggesting not implementing any new code on categories that currently less than 200 pages. GoingBatty (talk) 15:52, 29 August 2023 (UTC)

So, Lua can't read category sizes (last I checked). All we could have done would have been to make a lookup table, or add a bunch of parameters to the relevant section of the code that support a bunch of carveouts. Or we can just implement it for everything. Everything makes a lot more sense. :) Izno (talk) 16:22, 29 August 2023 (UTC)

This would have been extremely useful when I was clearing down cite errors back in 2021. I would have thought the same is true of all other error or maintenance categories. It would probably be good to not just sort drafts but also the other name spaces, Template / Wikipedia / User / etc. Also I'd still be interested to see the change at testwiki that was mentioned in the now archived VPT thread. -- LCU ActivelyDisinterested ∆transmissions∆ °co-ords° 10:06, 26 August 2023 (UTC)

According to Wikipedia:Categorization § Sort keys, Δ is reserved for Wikipedia:Template documentation 'by convention'. Seems odd to me for en.wiki to use characters from another wiki language (el.wiki) as sort keys. Because cs1|2 is supported at el.wiki, I don't think that we should use Greek letters as sort keys. Are there symbols that we could use instead? I thought we might use the sun and planet symbols (☉ Sun, ☿ Mercury, ♀ Venus, 🜨 Earth, ♂ Mars, ♃ Jupiter, ♄ Saturn, ⛢ or ♅ Uranus, ♆ Neptune, ♇ Pluto) but when I tried ♇ at {{CS1 config}} as an experiment, the template was categorized at the top of the list at Category:Templates with no visible output. We don't need many. I think that draft, template, and Wikipedia are the most common namespaces that use cs1|2 templates. All other supported namespaces could be grouped with a common sort key.

—Trappist the monk (talk) 14:50, 26 August 2023 (UTC)

From other tracking categories I assume symbols are sorted before numbers and letters, with only the special characters mentioned by Sort Keys sorted afterwards. See Category:Pages with incorrect ref formatting for example. If the special characters aren't usable due to elwiki crossover would a separate tracking categories for articles and non-articles work instead? -- LCU ActivelyDisinterested ∆transmissions∆ °co-ords° 15:04, 26 August 2023 (UTC)

I don't think I've seen template documentation sorted to Delta, ever. Almost always it has only one category (Category:Template documentation) in which it needs no sortkey. I'd actually be curious to see examples of template documentation which even have another category besides that one.

(Δ is of course inspired by Draft. As another example of using Greek letters, Τ is often used for templates in categories they shouldn't be in anyway.) Izno (talk) 15:52, 26 August 2023 (UTC)

I have hacked the module so that non-mainspace pages are sorted at the end. I used the Greek letters:

Δ (delta – draft)

τ (tau – template)

ω (omega – wikipedia)

ο (omicron – other)

It is hard to test this change so for the time being I have disabled the namespace categorization limit in the sandbox and tweaked the actual categorization link to be [[:Category:...]] instead of [[Category:...]]. When a sandbox template is rendered, the sort key is rendered as a wikilink at the end of the rendering (after the error/maintenance messages):

{{cite book/new |title=Title |date=27 Augst 2023 |authors=EB Green}}

Title. 27 Augst 2023. {{cite book}}: Check date values in: |date= (help); Unknown parameter |authors= ignored (help)

'"`UNIQ--templatestyles-00000046-QINU`"'<cite class="citation book cs1">''Title''. 27 Augst 2023.</cite><span title="ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Abook&rft.genre=book&rft.btitle=Title&rfr_id=info%3Asid%2Fen.wikipedia.org%3AHelp+talk%3ACitation+Style+1%2FArchive+90" class="Z3988"></span> <span class="cs1-visible-error citation-comment"><code class="cs1-code">{{[[Template:cite book|cite book]]}}</code>: </span><span class="cs1-visible-error citation-comment">Check date values in: <code class="cs1-code">&#124;date=</code> ([[Help:CS1 errors#bad_date|help]])</span>; <span class="cs1-visible-error citation-comment">Unknown parameter <code class="cs1-code">&#124;authors=</code> ignored ([[Help:CS1 errors#parameter_ignored|help]])</span>

You can copy that example into a page at other namespaces, preview, and observe the result. We won't know if it really works until we make the change live.

—Trappist the monk (talk) 01:10, 28 August 2023 (UTC)

Why are there two wikilinked 'o' (i.e. 'oo') after the /new citations? Most maintenance/errors categories seem to emit those now. I'm guessing those might be omicrons, rather latin o's? Is this intended, or just a temporary thing? Headbomb {t · c · p · b} 16:20, 2 September 2023 (UTC)

On this page because it's in the help namespace, the character is an omicron and it is displayed with all error and maintenance categories rendered by the sandbox. I did write: It is hard to test this change so for the time being I have disabled the namespace categorization limit in the sandbox where for the time being can be read as 'temporary'.

—Trappist the monk (talk) 18:22, 2 September 2023 (UTC)

Archived talk page included in CS1 language tracking category

Heya, folks. I regularly check a CS1 tracking category (this one, if that matters) to look for pages with wrong language codes. Recently, I found out that the page Help talk:Citation Style 1/Archive 6 was also included in the category (and hundreds of others) because it uses the template {{Cite book/new}} with the language parameter set. I presume this happens because of a change made to Module:Citation/CS1/sandbox at some point, but I'm not competent enough to find or fix it, so I'd appreciate some help here. ArcticSeeress (talk) 22:21, 1 September 2023 (UTC)

The cause of that is that I have disabled the categorization limits in Module:Citation/CS1/sandbox for testing as described at Help talk:Citation Style 1 § Sorting drafts to back of categories. The proof of that is shown in these two examples:

{{cite book |title=Northern Sami |language=se}} – no category link in this rendering:

'"`UNIQ--templatestyles-0000004B-QINU`"'<cite class="citation book cs1 cs1-prop-foreign-lang-source">''Northern Sami'' (in Northern Sami).</cite><span title="ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Abook&rft.genre=book&rft.btitle=Northern+Sami&rfr_id=info%3Asid%2Fen.wikipedia.org%3AHelp+talk%3ACitation+Style+1%2FArchive+90" class="Z3988"></span>

{{cite book/new |title=Northern Sami |language=se}} – this rendering has a category link:

'"`UNIQ--templatestyles-0000004E-QINU`"'<cite class="citation book cs1 cs1-prop-foreign-lang-source">''Northern Sami'' (in Northern Sami).</cite><span title="ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Abook&rft.genre=book&rft.btitle=Northern+Sami&rfr_id=info%3Asid%2Fen.wikipedia.org%3AHelp+talk%3ACitation+Style+1%2FArchive+90" class="Z3988"></span>

The language categories are properties categories. Only maintenance and error categories use the Greek letter sort keys so perhaps I can suppress property categories without disturbing the error and maint cat test.

—Trappist the monk (talk) 22:53, 1 September 2023 (UTC)

Property category talk page suppression restored in the sandbox; error and maint cat talk page suppression remains disabled.

—Trappist the monk (talk) 23:46, 1 September 2023 (UTC)

How to handle website unavailable in some countries?

For a |url= where the website says thing like "this content is unavailable in your country", how should that be handled by our cite templates? None of the current combinations of |url-status= and |url-access= values seem to correctly work for this situation. My workaround is to mark the url as dead with a note. Perhaps a new value for |url-access= called "geographical" or something could be introduced. Or maybe I'm overlooking the solution. Suggestions? Jason Quinn (talk) 06:06, 3 September 2023 (UTC)

If it's accessible to someone then it should not be marked dead. As I'm in the UK I often have US sites unavailable to me due to GDPR. If I really want to see it, I'll switch my VPN on and pretend I'm in the US.

There are too many variables around the world for citations to catch every possibility, so we shouldn't worry about the geographical ones. Just the global ones e.g. pay walled sites that affect everyone. Nthep (talk) 09:19, 3 September 2023 (UTC)

|url-access=limited seems to have pretty broad scope. Could that work for this situation? Agree that the link should not be marked as dead. Folly Mox (talk) 13:06, 3 September 2023 (UTC)

It is not appropriate to mark these links as anything. (And this question really needs to be made clear in the documentation since we keep getting questions on it.) Izno (talk) 03:12, 4 September 2023 (UTC)

Publications with multiple months as their dates

Hello fellow Wikipedians - Can anyone comment on the proper way to cite publications that are dated as being two or more months? For instance, I would like to use the following as a citation:

https://www.fedbar.org/wp-content/uploads/2013/01/bookrev-janfeb13-pdf-1.pdf

which is from the January/February 2013 issue of a publication called The Federal Lawyer.

However, I can't figure out how to do this without generating an error. Any insights from anyone?

Thanks KConWiki (talk) 21:20, 4 September 2023 (UTC)

Use the format indicated in MOS:NUM, which in your case would be January–February 2013. The character between the months is an n-dash. Don't use the html entity &ndash; because that won't work with the citation templates. Jc3s5h (talk) 21:33, 4 September 2023 (UTC)

OK great, done - Thanks for your guidance on that. KConWiki (talk) 21:37, 4 September 2023 (UTC)

Replacing “curly” quote marks with "typewriter" quote marks

Lines 478–479 of Module:Citation/CS1 read:

label = mw.ustring.gsub (label, '[“”]', '\"');
label = mw.ustring.gsub (label, '[‘’]', '\'');

and are intended to:

-- replace “” (U+201C & U+201D) with " (typewriter double quote mark)
-- replace ‘’ (U+2018 & U+2019) with ' (typewriter single quote mark)

in displaying chapter titles and the like, as far as I can tell.

Could someone explain why this is done, please? 0DF (talk) 00:50, 8 September 2023 (UTC)

To simplify the subsequent kerning patterns and because MOS:CURLY.

—Trappist the monk (talk) 00:56, 8 September 2023 (UTC)

@Trappist the monk: I was not aware of MOS:CURLY. Thanks for the explanation. 0DF (talk) 03:16, 8 September 2023 (UTC)

Citing translations

When citing a translation of a foreign work, should one supply |title=original and |trans-title=translation or only |title=translation? -- Shmuel (Seymour J.) Metz Username:Chatul (talk) 20:32, 6 September 2023 (UTC)

WP:SAYWHEREYOUGOTIT if your referencing the translation use |title=translation -- LCU ActivelyDisinterested ∆transmissions∆ °co-ords° 20:42, 6 September 2023 (UTC)

It seems to me both the title of the original and the title of the translation should be provided. This allows a reader to read the translation if the reader can find it. If not, the reader can, language skills permitting, read the original. Jc3s5h (talk) 20:46, 6 September 2023 (UTC)

I only use |trans-title= if I'm referencing the foreign original and want to give the reader some indication of what the title means.

I do like to provide the title of the original if I'm referencing a translated work, but I don't think any of the built in parameters is necessarily fit for this purpose. I've used |type= to hold this information in the past, but suspected it might be parameter misuse and started just adding "Translation of Non-English Title." after the closing curly brackets but before the closing ref tag. Folly Mox (talk) 21:08, 6 September 2023 (UTC)

Yeah that's not what |type= is for, adding it after the cite is a better idea. -- LCU ActivelyDisinterested ∆transmissions∆ °co-ords° 21:11, 6 September 2023 (UTC)

While we're on the subject, when a translation is an annotated, critical translation instead of just the regular type, is it better to credit the translator in the |editor= parameter? or leave them in |translator=? Folly Mox (talk) 21:30, 6 September 2023 (UTC)

Just as one person can appear as both author and editor in a compilation that includes some chapters authored by the editor, this case seems analogous imho, as that individual is both translator, and editor.

As far as Chatul's original question, the answer depends on whether you consulted the original foreign language version, or the English translation. As ActivelyDisinterested mentioned, you always say where you found it, and if that source is not in English, it's helpful to readers to add the |trans-title= parameter to give them the English version of the title. However, if you read a book in English translation, such as Beauvoir's The Second Sex, then there's no need to provide the original French title, mostly because it does not help WP:Verifiability, which is the whole reason we write citations in the first place, and it doesn't help English-speaking readers of Wikipedia, either. If you do wish to provide the original title, note that it won't fit either in parameter |title= (because param |title= is already taken by "The Second Sex") nor does it fit in |trans-title=, because that's *exclusively* for English titles of foreign works. So, where can you put it? The citation templates do not have a dedicated location for the original title of a work in a foreign language that you consulted in English translation, however, you could include it in |orig-date=, which is conceived to contain other information about an edition you did not consult. So, following the Beauvoir example, you could add: |orig-date=1st pub. [[Gallimard]]:1949 ''Le deuxième sexe''. Hope this helps, Mathglot (talk) 06:25, 7 September 2023 (UTC)

I follow the metadata the work provides. If all it says is "translator", into |others= it goes. If all it says is "editor", into |editor= it goes. In the case where the work lists them as both, I tend toward either placing it in both, or if I'm feeling lazy, solely in |editor=. Izno (talk) 20:58, 8 September 2023 (UTC)

East Asian name order

Most of my content work is in Chinese history, so I'm frequently citing works by Chinese authors. As is well known, in China the family name precedes the personal name, like Qiu Xigui.

When using the |last= and |first= parameters as usual, this causes names in citations to display like "Qiu, Xigui". While this isn't exactly wrong, it does look wrong, at least to me and many other people familiar with East Asian name order. Some English language scholars – even in the topic area – do format their bibliographical entries like this, but not as many as those who format names without the extraneous comma; some publications will ALLCAPS the family name for clarity, but I think this is recommended against here.

My usual solution to this is to put the full author name in the |author= parameter, but then I have to do extra work to get shortened footnotes to work, like |ref={{sfnref|Qiu|1999}}. Also I suspect this is suboptimal for COinS metadata.

I was thinking a new parameter like |name-separator=none could be a better solution, but I'm not sure how much work it would take to get it to apply dynamically to whichever contributor field it is supposed to. It would certainly be easy to add to existing citations without fiddling with |ref= and might benefit data reusers.

I was also wondering if this could be handled with |author1-mask=, and what the syntax for that would look like. Just the full author name?

What's the recommended practice for this, apart from "don't let it bother you"? Folly Mox (talk) 20:59, 6 September 2023 (UTC)

Publications specializing in Asian topics will typically use Qiu Xigui, etc in their bibliographies, but publications for a general audience often use a consistent marking of surnames and given names: "Qiu, Xigui" and "Smith, John". It could be argued that Wikipedia should be more like the latter category. Note also that bibliographies are already unusual: "Smith, John" isn't what you'd write in a sentence either.

However, I do find the parameter names |last= and |first= confusing, especially when working with a mix of Asian and Western author names. I find it less confusing to use the aliases |surname= and |given=. No change in the formatting, but at least the semantics is clear. Kanguole 22:01, 6 September 2023 (UTC)

(edit conflict)

Asian names in cs1|2 templates are problematic. In addition to the issue you describe, it is my understanding that when citing a person with an Asian name, the name should be written using the logograms because, apparently, it is not possible to accurately convert a transliteration, Qiu Xigui for example, to its logographic form(s): 裘锡圭 (zh-Hans) or 裘錫圭 (zh-Hant). Very often I see Asian names in cs1|2 templates written in |author= to 1) avoid the comma separator issue and 2) to include a logographic form: |author=Qiu Xigui (裘錫圭) (flipped order also).

I don't think that |name-separator=none is a solution because such a parameter would apply to all names in the list so a list of mixed Asian and western names would result in malformed western names. Such mixed lists are quite common, especially in STEM topics.

Format for using |author-mask= could be something like this:

{{cite book |title=Title |surname=Qiu |given=Xigui |author-mask=Qiu Xigui (裘錫圭)}}

Qiu Xigui (裘錫圭). Title.

'"`UNIQ--templatestyles-00000053-QINU`"'<cite id="CITEREFQiu" class="citation book cs1">Qiu Xigui (裘錫圭). ''Title''.</cite><span title="ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Abook&rft.genre=book&rft.btitle=Title&rft.aulast=Qiu&rft.aufirst=Xigui&rfr_id=info%3Asid%2Fen.wikipedia.org%3AHelp+talk%3ACitation+Style+1%2FArchive+90" class="Z3988"></span>

I suppose that it might be possible to create |asian-surnamen=, |asian-givenn=, and |asian-authorn= parameters that would be rendered without the comma. I haven't given any thought to how this might be implemented. I suppose that in theory, when all three are present, |asian-authorn= would hold the author name in logogram form so cs1|2 could build an internal |author-mask= as shown above.

—Trappist the monk (talk) 22:17, 6 September 2023 (UTC)

that allows one to mix and match asian and non-asian in the same person. first=Frank asian-last=Wong. That is a recipie for confusion. Perhaps is-asian-name1=yes/no AManWithNoPlan (talk) 22:26, 6 September 2023 (UTC)

Oh yeah, I didn't mention below but I don't think a separate group of parameters for cultures where the family name is presented first is the solution here. Seems messy, and in addition to the case above we have authors of Asian descent who live and work in the West and have chosen to present their name in the Western order, so attaching an ethnic label to their name or not isn't something I'd want to get into. Folly Mox (talk) 22:34, 6 September 2023 (UTC)

Yeah my thought for |name-separator= was to have it be a group of parameters (|editor2-name-separator= etc.) to avoid the issue you mention. Apologies I failed to clarify that in the original post.

It is true that it's usually not possible to reconstruct the Chinese original from a pinyin transliteration, which is a lossy conversion. For this specific case we have an article on the individual so it's not necessary per MOS, but often it is important to include the actual words alongside transliterations, which I've also seen as |last=Qiu 裘|first=Xigui 錫圭. It sounds like the |-mask= series of parameters is the easiest way to implement what I'm looking for without messing with the underlying metadata. Folly Mox (talk) 22:31, 6 September 2023 (UTC)

I think the current author-mask solution/provision is appropriate if painful for people who really wish to style these a certain way.

Incidentally and personally, the only reason I put these in |author= is because I never know which name is given and which is family, with the large number of Americanized East-Asian names being in the same order as other American names typically are. Izno (talk) 20:55, 8 September 2023 (UTC)

unicode v15.1 emoji

in Module:Citation/CS1/Configuration/sandbox, emoji_t has been updated to unicode v15.1 Newly added unicode code points are:

• U+2194 ↔ LEFT RIGHT ARROW
• U+2195 ↕ UP DOWN ARROW
• U+27A1 ➡ BLACK RIGHTWARDS ARROW
• U+1F4A5 💥 COLLISION SYMBOL
• U+1F7E9 🟩 LARGE GREEN SQUARE
• U+1F7EB 🟫 LARGE BROWN SQUARE
• U+1F9D2 🧒 CHILD

—Trappist the monk (talk) 18:12, 12 September 2023 (UTC)

US state format/guidelines in location parameter

Are there guidelines regarding consistency of US state names used in |location= parameter? In Philippines, it previously used US state abbreviations for all its sources (example: |location=Berkeley, CA), but an editor several months ago changed most of them to avoid abbreviating the state names (|location=Berkeley, Calif.). What is the recommended format? Should I restore all state abbreviations or should I use their full names (|location=Berkeley, California)? Sanglahi86 (talk) 02:12, 15 September 2023 (UTC)

See MOS:POSTABBREV. Nikkimaria (talk) 02:22, 15 September 2023 (UTC)

Thank you for the information. Sanglahi86 (talk) 02:28, 15 September 2023 (UTC)

Irish language

"Comhchoiste na Gaeilge, na Gaeltachta agus Phobal Labhartha na Gaeilge debate - Wednesday, 15 Jun 2022" [Joint Committee on The Irish Language, The Gaeltachts and the Use of Irish in Public]. Oireachtas.ie (in Irish). June 15, 2022.

"|language=ga" resolves as "in Ga". is that a bug, or an unwillingness to decide on the "gaelic"/"Irish language" debate? -Bogger (talk) 16:02, 13 September 2023 (UTC)

cs1|2 cannot distinguish between ga/Ga/GA/gA (the Ga language) and ga/Ga/GA/gA (the ISO 639-1 tag for Irish language) so defaults to language name. For Irish-language sources use |language=Irish; |language=Gaelic is accepted but is not recognized:

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

{{cite book |title=Title |language=Gaelic}} → Title (in Gaelic).{{cite book}}: CS1 maint: unrecognized language (link)

—Trappist the monk (talk) 16:24, 13 September 2023 (UTC)

There are hundreds of articles to be fixed.  Working... GoingBatty (talk) 18:11, 13 September 2023 (UTC)

@Trappist the monk: Now that I've updated over 100 articles, I'm wondering if there are any articles with citations with |language=ga that are supposed to represent the Ga language? The Ga language article doesn't use it. GoingBatty (talk) 02:24, 15 September 2023 (UTC)

@Trappist the monk: Found Yacub Addy which uses |language=gaa:

{{cite AV media |title=title |language=gaa}} → title (in Ga).

I've found a few articles where "ga" needed to be changed to "Galician", but none where "ga" meant the Ga language. GoingBatty (talk) 04:30, 15 September 2023 (UTC)

The language tag for Galician is gl. Not surprised that there aren't many Ga-language sources.

If you are interested, there is one other language-name/language-tag that can be confused:

ho is the language tag for Hiri Motu but that can be confused with the Ho language name (tag: hoc)

—Trappist the monk (talk) 14:39, 15 September 2023 (UTC)

Because our |language= documentation prefers language tags over language names, it occurs to me that Module:Citation/CS1 should presume that the value assigned to |language= is a language tag and not a two-character language name. So, I've switched the order of evaluation so that the module first assumes that |language= holds a tag and only when that fails, assume that |language= holds a language name:

Cite book comparison

Wikitext	{{cite book|language=ga|title=Title}}
Live	Title (in Irish).
Sandbox	Title (in Irish).

Cite book comparison

Wikitext	{{cite book|language=ho|title=Title}}
Live	Title (in Hiri Motu).
Sandbox	Title (in Hiri Motu).

—Trappist the monk (talk) 17:29, 15 September 2023 (UTC)

How would you specify Ga as the language of the source if it works that way? -- LCU ActivelyDisinterested ∆transmissions∆ °co-ords° 19:49, 15 September 2023 (UTC)

{{cite book |title=Title |language=gaa}} → Title (in Ga).

—Trappist the monk (talk) 19:51, 15 September 2023 (UTC)

Thanks Trappist. -- LCU ActivelyDisinterested ∆transmissions∆ °co-ords° 21:52, 15 September 2023 (UTC)

Language=de in "Ça plane pour moi"

Hi, I can't understand why language=de doesn't work in "Ça plane pour moi" (note 32, "Offiziellecharts.de – Plastic Bertrand – Ça plane pour moi". GfK Entertainment charts. Retrieved 15 February 2021).-- Carnby (talk) 20:08, 15 September 2023 (UTC)

Maybe because it's French?--Sturmvogel 66 (talk) 20:48, 15 September 2023 (UTC)

Because there is no citation template used there. I have added {{in lang}} to the "West Germany" entry in {{Single chart}}. I don't know if that will be accepted by the editors there, but it seemed like a nice thing to do for readers. – Jonesey95 (talk) 21:07, 15 September 2023 (UTC)

I've checked {{Single chart}}: apparently {{in lang|de}} works only if access-date is set before 2020.-- Carnby (talk) 21:14, 15 September 2023 (UTC)

@Jonesey95: Thank you. Could you please add it just after the title like in Austria or the Netherlands?--Carnby (talk) 21:20, 15 September 2023 (UTC)

Moved. Is it better now? – Jonesey95 (talk) 22:34, 15 September 2023 (UTC)

Perfect! Thank you!.-- Carnby (talk) 12:54, 16 September 2023 (UTC)

Adding a second archive url

Given the fact that sometimes Internet Archive will remove the archives of a webpage, amd that the whole Internet Archive enterprise may be in legal jeopardy, I was hoping it would be possible to add a second webarchive parameter. When I am creating a reference, I don't mind going to the trouble of creating an archive.today backup, and it seems good to have some redundancy so that archived links don't just disappear if IA ceases to exist. I think this would also imply a new parameter to track url archive status as well. -Furicorn (talk) 11:53, 16 September 2023 (UTC)

Clarifications on cite template usages and descriptions

I have a few questions about the templates, I would love to add these clarifications to the table, as well as to the text of the individual templates, as I can't imagine I'm the only one with these kinds of questions.

• {{Cite AV media}} - is this only for physical media? or does it also cover things like news broadcasts? Why does it exclude online videos? How does it differ from cite podcast? I know people can use cite web, but if you're citing a youtube video typically people aren't citing the comments
• {{Cite encyclopedia}} - is this also used for edited scholarly collections where each scholar provides a chapter? the description on the template makes it sound like it also includes those kinds of works, but I've historically used {{Cite book}} for a chapter in a book like that
• {{Cite interview}} - is this only for written interviews or does it also include video interviews?
• {{Cite technical report}} - can this description be specified a bit more, how does this differ from {{Cite report}}, seems to me govt bodies could def issue a technical report but I can't really tell from the current description
• {{Cite podcast}} - can a youtube channel be considered a podcast, since you can access a youtube channel via an RSS reader. Also why is this separate from {{Cite episode}}? It seems like they are both episodic content, and nowadays podcasts sometimes even have networks, or are distributed on the radio. I'm thinking a lot about online videos in the way we think about books, books get cited with the same template whether we found them online or physically, and I just wanted to maybe open a discussion about the proliferation of video media citations types.
• {{Cite episode}} vs {{Cite serial}} how would you choose one over the other, the difference here really confuses me.

Thanks! -Furicorn (talk) 12:28, 16 September 2023 (UTC)

I have never heard of {{Cite AV media}} applying only to offline sources, and in fact have only ever used it to cite sources with a working url or archive-url. I also use {{Cite book}} to cite books with individual chapter contributions. My feeling is that {{Cite encyclopedia}} is more for works with entries rather than chapters, but I'm not an expert on this. Folly Mox (talk) 16:10, 16 September 2023 (UTC)

DOI filling in URL in Cite journal

In the article October 1 (film), I've added DOI parameters for several journal articles, but it's linking the article title to the DOI even though I have not used the url parameter.

For example: {{Cite journal |last=Ezepue |first=Ezinne Michaelia |last2=Nwafor |first2=Chidera G. |date=July-September 2023 |title=''October 1'': Metaphorizing Nigeria's Collective Trauma of Colonization |journal=[[SAGE Open]] |doi=10.1177/21582440231197271 |doi-access=free}}

displays as:

Ezepue, Ezinne Michaelia; Nwafor, Chidera G. (July–September 2023). "October 1: Metaphorizing Nigeria's Collective Trauma of Colonization". SAGE Open. doi:10.1177/21582440231197271.{{cite journal}}: CS1 maint: date format (link)

This hasn't happened in the past; was there a change to the template or something? voorts (talk/contributions) 14:03, 17 September 2023 (UTC)

This functionality is not new. It was implemented at the 11 July 2020 module suite update as a result of these discussions:

• Wikipedia:Village pump (proposals)/Archive 167 § Auto-linking titles in citations of works with free-to-read DOIs
• Help talk:Citation Style 1/Archive 70 § Auto-linking titles with free DOIs

If you don't want |doi= to link |title= then:

{{Cite journal |last=Ezepue |first=Ezinne Michaelia |last2=Nwafor |first2=Chidera G. |date=July–September 2023 |title=''October 1'': Metaphorizing Nigeria's Collective Trauma of Colonization |journal=[[SAGE Open]] |doi=10.1177/21582440231197271 |doi-access=free |title-link=none}}

Ezepue, Ezinne Michaelia; Nwafor, Chidera G. (July–September 2023). "October 1: Metaphorizing Nigeria's Collective Trauma of Colonization". SAGE Open. doi:10.1177/21582440231197271.

—Trappist the monk (talk) 15:23, 17 September 2023 (UTC)

Thank you! I'm not sure why this has never occurred for me before. Very odd. voorts (talk/contributions) 15:26, 17 September 2023 (UTC)

I think it only makes the link when |doi-access=free is present. —  Jts1882 | talk  15:32, 17 September 2023 (UTC)

There was another cite in the article without |doi-access=free where the same behavior was occurring. voorts (talk/contributions) 15:37, 17 September 2023 (UTC)

If PMC is set it'll use the PMC link. Headbomb {t · c · p · b} 16:04, 17 September 2023 (UTC)

Are you sure? Going back to the last edit from 16 September 2023 (permalink) and the version just before you added |title-link=no (permalink) and looking for doi in the wikitext, I find two |doi= parameters with |doi-access=free and one |doi= without. Can you show me the [other] cite in the article without |doi-access=free where the same behavior was occurring? I presume that your same behavior means title-linked-from-doi.

And, by the way, |title-link=none when {{cite journal}} has a doi but does not have |doi-access=free is meaningless clutter.

—Trappist the monk (talk) 16:32, 17 September 2023 (UTC)

You're right. I must have misremembered. I'll remove |title-link=none from the cite without |doi-access=free. voorts (talk/contributions) 16:40, 17 September 2023 (UTC)

Maintenance category for supplemental issues in volume

See this in particular.

The pattern is |volume=\d+ *Suppl\.? *\d+. Headbomb {t · c · p · b} 21:37, 17 September 2023 (UTC)

Is a supplement always considered to be an issue? Is it possible to have volume, issue, and supplement all at the same time?

COinS has a &rft.part keyword for journal objects:

Part can be a special subdivision of a volume or it can be the highest level division of the journal. Parts are often designated with letters or names, i.e. "B", "Supplement".

That is different from &rft.issue. We could adopt |part= and |supplement= (as aliases of each other) and support them with &rft.part

If we do this, how do we render it?

when only volume with supplement?

when only issue with supplement? (if this is possible)

when volume, issue, with supplement? (doi:10.1161/CIRCULATIONAHA.110.971028 doi:10.1212/WNL.48.5_Suppl_6.2S)

What value does |supplement= get when when a supplement is not enumerated? (doi:10.1016/j.parkreldis.2007.06.003) Are 'special issues' supplements? (doi:10.36076/ppj.2013/16/SE217) How do we support that?another alias, |special-issue=?

Do we support |part= or |supplement= in non-journal citations?

If we do this that resolves the with-a-dot-without-a-dot bug report at User talk:Citation bot § Treat Suppl. as Suppl because it is the template's job to format its output.

I got my example DOIs from this search

—Trappist the monk (talk) 23:27, 17 September 2023 (UTC)

For journals, supplements are always issues. There might be books with "Volume 3, Supplement 2" or something, but those would be the odd balls out. For the above Circulation, we'd have |issue=18 Suppl 3. (They have Issue 11, Issue 11 Supplement 1, Issue 16, Issue 16 Supplement 2, Issue 18, Issue 18 Supplement 3, the rest being regularly numbered issues). For P&RD, it's an unnumbered supplement, so simply |issue=Suppl (or equivalent). The issue here isn't detecting weird stuff in |issue=, it's detecting weird stuff in |volume=. Headbomb {t · c · p · b} 01:01, 18 September 2023 (UTC)

Push PMC limit to 11000000

To deal with the cases in Category:CS1_errors:_PMC, e.g. PMC 10500258. Headbomb {t · c · p · b} 22:04, 17 September 2023 (UTC)

Cite conference format question

I am planning to convert some citations using {{cite report}} to {{cite conference}}. However, I find the format of cite conference a little confusing and somewhat bloated. As shown in the second citation below, using |title=, |conference=, and |publisher= in cite conference displays the term "Asia-Pacific Regional Conference on Underwater Cultural Heritage" thrice (although I may be unknowingly misusing the parameters). How should the cite conference citation be formatted?

{{cite report|type=Conference proceeding |last=Bolunia |first=Mary Jane Louise A. |chapter=Astilleros: the Spanish shipyards of Sorsogon |chapter-url=http://www.themua.org/collections/files/original/34a74c76efdb951655b9bde1213812dc.pdf |title=Proceedings of the 2014 Asia-Pacific Regional Conference on Underwater Cultural Heritage Conference; Session 5: Early Modern Colonialism in the Asia-Pacific Region |url=http://www.themua.org/collections/collections/show/13 |archive-url=https://web.archive.org/web/20150413233643/http://www.themua.org/collections/files/original/34a74c76efdb951655b9bde1213812dc.pdf |archive-date=April 13, 2015 |access-date=October 26, 2015 |publisher=Asia-Pacific Regional Conference on Underwater Cultural Heritage Planning Committee |page=1 |location=Honolulu, Hawaii |oclc=892536655 |via=The Museum of Underwater Archaeology}}

{{cite conference |last=Bolunia |first=Mary Jane Louise A. |conference=Asia-Pacific Regional Conference on Underwater Cultural Heritage |chapter=Astilleros: the Spanish shipyards of Sorsogon |chapter-url=http://www.themua.org/collections/files/original/34a74c76efdb951655b9bde1213812dc.pdf |title=Proceedings of the 2014 Asia-Pacific Regional Conference on Underwater Cultural Heritage Conference; Session 5: Early Modern Colonialism in the Asia-Pacific Region |url=http://www.themua.org/collections/collections/show/13 |archive-url=https://web.archive.org/web/20150413233643/http://www.themua.org/collections/files/original/34a74c76efdb951655b9bde1213812dc.pdf |archive-date=April 13, 2015 |access-date=October 26, 2015 |publisher=Asia-Pacific Regional Conference on Underwater Cultural Heritage Planning Committee |page=1 |location=Honolulu, Hawaii |oclc=892536655 |via=The Museum of Underwater Archaeology}} Sanglahi86 (talk) 06:46, 20 September 2023 (UTC)

Someone might correct me, but I think the problem is that you are trying to cite the conference and the published proceedings of the conference in the same cite. I think the following would be correct:

{{cite conference |last=Bolunia |first=Mary Jane Louise A. |conference=Asia-Pacific Regional Conference on Underwater Cultural Heritage |title=Astilleros: the Spanish shipyards of Sorsogon |url=http://www.themua.org/collections/files/original/34a74c76efdb951655b9bde1213812dc.pdf |archive-url=https://web.archive.org/web/20150413233643/http://www.themua.org/collections/files/original/34a74c76efdb951655b9bde1213812dc.pdf |archive-date=April 13, 2015 |access-date=October 26, 2015 |page=1 |location=Honolulu, Hawaii |oclc=892536655 |via=The Museum of Underwater Archaeology}} -- LCU ActivelyDisinterested ∆transmissions∆ °co-ords° 11:27, 20 September 2023 (UTC)

{{cite conference}} should be rewritten (I've been saying that for years now). The purported purpose of {{cite conference}} is to cite a paper in a proceedings. If one is to believe OCLC, the title of the proceedings is: Proceedings of the 2nd Asia-Pacific Regional Conference on Underwater Cultural Heritage. Googling that, I found an editors list: Hans van Tilburg, Sila Tripati, Veronica Walker, Brian Fahy, Jun Kimura. Elsewhere I found a url for all of the papers for the conference but I didn't find consistent publication data; some sites say the publisher is the conference organizing committee, another names The Museum of Underwater Archaeology. The online version of the cited paper itself does not indicate that it was presented at a conference and in fact, does not mention any conference or proceedings.

Absent a clear and consistent indication of the necessary bibliographic detail, I would shift from {{cite report}} to {{cite web}}:

{{cite web |last=Bolunia |first=Mary Jane Louise A. |title=''Astilleros'': the Spanish shipyards of Sorsogon |website=The Museum of Underwater Archaeology |url=http://www.themua.org/collections/files/original/34a74c76efdb951655b9bde1213812dc.pdf |url-status=live |archive-url=https://web.archive.org/web/20150413233643/http://www.themua.org/collections/files/original/34a74c76efdb951655b9bde1213812dc.pdf |archive-date=April 13, 2015 |access-date=October 26, 2015 |page=1}}

Bolunia, Mary Jane Louise A. "Astilleros: the Spanish shipyards of Sorsogon" (PDF). The Museum of Underwater Archaeology. p. 1. Archived (PDF) from the original on April 13, 2015. Retrieved October 26, 2015.

If you have a physical copy of the proceedings to hand, then {{cite conference}} might be usable, if not, stick to {{cite web}}; WP:SAYWHEREYOUREADIT.

—Trappist the monk (talk) 14:22, 20 September 2023 (UTC)

I think the problem with inconsistent publisher information probably stems from the fact that most conference proceedings are published as a joint collaboration between the organising body and some academic publisher. Since many systems (including our own) only have space for one publisher, people have to pick and choose, similar to how in previous centuries books could be published by a publishing house, but printed by a subcontracted press.

WP:SAYWHEREYOUREADIT is good advice, but I don't think I would ever remove the information that a certain paper was published as part of a conference proceedings (like how an academic bibliography would cite it) just because I read it online instead of perusing a physical book. If I took that logic train all the way to its terminus, I'd be using {{cite web}} for all the book and journal citations I add apart from the books that are present physically at my home. Folly Mox (talk) 14:40, 20 September 2023 (UTC)

I would suggest using |conference=Asia-Pacific Regional Conference on Underwater Cultural Heritage, |book-title=Proceedings of the 2014 Asia-Pacific Regional Conference on Underwater Cultural Heritage Conference and |title=Astilleros: the Spanish shipyards of Sorsogon. -- Shmuel (Seymour J.) Metz Username:Chatul (talk) 15:52, 20 September 2023 (UTC)

Contributors for a book with no primary author

I'm trying to cite a chapter in a book that doesn't have a primary author, but rather three editors and then contributors for each chapter. When I try to use |contributor-last=, it throws an error and does not display the contributor name:

Switching to |author-last= fixes this:

Is this a case of the error correctly pointing me to the appropriate way to format this information? Or is it leading me to incorrectly document that the chapter's author was the main author of the book (in which case we would need to fix CS1/error detection to permit citing contributors in books without a primary author)?

References

{{u|Sdkb}} ^talk 05:44, 22 September 2023 (UTC)

|author=/|last= is used for the author of a chapter in a volume edited by |editor=.

|contributor= is used more when there isn’t an editor of a book; rather the book has an author, but that author did not write one section (like an introduction). See the (help) link in the error message.

Second citation looks fine (although I don’t know any citation styles which require specifying the publication date—a full month, day, year—for a print volume instead of just the year. |doi=10.4324/9781315870663 would also be nice and you probably don’t need to link the publisher; Routledge is pretty well known. Umimmak (talk) 06:11, 22 September 2023 (UTC)

Can someone add Creative Commons parameters to the Cite template?

Template:Creative Commons text attribution notice is designed to go inside <ref> tags. This is impossible to do in Visual Editor (see background info here). In the free content movement, we spend a lot of energy trying to get institutions to release content under Wikipedia-compatible licenses, but within Wikipedia re-use of that content is actually hampered by technical limitations such as this one.

A good solution could be to add the five Creative Commons parameters to Template:Cite. These templates could then be displayed as options within the Add Citation dialog box in Visual Editor. If these parameters were made available as part of the citation itself, contributors would not have to insert Template:Creative Commons text attribution notice. What do you all think? Clayoquot (talk | contribs) 21:57, 23 September 2023 (UTC)

The information in cite templates is intended to help readers verify a claim made in an article by providing information useful in locating the cited source, and ideally, a location within the source. Attribution notices lie outside of that scope. It is trivial to place the attribution notice in the References section or inside the ref tags. If the Visual Editor can't help editors do this in a reasonable way, you might want to file a Phabricator ticket and then, while you are waiting for someone to address the ticket, add a section to Wikipedia:VisualEditor#Limitations. – Jonesey95 (talk) 22:17, 23 September 2023 (UTC)

Reference templates are for WP:V purposes. Licensing is not a matter of referencing. Headbomb {t · c · p · b} 01:04, 24 September 2023 (UTC)

Side note: Clayoquot, if you're trying to make these free content notices easier to use in the visual editor, you could add template data to their documentation. That would be universally appreciated. Good luck, Rjjⁱⁱⁱ (talk) 02:05, 24 September 2023 (UTC)

Thanks everyone for the prompt responses and suggestions. I'll follow up with Jonsey95's ideas. Rjjiii (talk · contribs), is there a place where I could flag down a volunteer who might be able to add template data? I don't know if I'll have bandwidth to figure out how to do it. Cheers, Clayoquot (talk | contribs) 17:48, 24 September 2023 (UTC)

s2cid

Kalambo structure is currently on the main page (In the news) and is returning the error "Check |s2cid= value". Not the best look for Wikipedia. I checked and double-checked the value (262084949) and it is correct. Help:CS1_errors#bad_s2cid says "if the value is correct and larger than the currently configured limit of 262000000, please report this at Help talk:Citation Style 1, so that the limit can be updated." Here I am. Viriditas (talk) 08:33, 25 September 2023 (UTC)

@Trappist the monk: A cited journal paper in Philosophical pessimism has an identifier of S2CID 262038677, which excesses the currently configured limit of 262000000 and leads to a bad S2CID error of Citation Style 1. Please update this limit. NmWTfs85lXusaybq (talk) 13:02, 25 September 2023 (UTC)

Suggest of "require" TemplateData param property

I suggested new TemplateData param property "require" or "depend on" to indicate that a param requires another (or depends on) other param. We need this property for citation params for example:

• "url-status", "url-access" and "access-date" all of them require "url"
• "dio-access" requires "dio"
• "author-first", "author-mask" and "author-link" all require "author-last"

please disscus this in phab:T347377. حبيشان (talk) 07:25, 26 September 2023 (UTC)

Generic title

Hello, another generic title that could do with flagging up is "Wayback Machine has not archived that URL". Keith D (talk) 11:38, 27 September 2023 (UTC)

Also "Subscribe to The Daily Telegraph for exclusive stories" - currently 79 of these. -- John of Reading (talk) 12:12, 27 September 2023 (UTC)

I've seen a lot of cases of generic titles being reduced to blank space, in effect swapping one error for another. Does anyone know if there's a bot that does this or if it's always the work of human editors? It doesn't seem helpful. Folly Mox (talk) 17:08, 27 September 2023 (UTC)

book citation parameter for publisher product pages?

Many books now, especially from academic presses, have a product page with a table of contents, some positive review excerpts, a brief author bio, and a link to purchase the book. Sometimes – but more often not – these pages have a DOI pointing to them. In general I don't like having these pages as the "url" parameter for a book, linked to the book title, because readers trying to verify citations cannot easily look at the text there and are likely to be at least slightly misled by the unadorned link. However, putting a url-access=subscription red lock icon by such links also doesn't quite seem appropriate. Would it be helpful for the citation templates to add some kind of "product page" parameter for such links? I'm not sure what the best way to render them would be. –jacobolus (t) 15:40, 27 September 2023 (UTC)

Sometimes an article, book, journal, magazine, etc., is available for download but there is also an abstract page with metadata. It would be nice if the templates had separate parameters for linking to both the abstract and the actual document. -- Shmuel (Seymour J.) Metz Username:Chatul (talk) 16:45, 27 September 2023 (UTC)

In such a case, if the abstract page clearly links to the PDF / full text, then it is appropriate to always link the abstract page. Readers can easily do one extra hop to arrive at the full text. (But that's a different kind of situation than what I am talking about here, and is not really relevant to my question.) –jacobolus (t) 16:58, 27 September 2023 (UTC)

In cases where the full text is not available online, a link to the publisher's landing page is often better than nothing, although it's pretty silly when they get archived. I agree that |url-access=subscription doesn't seem appropriate for this sort of URL, but maybe it actually is and I just feel wrong about it.

I don't think the solution is a |product-url= parameter, if that's what's being suggested. It would be mildly helpful for distinguishing without clickthrough whether a URL pointed to the source text or not, but would overwhelmingly end up being used for promotion, in my opinion. Folly Mox (talk) 17:06, 27 September 2023 (UTC)

I don't think I agree that a URL pointing at the landing page is better than nothing. It sets a misleading expectation for readers, who click through and are then disappointed when they can't actually see the source. I guess one current workaround could be something like |id=[http://example.com Publisher's site], but this seems like an abuse of the ID parameter. I don't really understand why links explicitly designated as pointing at a publisher's page would be more "used for promotion" than links on the book title, links from a DOI, etc. I guess my key point is that these are links about the book rather than containing the book. Perhaps instead of url-access=subscription there should be a synonym like url-access=purchase (instead of a lock icon it could perhaps use a $ icon). –jacobolus (t) 17:25, 27 September 2023 (UTC)

I see your point about a link to a landing page not necessarily being better than nothing. I guess I see it as skipping a few steps from tapping an ISBN link, then a search link at whichever cataloguing site I prefer (OCLC, gbooks, whatever): the landing page won't contain the full text, but demonstrates instantly that the source exists, and shows who publishes it (in case I somehow have a subscription with them). It sounds like you and I have different expectations around what a linked title in a book citation will lead to, and I'm not sure which of our perspectives is more broadly shared in the community or in the readerbase.

As to promotional use of a putative |product-url=, I am imagining well-meaning editors adding |product-url= values to citations where the full text is already available somewhere, as well as links to Amazon pages. I'd be happy to hear what others think about these things. Folly Mox (talk) 18:55, 27 September 2023 (UTC)

I definitely don't mean Amazon pages. I was thinking of either the author's personal page about their book (but not containing it), or the publisher's product page, or something like that. Sometimes such URLs contain valuable auxiliary material like images, code, extended bibliography, sample chapters, errata, etc., but as a reader I still find them frustrating if I was expecting to click and get the source directly. –jacobolus (t) 20:33, 27 September 2023 (UTC)

I understand that you definitely don't mean Amazon pages. My concern is the misinterpretation by future editors. I'm not sure if |type=publisher landing page is appropriate parameter usage, but might get the same point across without updating the templates. Folly Mox (talk) 21:07, 27 September 2023 (UTC)

I would prefer not to add a parameter like this because having a parameter encourages editors to fill in the parameter and most of the time it should not be filled in. —David Eppstein (talk) 21:27, 27 September 2023 (UTC)

What is the problem with |url-access=subscription? It is possible to have subscription access to books. (For instance my employer supplies me with a subscription to many Springer books.) That said, I tend to avoid using publisher urls in the |url= parameter, except for open-access books, mostly per WP:ELNO #5 as a page "that primarily exists to sell products or services". If it has a doi that can be included instead. —David Eppstein (talk) 19:24, 27 September 2023 (UTC)

Is "url-access=subscription" appropriate for a page that says "click here to buy a physical copy for $100?" That doesn't seem to me like a subscription, but maybe the red lock icon is the right idea there. –jacobolus (t) 20:34, 27 September 2023 (UTC)

If you have the subscription, what you see is different. —David Eppstein (talk) 20:38, 27 September 2023 (UTC)

I think we are talking about different links here. Here are some specific examples of what I would call product pages that don't (as far as I can tell) involve any subscription: https://bookstore.ams.org/hmath-27, https://wwnorton.com/books/the-man-from-the-future, https://www.penguinrandomhouse.com/books/133168/prisoners-dilemma-by-william-poundstone/, https://mitpress.mit.edu/9780262518857/. –jacobolus (t) 20:48, 27 September 2023 (UTC)

I can't tell because I don't have a subscription to those. Here's one that, when I visit it, shows me a prominent "Download book PDF" link (along with the table of contents, visible to everyone), but that probably looks like the same kind of product page to you: https://link.springer.com/book/10.1007/978-3-540-77974-2 —David Eppstein (talk) 21:29, 27 September 2023 (UTC)

This link should work for any editors with Wikipedia Library access. Folly Mox (talk) 22:51, 27 September 2023 (UTC)

I can't help thinking Wikilibrary links are a bad idea, they'd be incredibly helpful to me but most readers (or even editors) don't meet the criteria. If there was a coding way to autoswitch it would be great, but from past discussions there doesn't appear to be a real solution for that. Can't say I like the idea of |product-url= it looks ripe for abuse with spam or monetised links. -- LCU ActivelyDisinterested ∆transmissions∆ °co-ords° 23:33, 27 September 2023 (UTC)

I agree that that's a bad idea. Our reader-facing content should be aimed at readers, not editors. Wikilibrary links are aimed at editors, not readers. —David Eppstein (talk) 00:33, 28 September 2023 (UTC)

Oops apologies for my lack of clarity. I have never added a Wikipedia Library link to mainspace and don't propose to do so. I dropped the link there so people can compare how the landing pages look with and without a subscription to Springer. Folly Mox (talk) 01:14, 28 September 2023 (UTC)

Okay, I hear you about the way a product-url or similar parameter would encourage more spam. @ActivelyDisinterested, @David Eppstein, @Folly Mox do you think product page links like the ones I linked above to university presses etc. (which I just recently removed from an article's citations) should be included as the "url" parameter in citations, or is it better to just go without a "url"? If they were included, should they include "url-access=subscription" (no subscription is available, but the main point of the page is to direct people to a 'buy' button)? –jacobolus (t) 01:29, 28 September 2023 (UTC)

I think I'd like to hear more about what other editors expect to find behind a linked book title, because I think whether or not a product page is better than no url depends on what you're expecting.

I will say that it looks like some nuance might be better, because not all of the links removed are the same sort. Some (like Springer) are identical to the DOI, and thus have no real purpose except to attract parameter cruft like unnecessary |access-date=, |archive-url=, and |archive-date=. Some (like OUP) certainly have an equivalent DOI, but it was not added. Most if not all of the academic publishers support a subscription model, so even a link to a landing page will lead to the full text for subscribers. In these cases, they'll almost certainly have a DOI as well, which are presumed to be subscription only, and if we're using DOI in place of equivalent URLs, the |url-access=subscription parameter will be both unnecessary and a template error. For academic publishers with subscription models but no DOI schema (I'm unaware of any), the landing page with |url-access=subscription seems appropriate. Lastly, the commercial publishers. I don't think a publisher like Random House Penguin or WW Norton offers a subscription to read their content, so works must be independently purchased. I don't think landing pages of this genre are helpful outside of verifying the work exists. I might be all the way wrong about these business models. Folly Mox (talk) 02:56, 28 September 2023 (UTC)

I looked (briefly) for DOIs for the same books and added the ones I found, but didn't find some others, though I admit some of them might have DOIs I didn't locate in a brief search. The OUP ones are https://oup.com/academic/product/9780190655174 and https://oup.com/academic/product/9780190948191 – I still can't find any DOIs for these in a slightly less brief search. For academic publishers with subscription models but no DOI schema (I'm unaware of any), the landing page with url-access=subscription seems appropriate. I also added a couple of these, specifically to the links https://read.dukeupress.edu/hope/issue/24/Supplement (Duke) and https://muse.jhu.edu/book/17623 (UMichigan Press via a page at JHU Press) for which I could not find DOIs. –jacobolus (t) 02:59, 28 September 2023 (UTC)

Apologies for my oversights. I didn't consult the later diffs. I seem to remember OUP having DOIs. I'll see if I can find the two. Folly Mox (talk) 03:30, 28 September 2023 (UTC)

Attempt failed. I shouldn't have doubted you. Folly Mox (talk) 03:47, 28 September 2023 (UTC)

No worries at all. :-)

I can still plausibly imagine some Wiki authors wanting to keep these product page links, and would be happy to defer to some alternative (local or global) consensus about it. –jacobolus (t) 04:49, 28 September 2023 (UTC)

For this one, I would recommend just linking the DOI. I'm not talking about SpringerLink pages or the like. –jacobolus (t) 01:23, 28 September 2023 (UTC)

As a concrete example I just removed a bunch of product page links from John von Neumann in special:diff/1177440279, but perhaps other editors think those links should stay. –jacobolus (t) 20:36, 27 September 2023 (UTC)

"URL access level" options

Some publishers such as Springer Nature offer a type of URL that can be used as the URL and gives full open access to an otherwise paywalled source. It would be useful if there were an option in addition to 'registration', 'subscription' or 'limited', such as open (or equivalent name) that displayed a green padlock to make it clear these URL links do give the reader full access to the publication? Or should I use the 'limited' option?

Example, this paper is normally paywalled, however this version of the link attained via Wikipedia Library be used as the citation URL and gives the reader full access.The grey 'limited' padlock is described for "free access is subject to limited trial and a subscription is normally required", should this be used instead? Zenomonoz (talk) 04:33, 28 September 2023 (UTC)

I think these links are intended to be shared with a friend or two privately, not with the general public. I would recommend avoiding them in Wiki pages because my expectation is that they will stop working in a relatively short timeframe. If the publisher wants every reader to have open access to the paper, they'll publish the paper as open access.

Here are the T&C: We support a reasonable amount of sharing of content by authors, subscribers and authorised users (“Users”), for small-scale personal, non-commercial use provided that you maintain all copyright and other proprietary notices. ... Users and the recipients of the shareable link, may not 1. use the SharedIt service or shareable links for the purpose of providing other users with access to content on a regular or large scale basis or as a means to circumvent access control; ... We are not obligated to publish any information or content and may remove it and the shareable links or any SharedIt features or functionality at our sole discretion, at any time with or without notice. We may revoke this licence to you at any time and remove access to any copies of the shared content or shared links which have been saved.... If you intend to distribute our content to a wider audience on a regular basis or in any other manner not expressly permitted by these Sharing Terms of Use please contact us at sharedit@springernature.com.

Their examples are stuff like authors sharing a link to their own paper on facebook (an inherently temporary/ephemeral kind of sharing, to a relatively small group of readers). It does not really sound like "please publish this on Wikipedia" is one of the intended uses. –jacobolus (t) 05:00, 28 September 2023 (UTC)

Thanks for your response. Zenomonoz (talk) 07:47, 28 September 2023 (UTC)

Recognize free DOI prefixes

See also: User talk:Citation bot/Archive 36 § More open access DOIs

Several DOIs can be known to be free from their DOI prefix. While we could autoflag them as free, a better practice, IMO, would be to have Category: CS1 maint: unflagged free DOI (or similar), that would populate when we have a DOI prefix match, and when |doi-access=free is not set. This way we would have a category against which to run User:Citation bot (similar to Category:CS1 errors: DOI, or Category:CS1 maint: PMC format). Because right now, we need to collect all articles with DOI match (about 30,000 articles), but have no good way of excluding articles where their free DOIs have already been flagged, leading to a lot of wasted bot processing time.

10\.(1100|1155|1186|1371|1629|1989|1999|2147|2196|3285|3389|3390|3410|3748|3814|3847|3897|4061|4089|4103|4172|4175|4236|4239|4240|4251|4252|4253|4254|4291|4292|4329|4330|4331|5194|5306|5312|5313|5314|5315|5316|5317|5318|5319|5320|5321|5334|5402|5409|5410|5411|5412|5492|5493|5494|5495|5496|5497|5498|5499|5500|5501|5527|5528|5662|6064|6219|7167|7217|7287|7482|7490|7554|7717|7766|11131|11569|11647|11648|12688|12703|12715|12998|13105|14293|14303|15215|15412|15560|16995|17645|19080|19173|20944|21037|21468|21767|22261|22459|24105|24196|24966|26775|30845|32545|35711|35712|35713|35995|36648|37126|37532|37871|47128|47622|47959|52437|52975|53288|54081|54947|55667|55914|57009|58647|59081)

will match the currently known garanteed-to-be-free DOI prefixes. The list could be expanded as more are discovered (and likely externalized for ease of maintenance). Headbomb {t · c · p · b} 04:53, 18 August 2023 (UTC)

This shouldn't be very hard to implement. Any news on this? Headbomb {t · c · p · b} 23:12, 1 September 2023 (UTC)

{{cite book/new |title=Title |doi=10.1100/sommat}}

Title. doi:10.1100/sommat.{{cite book}}: CS1 maint: unflagged free DOI (link)

{{cite book/new |title=Title |doi=10.1100/sommat |doi-access=free}}

Title. doi:10.1100/sommat.

—Trappist the monk (talk) 13:38, 2 September 2023 (UTC)

Given the intent is to run a bot against this, can we adjust this to emit a properties category without message instead? Izno (talk) 17:58, 12 September 2023 (UTC)

When it's not a high-priority fix/an actual error, that's what maintenance categories are for, basically. Citation bot already handles the vast majority of issues in

• Category:CS1 errors: DOI
• Category:CS1 errors: invisible characters
• Category:CS1 maint: bibcode
• Category:CS1 maint: extra punctuation
• Category:CS1 maint: MR format
• Category:CS1 maint: PMC embargo expired
• Category:CS1 maint: PMC format

We don't really need another type of category that's "maintenance, but not maintenance that needs to be displayed when I enable the maintenance messages". It'll have a few hundred/thousands pages in it at first, but one the initial run is done, remain below 10ish pages a day like the others. Headbomb {t · c · p · b} 21:56, 17 September 2023 (UTC)

Category:CS1 properties does exist.

I am entirely unconcerned about the count, the thought is that no human reader should want to maintain this category by hand, since it's fixable by bot (not all of the above are, despite Citation bot fixing them). So why emit a message to the user? (This is rhetorical, I don't really care enough on this point.)

Separately, what happens when one of these publishers decides they're no longer going to publish content freely? Izno (talk) 16:52, 25 September 2023 (UTC)

If a publisher stops being systematically free, we can remove them from the flag missing category and update bots accordingly (e.g. Citation bot stops flagging automatically, OABot keeps flagging on a case-by-case) basis. Headbomb {t · c · p · b} 21:51, 29 September 2023 (UTC)

Update chapter and format sections??

I dunno if it's worth it, but I was wondering if it's worth mentioning in the 'format' section any relevant policies related to ISBN and ISSN numbers, where the journal or book cited may be in ebook, hardcover, or paperback form and each having a different ISSN or ISBN. Sort of along the lines of why locations are often cited, each location has a slightly different edition and ISSN/ISBN in many cases and thus providing the location helps to find the exact version of whatever. Similarly, I know I was a bit confused by what to do with chapter DOIs. Apparently, a variable for this was proposed back in 2020 and then scrapped (Help talk:Citation Style 1/Archive 70#Auto-linking titles with free DOIs under sub-section 'Auto-linking for book chapters'). I'm assuming, not sure if this is correct or not, that in such cases the current protocol is to use the 'cite chapter' tag and then cite the corresponding chapter DOI and maybe it might be worth mentioning it under the chapter sections of this document? And I'm also not sure I have the current consensus correct either, but, was wondering if for future ease of newer editors and for the ease of users, if updating this document to include sections about what to do in such instances may be worth explicitly mentioning. Thanks for reading. Thoughts? KnowTheManyHistories (talk) 01:12, 27 September 2023 (UTC)

For the first question, if I understand it, the relevant guideline is at WP:SAYWHEREYOUREADIT. For the chapter DOI issue, please give an example. – Jonesey95 (talk) 03:55, 27 September 2023 (UTC)

|format= is for the kind of file at the other end of a URL. It might as well be named |url-file-format=. If you are using it in some other way, that's incorrect. Izno (talk) 20:33, 29 September 2023 (UTC)

url=w.media false warning

{{cite web |title=W.Media| url=https://w.media}} produces:

"W.Media".

It currently says "Check |url= value" but the link https://w.media works. The warning comes for a single-letter second level domain. Originally reported at Wikipedia:Village pump (technical)#.Media web sites confusing the cite web template. PrimeHunter (talk) 20:58, 29 September 2023 (UTC)

fixed in the sandbox:

{{cite web/new |title=W.Media| url=https://w.media}}

"W.Media".

—Trappist the monk (talk) 21:42, 29 September 2023 (UTC)

Protected edit request on 3 October 2023 Suggestion: Suggestion add template data

Want to add TemplateData for Cite map so that it can work with ProveIt, using Cite book page as an example

Change from: <includeonly>{{#invoke:Citation/CS1 | citation |CitationClass=map }}</includeonly><noinclude> {{documentation}} </noinclude>

to

<includeonly>{{#invoke:Citation/CS1 | citation |CitationClass=map }}</includeonly><noinclude> {{documentation}} {{collapse top|TemplateData}} {{Cite map/TemplateData}} {{collapse bottom}} </noinclude> Furicorn (talk) 20:52, 3 October 2023 (UTC)

There is no need to change the wikitext in {{cite map}} in order to add TemplateData. You can add TemplateData to Template:Cite map/doc. Most cs1|2 templates do not have separate TemplateData subpages.

—Trappist the monk (talk) 21:50, 3 October 2023 (UTC)

Serbian-language citation categories

The latest dump of redlinked (non-existent) categories at Special:WantedCategories featured four maintenance categories for Serbian-language sourcing: both Category:CS1 srpski (latinica)-language sources (sr-el) and Category:CS1 Serbian (Latin script)-language sources (sr-latn) for Serbian-Latin, based solely on whether a citation template's language= field was using the two-letter el or four-letter latn code, and both Category:CS1 српски (ћирилица)-language sources (sr-ec) and Category:CS1 Serbian (Cyrillic script)-language sources (sr-cyrl) for Serbian-Cyrillic, based solely on ec vs. cyrl in the same context.

Now, obviously we don't need two different categories for the same thing just because of non-semantic coding differences, so I've moved all the existing ec's and el's over to cyrl's and latn's — but since this is a problem that's likely to recur and need ongoing cleanup of non-empty categoryredirects, I wanted to ask if there's any way that ec and el can just be coded to automatically use the cyrl and latn categories instead of needing manual changeovers. Bearcat (talk) 15:22, 7 October 2023 (UTC)

I have hacked the module sandbox to recognize the sr-el and sr-ec MediaWiki language tags. When these are encountered, the module switches to use IETF language tags sr-latn and sr-cyrl (which MediaWiki also recognizes as a result of phab:T117845) and adds the article to Category:CS1 maint: unrecognized language. I don't see a need for a special category just for these two language tags.

{{cite book/new |title=Title |language=sr-el}}

Title (in Serbian (Latin script)).{{cite book}}: CS1 maint: unrecognized language (link)

{{cite book/new |title=Title |language=sr-ec}}

Title (in Serbian (Cyrillic script)).{{cite book}}: CS1 maint: unrecognized language (link)

{{cite book/new |title=Title |language=sr-latn}}

Title (in Serbian (Latin script)).

{{cite book/new |title=Title |language=sr-Cyrl}}

Title (in Serbian (Cyrillic script)).

{{cite book/new |title=Title |language=sr}}

Title (in Serbian).

When this change goes live, Category:CS1 srpski (latinica)-language sources (sr-el) and Category:CS1 српски (ћирилица)-language sources (sr-ec) can be deleted.

—Trappist the monk (talk) 16:22, 7 October 2023 (UTC)

Dead chapter-url which has been archived and available therefrom

I don't think this has been discussed before. There is a clear path to the indication that 'url' is dead and has been archived, but this does not appear to be available for 'chapter-url'. I'm looking at a citation now where this is the case; this is the first citation (Cañas et al.) of CmapTools; there is an available archive.org link, but there is no in-template way to use this like one would do so for the 'URL' parameter. One could use some cludge based on {{Webarchive}}, or simply replace the dead chapter-url with the archive.org url, but I'm looking for a more elegant method than either of those. Thoughts? --User:Ceyockey (talk to me) 01:41, 5 October 2023 (UTC)

It's actually incredibly intuitive, and works exactly the same as a |url= parameter would. See Special:Diff/1178657342. Folly Mox (talk) 01:55, 5 October 2023 (UTC)

Thank you @Folly Mox. User:Ceyockey (talk to me) 00:25, 10 October 2023 (UTC)

Italics in {{Cite AV media}}

Currently, {{Cite AV media}} automatically italicizes the source title. While italics are appropriate for films and television programs, it is not appropriate for online videos posted on YouTube, Vimeo, etc. Please alter the template's code so that when an online video is being cited, no italics are applied and the source title is enclosed in quotation marks, per MOS:MINORWORK. This can be done in two ways:

• We could use quotation marks whenever |via= or |publisher= is set to YouTube, [[YouTube]], Vimeo, etc. However, this approach could lead to frequent edit requests to add smaller video-hosting sites to the list of exemptions.
• Another approach would be to use quotation marks whenever |type= is not set to motion picture, television program, documentary, or television special. This could theoretically cause false positives, but I don't foresee that happening very often.

Either way, this issue needs to be fixed, because many articles are incorrectly italicizing YouTube videos. InfiniteNexus (talk) 23:25, 7 October 2023 (UTC)

While I agree with you in principle, I do not see either of your suggestions as workable remedies. In both cases, the suggestions ignore the 'A' part of 'AV'. Alas, I have no solution to offer without we create separate 'major' and 'minor' versions of the template.

—Trappist the monk (talk) 14:14, 8 October 2023 (UTC)

If {{Cite AV Media}} is used to cite audio singles, the title should also be in quotation marks, not in italics. This could be solved if the template {{noitalic}} were allowed inside parameters, but I suspect there might be a technical reason not to do that. Another way might be to extend the behaviour of the ((…)) construct to take |title= verbatim, without any imposed styling. -- Michael Bednarek (talk) 15:10, 8 October 2023 (UTC)

The second suggestion would not work because quotation marks should not be part of the link. InfiniteNexus (talk) 15:53, 8 October 2023 (UTC)

(edit conflict)

{{noitalic}} may not be used in |title= because it will corrupt the metadata by dragging in a bunch of non-title stuff:

{{cite av media |title={{noitalic|Title}}}}

Title. {{cite AV media}}: templatestyles stripmarker in |title= at position 1 (help)

'"`UNIQ--templatestyles-000000AE-QINU`"'<cite class="citation audio-visual cs1">'''"`UNIQ--templatestyles-000000AD-QINU`"'<span class="noitalic">Title</span>''.</cite><span title="ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Abook&rft.genre=unknown&rft.btitle=%7F%27%22%60UNIQ--templatestyles-000000AD-QINU%60%22%27%7F%3Cspan+class%3D%22noitalic%22%3ETitle%3C%2Fspan%3E&rfr_id=info%3Asid%2Fen.wikipedia.org%3AHelp+talk%3ACitation+Style+1%2FArchive+90" class="Z3988"></span> <span class="cs1-visible-error citation-comment"><code class="cs1-code">{{[[Template:cite AV media|cite AV media]]}}</code>: </span><span class="cs1-visible-error citation-comment">templatestyles stripmarker in <code class="cs1-code">&#124;title=</code> at position 1 ([[Help:CS1 errors#invisible_char|help]])</span>

you are looking for rft.btitle= in that mess.

The accept-as-written markup isn't intended to switch a parameter value's styling but rather, to tell the module that it must not fidget with the value or emit maintenance and error messages because of the value.

For completeness, adding quotes and italic markup looks ok, but also corrupts the metadata because the added quote marks are not part of the source's title:

{{cite av media |title=''"Title"''}}

"Title".

'"`UNIQ--templatestyles-000000B2-QINU`"'<cite class="citation audio-visual cs1">''<span></span>''"Title"''<span></span>''.</cite><span title="ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Abook&rft.genre=unknown&rft.btitle=%22Title%22&rfr_id=info%3Asid%2Fen.wikipedia.org%3AHelp+talk%3ACitation+Style+1%2FArchive+90" class="Z3988"></span>

—Trappist the monk (talk) 16:42, 8 October 2023 (UTC)

What types of audio would {{Cite AV media}} be (plausibly) appropriate for? Radio broadcasts should be using {{Cite episode}}, and podcasts should be using {{Cite podcast}}. And if there are other use cases, can those not be added to the two lists above (i.e. if it should be italicized, add it to the second list; if it should be in quotes, add it to the first)? InfiniteNexus (talk) 15:48, 8 October 2023 (UTC)

As I wrote, to cite audio singles. Also, no one is compelled to use {{Cite AV media}}. {{Cite web}} is probably flexible enough to cover all these cases, or one can simply knit a free-form citation. -- Michael Bednarek (talk) 03:13, 9 October 2023 (UTC)

Does no one else have an idea on how to fix this? InfiniteNexus (talk) 02:50, 10 October 2023 (UTC)

OCLC error

An OCLC value for one of the citations in Genetic history of the African diaspora is correct and greater than 10005000000. Achmad Rachmani (talk) 12:19, 9 October 2023 (UTC)

Dropping cruft from long google books urls

I seem to remember somewhere seeing a description of stripping all the extraneous URL query parameters from a Google books url for use in param |url= in a {{cite book}} citation, but I don't see it described either at Template:Cite book/doc or at Wikipedia:Citing sources#Linking to Google Books pages. I already do this as a matter of course, but I need the link for an edit summary to explain what I'm doing and why. Anybody remember where it is? When found, I'll link it from both of those doc pages. Thanks, Mathglot (talk) 22:53, 9 October 2023 (UTC)

Perhaps the template's url parameter documentations?

—Trappist the monk (talk) 23:30, 9 October 2023 (UTC)

Wikipedia:Citing sources/Further considerations#Cleaning of URLs used in references? Folly Mox (talk) 23:35, 9 October 2023 (UTC)

User:AManWithNoPlan has developed experience with GB URLs and Citation bot. One way is run the bot on the page and it will normalize it for you. -- GreenC 00:07, 10 October 2023 (UTC)

Cool; thanks, all! Mathglot (talk) 10:03, 18 October 2023 (UTC)

Category:CS1 maint: url-status gives false positives for 'cite Q'

The Category:CS1 maint: url-status gives false positives for {{cite Q}} citations. In this case, the |url-status parameter is necessary (unless the source is given with no archival copy), but the |archive-url= normally should be absent from Wikipedia. Instead, the d:Property:P1065 (archive url) should be given in a way that includes a date - Wayback does this in an obvious way; for Archive.today, you need to click on share, select long link, and change http to https. Boud (talk) 07:34, 17 October 2023 (UTC)

Presumably this is about Elleni Zeleke (permalink) where you have added |url-status=live to every {{cite q}} template in the article; even those templates that do no render with |url=. For example, this template does not render with |url=:

{{cite Q|Q117768677|url-status=live}}

{{Cite book |author-link1=Elleni Zeleke |author1=Elleni Zeleke |id=Wikidata Q117768677 |isbn=978-90-04-41475-4 |language=en |publication-date=2019 |publisher=Brill Publishers |title=Ethiopia in Theory: Revolution and Knowledge Production, 1964–2016 |url=https://brill.com/display/title/34474 |url-status=live}}

Elleni Zeleke (2019). Ethiopia in Theory: Revolution and Knowledge Production, 1964–2016. Brill Publishers. ISBN 978-90-04-41475-4. Wikidata Q117768677.{{cite book}}: CS1 maint: url-status (link)

The maintenance message and category are correctly applied because |url-status= without |url= and |archive-url= is meaningless clutter.

In this case, the |url-status parameter is necessary (unless the source is given with no archival copy), but the |archive-url= normally should be absent from Wikipedia. You have not described why you believe that |url-status= is necessary. I don't know what you mean by the |archive-url= normally should be absent from Wikipedia.

Whatever hoops you have to jump through to get longform archive.today urls is outside of the cs1|2 remit.

I will revert your edit at Category:CS1 maint: url-status because use of |url-status= in {{cite q}} is no different from its use in the canonical cs1|2 templates.

—Trappist the monk (talk) 13:41, 17 October 2023 (UTC)

I agree that in the case where the archive is missing from Wikidata, the |url-status parameter could be dropped. However, in that case, once someone adds an archive in the Wikidata element, all {{cite Q}} links without |url-status will automatically switch to showing primarily the archived link, with the live link mentioned afterwards.

Why should someone adding an archive link to the Wikidata element have to search for all usage in (at least) the en.Wikipedia (and possibly other language Wikipedias or other WMF wikis) and add url-status tags there? I guess you could argue that Wikidata people have to add a property that can be used by cite Q to represent url-status, and the status should then be updated on Wikidata, not en.Wikipedia. I started a discussion over there for people interested in following up, since that would make sense to me.

In any case, for cases where the |archive-date and |archive-url parameters are read automatically from Wikidata, it is clearly not currently an error to include |url-status with {{cite Q}}; on the contrary, it's an error to exclude |url-status. I would recommend including something similar to my reverted note to clarify this in the lead of Category:CS1 maint: url-status. Boud (talk) 15:30, 17 October 2023 (UTC)

It would be sensible for wikidata to support a url-status property and also for someone to tweak {{cite q}} to support that new property. Mayhaps, someday, these things shall come to pass.

Including |url-status=dead when |url= is dead and |archive-url= is present is pointless clutter. The only time that |url-status=live should be present is when |url= is live and |archive-url= is present.

—Trappist the monk (talk) 16:39, 17 October 2023 (UTC)

PDF page links

I was creating a citation to a PDF at specific page so I used {{Cite web}} with the |page= parameter. I then searched online to see if it's possible to link to a specific PDF page in the URL and the result was to add #page=page number. I was wondering if this should and can be added to the module to handle automatically or just handled manually? Gonnym (talk) 12:54, 18 October 2023 (UTC)

Printed page numbers are not always PDF page numbers: page 82 of this paper is PDF page 4. -- Michael Bednarek (talk) 13:45, 18 October 2023 (UTC)

Ah, good point. Gonnym (talk) 13:57, 18 October 2023 (UTC)

Still, there's a lengthy section in the documentation, "Using |format=" dealing with PDFs. Maybe a brief sentence explaining this construct would be generally helpful. -- Michael Bednarek (talk) 14:20, 18 October 2023 (UTC)

ffhalshs

A reference in the article Edward Vernon Arnold is described as "ffhalshs-01929253f". This is utterly unfamiliar to me, but when I look for it I find that other articles too cite sources labelled "ffhalshs-" something. I haven't found this linked to any explanation. Googling "ffhalshs" shows examples of its use, but again no explanation. Is this perhaps a referencing system that never caught on and can now safely be ignored? -- Hoary (talk) 23:49, 18 October 2023 (UTC)

It seems to have something to do with https://shs.hal.science/, which seems to be an imprint of HAL (open archive). I haven't been able to locate any information on their website, and looking at the metadata of papers uploaded there does not reveal ffhalshs identifiers. Maybe they've sunsetted the format? Bewildering. Folly Mox (talk) 01:43, 19 October 2023 (UTC)

A Free French archiving system, it appears. More available here. Maybe hide it, but leave it in for now?  Mr.choppers | ✎  01:49, 19 October 2023 (UTC)

Oh ho! Looky here: The cited work!  Mr.choppers | ✎  01:54, 19 October 2023 (UTC)

Mr.choppers, the cited work that you've unearthed starts with

To cite this version:

Arlo Griffiths, Annette Schmiedchen (Dir.). The Atharvaveda and its Paippalādaśākhā: Historical and philological papers on a Vedic tradition. Arlo Griffiths; Annette Schmiedchen. Shaker, 11, 2007, Indologica Halensis, 978-3-8322-6255-6. halshs-01929253

In which "halshs-01929253" is immediately surrounded by bytes that Firefox (which I happen to be using now) renders as "FFFF". I now wonder if the longer version with "ff" at the front is merely a garbled version of this. ("FF" could be FF₁₆, i.e. decimal 255.) If my guess is right, then "ff" should be stripped from "ffhalshs"; "halshs" is written up within the article Centre pour la communication scientifique directe. -- Hoary (talk) 04:56, 19 October 2023 (UTC)

Yeah, I am not computer literate enough to know where the "ff" bit originated, but I don't think stripping it will cause any harm. I think we ought to include the weblink in the reference, and put "halshs-01929253" in the |id= field. I also tried to read a bit about the Paippalādaśākhā but it proved ten times more esoteric than even this conversation.  Mr.choppers | ✎  14:00, 19 October 2023 (UTC)

• It's a unique identifier for HAL (open archive), The |id= parameter can be used for it where none of the other specialized identifiers are applicable.⋆｡°✩🎃✩°｡⋆ Isaidnoway (talk) 17:10, 19 October 2023 (UTC)

  The |id= parameter accepts templates so |id={{HAL|halshs-01929253}} will give you link in the cite with the format HAL halshs-01929253. -- LCU ActivelyDisinterested ∆transmissions∆ °co-ords° 18:33, 19 October 2023 (UTC)

ISBN wikilink

While using {{cite book}}, I have just realised that the ISBN parameter creates a link to ISBN (identifier), which is actually a redirect "from currently unnecessary disambiguation" to ISBN. Is it really anticipated that the current usage of ISBN will be usurped to such an extent that the book identifier ISBN will no longer be the principle meaning? It seems very unlikely.

I suggest that cite book (and any similar templates) be changed to use the direct link; it will simplify at least 1.6m pages, and save a kg or two of carbon emissions by reducing processing. If the meaning of ISBN does change, it can always be updated again (as the redirect would have to be in the same situation). Since cite book is not normally subst:ed, any change will update references on their next use. -- Verbarson  ^talk_edits 12:39, 21 October 2023 (UTC)

cs1|2 uses the ISBN (identifier) redirect so that Special:WhatLinksHere/ISBN lists only those pages that have meaningful links to ISBN of which there are less than 10,000.

—Trappist the monk (talk) 13:15, 21 October 2023 (UTC)

Thank you. -- Verbarson  ^talk_edits 13:44, 21 October 2023 (UTC)

Subscription and via, when link is dead

User:Srich32977 has been systematically removing |via= and |subscription= from thousands of citations that have dead links, focusing on HighBeam. For example Special:Diff/1180668590/1180833359. Their rationale is best explained here Special:Diff/1180822274/1180830474, they are "cleaning up clutter". Myself and a number of other editors have raised questions on their talk page. What do you think? Bigger picture, if this is our intention, should we remove these parameters from all citations with dead links ie. creating tracking categories, enlisting bots and showing warning/maintenance messages. -- GreenC 04:22, 19 October 2023 (UTC)

This is a distortion of my efforts. For example, when there is a "subscription" parameter for the defunct HighBeam citations, the removal is entirely proper because there is no provider with which a subscription is applicable. Same rationale applies to "via". HighBeam is defunct, and cannot provide a "via" to the reader. The best we have is an archive copy of the defunct HighBeam url, which is actually an archive of original source. Yes, this is a clutter-removal project. And I think it comports with WP:DEADLINK. Need more be said? – S. Rich (talk) 04:46, 19 October 2023 (UTC)

The documentation says if the publisher and source differ, use |via=. That's all it says, nothing about removing when the link is dead.

As for subscription, there might be a stronger case for it's removal, but I could also see rationales for keeping. Again, no guidance in the documentation about removal when the link is dead.

By removing metadata it becomes less clear what the original citation was about, particularly for non-digital versions of the article.

(OT: HighBeam was not a web archive, it was similar to GALE or JSTOR, a commercial database provider that sold access to libraries and individuals. The cite sometimes verifies with the limited free content they provided, which is why so many people linked to it on Wikipedia, it was easy to find results with Google searches.)

-- GreenC 05:56, 19 October 2023 (UTC)

The best we have is an archive copy of the defunct HighBeam url, which is actually an archive of original source. Purportedly an archive of the original source by HighBeam. I simply do not understand the logic here of pruning the information from the citations without pruning the entire thing. It's still through HeadBeam, whether the site is up or not. If we decide that this is the wrong approach, who is going to undo this mass of changes which in the mind of other editors are apparently destroying the citations? I wish Wikipedia had a behavioral guideline that any mass (what I would call semi-automated) changes be discussed first. BOLDness can less to a mess that no one is going to fix. —DIYeditor (talk) 09:35, 19 October 2023 (UTC)

My bot can restore these mostly. If that is what is wanted. -- GreenC 14:36, 19 October 2023 (UTC)

What would that look like? Would the bot add a deadlink/attempted fix, as suggested by LCU ActivelyDisinterested below. I also support stopping these mass removals until a consensus has been reached on whether these edits are within policy/guidelines and are indeed productive edits that benefit the encyclopedia. Isaidnoway (talk) 14:51, 19 October 2023 (UTC) 🦇

Honestly I'm lost as to what this thread has turned into. I posted concerning |subscription= and |via= which are still actively being deleted by the user. As for the dead links, as far as I know, the user is no longer removing those, that issue is settled? I can restore, I mean restore |subscription= and |via=. What is your opinion about the removal of |subscription= and |via=? -- GreenC 18:42, 19 October 2023 (UTC)

If those two specific parameters are not harming anything, they shouldn't be removed. And I don't see how WP:DEADLINK (cited above) applies here, as the removal of those parameters has nothing to do with 'repairing a dead link'. Isaidnoway (talk) 23:04, 21 October 2023 (UTC)

The "WP:5C's" of copy-editing say articles should be "clear, correct, concise, comprehensible, and consistent". When we put in (or keep) notations about HighBeam that are incorrect, we violate correctness, conciseness, and comprehensibleness. E.g., if the reader sees "(subscription required)" they are told the connected website will ask them to "'Please sign-up' if you want to look at the material we provide." The {{via}} message is telling the reader that the link to the cited source does not link directly to the source. (This implies that the "via" link will be an accurate duplication of the original source.) But the HighBeam-urls we see archive-urls. And those archive-urls are usually mere title/author/date/publisher notes. They do not contain the substance of the source. The "via" parameter in citation should be the publisher that is providing the source – the actual article substance – to the reader. It is not a parameter that says "the link here is an archive of the defunct service that once upon a time provided an archive of the source." Including "via" is not helpful to the reader who want to verify what a source contains. – S. Rich (talk) 23:57, 21 October 2023 (UTC)

• My original issue raised on Srich32977's talk page was leaving empty cite web templates, creating cite errors, but this solution seen here doesn't help either. I don't know what the answer is, but leaving them intact at least lets us know that the content was (probably) verifiable at some point per WP:KDL - which also says - Do not delete a citation just because it has been tagged with {{dead link}} for a long time. Just wanted to add, I don't think these citations are "clutter". Isaidnoway (talk) 06:28, 19 October 2023 (UTC) ⋆｡°✩🎃✩°｡⋆

  I have a feeling that deadlink is duplicated here[1], another reason deadlinks should be handled individually.

  I'd agree with the removal of the archive links if archive page is broken, but that's a reason to use deadlink with fix-attempted. -- LCU ActivelyDisinterested ∆transmissions∆ °co-ords° 10:35, 19 October 2023 (UTC)

Definitely leave in the |via= field, agnostic on the rest.  Mr.choppers | ✎  14:02, 19 October 2023 (UTC)

Good find! I also found it at ProQuest 340013732, and since it didn't include all the names of the founders listed in the article, I found those additional names through Gale A84644401 and Newspapers.com, which I added to the article. I also agree the deadlinks should be handled individually, with a chance to look for replacement refs. But if thousands have already been removed, I don't know what the solution would be then. Isaidnoway (talk) 14:30, 19 October 2023 (UTC) 👻

The mass removal of deadlinks should stop, as any mass editing should if requested. Also the use of the {{dead links}} is much more suitable, and gives editors a chance to find other sources.

I would be for restoring this, and instead removing the archive-url and adding {{dead link}} with |fix-attempted=yes set. -- LCU ActivelyDisinterested ∆transmissions∆ °co-ords° 14:42, 19 October 2023 (UTC)

I have been watching the discussions and seen the removal on many of the articles but have have held off from commenting but I do believe that listing HighBeam in the via parameter is still beneficial since the references were accessed via HighBeam, and that doesn't change just because HighBeam is defunct. It seems not too dissimilar to a link being dead; even if the information can't necessarily be accessed directly, knowing where it was or how it was obtained is still beneficial information. - Aoidh (talk) 02:07, 23 October 2023 (UTC)

User:Aoidh, thank you for participating it is helpful to gain consensus one way or another. This question would have far-reaching precedent since it could lead to the removal of all via when a link is dead. Do you have an opinion about the removal of subscription when a link is dead? -- GreenC 02:29, 23 October 2023 (UTC)

My opinion was mostly about the via parameter, but concerning the subscription parameter I don't see how removing it when the link is dead would be helpful, since it provides crucial context for how the source was originally obtained and would help in knowing where to look (and not to look) when trying to find a copy of the source or an alternative citation, for example. - Aoidh (talk) 08:23, 23 October 2023 (UTC)

Procedure when author differs between live and archived url

In adding a reference for The Woman in Black (play), I noticed that the author as of today is "Chris Raven," while the author is "Sarah James" in the version archived on the date of publication. For now, I've just cited the former, but I couldn't find any discussions in the archives for whether I should also note the prior (ostensibly original) author.

– spida-tarbell ❀ (talk) (contribs) 19:55, 19 October 2023 (UTC)

Given that the website reattributed authorship of this press release, it's likely that they see the "author" as the "contact person" moreso than anything else. Maybe Chris is the new social media officer or something. I'd personally probably attribute Sarah with the authorship, or jointly attribute authorship, or list Sarah as author and Chris as editor, but I can't pretend to speak from a policy basis. Folly Mox (talk) 20:41, 21 October 2023 (UTC)

That's a reasonable assessment. If what you say is accurate, and they change the contact person based on whoever holds the PR position, it could keep changing in the future. This presents a problem for Wikipedia. But we have a solution. This phenomenon is known in the computer/library science world as content drift, the source keeps changing content slightly over time. The parameter for this is |url-status=deviated (we should rename it "drifted" to be more clear, but that is OT). Use the original author name Sarah James, while setting to "deviated" because the live link is different from the archived link (see Template:Cite_web#URL). A wikicomment outside the boundary of the template explaining why it's deviated would help. -- GreenC 22:52, 22 October 2023 (UTC)

Citing reviews with cite journal

Titles for reviews, at least in classics, are usually pro forma repetitions of the publication information. For example, this JRS review of Morstein-Marx's Mass oratory (2004). If you create a citation without the title, CS1 will give a warning:

Mouritsen, H (2005). Journal of Roman Studies. 95: 251–52. doi:10.1017/S007543580000263X https://www.cambridge.org/core/journals/journal-of-roman-studies/article/abs/r-morsteinmarx-mass-oratory-and-political-power-in-the-late-roman-republic-cambridge-cambridge-university-press-2004-pp-xiv-313-isbn-05218232777-5000/A285ADA462DCE712C47B836720BEA377. {{cite journal}}: Missing or empty |title= (help)

Somewhat shortened citations for articles are common. Eg in Erich S Gruen's Last generation of the Roman republic (1995):

Gruen 1995 p 197 n 134, citing Syme, Historia, 4 (1955): 63.

Gruen 1995 p 190 n 100, citing Gabba, Athenaeum, 29 (1951): 262–70.

Is it possible to suppress the missing title warning and generate mark-up (for the 2005 review above) like so?

Mouritsen, H (2005). Journal of Roman Studies. 95: 251–52. doi:10.1017/S007543580000263X.

I am aware of the template {{list journal}} but it seems to have no parameters for a specific article or page range. Ifly6 (talk) 15:47, 23 October 2023 (UTC)

|title=none

—Trappist the monk (talk) 15:54, 23 October 2023 (UTC)

If I pass a URL that would still raise a missing or empty title error: Forsythe, Gary (1994). Bryn Mawr Classical Review https://bmcr.brynmawr.edu/1994/1994.02.11/. {{cite journal}}: |url= missing title (help)CS1 maint: untitled periodical (link). Ifly6 (talk) 15:57, 23 October 2023 (UTC)

I'll just put the publication information of the book if the book review section is untitled, or use "Book Reviews" or "Works Reviewed" or whatever the journal has for the section, and sometimes add |type=book review if it's still somehow unclear. I just did a bunch of these at Charles Hucker and have more waiting at Talk:Kirsten Seaver if you want to see my (potentially suboptimal) method. Folly Mox (talk) 16:10, 23 October 2023 (UTC)

At Erich S Gruen I ended up just placing the URL at the page numbers as above and leaving everything else otherwise unlinked. Thanks, Trappist, for telling me about |title=none. Ifly6 (talk) 19:33, 23 October 2023 (UTC)

The book templates should always include the author so that the metadata are complete. You can hide the author names from the rendering with |author-mask=2 or |display-authors=0:

{{cite book |last=Gruen |first=Erich S |author-mask=2 |title=Roman politics and the criminal courts, 149–78 BC |publisher=Harvard University Press |year=1968 |isbn=978-0-674-28421-0 |location=Cambridge, MA |doi=10.4159/harvard.9780674284210}}

—— (1968). Roman politics and the criminal courts, 149–78 BC. Cambridge, MA: Harvard University Press. doi:10.4159/harvard.9780674284210. ISBN 978-0-674-28421-0.

{{cite book |last=Gruen |first=Erich S |display-authors=0 |title=Roman politics and the criminal courts, 149–78 BC |publisher=Harvard University Press |year=1968 |isbn=978-0-674-28421-0 |location=Cambridge, MA |doi=10.4159/harvard.9780674284210}}

Roman politics and the criminal courts, 149–78 BC. Cambridge, MA: Harvard University Press. 1968. doi:10.4159/harvard.9780674284210. ISBN 978-0-674-28421-0.

—Trappist the monk (talk) 19:51, 23 October 2023 (UTC)

That's a cool parameter. Thanks, I didn't know about it. Ifly6 (talk) 20:18, 23 October 2023 (UTC)

You get the error because there is no title for the template to link. In {{cite journal}}, |url= requires |title=.

—Trappist the monk (talk) 16:21, 23 October 2023 (UTC)

Yes. The way to get no title in a cite journal template is to use |title=none – I use this all the time for book reviews with doi, jstor, or hdl links. But when you give the template a url link, it needs something to link the url to. In this case the error message is for a good reason, that there is no way to incorporate a title-less url link into our current cite journal format, rather than for the more abstract (and false) reason that title-less journal references don't exist. I usually just use |title=Review. —David Eppstein (talk) 20:08, 23 October 2023 (UTC)

Could the link be placed at the journal name automatically? Eg Mouritsen, H (2005). Journal of Roman Studies. 95: 251–52. doi:10.1017/S007543580000263X. Ifly6 (talk) 20:20, 23 October 2023 (UTC)

Bad idea. The journal name should only be linked to its article, Journal of Roman Studies. -- Michael Bednarek (talk) 02:30, 24 October 2023 (UTC)

Hmm, lacking a title, I guess I'll just keep the link out at the page then. (Or for BMCR at the |at= parameter). Ifly6 (talk) 02:35, 24 October 2023 (UTC)

We sometimes put links on page numbers but I think that would be too inconspicuous. —David Eppstein (talk) 05:24, 24 October 2023 (UTC)

Titles that end with a full stop (period)

I notice that titles that end with a full stop are treated in an unusual way. {{cite news|title=He Killed The Man from UNCLE.}} produces the same output as {{cite news|title=He Killed The Man from UNCLE}}, i.e., it produces "He Killed The Man from UNCLE". (The terminating full stop is removed from the quote.) But {{cite news|title=He Killed The Man from U.N.C.L.E.}} produces a different output than {{cite news|title=He Killed The Man from U.N.C.L.E}}; i.e., it produces "He Killed The Man from U.N.C.L.E.". (In this case, the terminating full stop is not removed.)

If I want a full stop to not be removed, what should I do? I notice that {{cite news|title=He Killed The Man from UNCLE..}} seems to work, producing "He Killed The Man from UNCLE.". (with one dot inside the quote marks of the output and the other one removed, but that seems semantically incorrect.

The case with three dots seems to get different treatment from the one with two. If there are three dots, as in {{cite news|title=Once upon a time...}}, the last one doesn't get removed.

Should the instructions say something about this? For example, the description of the |title= parameter could say that in most cases, if the title ends with a full stop, the punctuation mark will be removed.

—⁠ ⁠BarrelProof (talk) 21:04, 25 October 2023 (UTC)

@BarrelProof: Hi there! Note that {{cite news|title=((He Killed The Man from UNCLE.))}} generates "He Killed The Man from UNCLE.". per Help:Citation Style 1#Accept-this-as-written markup. Happy editing!

I see. Thanks! I had searched for mentions of "full stop" and "period", but that section uses different terminology – it calls them "dots", so it escaped my search. —⁠ ⁠BarrelProof (talk) 22:16, 25 October 2023 (UTC)

Request to expand checks for bad URLs

Could you please consider expanding the checks for bad URLs to also catch hhttp and hhttps? I stumbled across one of these today, and was surprised it didn't have an error message.

{{cite web |title=Title |url=http://foobar.com |website=Good example}}

"Title". Good example.

{{cite web |title=Title |url=http//foobar.com |website=Error displays}}

[http//foobar.com "Title"]. Error displays. {{cite web}}: Check |url= value (help)

{{cite web |title=Title |url=hhttp://foobar.com |website=No error displayed}}

[hhttp://foobar.com "Title"]. No error displayed.

If you were to do add these so they are included in Category:CS1 errors: URL, I'll periodically run my bot to fix them. Thanks! GoingBatty (talk) 00:17, 23 September 2023 (UTC)

60 uses. Izno (talk) 16:57, 25 September 2023 (UTC)

Also this:

• insource:"%7" insource:/%7[Cc](%20)*(url|archive|title|access|work|website|last|first|author|date|quote|publisher|isbn|editor|agency|location|page|language|trans|type|format|doi|jstor|)/] (697)

Not all are errors, most are. This is for Cite Web. There are still some arguments missing, I didn't want to overload regex search. -- GreenC 18:33, 25 September 2023 (UTC)

Oh no! What process causes | to be escaped as %7c? Folly Mox (talk) 06:12, 28 September 2023 (UTC)

Automated editing that doesn't parse things correctly which can be a GIGO situation [input], tool bug [output], or some series of both. If someone wanted to try and determine a prolific culprit it would be helpful, assuming they exist and it hasn't been fixed yet. But I think this sort of thing is par for the course and new ones will keep showing up indefinitely. -- GreenC 07:36, 28 September 2023 (UTC)

Well, it seems like a common-ish and easy to detect case. Same with the copy-paste errors "ttps://" and "ttp://". Maybe, though, it would make more sense to have a list of URL prefix strings that are legit, and flag anything that doesn't match, instead of targeting specific things that match a list of non-valids. That is, go with a whitelist instead of a blacklist.  — SMcCandlish ☏ ¢ 😼  08:39, 28 October 2023 (UTC)

Abuse of the "last"/"author" parameter for last-first name pairs

|last= and its alias |author= are not for full lastname-firstname[s] sets. They are the last name (surname, family name), or can be used for an organizational editor (e.g. a committee), or a mononymic author (like Madonna or James I). Putting full "First Last" or "Last, First" human name sets in there is directly polluting (blatantly lying about) the nature of the data in the parameter, and undermines the whole point of providing COinS metadata in the first place. (In particular, we are emitting rft.aulast metadata for this parameter, which claims that the data in the parameter is the author's last name. When the author only has one name, being mononymic or an organizational entity, this is not misleading, but when it's somethinge like "Chen, Jaime C." it is a patent falsehood, for no defensible reason, and it harms WP:REUSE of our material as well as parsing, e.g. by bibliographic software, by our more technically/academically inclined readers.)

What we have now in Template:Citation Style documentation/author is:

author: this parameter is used to hold the complete name of a single author (first and last) or to hold the name of a corporate author. This parameter should never hold the names of more than one author.

I sensibly changed this to:

author: this parameter is used to hold the complete name of an organizational author (e.g. a committee). This parameter should never hold the names of more than one author. Use to hold first and last names of an individual author is deprecated.

But I got reverted by Nikkimaria. (Reglardless of the rest of this discussion, "corporate" should be changed, since this doesn't have anything to do with corporations in particular, and people keep mistaking this for an instruction to repeat the |publisher= as the |author=, or even put the company name in |author= instead of in |publisher=, both of which practices are obviously incorrect; I've had a to fix about a dozen instances of this stuff today alone).

I think this change (or functionally equivalent wording) should be put back in, because it actually reflects best practices, both in theory and in action. The parameters is this template are for rather specialized/specific purposes, and abusing them (out of, frankly, laziness about using multiple parameters properly) does harm to the data they emit, makes for confusing markup for editors, does nothing whatsoever to help readers, and is simply not how these templates in practice are used by the vast majority of our editors. For over a decade, I have been correcting such misuses of these template parameters for full human names. I've done this many thousands of instances (mostly very old ones dating from before the templates were so well-developed, and in some cases injected by tools that have since been re-coded to do better markup, though there is a small handful of editors who manually keep abusing the template parameters out of bad habit), and I've never been reverted on one these corrections, ever, even once. It's time that the documentation made better sense, and stopped including misguiding wording that results in a massive waste of editorial cleanup time.

I have faith that this can be accomplished, since we've made substantial progress already on the confusion between |publisher= and |work= (or its aliases like |website=, |newspaper=, |magazine=, etc.). Mike Novikoff and I tried to resolve that issue back in May of last year only to be reverted by Nikkimaria again, but the wording of the |publisher= entry at Template:Citation Style documentation/publisher today now does in fact address the issue very clearly, and I don't see anything at entries like |website= in Template:Citation Style documentation/web, or |work= at Template:Citation Style documentation/work, that any longer work against this clarity. If we can fix that problem, we can fix this one, too.
 — SMcCandlish ☏ ¢ 😼  01:30, 26 October 2023 (UTC)

I'm not doing that. If I'm fixing up citations with no author attributed at all, copypasting author names from dozens of websites over and over, of course I'm not going to take the wholly unnecessary step of editing each into |first= |last= format. There are probably five orders of magnitude of citations using |author= to hold the name of an author. Folly Mox (talk) 01:35, 26 October 2023 (UTC)

When you're copy-pasting author names, I have found it's much easier to let Parsoid or another of our current tools to have a first go at things. They're not perfect, but they can reduce the tediousness sometimes of getting good first/last pairs. Izno (talk) 03:21, 28 October 2023 (UTC)

And how is it parameter abuse to use the |author= parameter to hold the name of an author? That's silly. Folly Mox (talk) 01:45, 26 October 2023 (UTC)

I agree that this should have been reverted. Your assertion at are not for full lastname-firstname[s] sets has for a long time been false. And, the text deprecated has a specific meaning in CS1 (that I think you have been educated on elsewhere?).

But I do think there is room to move this one liner more toward the actual status, which is that we very much prefer to use |first= and |last= for persons and that |author= is generally discouraged. I feel comfortable saying the former, so let's at least say that. I also agree that this should refer to organizational authors instead, and that an example is probably merited. Here is a shot:

author: this parameter is used to hold the complete name of a single author (first and last) or to hold the name of an organizational corporate author (e.g. a committee). For a person, you should prefer to use |last= and |first=. This parameter should never hold the names of more than one author.

I do not know how I feel about saying the parameter is discouraged. It has valid use for the organization case as you recognize, and it has valid use for gnomes who are working through categories like Category:CS1 maint: multiple names: authors list which from my perspective cannot be easily dealt with by saying "you must correct these to use first|last only". And lastly, I doubt discouragement is needed if we add the suggested alternative. There are many other trees to bark at than the effort it would take to eliminate all uses of commas in |author= (we could make up a category for that trivially and it would probably be half the wiki), though no doubt small-ly valuable to move a first name from the last name key in the metadata. Izno (talk) 08:58, 27 October 2023 (UTC)

Less snarkily, there are plenty of articles with referencing styles where authors are presented with their names in "first last" order rather than "last, first", and there's no way consensus could be reached to standardise every article to use the "last, first" order. Folly Mox (talk) 11:00, 27 October 2023 (UTC)

I don't think that particular case is one to support above and beyond "here's a parameter for a single author". We should state our preference for using the split parameters and leave it at that. Izno (talk) 19:42, 27 October 2023 (UTC)

Izno's wording is an improvement. I would prefer it even more as something like

author: this parameter is used to hold the complete name of a single organizational author (e.g. a committee). For a person, prefer |last= and |first=. This parameter should never hold the names of more than one author.

As for Folly Mox's "I'm not doing that": We don't need to shape our documentation and templating behavior around a single editor who bucks the flow and refuses to use |last= |first=. Nor do we need to care about some old-time WP:LOCALCONSENSUS at a particular article that somehow insisted on "First Last" name order. In both cases, they can just use untemplated citations or just stubbornly abuse template parameters, and someone will clean it up later in the first case, and consensus will change eventually in the latter case. The idea that some handful of editors deciding many years ago to use a name ordering format that doesn't work properly with our modern templating system means that it can never change is a misunderstanding of how WP:CONSENSUS operates. Consensus changes all the time when given a good reason to do so, and citations that emit proper bibliographic information about author names is a good reason (and there are several others). If we still wanted to enable randomly varying name order on an article-by-article basis, the way to do that would be to add a |name-order=FL parameter and value for First Last name ordering. But the number of articles that are using First Last order consistently and have a declared consensus to do so, and are actively maintained to keep this order, are a vanishingly small number. What is vastly more common is an article in which a few old citations are in that order and all the rest are not; WP:CITEVAR instructs us to normalize them to a single, consistent format. The one to choose is obviously the one that matches our current templating best practices with |last[N]= and |first[N]=. I do it routinely, and no one ever objects, because editors generally recognize the utility of consistent and metadata-rich citations (versus the rather-less-than-utility of picking a fight to retain some unhelpful citation style that was used in the article 13 years ago, which no one has since obeyed anyway when adding new cites that now dwarf those of the old format [i.e. the alleged consensus for First Last is not real], and which no one actually cares to retain).  — SMcCandlish ☏ ¢ 😼  01:12, 28 October 2023 (UTC)

Yes, this suggestion returns us to what you want to do, which is to remove the documentation that allows its use for a single person. That isn't going to get consensus for a whole variety of reasons already documented in this section (and touching on reasons documented in others on this page right now). That's why I suggested the "prefer" language while retaining the majority of the previous structure ("use for a person or for an organizational author; for a person, prefer first/last"), which I think does move the documentation closer to current consensus understanding of the parameters, for the benefits described related to use of first/last, namely style consistency and slightly better metadata output (instead of both first and last landing in the last key, the first name ends up in the first key). (NB, |authors= emits no metadata.) Izno (talk) 03:19, 28 October 2023 (UTC)

As I said, your version is an improvement, and I can live with it. In the long run (maybe years), I think it's ultimately going to reflect the narrow change I proposed. The tiny walled garden of regulars on this page do not represent site-wide consensus, which is reflected primarily in how our citations are used by the majority of experienced editors today. To the extent that a very small number of them continue to do unhelpful things like |author=McNab, Janet S. they are doing it primarily out of a combination of confusion induced by the current poor state of the documentation itself, laziness about using multiple parameters, and dependence on scripts and other tools that are obsolete and doing poor markup as its default or only behavior. There is no site-wide consensus at all that what they are doing is a best practice, or we would find |author=McNab, Janet S. everywhere and hardly any use of |last=McNab|first=Janet S. I really have no idea what is the source of the particular mania, when it comes to citations, for assuming that everything anyone ever wants to do, no matter how daft, is something that we must actively support. There was a lot of that going around in the camp at WT:CITE about a decade ago, but it has largely died out with the disappearance of several particular afficiodos of that strange mindset. And it is strange. We don't entertain it in any other way, and routinely merge away and delete redundant and unhelpful template code, normalize conflicting procedures to a single workflow, close inclarities and loopholes in guidance that were leading to repetitive strife, etc. As I've indicated in related comments over at WT:CITE, the sotto voce argument here, that the fact that our current template coding that makes use of CITEREF geekery to produce a particular uncommon output, dictates to us forever that that a redundant parameter will be kept and unhelpful use of it permitted until the end of time, is just tail-wagging-the-dog stuff. It is the job of these templates and CITEREF code to make our work easier and produce better and more useful output. It is absolutely not our job to bend over backwards indefinitely and inject confusing code with confusing and polluted output, just because the tools need further improvement to make them more practical. The ultimate solution is to fix the problem, not continue doing bletcherous and bagbiting things to work around the problem and avoid fixing it.  — SMcCandlish ☏ ¢ 😼  05:57, 28 October 2023 (UTC)

We don't have any sitewide consensus to enforce any particular citation style, or even what to title the back matter subheadings.

If people feel super strongly that authors always need to be presented in "last, first" order and are cleaning up after my cleaning up after Citoid, of course I'm not going to revert them, or even notice, since I don't watchlist those articles and only check back in on them if I have way more free time than I currently do.

No one reverts my pointless stylistic edits either, and I don't revert stylistic choices because it's lame and timewastey.

I'm fine with Izno's wording to prefer |last= |first=. I do follow best practices when I'm doing content creation work, but usually focus on incremental improvement when doing gnoming work. Folly Mox (talk) 08:15, 28 October 2023 (UTC)

This isn't substantively responsive to my point at all. But to reply anyway: What order the names are in is basically irrelevant to this discussion; if there was a strong desire (there isn't) to put author names in "First Last" order at a bunch of articles, e.g. because some widely acceptable citation style required it (there isn't one that does), then this template would long ago have supported a parameter switch to do that, without any effect on the |first=|last= data entry. But in reality, there is not demand for it at all. These parameters are separte for a reason and emit distinct metadata. When you do |last=Garcia, J. B. (or |author=Garcia, J. B. which resolves to the same thing because |author= is an alias of |last=), you are producing false and confusing metadata that claims the author's surname (not full name) is "Garcia, J. B." The reason this keeps happening is primarily because our poor documentation wrongly encourages people to do it (the other reasons being "I just can't be arsed to use two parameters" and "I just paste in what this broken old tool from 2009 generates, and I'm not going to use anything newer and more functional, just because").  — SMcCandlish ☏ ¢ 😼  08:35, 28 October 2023 (UTC)

It was intended as a general reply to your OP at the top of the thread moreso than the post ReplyTool indented it as replying to, but I think in this most recent reply of yours I'm not really finding anything I disagree with. Maybe there's an unexplored route to solution here where the CS1 templates are altered such that |authorn= no longer aliases to |lastn=, but instead generates an error when they're both included. (As an aside, APA does specify that authors after the first author are presented in "first last" name order, but that's not an argument for anything really, and can be fixed with |author2-mask= etc if people are concerned about APA style for some reason). Folly Mox (talk) 16:57, 28 October 2023 (UTC)

Trappist mentions above a COinS key called $rft.au, which I presume holds the full name of an author (examples at WP:COINS and other sites reinforce this presumption). Is there a reason that the CS templates' |author= parameter can't be remapped onto this key instead of aliasing |last= in mapping onto $rft.aulast? Then people could use the |author= parameter while still producing clean metadata, unless I'm misunderstanding something. Folly Mox (talk) 04:33, 29 October 2023 (UTC)

Already does that:

{{cite book |title=Title |author=Green, EB}}

'"`UNIQ--templatestyles-000000E3-QINU`"'<cite id="CITEREFGreen,_EB" class="citation book cs1">Green, EB. ''Title''.</cite><span title="ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Abook&rft.genre=book&rft.btitle=Title&rft.au=Green%2C+EB&rfr_id=info%3Asid%2Fen.wikipedia.org%3AHelp+talk%3ACitation+Style+1%2FArchive+90" class="Z3988"></span>

Green, EB. Title.

—Trappist the monk (talk) 12:13, 29 October 2023 (UTC)

Thanks, Trappist. I definitely must be misunderstanding something then, because it seems like the |author= parameter does produce correct metadata, which isn't the impression I came away with from reading SMcCandlish's concerns in this thread. Folly Mox (talk) 15:54, 29 October 2023 (UTC)

Just to cover that other condition (|last=):

{{cite book |title=Title |last=Green, EB}}

'"`UNIQ--templatestyles-000000E7-QINU`"'<cite id="CITEREFGreen,_EB" class="citation book cs1">Green, EB. ''Title''.</cite><span title="ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Abook&rft.genre=book&rft.btitle=Title&rft.au=Green%2C+EB&rfr_id=info%3Asid%2Fen.wikipedia.org%3AHelp+talk%3ACitation+Style+1%2FArchive+90" class="Z3988"></span>

Green, EB. Title.

The module won't use rft.aulast= and rft.aufirst= if there isn't a |first= or |first1=. rft.aulast= and rft.aufirst= are only used by the first author; all other |lastn= / |firstn= pairs are individually concatenated, <last><comma><space><first>, and assigned to individual rft.au= keys.

—Trappist the monk (talk) 16:15, 29 October 2023 (UTC)

Ok, we've got a few for this change, so I've made it. Izno (talk) 16:23, 28 October 2023 (UTC)

You might have changed it, but it can't be forced on the community with just a few for this change. The original documentation has a longstanding community consensus.👻 Isaidnoway (talk) 01:17, 29 October 2023 (UTC)

If you are here to say "no way" for sport, forgive me for failing to get the joke; I can be, at times, impervious to subtlety and humor. Taking your post 100% seriously though, I believe you are mistaken. I think if you were to modify any of the citations with the full name in the author parameter, to use separate |last= and |first= parameters, there would be no issue. I've done this before as cleanup, and nobody has complained. Rjjⁱⁱⁱ (talk) 02:22, 29 October 2023 (UTC)

What I was referring to is the instruction creep in the new documentation language based on a "few for this change", rather than a wider input from the community that actually reflects community consensus. Hope this clears up your confusion. ⋆｡°✩🎃✩°｡⋆ Isaidnoway (talk) 22:47, 29 October 2023 (UTC)

It is not instruction creep to state our preference in the documentation. Do you have an issue with the preference itself? You should discuss that if so. Izno (talk) 00:42, 30 October 2023 (UTC)

When you changed the language to prefer the use of |last= |first=, based on "a few for this change", there is now a stated preference there for |last= |first=, that wasn't previously there in the original language. That is indeed instruction creep, because of a stated preference. And since the change has already been implemented, what is left to discuss, the new guidance has already been decided by a "select few". Isaidnoway (talk) 04:48, 30 October 2023 (UTC)

When a change to a gudieline actually better reflects site-wide practice (as that one does), then the number of discussants really isn't relevant; it is necessarily an improvement anyway. The number of editors still running around doing |author=Smith, James B. is very small, and their continued impact on the formatting of our citaions is smaller still. I do a lot of cite cleanup, and this is decreasingly a type that I need to do (and it's almost always in material that was added many years ago, or was done by an anon or noob who has not read the template documentation and is doing other bad-idea things in the same cite).  — SMcCandlish ☏ ¢ 😼  05:28, 30 October 2023 (UTC)

You still do not appear to have stated whether you have an issue with the preference. Do you? Why, if so? I am asking these questions because those can help decide whether I was ultimately right to make this change (quickly). :) Izno (talk) 06:04, 30 October 2023 (UTC)

I would think after everything I've said here that my position on this could not be clearer (and probably no one wants to hear me repeat it in any detail). Why on earth would I be defending the documentation making it clear |first=Firstname|last=Lastname is preferable over doing |author=Firstname Lastname or |author=Lastname, Firstname if I didn't actually agree with that (especially when I'm the one who opened this thread about asking us to do this in first place)? Why are you asking such a strange question and acting as if I've somehow been hiding my position on the matter, when the heading of this thread says it all?  — SMcCandlish ☏ ¢ 😼  10:29, 30 October 2023 (UTC)

@SMcCandlish, my indentation clearly indicates a response to Isaidnoway. Izno (talk) 17:35, 30 October 2023 (UTC)

Derp. I'll have to smoke less crack.  — SMcCandlish ☏ ¢ 😼  02:58, 31 October 2023 (UTC)

I have an issue with the process, since this instruction creep was implemented on the basis of a "select few". But, if an issue does ever arise over the "stated preference", I can point to this discussion for the changes made being based on a "select few". As Molly Fox points out - because it seems like the |author= parameter does produce correct metadata, which isn't the impression I came away with from reading SMcCandlish's concerns in this thread. Isaidnoway (talk) 07:42, 30 October 2023 (UTC)

The output of something like |author=Maria Garcia or |author=Garcia, Maria has gotten to be less poor than I thought (and mea culpa for not checking in rendered browser source first to see what it's doing today), but it is still inferior to that of |last=Garcia|first=Maria. The first pair of cases treat the entire name as if it's a mononym, which it is not: rft.au=Maria+Garcia or rft.au=Garcia%2C+Maria (%2C is the comma); the latter case properly separates the two name parts: rft.aulast=Garcia&rft.aufirst=Maria. They are not equivalent output. And the |author=Garcia, Maria case (rft.au=Garcia%2C+Maria) is worst of all, for wrongly stating that the comma is part of the name string, when it is a separator between discrete pieces of metadata; this is a separation of content and presentation failure, and does in fact amount to polluted/invalid/false/counterfactual/whatever-critical-label-you-prefer metadata, which has been my main concern all along. So, as far as I'm concerned we should clarify further that if you insist on using |author= for a full human name for some reason (a valid one might be a full name that is not a first-last pair, like an Icelandic or Mongolian patronymic) that it is never for "Lastname, Firstname" patterns.  — SMcCandlish ☏ ¢ 😼  10:29, 30 October 2023 (UTC)

@Isaidnoway, you should remember that we aren't a bureaucracy: if you can't find anything wrong with the substantive change, your words then aren't going to mean a lot. If you don't like it, revert it, but expect that you will need to discuss it as well. Which you don't seem to want to do for whatever reason, so it will likely be reinstated over your non-actual-objection. Izno (talk) 17:38, 30 October 2023 (UTC)

The doc still says - this parameter [author] is used to hold the the complete name (first and last) of a single person, so apparently it is still an acceptable use of the parameter. I will remember that the instruction creep was a result of a select few. Have a safe and Happy Halloween my friend. ✦•┈๑⋅⋯ 👻 ⋯⋅๑┈•✦ Isaidnoway (talk) 22:29, 30 October 2023 (UTC)

Isaidnoway: While you are remembering things, it may be useful to remember that this page, along with the documentation pages, are watched by many editors who will quickly revert changes that are unreasonable or to which they object and know that others will object to. You would do well to remember that such a revert has not happened in this case. Silent consensus is a real thing. – Jonesey95 (talk) 23:27, 30 October 2023 (UTC)

What are you talking about? A revert did quickly happen to changes that were unreasonable and were objected to. That's how this whole discussion got started in the first place. And I never explicitly stated or even implied that I was going to revert anything. So your comment seems a little odd, and off base, to say the least. Anyway, have a safe and Happy Halloween. ⋆｡°✩🎃✩°｡⋆ Isaidnoway (talk) 23:47, 30 October 2023 (UTC)

History of author documentation at Help:Citation Style 1:

• 11 October 2011 – first version; prefers |lastn= and |firstn=; |authorn= is 'generally discouraged' (with exceptions);
• 12 October 2011 – first mention of using |author= for corporate authors
• 13 October 2011 – |authorn= no longer 'generally discouraged'
• 16 December 2011 – expanded discussion of |author= for organizational authors
• 16 October 2013 – copy editing; heading name change; the discussion mentioned in the edit summary is now archived
• 28 November 2014 – use of |author= for some name styles removed; edit summary says per Talk, perhaps that discussion is Help talk:Citation Style 1/Archive 6 § COinS: surname? first?
• 18 June 2016 – note about one author name per |authorn= parameter

And since I'm poking around in histories, here is the history of {{Citation Style documentation/author}}:

• 12 January 2012 – first version; no mention of |author=; includes recommendation to use |last= for Asian or corporate names
• 12 January 2012 – |author= mentioned as an alias
• 28 November 2014 – recommendation to use |last= for Asian names removed
• 18 June 2016 – advice for using both individual and corporate names
• 18 June 2016 – |author= gets its own definition
• 28 October 2023 – |lastn= and |firstn= explicitly preferred over |authorn=

From the above histories I take it that the preference for |lastn= and |firstn= is nothing new and that the preference has existed for a rather long time.

—Trappist the monk (talk) 15:45, 30 October 2023 (UTC)

Thought I'd mention Chinese names here. Chinese name order is usually Surname first, followed by 2 personal names - eg the (fictional) Fu Ling Yu would be a a girl born to the Fu family. The fun comes when she is listed in Western sources. She might be listed in her natural order as "Fu Ling Yu" or more helpfully as "Fu Ling-Yu" (the hyphen is nearly always between the personal parts of the name, leaving the surname separate). Or it might be re-arranged as "Fu, Ling Yu", "Ling Yu Fu" or "Ling-Yu Fu". Sometimes a helpful sole mis-translates "Ling Yu Fu" a second time into "Yu Fu Ling". Which is a long-winded way to say that sometimes we do not know which part is the surname. In which case we cannot use |first= and |last= but have to fall back on |author=. Although I vastly prefer using |first= and |last= when they are known. There are probably other languages with similar issues. If I saw a name in an Arabic source I would have little confidence in choosing which is their surname.  Stepho  talk  05:04, 29 October 2023 (UTC)

If you don't know and can't find out which is the family name, then |author=Fu Ling Yu would be reasonable, just as it is reasonable for |author=Pliny the Elder. I don't think anyone's arguing to get rid of |author=. Instances where we just don't have a way of knowing are actually pretty rare. If it is already known or easily find-out-able by Googling for the author, then |last=Fu|. Same as any journal publisher would do. It is not up to us (or, from journal editors' perspective, them) to try to solve the cultural name-order preferences matter that some people somewhere might care about while others would not. It's sufficient for our citation needs that a reader understand that |last=Fu is the family name; the same author in different publications (or even different journal databases listing the exact same publication) might be rendered |last=Fu|first=L. Y. or awful Vancouver style |vauthors=Fu LY, or in the confusing style someone else mentioned where only the first author is given surname-first, then something like "Smith, C. B.; L. Y. Fu; H. D. Jones". And we don't really have any control over that, or need to care about it. Nor about the fact that the same author might be "Ling Yu Fu" or "Ling-yu Fu" on a book they published in English, but be their native-language characters for "Fu Ling Yu" on the Chinese edition of the same book. It just doesn't have any implications for how we cite a source at en.wikipedia.  — SMcCandlish ☏ ¢ 😼  06:55, 29 October 2023 (UTC)

There are plenty of people who can be authors of references and have names in formats where there is no surname at all. S. Muthukrishnan, for example, linked as an author in about a dozen articles. "Muthukrishnan" is the personal name (the one that would be a first name in western name order). "S." is not a surname (it is not a name that would be inherited through a family); it is the initial of his father's personal name. If you haven't seen Falsehoods Programmers Believe About Names, you should. —David Eppstein (talk) 06:50, 29 October 2023 (UTC)

Makes me wonder also if there's any conventional way to treat Icelandic patronymics. Do we just treat them as if they are surnames, or as if the entire name is a unit?  — SMcCandlish ☏ ¢ 😼  07:10, 29 October 2023 (UTC)

User:Stepho-wrs, I brought this up last month at Help talk:Citation Style 1/Archive 90#East Asian name order, where we discussed a few ideas. I do still typically use the |author= parameter when I'm citing works by Chinese authors, but if I find them in |last= |first=, I no longer recast them into |author= and have started using |author-mask= instead to fix the display of their names. Folly Mox (talk) 07:50, 29 October 2023 (UTC)

Also, if anyone is having trouble determining a Chinese author's name (like which bit is the surname), feel free to drop a {{csni}} near the citation. That places the article in Category:Articles needing Chinese script or text (12), which is pretty well-patrolled.

Another convention that is gaining popularity in Western language publications is setting the author's surname in Smallcaps, which we also have a template for, but is, like many conventions, discouraged on Wikipedia. Folly Mox (talk) 08:00, 29 October 2023 (UTC)

What is the evidence for "gaining popularity"? I used to have a collection of almost every style guide (for English) published in the last century, and saw no shift over time toward favoring that format. While I offloaded thousands of books (including most of the style guides) several years ago, I'm not aware of any established style guide that has switched to this format recently, only the same ones that have used it for a long time continuing to use it.  — SMcCandlish ☏ ¢ 😼  10:29, 30 October 2023 (UTC)

I have no evidence for setting East Asian surnames in Smallcaps gaining popularity other than I see it more often than I used to, including recently in a whole chapter of a book rather than just in the credits of a paper.

I haven't done any sort of empirical sampling, but in general the sort of sources I'm looking at these days are newer than the ones I was looking at decades ago in my academic days.

My communication here was pretty unclear, and appears to have been written in the middle of the night, but this is a practice I don't see frequently in citations: it's usually the credits at the head / cover sheet of a published article. I don't know of any citation style guide that recommends this, and my vague impression is that it's an authorial or publisher choice. Folly Mox (talk) 11:31, 30 October 2023 (UTC)

Ah, I have also anecdotally noticed a few publications do this with East Asian names in particular, because of potential "what is the family name?" ambiguity. But that is not a problem for us or our readers often. We typically know already one way or another, and can thus use |last=Li|first=Cheng Po (perhaps with a mask if you really want to mess around with it). Unless someone has gone out of their way to prevent the "Li, Chen Po" rendering, the reader will get that. Essentially the same with |vauthors=; they're going to get "Li CP" and not be confused. In order to use a smallcaps "convention" (I don't agree with applying that term to things that are not broadly conventionalized/standardized) we would already have to know what the family name is anyway. And the purpose of our citations is not "making authors, or some prescriptive sliver of our readers, especially pleased about how this name is rendered". It is only helping people find sources to verify our content, and "Li, Chen Po" does that just as well as "Li Chen Po". Another issue is that this smallcaps thing is a feature of a handful of citation styles, and not permitted in other citation styles, so we could never actually enforce it as a norm site-wide, even if we built it into CS1 (it's not required to use CS1, and editors can use, and at a particular article effectively enforce, any consistent citation style they choose. Which is completely daft and we never should have permitted it, but we're stuck with it at least for the forseeable future.)  — SMcCandlish ☏ ¢ 😼  12:02, 30 October 2023 (UTC)

Burmese names are another example; there is no separate surname to distinguish |first= from |last= per se, so the whole thing (sans any honorifics) should go in |author=. Umimmak (talk) 16:12, 29 October 2023 (UTC)

If we think |author=Full Name Here is the best way to treat anything like that, then I guess I'll also apply it to the Icelandic patronymic cases. However, I do see various journals treat them as if they're surnames, so I have some lingering doubts. Should we mimic what the journals are doing (people who over-apply "follow the sources" to every imaginable circumstance will probably like that idea), or aim for consistent treatment of a general class of names that aren't really first-last pairs?  — SMcCandlish ☏ ¢ 😼  10:29, 30 October 2023 (UTC)

CMoS specifically calls out how to cite and index Burmese names but doesn't seem to specifically mention Icelandic patronymics which is unfortunate. MLA says to treat patronymics as surnames for the purposes of indexing and citation in nonspecialist contexts (so on Wikipedia |last=Karlsson & |first=Gunnar), but if the reader is likely to be familiar with Icelandic names to not invert the name in the bibliography and use the given name for the purposes of short citations (on Wikipedia: |author=Gunnar Karlsson with |ref={{harvid|Gunnar|YYYY}}. It would be nice if Wikipedia:WikiProject Iceland/Style advice were more specific, but I think per WP:CITEVAR either option could be used on Wikipedia so long as it were consistent in a single article and ideally what a majority of sources in that field used for citing Icelandic names. For that matter it would be nice if Wikipedia:Naming conventions (Burmese) were explicit on citation as well, too.

I'm hesitant to trust random citations to always do the correct thing; one could imagine a journal incorrectly citing (English-language publications of) Katalin É. Kiss with |last=Kiss and |first=Katalin É. if they didn't know the specifics of her name but that doesn't mean Wikipedia should do that. Ideally see how the author cites themself in English-language works, or what is common across the most relevant discipline vs one source you happened to have off hand. Umimmak (talk) 23:11, 30 October 2023 (UTC)

Another generic title

Hello, can you add "Page cannot be found" as part of the title as a generic title. Currently, 17 instances. Keith D (talk) 17:07, 26 October 2023 (UTC)

This should be fixed at the source, by sanity checking in Citoid, but probably won't be. Folly Mox (talk) 04:43, 29 October 2023 (UTC)

Parameter first= with comma in it

I get error messages "cite book CS1 maint multiple names authors list (link)" for citations in which the first argument of the first parameter contains a comma. These are usually aristocrats, for example "|first=Winifred Anne Henrietta Christina Herbert Gardner, Baroness", "|first=Hervey Redmond Morres, Viscount", "|first=Philippe de Courcillon, marquis de", "|first=Patrick Theobald Tower Butler, Baron", "|first1=Desmond, Knight of Glin" etc. Is it incorrect to add such titles to better identify the person? Best regards Johannes Schade (talk) 15:26, 29 October 2023 (UTC)

The discussions that caused us to add that maintenance message are:

• Wikipedia:Village pump (technical)/Archive 206 § Can I get a list of cite web templates that probably have excessive numbers of authors in the fields?
• Help talk:Citation Style 1/Archive 88 § multiple names in |first=

—Trappist the monk (talk) 16:31, 29 October 2023 (UTC)

I noticed this error/warning message, too, and have been removing the titles and stuff to avoid it. That seems to be largely in keeping with MOS:HONORIFICS and such, but people are probably apt to have some disagreements about this. The solution is often to do something like |last=Graham|first=James Angus|author-link=James Angus Graham, 7th Duke of Montrose, but of course that only works for someone with an article (or at least a list entry to link to). If one really insisted on including the arguably extraneous titles, I guess try |first=Marquess James or |first=Dame Anne or whatever. But other editors might remove the titles later, as not literally/exactly part of the name. I've been writing in a topic area with a lot of sirs and other titles and just omitting them (completely in citations, and in the main prose when the title doesn't seem especially pertinent to why the person is mentioned, e.g. as a book author not as a socio-political figure). No one has seemed to care. But maybe they would if it were some "hot" topic of current British affairs or something.  — SMcCandlish ☏ ¢ 😼  17:25, 29 October 2023 (UTC)

User:Johannes Schade, you could always cut the title bits from the |first= parameter and use |author-mask= to display the author's full name and title in whatever format feels most appropriate to the context. Folly Mox (talk) 18:13, 29 October 2023 (UTC)

Yeah, that does work. I just tested {{cite book |last=Sinclair-Smythe |first=Janet Hortence |author-link=Janet Sinclair-Smythe, 2nd Baroness Wolverhampton |author-mask=J. H. Sinclair-Smythe, Baroness |title=Some Title Here |date=2023}} and it had the expected effect. I don't see a use-case for it though, except where there's a burning desire to precisely match the name-string on the book cover, maybe because there are several authors with the name base name, and our article on the subject is something rather different or the article doesn't exist. Even then, if there's a DOI, ISBN, or other identifier, or even a work title that leads to info on the correct source at the top of a Google/Bing/Yandex search, this seems unnecessary. Is it only to appease editors who really want to add titles onto authors?  — SMcCandlish ☏ ¢ 😼  18:39, 29 October 2023 (UTC)

The original use of author-mask was primarily for its numerical input rendering a dash for bibliographies and other lists of works. Support for non-numerical masks was added likely as part of the shift to Lua enabled more complicated processing of parameters.

I think the majority reason is that burning desire. Asian names and other "what's the family name" cases are another ("the comma in the middle makes me twitch when we already have a good last-first ordering"). Asian names including the kanji for romanized listings, or the romanization for kanji listings, is a third (|first=A |last=B |author-mask=A B (kanji)). There's the fourth HONORIFIC bent to it, "gotta give due credit to people who are kings and generals" (the latter of which are in this category a lot as well, though not often ranked so highly). There's a fifth "with" case, as in |author-mask=with so-and-so.

I think (3) is highly motivating to me to have the parameter accept non-numerical input, and if the others exist, that's not going to ruffle my feathers. FAC might not like some specific use in an article, but that's a matter for consensus. Izno (talk) 20:50, 29 October 2023 (UTC)

I brought this up here to show that there are cases when one would like to use a comma in the argument of the first-parameter. It is importanct in may circumstances to identify the author as precisely as possible. The maintenance message has not always been there and nobody has said that it is now forbidden to use commas in this parameter. I hope the maintennce message will be removed once it has served its purposes and is not needed any more. With thanks and best regards, Johannes Schade (talk) 20:20, 29 October 2023 (UTC)

Trappist the monk pointed to the motivating discussions of interest regarding the use of commas in this parameter and the categorization now attendant. Izno (talk) 20:51, 29 October 2023 (UTC)

If someone must have this in the displayed citation, Folly Mox's solution is appropriate. I think it's just more noise in the vast majority of cases. Izno (talk) 20:26, 29 October 2023 (UTC)

Re removing the titles and stuff to avoid it: User:SMcCandlish, you are cutting off your feet to fit the too-short bed. Don't do that. Fix the bed, or find a different bed provider if the current provider remains insistent on keeping it so rigid. —David Eppstein (talk) 21:02, 29 October 2023 (UTC)

Maybe that would be the case if I were a title-booster, but I'm not, and we have MOS:HONORIFICS for a reason. These titles are almost always extraneous clutter in a citation, and are just added to puff up the author and make them seem more important than other authors, or done out of robotic adherence to the nomenclature of a dying class system that ultimately has nothing to do with finding and verifying sources. I've slept on it, and I regret offering even the suggestions above for making this easier.  — SMcCandlish ☏ ¢ 😼  03:03, 30 October 2023 (UTC)

Is any of this even correct? Take for instance Herbert Coulstoun Gardner, who was the 1st Baron of Burghclere. The construct "Burghclere, Herbert Coulstoun Gardner, Baron" would just be wrong, that's not his name. The same would be true of "Baron Herbert Coulstoun Gardner Burghclere".

"Herbert Coulstoun Gardner, the Baron Burghclere" maybe, but it's very formal. -- LCU ActivelyDisinterested ∆transmissions∆ °co-ords° 21:26, 29 October 2023 (UTC)

And just doesn't seem to relate to the purpose of a citation, which is identifying a source and its authorship well enough to enable verification of our claim(s) cited to that source.  — SMcCandlish ☏ ¢ 😼  03:03, 30 October 2023 (UTC)

Well if that's the purpose of a citation, what's the problem with using |author= to hold the full name of an author? Or using |authors= to list the authors? I'm not understanding how to hold in the one hand "our downstream metadata reusers require absolutely perfect information no matter the labour cost to Wikipedia editors" and in the other hand "making the author's credited name match up with what's printed in the published source isn't necessary as long as there's enough information to identify the source positively". Folly Mox (talk) 03:30, 30 October 2023 (UTC)

making the author's credited name match up with what's printed in the published source That is part of my point as well, if you look at the front matter of these works they'll say the author is "Lord Burghclere" or similar, never the name / title hybrids that are at issue. -- LCU ActivelyDisinterested ∆transmissions∆ °co-ords° 11:12, 30 October 2023 (UTC)

Not everyone was gung-ho about this metadata stuff to begin with, but if we're going to use it, it's important that it be accurate as to what it purports to be, parameter by parameter. They're severable concerns. There's a big difference between leaving something off, like a noble or other honorific title, and basically lying about the nature of the data contained in a particular parameter. I don't buy the idea that editors here care in the least about precisely mimicking the appearance of the author's name on the original published source. Otherwise we would immediately ban Vancouver citation style just for starters, and also prohibit otherwise reducing a full author name to initials (or expanding a notable author's name given on that paper/book as initials to a fuller name that we know is right because it's our article title about that person). And so on.  — SMcCandlish ☏ ¢ 😼  12:11, 30 October 2023 (UTC)

I just also want to add I've also had error messages for having |last=LAST |first=GIVEN, Jr./III/etc. and to avoid the error message I've simply removed the comma in |first= even though outside of Wikipedia this comma is de rigueur:

Strong, E. K., Jr., & Uhrbrock, R. S. (1923). Bibliography on job analysis. In L. Outhwaite (Series Ed.), Personnel Research Series: Vol. 1. Job analysis and the curriculum (pp. 140–146). doi:10.1037/10762-000

— APA

A suffix that is an essential part of the name—like Jr. or a roman numeral— appears after the given name, preceded by a comma.

• Rockefeller, John D., IV
• Rust, Arthur George, Jr.

— MLA

In an inverted name, however (as in an index; see 16.41), a comma is required before such an element, which comes last. [...]

• Doe, John, Sr.
• Deer, Jason, III

— CMoS

Umimmak (talk) 23:23, 30 October 2023 (UTC)

cs1|2 is not APA, is not MLS, is not CMoS. For generational suffixes, cs1|2 follows MOS:JR. Also, maintenance messages are not errors.

—Trappist the monk (talk) 23:35, 30 October 2023 (UTC)

Yes, though if a strong case were made to make an exception for "Surname, Givenname M. I., Jr." usage in citations (or other circumstances of surname-first listing), I can see the community probably going along with it. I suggested this myself back-when, but did not RfC it or anything. I think it would actually be a clearer formatting convention, especially since a few names (especially in French and some other languages) sometimes take multi-letter initials like "Th." If someone wanted to go that route, I would suggest making it a WP:VPPOL RfC, since MOS:JR's basic wording was decided there. This page here is probably too narrow a venue with too few watchers to achieve a "make an exception to a general guideline" consensus that would be respected.  — SMcCandlish ☏ ¢ 😼  08:48, 31 October 2023 (UTC)

Maximum PMID numerical value exceeded

Hello. It appears that the current upper limit for PMID numerical value of 37900000 has been exceeded as I tried to use 37902774 and it was not allowed. Thank you for increasing the MAX integer value for this field. User:Ceyockey (talk to me) 00:54, 31 October 2023 (UTC)