Help talk:Citation Style 1

Sub-titles, numeration, parts and |trans-series= request

Sub-titles for {{cite book| and accompanying numbering

I need several sub title parameters for {{cite book| because the template as it now exists is difficult to work with.

For example, if I'm citing the Corpus of Hieroglyphic Luwian Inscriptions:

• the actual series is Series in Indo-European Language and Culture,
  • while the title is Corpus of Hieroglyphic Luwian Inscriptions,
    • the 1st volume is Inscriptions of the Iron Age,
      • and its first part is Text Introduction, Karatepe, Karkamiš, Tell Ahmar, Maraş, Malatya, Commagene,
      • its second part is Amuq, Aleppo, Hama, Tabal, Assur Letters, Miscellaneous, Seals, Indices,
      • and its third part is Plates,
    • the 2nd volume is Karatepe-Aslantaş
      • the 2nd volume is sub-titled The Inscriptions: Facsimile Edition,
    • the 3rd volume is Inscriptions of the Hittite Empire and New Inscriptions of the Iron Age,
      • the 3rd volume is itself divided into a part III/1 and a part III/2.

Despite the recommendations I have received during my previous requests here, this is not working for me. I am having trouble adding proper titles in the template for several publications whose titles and sub-titles are similarly extensive.

Numeration

Along with this, there also needs to be accompanying series numeration, volume numeration, and parts numeration.

Parts for {{cite encyclopedia|

I would also need {{cite encyclopedia| to also have a numbering or part accompanying the titles.

For example, the entry for Que in the Reallexikon der Assyriologie und Vorderasiatischen Archäologie has a part A written by J.D. Hawkins and a part B written by D. Syrmington.

And several more sources I cite have similar entries divided into several parts, which are either labelled with a letter of the alphabet or a number.

I need a parameter to add this numeration.

Need for |trans-series

I also need a translation option for series names in languages other than English.

Which citation to use when citing a dictionary

Additionally, which citation template should I use when citing a dictionary?

For example, if I am citing the eDiAna Dictionary, which has sections for various languages and entries that are divided into several parts written by multiple authors, which citation template should I use? Antiquistik (talk) 15:37, 16 June 2024 (UTC)

In the first case, {{cite book |chapter=<Foobar> |title=Corpus of Hieroglyphic Luwian Inscriptions – Volume 1: Inscriptions of the Iron Age |series=Series in Indo-European Language and Culture |volume=<xxx> |page=<yyy> }} will give "<Foobar>". Corpus of Hieroglyphic Luwian Inscriptions – Volume 1: Inscriptions of the Iron Age. Series in Indo-European Language and Culture. Vol. <xxx>. p. <yyy>.

Replace <Foobar> with "Text Introduction", "Tell Ahmar", or whatever. Similar for Vol 2/Vol 3.

Headbomb {t · c · p · b} 15:46, 16 June 2024 (UTC)

Honestly, this is still very unwieldy. Can't additional sub-titles be added to the template instead? Antiquistik (talk) 16:54, 16 June 2024 (UTC)

There's no need for them. Put subtitles with titles. Put series into series. Put (series) volume into volume. Put chapter into chapter. Headbomb {t · c · p · b} 17:18, 16 June 2024 (UTC)

This unfortunately doesn't work, especially with sources that have multiple levels of sub-divisions. I really need an expansion of the template. Antiquistik (talk) 21:01, 19 June 2024 (UTC)

I've just shown you. Headbomb {t · c · p · b} 21:09, 19 June 2024 (UTC)

I understand that, and I appreciate the help. But this solution doesn't solve the issues that I am facing with using the template in its current state. Antiquistik (talk) 06:48, 23 June 2024 (UTC)

What is the issue you are facing then? Give me a specific case of what you want to cite, and I'll show you how to use the template. Headbomb {t · c · p · b} 20:16, 26 June 2024 (UTC)

(ec) I've seen bots change {{cite dictionary}} to {{cite encyclopedia}}, so I suppose that's the one to use for dictionaries. Agree that |trans-series= would be helpful; I come up against this periodically, and it feels weird to cram the translation into the same parameter after splitting it out for the previous two.

As to the |subtitle= idea, I do low-key agree that adding one could be helpful, but not for reasons of unwieldiness (any solution where the source is "Chapter" in Title: Named Volume, Part something is going to be unwieldy).

My experience has been that I'll sometimes want to use |title-link= for a source we have an article about, but multiple named volumes comprise the title, so I end up with Science and Civilization in China: vol. 4 Physics and Physical Technology, part 1: Physics, with the entire title linking the article Science and Civilization in China.

The other use case I would have for |subtitle= is for links to old books on Internet Archive or HathiTrust (or, decreasingly commonly, Project Gutenberg), where the title is something fashionably lengthy for the turn of the twentieth century like Travels and researches in Chaldæa and Susiana; with an account of excavations at Warka, the Erech of Nimrod, and Shúsh, Shushan the Palace of Esther, in 1849–52 or Bismya; or The lost city of Adab : a story of adventure, of exploration, and of excavation among the ruins of the oldest of the buried cities of Babylonia, and the whole dang thing gets bluelinked across three lines by the |url= parameter, because there's no way to cordon off the main part of the title for linking or put an external link inside the |title= parameter, and any other parameter I try to kludge the subtitle into doesn't concatenate next to the title but instead is separated by other information.

Anyway I don't really see a pressing need for this, but it would be nice for those sorts of situations. Folly Mox (talk) 17:23, 16 June 2024 (UTC)

PMID limit needs updating

Looks like PMIDs started ticking over 38900000 in the past couple of days. An article referencing 38900028 showed up in the tracking category and it is valid. Masterzora (talk) 03:59, 23 June 2024 (UTC)

generic name warning on "The Antisemitism Policy Trust"

"The Antisemitism Policy Trust" causes a generic name error (here). I marked it accept-this-as-written. Was that correct? I can't find any other author on the report. What is causing it to be flagged? AlmostReadytoFly (talk) 14:56, 26 June 2024 (UTC)

The error occurs because |author= includes the word policy. I would have written that template this way:

{{cite web |title= Conspiracy Theories: A Guide for Members of Parliament and Candidates |website=The Antisemitism Policy Trust |url= https://antisemitism.org.uk/wp-content/uploads/2024/05/Conspiracy-Theory-Guide.pdf |access-date= 11 June 2024}}

"Conspiracy Theories: A Guide for Members of Parliament and Candidates" (PDF). The Antisemitism Policy Trust. Retrieved 11 June 2024.

—Trappist the monk (talk) 15:16, 26 June 2024 (UTC)

Thanks. I failed to notice "policy" in the list in Help:CS1_errors#generic_name. AlmostReadytoFly (talk) 15:40, 26 June 2024 (UTC)

Add an "adblock removal" signal to "Subscription or registration required" at Template:Cite web

An increasing number of websites, particularly in the news and information space, require you to disable your adblocker to access their content. While this is not quite the same as a paywall or registration requirement, it is still an annoyance. I therefore propose that the "Subscription or registration required" parameter at Template:Cite web should have a variable added to indicate that the website requires adblock disabling for access. BD2412 T 18:02, 26 June 2024 (UTC)

Might it be better to make that a separate parameter, since a site requiring removing ad blockers might or might not, e.g., require registration. -- Shmuel (Seymour J.) Metz Username:Chatul (talk) 19:11, 26 June 2024 (UTC)

I have not experienced that, but then I again I never register for the sites that require registration, so I have not seen whether they also require adblock disabling. I would still think that this could be handled with a single parameter, with one additional variable for those that require registration and adblock disabling. BD2412 T 20:04, 26 June 2024 (UTC)

For large values of one. A site that doesn't work with ad blockers might be at any of four access levels, so the options are:

1. Status quo
2. Add a parameter for requires disabling ad blockers for each |foo-access= parameter
3. Define 4 new values for each |foo-access= parameter, e.g., |url-access=limited-noadblocker
4. Let each |foo-access= parameter take a list of two subparameters

I believe that the first two options are the most reasonable. -- Shmuel (Seymour J.) Metz Username:Chatul (talk) 10:17, 27 June 2024 (UTC)

Agreed, and I have to lean toward 1, because it's not WP's job to tell readers what they have to do to get access to something. This is just yet another form of "policy block" like region-specific blocking, and it's essentially an insoluble issue by us, because there are millions of websites and they change all the time. WP:NOT#DATABASE of random websites' policies. We're presently permitting notice of paywalled or registration-required links, but even this is dubiously useful. Any given paywalled academic site is effectively not paywalled for any academic or student whose institution provides institutional-subscription access, for example. And whether or not a site such as Internet Archive requires a free user registration to access something is ultimately immaterial, since the source is still accessible and one can (unless particularly clueless) use fake data to register anyway. Even if we continue to tolerate that minimal level of trying to tell the reader what to expect at innumerable random websites that may change their behavior at any moment (and may do it on a regional or other policy basis, too), we should not expand this worm-can further.  — SMcCandlish ☏ ¢ 😼  10:56, 28 June 2024 (UTC)

That's true across the web, and if you use an adblocker, while not illegal, you are changing how websites operate and violate the implicit free content paid by ads agreement. I'm against the inclusion of this parameter because custom scripts designed to circumvent those agreements should not be encouraged or supported. Headbomb {t · c · p · b} 20:11, 26 June 2024 (UTC)

@Headbomb: Adblockers generally do not prevent a website from including integrated textual advertising content, e.g., a sidebar or footer on a news website. They block intrusive forms of advertising like popups. There wouldn't be adblockers if there weren't popup ads. In any case, this is intended to caution our readers, many of whom do have adblockers that a specified externally linked website may be foreclosed to them. If a link had an appropriate caution, I as a reader would know not to waste my time following the link, knowing that I would not be able to access the content at the other end. I don't see how such a notice is materially different from one indicating that registration is required. BD2412 T 20:19, 26 June 2024 (UTC)

You choose to use an adblocker. The cause of the problem is the you using an adblocker to circumvent how the website is designed to be used. We shouldn't have to warn you about your own choices. Headbomb {t · c · p · b} 20:26, 26 June 2024 (UTC)

No, the cause of the problem is the failure to provide enough information to make an informed choice. Only if you chose to click on a link that you know prohibits ad blockers is it reasonable to claim that it's what you chose. -- Shmuel (Seymour J.) Metz Username:Chatul (talk) 10:17, 27 June 2024 (UTC)

Requiring you to disable adblockers is not merely an annoyance: it is a breach of your security perimeter, of which adblocking may be an important part. See e.g. the NSA and CIA use ad-blockers (2021) and FBI Recommends Ad Blockers (2022).

Conversely, use of adblockers is not a circumvention and should not be discouraged. It is an important security measure. —David Eppstein (talk) 20:47, 26 June 2024 (UTC)

I agree that ads are a common attack vector, cross-site scripting was a bad idea from the beginning. -- LCU ActivelyDisinterested «@» °∆t° 16:32, 27 June 2024 (UTC)

Yep.  — SMcCandlish ☏ ¢ 😼  10:51, 28 June 2024 (UTC)

Is this only for sites that currently need to have adblockers disabled? What happens if some adblockers work but other don't, or adblockers must be disabled now but later they work out a way to circumvent the detection? If this isn't just based on the technical issue then what of sites that disallow adblockers but make no technical measures to stop you from using them? -- LCU ActivelyDisinterested «@» °∆t° 07:52, 27 June 2024 (UTC)

@ActivelyDisinterested: See, e.g., this. I encounter this sort of thing all the time. I don't think anyone wants to follow a link that we provide as a source in an article, only to have a screen-blocking pop-up in their face telling them that they must disable their ad-blocker to continue. BD2412 T 15:03, 27 June 2024 (UTC)

You miss my point. The adblockers work to overcome detection, so if your adblocker no longer triggers that message what then? No site supported by ads wants you to use an adblocker, and Wikipedia shouldn't care one way or the other. -- LCU ActivelyDisinterested «@» °∆t° 16:31, 27 June 2024 (UTC)

If a site is functionally inaccessible because it requires that you remove defenses, then it is no better than a site that requires you to pay to access it. I'm just saying that we should have the option of letting our readers know that before they click the link that we are providing to them. Wikipedia should care about the experience we provide our readers. BD2412 T 16:51, 27 June 2024 (UTC)

The majority of Wikipedia's readers are not using it or care about it. For them there is no difficulty accessing it. -- LCU ActivelyDisinterested «@» °∆t° 19:51, 27 June 2024 (UTC)

What's the purpose of this? Potentially saving the vanishingly small percentage of people who actually verify sourced information intersecting the set of people who use adblockers the trivial time it takes to decide of whether to whitelist a news site's ads, disable their ad blocker, close the tab, or attempt to locate the tiny continue to article link in the "Looks like you're using an adblocker" modal?

I don't think that technical foibles are really necessary to include in citation information, but particularly not at the citation template level. If this is a real concern, follow the citation template with a transclusion of {{subscription or advertising}}.

This might also be the wrong area of concentration if we're concerned about clear signalling of access levels: as far as I'm aware, zero citation generation scripts contain functionality that automatically adds |url-access= subscription to any source, meaning that we have tens of thousands or hundreds of thousands of citations to subscription-only sources with no red padlock icons. Folly Mox (talk) 11:25, 27 June 2024 (UTC)

@Folly Mox: Do you have data on the "percentage of people who actually verify sourced information"? Many browsers now have an adblocker built in, particularly because adblockers prevent websites from downloading tracking software onto your computer. As for whether it is used, we have countless citation templates that are missing basic things like dates, author names, even titles of the work cited. We have functionalities throughout the encyclopedia that are little-used, but would improve the encyclopedia if well-used. We should still have those options. BD2412 T 15:13, 27 June 2024 (UTC)

I don't have data on what percentage of editors bother to verify sources. I feel like I remember hearing that the Foundation has stats on reader clickthrough to sources, and it's something like 1%, but I don't remember where I read that or when the data is from.

Point taken about unused functionality; have you thought about the suggestion to use {{subscription or advertising}} if no consensus develops to add |url-access=ads? Folly Mox (talk) 17:49, 27 June 2024 (UTC)

The template {{subscription or advertising}} renders as

(subscription or advertising required)

Until there is a decision to not delete it, ... -- Shmuel (Seymour J.) Metz Username:Chatul (talk) 20:11, 27 June 2024 (UTC)

Yeah, I forgot to check transclusions when I found that template and proposed it as an alternative solution, and another participant in this discussion nominated it for deletion in the time since my above comments. Honestly I don't feel particularly strongly about this thread either way. I was just trying to find a quick and simple method to address the concerns with existing templates. Folly Mox (talk) 11:02, 29 June 2024 (UTC)

Rather than worrying about this, or the other many variation (see for instance the section below), would it be worthwhile just change this to have one option 'restricted'. This covers subscription, adblocking, geoblocking, etc. -- LCU ActivelyDisinterested «@» °∆t° 19:54, 27 June 2024 (UTC)

I do think that the type of restriction may be relevant, and editors who are creating templates should have the flexibility to specify a type. Perhaps the parameter should provide an option to add a generic "restricted" signal, or a more specific signal of the editor's choosing. BD2412 T 21:24, 27 June 2024 (UTC)

We should not be trying to track this sort of information in citation templates. These are website "policy" issues that can change at any time for any reason based on the whim of a low-level engineer, a mid-level manager, or high-level politician. Policy can change every few months. There is no way to keep it accurate. Nor is it required to cite a source. There is an expectation readers are able to navigate around the web. -- GreenC 15:20, 1 July 2024 (UTC)

Before nomination of {{subscription or advertising}} for deletion, its two ns0 transclusions were altered to {{subscription required}}, as the websites cited no longer supported free reading with ads. It is a difficult thing to stay on track of updating. Folly Mox (talk) 16:12, 1 July 2024 (UTC)

Nonetheless, there are many external websites to which we link for which a reader traversing the link will receive an immovable popup requiring the lowering of their adblock defenses. BD2412 T 02:07, 7 July 2024 (UTC)

URL blocked for certain locations

I can't access the URL https://tvlistings.zap2it.com/overview.html?programSeriesId=SH01739244&aid=gapzap and marked it as dead, however another editor can apparently access it. Is there some kind of parameter that should be used here to note this? I was looking at {{Cite web}} but didn't find one. Gonnym (talk) 11:29, 27 June 2024 (UTC)

This is a perennial faq, no we do not manage policy blocks because they are changeable and relative to the viewer. For example, people in Romania can't access BBC links hosted in the UK, but only for 18 months, and this information is not made public anywhere. The possibilities are endless. The alternative? Check the archive link when you can't reach the main link. Of course this leads to the situation you describe of incorrectly marking a link dead, which is its own problem. Because even if the citation was tagged as a possible policy block, as you suggest, how would you know if it was policy block dead, or actual dead? It then leads to the problem of links not being marked dead when they should be. Probably in this case one would need to use a site like isitdownrightnow.com (assuming that site is not also policy blocked). It's a messy complex problem. -- GreenC 14:57, 27 June 2024 (UTC)

Minor bug: missing "."

Any CS1 citation templates ends with "." However, this does not happen if a) |quote= is used and its value does not end with "."; and b) no other parameter injects content into the rendered citation after the quotation content. Example:

• {{cite book |editor1-last=Jenny |editor1-first=M. |editor2-last=Sidwell |editor2-first=P. |chapter=Reconstructing Austroasiatic prehistory |date=2015 |title=Handbook of the Austroasiatic Languages |location=Leiden |publisher=Brill |page=1 |quote=Sagart (2011) and Bellwood (2013) favour the middle Yangzi |ref=none}}

renders as:

• Jenny, M.; Sidwell, P., eds. (2015). "Reconstructing Austroasiatic prehistory". Handbook of the Austroasiatic Languages. Leiden: Brill. p. 1. Sagart (2011) and Bellwood (2013) favour the middle Yangzi

 — SMcCandlish ☏ ¢ 😼  10:45, 28 June 2024 (UTC)

'Twas ever thus; probably to avoid multiple terminal punctuation characters: !., ?., etc. This functionality was established long before we had |postscript=none.

—Trappist the monk (talk) 13:47, 28 June 2024 (UTC)

Well, can something be done about it now in this Lua golden age?  — SMcCandlish ☏ ¢ 😼  00:08, 1 July 2024 (UTC)

Is this example supposed to be bibliographically accurate? (genuine question: autism) I'm not seeing chapter Reconstructing Austroasiatic prehistory at doi:10.1163/9789004283572, nor any chapter by that name across Brill. (Also I guess add a four dots sentence-terminal ellipsis to the quote as a workaround?) Folly Mox (talk) 14:34, 30 June 2024 (UTC)

I would think it should be. It's just a citation I ran across (I think I may have formatted a bare-text one into a template though; don't remember at this point). Please do feel free to repair it in any way it needs.  — SMcCandlish ☏ ¢ 😼  00:08, 1 July 2024 (UTC)

Veering entirely off topic here, but this page provides the answer: the chapter was not included in the published book, and so the four references to this source are all citing an unpublished manuscript. Folly Mox (talk) 08:30, 1 July 2024 (UTC)

I'm fixing these, and I'll stop derailing this thread after this post, but noting for funsies that the full sentence in the original source reads "Sagart (2011) and Bellwood (2013) favour the middle Yangzi, although there is no direct linguistic evidence for this, and the expansion of the [language] phylum in its present form would have to begin further south." So there may be some misrepresentation. Folly Mox (talk) 09:07, 1 July 2024 (UTC)

Good sleuthing. I guess this PDF could count as self-publication by a subject-matter expert, so still usable, as long as used properly. But there might be more, latter, better sourcing anyway.  — SMcCandlish ☏ ¢ 😼  00:42, 2 July 2024 (UTC)

year parameter

cs1|2 is somewhat schizophrenic when validating |year=. If I write:

{{cite book |title=Title |year=August 2023}} → Title. August 2023.{{cite book}}: CS1 maint: year (link)

no error even though 'August 2023' is not a 'year'. But, if I write:

{{cite book |title=Title |year=August 2023 |date=August 2023}} → Title. August 2023. {{cite book}}: Check date values in: |year= (help)CS1 maint: date and year (link) CS1 maint: year (link)

there is an error message because 'August 2023' is not a 'year'.

I propose to add a maintenance category to identify cs1|2 templates that have |year= where the assigned value is not YYY, YYYY, their circa forms, year-only ranges, and with or without CITEREF disambiguators. To make cs1|2 consistent in how it validates |year= I propose that we define |year= so that it may only hold one of the year formats named above. To accomplish that, we need to know where noncompliant |year= year parameters exist so that they may be repaired before a fix is made in Module:Citation/CS1/Date validation. The category is necessary because there are a so many non-cs1|2 templates that use |year= that Cirrus searching is woefully inadequate.

Yea or nay?

—Trappist the monk (talk) 15:53, 29 June 2024 (UTC) 13:24, 30 June 2024 (UTC) (modified)

How should a range, |year=2020–2022, be treated? -- Michael Bednarek (talk) 01:03, 30 June 2024 (UTC)

That would need to be allowed. Kanguole 11:55, 30 June 2024 (UTC)

Literalist as I have been accused of being, year to me means just that. Year range is a date so |date=2020–2022. Clearly there will be whining about this so I have modified the proposed definition of |year=.

—Trappist the monk (talk) 13:24, 30 June 2024 (UTC)

This matches a rationale for keeping both |date= and |year= explained at Help talk:Citation Style 1/Archive 31#Preference between year or date parameter in Cite Journal. Two editors mention using |year= to discourage future editors/bots from changing "YYYY" to something like "January YYYY" arbitrarily. Rjjⁱⁱⁱ (talk) 07:27, 30 June 2024 (UTC)

Support as maintenance category; oppose as error category. I don't think that a new CS1 error is being proposed here, but for clarity. Folly Mox (talk) 12:50, 30 June 2024 (UTC)

Initially a maintenance category. Once that category is cleared, it goes away, the fix is made to Module:Citation/CS1/Date validation, and thereafter, noncompliant |year= parameters become errors categorized in the already existing Category:CS1 errors: dates.

—Trappist the monk (talk) 13:24, 30 June 2024 (UTC)

Sounds fair. Folly Mox (talk) 14:13, 30 June 2024 (UTC)

I have tweaked the sandbox. The examples below are variations on this theme:

{{cite book/new |title=Title |year=900}}

|year=900 (ok):

Title. 900.

|year=c. 900 (ok):

Title. c. 900.

|year=c. 900a (ok):

Title. c. 900a.

|year=1900 (ok):

Title. 1900.

|year=900–1000 (ok):

Title. 900–1000.

|year=1951–52 (ok):

Title. 1951–52.

|year=August 1900 (not ok because month is not a year):

Title. August 1900.{{cite book}}: CS1 maint: year (link)

|year=Winter 1951–52 (not ok because season is not a year)::

Title. Winter 1951–52.{{cite book}}: CS1 maint: year (link)

|year=April–May 1900 (not ok because month range is not a year):

Title. April–May 1900.{{cite book}}: CS1 maint: year (link)

—Trappist the monk (talk) 16:28, 12 July 2024 (UTC)

I feel like "c." constructs should authomatically use {{circa}} to explain the notation, especially since

{{cite book/new |title=Title |year={{circa}} 900}}

Title. c. 900. {{cite book}}: Check date values in: |year= (help)CS1 maint: year (link)

produces an error. IceWelder [✉] 19:43, 12 July 2024 (UTC)

{{circa}} is bad for accessibility (mobile readers can't hover) in addition to polluting the metadata. c. 900 is pretty widely understood as an approximate date. Folly Mox (talk) 22:17, 12 July 2024 (UTC)

Volume in bold

"Volume values that are wholly digits, wholly uppercase Roman numerals, or fewer than five characters will appear in bold." Why is bold text used in these cases? - BobKilcoyne (talk) 05:47, 30 June 2024 (UTC)

That's true for e.g. {{cite journal}}, and not true for e.g. {{cite periodical}}, {{cite encyclopaedia}}, {{cite book}}.

I don't remember which published academic citation style guides recommended bolding the volume number, but it does a good job of setting it apart from the issue number and visually separating the citation. I feel like we had a discussion here about this just last year at least. I'll see if I can locate it in the archives for you. Folly Mox (talk) 13:03, 30 June 2024 (UTC)

Well, I wasn't able to locate the discussion I was remembering, but see for example:

• Help talk:Citation Style 1/Archive 50 § When |volume= is a Roman Numeral (2018)
• Help talk:Citation Style 1/Archive 62 § Bolding of the volume number (2020)
• Help talk:Citation Style 1/Archive 77 § Journal volume in Bold (2021)
• Help talk:Citation Style 1/Archive 79 § Still an issue with book volumes (2021)

Short answer I guess is that a lot of people talked it through over the years and it got consensus. Folly Mox (talk) 13:21, 30 June 2024 (UTC)

This seems like a reasonable style for citation output in the form "63 (7): 43–51", but a) we really have reason to do that at all, since WP:NOTPAPER and we have no reason to compress space; and b) "vol. 63, no. 7, pp. 43–53" (or "Vol." and "No." if one insists on capitalizing those things) is much clearer. It's also a format in which the boldfacing would serve no purpose. That is, the boldfacing only serves a disambiguating purpose for a format that we have no reason to use and a good reason not to.  — SMcCandlish ☏ ¢ 😼  00:48, 2 July 2024 (UTC)

This, exactly. I consistently use {{cite magazine}} even when citing traditional academic journals just to get away from the compressed format of {{cite journal}}. Imzadi 1979 → 04:18, 2 July 2024 (UTC)

I support switching to an explicit style. — UnladenSwallow (talk) 04:26, 13 July 2024 (UTC)

I oppose switching to a single style for both academic journals and popular periodicals. Having 30 (2) for journals and Vol. 30 no. 2 for magazines lets me tell at a glance what kind of publication I'm looking at in the reference list. Additionally, if we were to adopt a single style, I'd argue for the other direction, since bolded text is easier to distinguish amongst an information dense morass of a citation than a couple abbreviations prepending two of possibly a half dozen or more numeric strings. Folly Mox (talk) 14:57, 13 July 2024 (UTC)

If not using paper meant space was no longer an issue, we'd be using "volume", "number" and "pages" instead of "vol.", "no." and "pp.". Many screens are smaller than pages, and readers are still human, so the old ergonomic factors still apply. Kanguole 15:33, 13 July 2024 (UTC)

Google URL replacing Clyde Ships URL

Why has this template recently changed from correctly citing references from the Clyde Ships website, such as https://www.clydeships.co.uk/view.php?ref=10727 and is now translating them to show them as Google, such as https://www.google.com.hk/?ref=10727&gws_rd=ssl ? Johnragla (talk) 20:16, 30 June 2024 (UTC)

@Johnragla have you got an example in an article to look at? Nthep (talk) 20:21, 30 June 2024 (UTC)

No, because I've used manual citations, rather than automatic. An example of how the template used to work is ref 131 on the Northern Steamship Company page. Johnragla (talk) 20:33, 30 June 2024 (UTC)

@Johnragla You're using the visual editor rather than the source editor, correct? The behaviour you're seeing is a VisualEditor citation tool issue rather than an issue with any of the citation templates (I can replicate your issue if I use the visual editor). I've no idea where that tool is managed for en:WP. Anyone? Nthep (talk) 21:10, 30 June 2024 (UTC)

@Nthep Thank you, yes, correct. Wikipedia:VisualEditor says "Use Phabricator to report problems with Visual Editor." Do you want to do that, or shall I? Johnragla (talk) 21:22, 30 June 2024 (UTC)

I'll leave it to you. Nthep (talk) 07:56, 1 July 2024 (UTC)

cite magazine should support |agency

The cite magazine template should support the |agency parameter - for example this article https://www.golfdigest.com/story/golf-hope-ap should be cited as "Vegas Hangs On". Golf Digest. Associated Press. January 23, 2011. - but that throws an error. Some magazines do use news agencies so this should be a supported parameter. Tewapack (talk) 19:39, 2 July 2024 (UTC)

Tewapack, lateness of reply acknowledged, but how is this source not a case for {{cite news}}? Granted it's hosted by Golf Digest, but nothing on the page indicates it was published as a story in any issue of their periodical. It appears just to be a wire story that they reprinted online. I'd probably go with {{cite news |url= https://www.golfdigest.com/story/golf-hope-ap |title= Vegas Hangs On |work= Golf Digest | date= January 23, 2011 |agency= Associated Press}} Folly Mox (talk) 16:13, 13 July 2024 (UTC)

Adding a language code

Maybe I'm bad at reading comprehension, but I couldn't find how to add a new supported language code on the page Template:Citation Style documentation/language/doc. Can anyone help please? Amir E. Aharoni (talk) 12:14, 3 July 2024 (UTC)

What language tag? The lists of MediaWiki-supported language name/tags are automatically rendered by querying MediaWiki with the Scribunto language library function mw.language.fetchLanguageNames(lang, 'all'). To be displayed at Template:Citation Style documentation/language/doc MediaWiki must have support for the language name/tag.

—Trappist the monk (talk) 13:21, 3 July 2024 (UTC)

It's "wlx", which is not yet fully supported by MediaWiki. Maybe it will be supported in the future, but is it possible to add a custom language until then? Amir E. Aharoni (talk) 14:42, 7 July 2024 (UTC)

Limits

Hi, @Trappist the monk, it's me again, from Help talk:Citation Style 1/Archive 93#Limits. As I could see today by chance, my suggestion was excepted, and tabular data is a part of the code now, isn't it? IKhitron (talk) 23:45, 3 July 2024 (UTC)

Help talk:Citation Style 1/Archive 94 § module suite update 23–24 March 2024

—Trappist the monk (talk) 00:43, 4 July 2024 (UTC)

Doesn't play well with {{ill}}

I tried to use {{ill}} inside a {{cite journal}}, like this:

* {{cite journal |author={{ill|Reinhold Merkelbach|de|Reinhold Merkelbach}} |title=Zwei neue orphisch-dionysische Totenpässe |lang=de |journal=Zeitschrift für Papyrologie und Epigraphik |number=76 |year=1989 |pages=15–16 |url=https://www.jstor.org/stable/20187001}}

But that currently renders without any wikilink, like this:

• Reinhold Merkelbach (1989). "Zwei neue orphisch-dionysische Totenpässe". Zeitschrift für Papyrologie und Epigraphik (in German) (76): 15–16. {{cite journal}}: Check |author= value (help)CS1 maint: multiple names: authors list (link) CS1 maint: numeric names: authors list (link)

Is this bad interaction fixable by someone who knows about templates? --Quuxplusone (talk) 14:46, 6 July 2024 (UTC)

You'll want to use |author-link=:de:Reinhold Merkelbach, which has the desired effect. Folly Mox (talk) 14:49, 6 July 2024 (UTC)

Not fixable. When expanded, your example {{ill}} produces this:

[[Reinhold Merkelbach]]<span class="noprint" style="font-size:85%; font-style: normal; ">&nbsp;&#91;[[:de:Reinhold Merkelbach|de]]&#93;</span>

|author= wants to see only a single name (which may be wikilinked) but it certainly does not want to see the styling that {{ill}} adds.

One other way to wikilink the author's name is:

|author=[[:de:Reinhold Merkelbach|Reinhold Merkelbach]]

—Trappist the monk (talk) 15:06, 6 July 2024 (UTC)

Hm, that's too bad. I'm not a fan of unmarked wikilinks to non-English Wikipedias, so the suggestion to mark it up as Reinhold Merkelbach (via author-link or otherwise) is right out. I'll leave it as-is for now, but I hope this can be fixed someday. (For example, by finding whatever innards of the author field currently "want[] to see only a single name (which may be wikilinked)" and whitelisting {{ill}} as a valid possibility there, too.) --Quuxplusone (talk) 17:39, 6 July 2024 (UTC)

Not going to happen. cs1|2 annotates interwiki-linked author names so that readers can see that the interwiki-linked author name is at a non-English Wikipedia:

{{cite journal |author=[[:de:Reinhold Merkelbach|Reinhold Merkelbach]] |title=Zwei neue orphisch-dionysische Totenpässe |lang=de |journal=Zeitschrift für Papyrologie und Epigraphik |number=76 |year=1989 |pages=15–16 |url=https://www.jstor.org/stable/20187001}}

Reinhold Merkelbach [in German] (1989). "Zwei neue orphisch-dionysische Totenpässe". Zeitschrift für Papyrologie und Epigraphik (in German) (76): 15–16.

—Trappist the monk (talk) 17:54, 6 July 2024 (UTC)

I understand the reasons for the behaviour by the citation templates. However, this construction, [[:xx:Name]], will AFAIK forever prevent those links to be automatically converted to a local link if an article for that author gets written here. I wonder if this could be improved if the templates added a tracking category in those cases (in article space only) so that User:Cewbot's task #1, run by User:Kanashimi, has a way of locating this usage. -- Michael Bednarek (talk) 00:54, 7 July 2024 (UTC)

The bot can only handle interlanguage templates. Sorry it can't handle links to other language wikipedias, that would require quite a bit of extra work. Kanashimi (talk) 02:38, 7 July 2024 (UTC)

A tracking category for interwiki links in templated citation authors could still be useful for others to check. —David Eppstein (talk) 04:09, 7 July 2024 (UTC)

In the sandbox, interwiki-linked and interproject-linked names (author, editor, etc) will be categorized in one of two new properties categories. When both project and language are part of the link prefix, only the project will be categorized; this is in keeping with the rendered annotation. Using the example above, copy one (or both) of these to someplace in mainspace (necessary because prop cats are suppressed here), edit and preview (do not save):

{{cite journal/new |author=[[:de:Reinhold Merkelbach|Reinhold Merkelbach]] |title=Zwei neue orphisch-dionysische Totenpässe |lang=de |journal=Zeitschrift für Papyrologie und Epigraphik |number=76 |year=1989 |pages=15–16 |url=https://www.jstor.org/stable/20187001}}

{{cite journal/new |author=Reinhold Merkelbach |author-link=:d:Q972677 |title=Zwei neue orphisch-dionysische Totenpässe |lang=de |journal=Zeitschrift für Papyrologie und Epigraphik |number=76 |year=1989 |pages=15–16 |url=https://www.jstor.org/stable/20187001}}

At the bottom of the mainspace article you will see two red-linked categories:

Category:CS1 interwiki-linked names

Category:CS1 interproject-linked names

Articles in those categories will be sorted by the interwiki or interproject prefix.

Keep? Discard?

—Trappist the monk (talk) 17:41, 13 July 2024 (UTC)

A safer test is to copy the templates to the 'Input wikitext' box at Special:ExpandTemplates. Then click OK. Redlinked cats at the bottom of the page.

—Trappist the monk (talk) 17:49, 13 July 2024 (UTC)

"cs1|2 annotates interwiki-linked author names so that readers can see that the interwiki-linked author name is at a non-English Wikipedia" — Oh, that's awesome! I recommend tweaking the formatting just a little bit, so that instead of displaying as "Reinhold Merkelbach [in German]" it would display as "Reinhold Merkelbach [‌de‌]". (That's trivial, and would also address Michael Bednarek's defect report.) And then perhaps instead of making the user have to know to type [[:de:Thing|Thing]], permit them to type {{ill|Thing|de|Thing}}. That would have the effect of accomplishing what I'm looking for, as a very small modification of what you've already implemented. --Quuxplusone (talk) 17:41, 7 July 2024 (UTC)

The implementing discussion may explain to you why we did not do what you want us to do: Help talk:Citation Style 1/Archive 86 § author-link=interlanguage

—Trappist the monk (talk) 18:00, 7 July 2024 (UTC)

Keep? Discard? +1 for 'keep'. -- Michael Bednarek (talk) 03:00, 14 July 2024 (UTC)

I have to think that, for metadata purposes, it would be much cleaner to do this:

{{cite journal |last=Merkelbach |first=Reinhold |author-link=de:Reinhold Merkelbach |title=Zwei neue orphisch-dionysische Totenpässe |lang=de |journal=Zeitschrift für Papyrologie und Epigraphik |number=76 |date=1989 |pages=15–16 |url= https://www.jstor.org/stable/20187001}}

But for some reason this is mis-rendered, presumably due to some questionably desirable pre-filtering of the value of |author-link=:

Merkelbach, Reinhold (1989). "Zwei neue orphisch-dionysische Totenpässe". Zeitschrift für Papyrologie und Epigraphik (in German) (76): 15–16. {{cite journal}}: Check |author-link= value (help)

This:

{{cite journal |last=Merkelbach |first=Reinhold |author-mask=[[de:Reinhold Merkelbach|Merkelbach, Reinhold]] |title=Zwei neue orphisch-dionysische Totenpässe |lang=de |journal=Zeitschrift für Papyrologie und Epigraphik |number=76 |date=1989 |pages=15–16 |url= https://www.jstor.org/stable/20187001}}

also fails:

Merkelbach, Reinhold (1989). "Zwei neue orphisch-dionysische Totenpässe". Zeitschrift für Papyrologie und Epigraphik (in German) (76): 15–16. {{cite journal}}: Check |author-mask= value (help)

Ideally, I would think |author-link= would be the way to do this, and that it would detect the canonical other-project prefixes (mostly language codes), and do {{ILL}}-style stuff. Even if that's too much work, then just not barfing on a xx: language-code prefix would be good, even if does no extra things borrowed from {{ILL}} and just builds the link the way doing a bare [[de:Reinhold Merkelbach|Merkelbach, Reinhold]] works outside the template: Merkelbach, Reinhold.  — SMcCandlish ☏ ¢ 😼  11:21, 14 July 2024 (UTC)

You are mistook:

[[de:Reinhold Merkelbach|Merkelbach, Reinhold]] → Merkelbach, Reinhold

works in this namespace but does not work in mainspace because the above markup is for adding interwiki links to the languages menu. Prove it to yourself by editing a page that does not list Deutsch in the languages menu (USS Will Rogers is one such). Edit and paste the above wikitext into the article and preview. Deutsch will be listed in the languages menu but Merkelbach will not be found where you inserted the link. This is why your example templates show the Check author-link= value error message. We don't want to be indiscriminately adding links to the languages menu so Module:Citation/CS1 suppresses the malformed author link whether the template wikilinks the |author= parameter or uses the |author-link= parameter; contributor, editor, etc links similarly suppressed.

This is, by the way, discussed at the error message's help link.

—Trappist the monk (talk) 14:52, 14 July 2024 (UTC)

External link indicator

In a conversation at Template talk:Internet Archive#Registration required parameter it was pointed out that {{Cite book}} does not produce an external link indicator for a title URL if |url-access= is specified:

• Bloggs, Joe. Book of Bloggs.
• Bloggs, Joe. Book of Bloggs.

What's the rationale? -- Michael Bednarek (talk) 14:26, 7 July 2024 (UTC)

If there was any discussion to explicitly overwrite the external link icon, I don't recall it. You might find your answer somewhere in the archives. I think the first discussion in a rather long chain of discussions might be at Help talk:Citation Style 1/Archive 13 § Open access icon.

If I had to guess, I would say that we opted to do as MediaWiki does with external links to pdf documents:

[https://example.com/document.pdf A PDF Document] → A PDF Document

—Trappist the monk (talk) 14:57, 7 July 2024 (UTC)

Seems fine. Having links cluttered with an icon that means "this is an ext. link" followed by another that means "this is an external link to which X access conditions apply" would be redundant and annoying.  — SMcCandlish ☏ ¢ 😼  11:07, 14 July 2024 (UTC)

|transcript-url not working

Smith, Adam (July 7, 2024). Title (Speech). Event. Location. {{cite speech}}: Unknown parameter |transcript-url= ignored (help) Amayorov (talk) 17:59, 7 July 2024 (UTC)

|transcript= and |transcript-url= were not supported by {{cite speech}} in its wikitext (old) form so they are not supported in its current Module:Citation/CS1 form:

Cite speech comparison

Wikitext	{{cite speech|date=July 7, 2024|event=Event|first=Adam|last=Smith|location=Location|title=Title|transcript-url=https://www.example.com|transcript=Transcript Title|url=https://www.example.com}}
Old	Smith, Adam (July 7, 2024). Title (Speech). Event. Location. https://www.example.com.
Live	Smith, Adam (July 7, 2024). Title (Speech). Event. Location. {{cite speech}}: Unknown parameter |transcript-url= ignored (help); Unknown parameter |transcript= ignored (help)

I added |transcript=Transcript Title to your example so that |transcript-url= would have something to link if it did work.

The |transcript= parameters are supported by {{cite av media}} and {{cite episode}}.

—Trappist the monk (talk) 18:28, 7 July 2024 (UTC)

It appears on Template:Cite speech though!

Besides, even if this parameter isn't supposed to work, shouldn't we add it? It could be very useful. Amayorov (talk) 19:05, 7 July 2024 (UTC)

If you mean the mentions in Template:Cite speech § Deprecated, you will find that mention in every cs1|2 template (Template:Cite book § Deprecated, Template:Cite journal § Deprecated, etc). The mention is supposed to convey the fact that support for the unhyphenated |transcripturl= has been withdrawn globally. Nearly a year later, that table will be emptied at the next module suite update when support for |authors= is withdrawn.

—Trappist the monk (talk) 19:14, 7 July 2024 (UTC)

I see, thanks! Amayorov (talk) 22:40, 7 July 2024 (UTC)

"Wikipedia:Lua cites" listed at Redirects for discussion

The redirect Wikipedia:Lua cites has been listed at redirects for discussion to determine whether its use and function meets the redirect guidelines. Readers of this page are welcome to comment on this redirect at Wikipedia:Redirects for discussion/Log/2024 July 8 § Wikipedia:Lua cites until a consensus is reached. Nickps (talk) 13:48, 8 July 2024 (UTC)

Nomination for deletion of Module:Citation

Module:Citation has been nominated for deletion. You are invited to comment on the discussion at the entry on the Templates for discussion page. Nickps (talk) 16:01, 8 July 2024 (UTC)

Actually I nominated for redirection rather than deletion. There is no such TfD notice template though. Nickps (talk) 16:03, 8 July 2024 (UTC)

Another generic pseudo-author to detect and warn about

"Newsroom" (or "newsroom", "News-room", "news-room", "News Room", "News room", "news room"). I've encounted this in |last= at least twice in the last month or so. Might need to flag "News" by itself, too, though I guess it's conceivable for someone to be named something like "Janet News". I know for a fact that Room is an extant surname.  — SMcCandlish ☏ ¢ 😼  11:01, 14 July 2024 (UTC)

That reminds me that I keep running into "Company" in |last= and was a bit surprised it's not considered a generic name. An insource: search yielded around 1000 hits, including maybe 30% false positives because I didn't want to pound the servers with a regex to escape the =. A quick scroll through the first 500 results showed a single valid usage as a surname, at Ziphosuchia, with the balance of true positives consisting of publishing companies misparsed by Citoid and pals. Folly Mox (talk) 11:24, 14 July 2024 (UTC)

We might add a test to find only Company or company as whole values. If someone cares to check the results of this search if may be possible to loosen the restriction so that the test finds names that include Company or company. Corporate authors are allowed so I don't think that we can error when a name simply includes Company or company.

—Trappist the monk (talk) 15:30, 14 July 2024 (UTC)

Sorry for the inclarity, but yes I meant specifically just |last=Company, without involving substring matching. Folly Mox (talk) 21:40, 14 July 2024 (UTC)

Before timing out, this search found ~2040 articles that have |lastn= or |authorn= parameters with values that begin News or news. When I ran that search, I found: Newsby, Newsinger, Newsom, Newsome, Newstead, Newsum among the first 20 results; some of them multiple times. So our generic name search is limited to finding only News or news as whole values to avoid false positives.

For the others that you name:

Newsroom and newsroom: ~570 articles

News-room and news-room: none

News Room, News room, and news room: 2 (times out)

Adding a specific test for Newsroom and newsroom seems worthwhile; the others, not.

—Trappist the monk (talk) 15:30, 14 July 2024 (UTC)

Another that you all should look at is |lastn=Bureau or |authorn=Bureau. This search fund about 8300 articles where the assigned value begins with Bureau. Of those about 6680 hold only the word Bureau. There are authors whose surname is Bureau.

—Trappist the monk (talk) 16:59, 15 July 2024 (UTC)

{{Cite paper}} without a journal?

Cite paper redirects to Cite journal. What should be done when the paper in question is a white paper published by a manufacturer, but not part of a journal, and not one of a clear series? It's more of a technical backgrounder on their significant invention. Andy Dingley (talk) 13:50, 14 July 2024 (UTC)

I use {{Citation}} for this sort of source, but if it's online and you don't need specific page numbers, {{Cite web}} will work. Both templates accept |series=. If this is about Paxman Hi-Dyne engines, I'd probably go with {{Cite web}}, since the reproduction of the original via Richard Carr's Paxman History Pages is a human conversion to HTML and the original source is not what was consulted. Folly Mox (talk) 14:39, 14 July 2024 (UTC)

I have a photocopy of the paper copy too, but there's nothing useful on there about a journal as such.

I know it's pointless on WP, because they're all just redirects, but I do prefer the semantics of marking up journals as journals and papers as papers. Andy Dingley (talk) 14:46, 14 July 2024 (UTC)

Perhaps one could employ |type=White paper? Remsense诉 15:42, 14 July 2024 (UTC)

(edit conflict)

but if it's online and you don't need specific page numbers Do you mean to suggest that {{cite web}} does not support the pagination parameters? If you do then you are mistook:

{{cite web |url=//example.com |title=Title |page=23}} → "Title". p. 23.

{{cite web |url=//example.com |title=Title |pages=23–45}} → "Title". pp. 23–45.

—Trappist the monk (talk) 15:43, 14 July 2024 (UTC)

Is {{cite report}} appropriate here?  —  Jts1882 | talk  15:34, 14 July 2024 (UTC)

Thanks, that seems like the best fix. Andy Dingley (talk) 19:55, 14 July 2024 (UTC)

While we're here: is this also ideal for standards documents? Remsense诉 20:07, 14 July 2024 (UTC)

Please fix: the limited mouseover for url-access is too specific

Some web servers refuse access as a way of avoiding having to respect the GDPR. This is especially the case for some US-based servers - presumably the idea that ordinary people might have the right to privacy is too radical to some newspapers. See this example for an archiver, in which case the archiver was presumably a server located outside of the US. Maybe there are similar cases for some Russian and Chinese servers that refuse access to people who can't be tracked.

Our current option limited for url-access for {{web cite}} gives the mouseover text Free access subject to limited trial, subscription normally required, which is misleading for web servers that require privacy violation. The alternatives registration and subscription are misleading for this case too.

We need to either:

• add a fourth option, e.g. geolimited with mouseover text Access forbidden to some geographical locations; or
• change the limited text to something more generic such as Free access in some cases.

This will require an extension or correction (respectively) to

['registration'] = {class='id-lock-registration', title='Free registration required'},
['limited'] = {class='id-lock-limited', title='Free access subject to limited trial, subscription normally required'},
['subscription'] = {class='id-lock-subscription', title='Paid subscription required'},

in Module:Citation/CS1/Configuration by someone with editing access. Boud (talk) 11:35, 16 July 2024 (UTC)

Possibly related discussions:

• Help talk:Citation Style 1/Archive 62#Request for new url-access_value(s) - Dec 2019/Jan 2020
• Help talk:Citation Style 1/Archive 74#Intent of url-access=limited - Jan 2021

Neither of these seem to mention the geo-related access-only-with-privacy-violation issue. The GDPR officially became active in 2018 and my feeling is that US geo restrictions were implemented by some US newspapers quite rapidly. But it seems like this issue hasn't been discussed earlier. Boud (talk) 11:45, 16 July 2024 (UTC)

Numeric author name

• 34 (19 September 2021). "Lane Rasberry". 34Questions. YouTube. {{cite web}}: |author1= has numeric name (help)

The |author1=34 generates a red message. This is how the author signs their name, "34", and the name of the work is 34Questions. Is there a way to express this without a red message? -- GreenC 23:08, 16 July 2024 (UTC)

{{cite av media |author1=((34)) |title=Lane Rasberry |url=https://www.youtube.com/watch?v=gmhsqYsvz-I |publisher=34Questions |via=YouTube |language=en |date=19 September 2021}}

34 (19 September 2021). Lane Rasberry. 34Questions – via YouTube.

—Trappist the monk (talk) 23:14, 16 July 2024 (UTC)

MNRAS is open access

This should cover DOI patterns

• 10.1093/mnras
• 10.1111/j.1365-2966
• 10.1046/j.1365-8711

Is is possible to implement those? Headbomb {t · c · p · b} 02:44, 17 July 2024 (UTC)