Help talk:Citation Style 1

Citation templates

... in conception

... and in reality

Publication date for journal references

{{cite journal}} accepts both year and date, but the former is discouraged. Since date can accept day, month, and year; this creates inconsistency in the references. I understand the full date is necessary for some references such as news articles, but it is really superfluous for scholarly journals. I suggest encouraging date=YYYY for journal references for the following reasons: (i) In scholarly referencing, the full date of publication is (almost) never used for journal articles. (ii) Full date of publication is technically useful for scholarly articles, as the dates of submission, acceptance, online publication, print publication are months apart in the best-case scenario. (iii) The guide says it is useful if an author publishes several articles in the same year, but Wikipedia references are numbered not sorted by authors' names in Chicago style. Even in the latter, YYYYa,b,c is used since there is no guarantee that one author has not several articles in the same month.

My suggestion is not to change anything but to encourage in the referencing guide using the year of publication.589q (talk) 02:25, 23 December 2021 (UTC)

The date used in journal citations reflects the date of publication of the specific issue. This has to be so because this is one of the fields indexed by periodical reference/biblio database providers. Therefore it is an important aid in finding the source of the citation and verifying the wikitext. Wikipedia by its very nature demands this. It should not be compared to other projects that have different audiences, specifications, or demands. 71.247.146.98 (talk) 12:50, 23 December 2021 (UTC)

(i) Nobody uses the issue to find an article. Every journal article is linked with DOI. (ii) 80% of journal articles in Wikipedia references are cited by year only. My suggestion is for consistency. (iii) The reset usually have a YYYY-MM format, which is not enough for finding an issue because most journals have more than 12 issues per year. (iv) Most journals do not even mention the publication date in the list of issues (only issue number).589q (talk) 13:45, 23 December 2021 (UTC)

It is not correct to say that every journal article is linked with a DOI. Not all of them are, for many different reasons. Secondly, you assume that the average Wikipedia reader would know what a DOI is, as it is generally considered scholarly/expert info. As a matter of course, registrants such as CrossRef assign part of the suffix by journal date and/or issue. Also, it doesn't matter how journal references are cited in Wikipedia; we are only discussing how they should be correctly cited. A reader wanting to verify a citation can see several non-cryptic pieces of information before the identifiers. This order of placement is not random. As noted before, reference databases index author/date/issue/article title/identifier per journal. That is the easiest way for the average reader to find them. Not coincidentally, DOI registrants may use the very same databases (among other information) to build DOI suffixes. The resulting DOI number will then be used to update the relevant databases. 65.88.88.68 (talk) 15:30, 23 December 2021 (UTC)

You got me wrong on the DOI matter. I didn't say people use DOI to check the citations. I said (almost) every journal article referenced in Wikipedia has a hyperlink via doi.org which sends the reader to the article. For checking the reference, people simply click on the available hyperlink. Nobody finds the article via the table of contents when there is a direct link, whether you are familiar with DOI or not. All scholarly articles have DOI. My suggestion is all about the readability for both professional and average readers. I just suggest consistency for "Doe, J. (2021)", "Doe, J. (December 2021)", and "Doe, J. (23 December 2021)" referencing. Roughly speaking, 80% of journal articles in Wikipedia references use the first format. I just suggest having a recommendation for the preferred format. When I add a reference, I do not know which format is recommended. Thus, I pick one randomly. These random choices add to the unnecessary inconsistency.589q (talk) 17:37, 23 December 2021 (UTC)

Not trying to prove anybody wrong on anything, we are discussing a proposition. I know that |date= documentation suggests several different ways to input the date. Presumably, the source can be found whether the date is input as year only or as a more complete date. However it is best to input the date the way you see it in the publication itself, again because this is how the source will be found faster when one searches for it by date. The consistency proposition satisfies aesthetics but may hamper/delay discovery. In an inherently unreliable project like Wikipedia, ease of source discovery and therefore of verification is important. Consistency regarding dates is recommended where it will not affect discovery. And may I repeat that the idea that the average reader will see a citation and immediately click on an otherwise cryptic identifier is not a useful assumption, and imo highly unlikely. 65.88.88.68 (talk) 17:06, 23 December 2021 (UTC)

I am probably on a different page, as I have no clue what you are referring to. "this is how the source will be found faster when one searches for it by date". Could you please let me know how you search for a journal article by the date of publication? And when there is a direct hyperlink to the article, why should one search for the article?589q (talk) 18:28, 23 December 2021 (UTC)

Not all of the references that are cited in Wikipedia are online, and some readers may have to resort to searching through physical journals at libraries (particularly for older works), in which case details of how the journal refers to the location etc of the article (i.e. how the journal presents the date of the issue and things like volume and issue number, and even page numbers) will be very helpful in finding the article in question. Your proposal merely strengthens FUTON bias.Nigel Ish (talk) 20:42, 23 December 2021 (UTC)

Even when the full text is available online, you may still have to search on the date, drilling down to the year, month, volume and issue. This occurs when the journal has been digitised by being scanned, but the text is not searchable. Hawkeye7 (discuss) 21:16, 23 December 2021 (UTC)

(i) I have not come across a single journal article without a PDF version. If there is, it is almost impossible to find them in any library. (ii) If someone has access to a library with a physical archive of the scholarly journals, the library should have an online subscription too. (iii) I come from the generation of hardcopy and spent nights in libraries for finding references. I have never used the publication date for finding an article because it is technically impractical. Journal issues are bonded together and only the range of issues is printed on the cover. (iv) If I am wrong, and the date of publication is useful in finding an article, then, there should be a recommendation for providing the full date of publications for the 80% of the Wikipedia references, which have provided year only.

My suggestion was simple. I asked when I am adding a reference, which of the three formats (bolded above) is recommended? If your answer is: whichever you like, it is not appropriate for an encyclopedia. If your answer is: whichever is available, I have the full date of thousands of (almost all) references with year only. Should we add the missing information? If your answer is: leave them the way they are, it is not appropriate for an encyclopedia because the choice was based on personal preferences to include the full date or year only. 589q (talk) 00:27, 24 December 2021 (UTC)

589q, please provide data for your claims about date formats and the presence of DOIs for journal citations in WP articles. Your claims are wildly inconsistent with my experience in editing tens of thousands of citations in articles. Thanks. – Jonesey95 (talk) 00:59, 24 December 2021 (UTC)

Jonesey95, I didn't get what part was different from your experience. Do you mean the DOI is not available for most journal articles cited in Wikipedia? Or the date formats are not mostly years? For example, see Lithium as a general article with numerous similar ones.589q (talk) 01:29, 24 December 2021 (UTC)

[edit conflict] The answer really is: whichever you like. I tend to use either year=2021 or date=December 2021; I don't think the full dates are useful, but the months sometimes are, for the purpose suggested above: tracking down articles in journals from the journal name and publication date in cases where the title isn't working well. Re the discussion above about journal publications with no online pdf: they're unusual but not unheard of. For instance I don't know where to find the following in its original form (I do know of a revised version in a 2019 book that is available online): Datta, Bibhutibhusan; Singh, Awadhesh Narayan (1992). "Use of permutations and combinations in India". Indian Journal of History of Science. 27 (3): 231–249. MR 1189487. Re your attitude that there can only be one format: See WP:CITEVAR. —David Eppstein (talk) 01:04, 24 December 2021 (UTC)

David Eppstein, it is very unlikely to find that article in physical form in libraries too. Does it help to find it easier? Datta, Bibhutibhusan; Singh, Awadhesh Narayan (24 December 1992). "Use of permutations and combinations in India". Indian Journal of History of Science. 27 (3): 231–249. MR 1189487..589q (talk) 01:36, 24 December 2021 (UTC)

The issues I can find online of that journal [1] are labeled by month and year, but not by the day within the month. So the month and year are useful information to me; the day is not. Also, the issue with that paper appears to be available in a physical copy at the Stanford University library, very near where I happen to be now and where (as an alumnus) I would probably have access to it if it weren't a holiday, and I definitely would have access to photocopies of either that or the UC Berkeley copy through interlibrary loan from my home library at UC Irvine. —David Eppstein (talk) 01:44, 24 December 2021 (UTC)

Normally, when looking up for an article in the physical archive, volume and page number is sufficient. Extra information is the issue number. The month of publication does not provide any information beyond the issue number. The issue number is usually mentioned in both the academic bibliography and Wikipedia reference (including your example). If we want to add more information, why not using one that is available, common, and more accurate (issue number), and just add extra data, which might be useful or not. By the way, if you travel to another institution (whatever close) to get an article, you wouldn't care to have the month of publication in hand to find it 10 seconds faster.589q (talk) 02:00, 24 December 2021 (UTC)

Point of note, "YYYY-MM" is not an acceptable date format. This is because it is ambiguous if a date such as "2006-07" refers to July 2006, or the year range "2006–2007".  — sbb (talk) 16:17, 24 December 2021 (UTC)

The statement "if date is useful in finding a journal article" is incorrect. Journal dates are indexed by all metadata providers so that search queries can find a particular issue by date. There is no "if" here, this is one of the items that sources are classified by. So date has semantic significance in the context, and is not just a matter of aesthetics. It is also not an obtuse item for the average reader, unlike any identifier. That said, nobody forces anybody to use the complete issue date (even though they should). But it would be semantically diminishing to suggest a date abbreviation as the "preferred" date. If anything, the complete date should be suggested as the preferred option. 69.203.140.37 (talk) 22:23, 24 December 2021 (UTC)

Clarification: above, it was not meant that editors should be obligated to use the complete publication date as it appears in the journal. It is just my opinion that they should, for the sake of faster/easier discovery. 172.254.162.90 (talk) 23:43, 24 December 2021 (UTC)

Almost everyone is in favor of the month of publication. I still believe an article is looked up by its year, volume, and page number if DOI is not available. I just wonder if the month of publication is such useful, why is there no petition to add the missing date of publication in the references. I come to my second reasoning that the date of publication is misleading.

Let me clarify this through an example. How do you cite this article https://pubs.acs.org/doi/10.1021/jacs.1c08484? At the top of the page, it is written: Publication Date:November 28, 2021, but this article belongs to volume 143, issue 49 (December 15, 2021). Nowhere on the page, you can find December 15, 2021 unless you go to the issue page.

You may wonder what if the publication year is different from the issue. Here is an example: https://pubs.acs.org/doi/10.1021/jacs.0c10943 Publication Date:December 15, 2020 belongs to volume 143, issue 1 (January 13, 2021). At the top of the page, it is clearly stated Cite this: J. Am. Chem. Soc. 2021, 143, 1, 5–16

The problem is: for most publishers, the publication date is the date of (online) publication of the article, but the publication year is of the release of the whole issue. The latter must be used for citation. Usually, the latter is included in the former, but not necessarily (the second example I gave). 589q (talk) 03:26, 26 December 2021 (UTC)

My mistake: I should have used "issue date" where I used "publication date". Most (not all) journals have a set issue date schedule, but often the publication schedule diverges for whatever reason. For this reason, most biblio providers classify by "issue date" if it exists, rather than "publication date", which comes into play if it is the only date. If you look at the way providers structure the metadata, "date" almost always refers to issue date (usually a known in-advance property), with publication date commonly relegated to a "Notes"-like field. In CS1, a citation can provide both dates, although there is an opinion to do away with publication date, and use that info only when issue date is absent (confining this argument to journals for now).

In you first example, suppose one remembers part of an author's/editor's last name. It is also known that the work was published in late 2021. With that info, you will get a list of results. I suggest that in the great majority of queries the entry with the author and issue date will appear before any other date in a browser with no previously cached results, simply because that is how the info is indexed, and search engines use this same info. If you know the journal name, it is easier, because the issue schedule is set, and you can zero-in on the "December 2021" issue. And as you can see in the second example this correct procedure is given (cite by issue date), as this leads to the most efficient doscovery. 68.173.76.118 (talk) 14:25, 26 December 2021 (UTC)

Reiterating that this discussion is about serial publications. Other considerations apply in e.g. books, including book series. 68.173.76.118 (talk) 14:42, 26 December 2021 (UTC)

We have two independent parameters: |date=, for the date printed on the cover; and |publication-date= for the date that it became available to subscribers and other potential purchasers. These two need not be the same, see Template:Cite journal#csdoc_date and Template:Cite journal#csdoc_publication-date. For example:

• Feifan Wang; Yongping Fu; Ziffer, Mark E.; Yanan Dai; Maehrlein, Sebastian F.; X.-Y. Zhu (January 13, 2021). "Solvated Electrons in Solids—Ferroelectric Large Polarons in Lead Halide Perovskites". Journal of the American Chemical Society. 143 (1) (published December 15, 2020): 5–16. doi:10.1021/jacs.0c10943.

Is that way of showing both dates satisfactory? --Redrose64 🌹 (talk) 00:07, 27 December 2021 (UTC)

It seems clear to me that the positer of this query likely doesn't write historical articles nor possibly on foreign topics. As someone who does, I can definitely state that it is less often than frequent that there is a DOI reference to the majority of articles I use as reference materials. Unequivocally knowing the date as well as volume and issue are incredibly important. Many journals which have existed for decades have altered their range numbers, thus you must tie both the date of the issue to the vol/no. I cannot even estimate how many times I have used the "ask a librarian" feature of world cat to retrieve and have e-mailed to me an article that exists in a publication that has not been digitized. In every single instance, I was asked to provide the issue date as well as the volume and issue number. While DOI may be common in the US/UK, it is less so in the rest of the world mainly because it requires that sources be digitized, which is much less frequent, especially for historic documents, in places that are not as affluent or digitally oriented. SusunW (talk) 15:03, 12 January 2022 (UTC)

Internationalisation need

Module:Citation/CS1/Configuration has local date information along with English language date information. This is a creating problem for Telugu Wikipedia users, as everytime this module is refreshed from enwikipedia, as part of import of Templates that use this module, the Telugu language information is getting overwritten. Then a manual update of Telugu language language dates is required to avoid check date errors being shown for Telugu dates. I request the maintainers to internationalise that portion. Arjunaraoc (talk) 00:30, 25 December 2021 (UTC)

By doing what, exactly? We will not add all of every language's possible date names as that would be undue burden of page processing on English Wikipedia. I think it's fairly reasonable to expect users refreshing the configuration page to check what they are doing and refresh only the relevant parts. Izno (talk) 05:03, 25 December 2021 (UTC)

@Izno, I am hoping that the local dates information can be stored in a subpage with language suffix. If such a page is not available, the default English dates can be used as local dates as well. On Telugu wikipedia, there are many admins who refresh the templates for their need, but do not have knowledge of template code or often forget to update the local date info. Hope that helps. Arjunaraoc (talk) 12:50, 29 December 2021 (UTC)

This is on my TODO list for after the next update.

—Trappist the monk (talk) 11:40, 25 December 2021 (UTC)

@Trappist the monk, Glad to know that it is in your todo list. Thanks. Arjunaraoc (talk) 12:51, 29 December 2021 (UTC)

addition of 'quote-p' and 'quote-pp' to citiation templates

Can someone please add 'quote-p' and 'quote-pp' as aliases of 'quote-page' and 'quote-pages' respectively? -- PK2 (talk) 05:06, 29 December 2021 (UTC)

WTF is this? (templatestyles stripmarker in title= at position XX)

Tang, Jian; Oka, Takeshi (1999). "Infrared spectroscopy of H₃O⁺: the v₁ fundamental band". Journal of Molecular Spectroscopy. 196 (1): 120–130. Bibcode:1999JMoSp.196..120T. doi:10.1006/jmsp.1999.7844. PMID 10361062. {{cite journal}}: templatestyles stripmarker in |title= at position 26 (help)

There's no issue in this citation. That error message needs to be suppressed. Headbomb {t · c · p · b} 18:23, 29 December 2021 (UTC)

It's old news that you shouldn't use templates in certain parameters. This is an outcome of someone's deliberate decision to do so.

See also a recent-enough archive that you can go looking for a discussion on a related topic. Izno (talk) 18:56, 29 December 2021 (UTC)

"you shouldn't use templates in certain parameters" there's never been any such proscriptions on template use anywhere. Case in point

Smith, J. (1999). "Fake title NO³⁻
". Journal of Stuff. 1 (2): 3–4.

Headbomb {t · c · p · b} 19:30, 29 December 2021 (UTC)

It has been repeated here ad nauseum. I doubt you have somehow missed those discussions. Izno (talk) 19:53, 29 December 2021 (UTC)

Something false repeated many times doesn't suddenly become true. Headbomb {t · c · p · b} 20:26, 29 December 2021 (UTC)

{{Su}} has been marked with {{COinS safe|n}} since this edit 18 January 2015. {{COinS safe}} has been around since 18 May 2012‎ (Special:Permalink/493117278). The COinS section of the cs1|2 template documentation was created 12 January 2012‎ (Special:Permalink/470891851) and incorporated at this edit (11 January 2012). Yeah, the timing seems a little odd... Still, we have discouraged the use of templates in cs1|2 parameters for nearly a decade now.

—Trappist the monk (talk) 21:15, 29 December 2021 (UTC)

@Headbomb: How about replacing {{H3O+}} with <sub>...</sub> and <sup>...</sup> tags, like this:

Tang, Jian; Oka, Takeshi (1999). "Infrared spectroscopy of H₃O⁺: the v₁ fundamental band". Journal of Molecular Spectroscopy. 196 (1): 120–130. Bibcode:1999JMoSp.196..120T. doi:10.1006/jmsp.1999.7844. PMID 10361062.

Happy editing! GoingBatty (talk) 19:26, 29 December 2021 (UTC)

The point is that this shouldn't throw an error at all, not that you can half ass a workaround. Headbomb {t · c · p · b} 19:30, 29 December 2021 (UTC)

Yup, the old issue of the inferior coins scheme used here. As suggested, such errors (that have nothing to do with citations) should be suppressed. Instead, perhaps whoever maintains coins could be auto-pinged any time this happens. 65.88.88.91 (talk) 19:32, 29 December 2021 (UTC)

This wouldn't be Wikipedia without additional confusion: some templates do work anywhere including |title=. One common example is {{en dash}}. For more, you can turn to the imaginary list documenting such templates that do not blame the victims. 65.88.88.91 (talk) 19:36, 29 December 2021 (UTC)

This seems to be related to <chem></chem> tags. Headbomb {t · c · p · b} 19:43, 29 December 2021 (UTC)

This should bypass the error. Headbomb {t · c · p · b} 19:49, 29 December 2021 (UTC)

Current

• Tang, Jian; Oka, Takeshi (1999). "Infrared spectroscopy of H₃O⁺: the v₁ fundamental band". Journal of Molecular Spectroscopy. 196 (1): 120–130. Bibcode:1999JMoSp.196..120T. doi:10.1006/jmsp.1999.7844. PMID 10361062. {{cite journal}}: templatestyles stripmarker in |title= at position 26 (help)

Sandbox

• Tang, Jian; Oka, Takeshi (1999). "Infrared spectroscopy of H₃O⁺: the v₁ fundamental band". Journal of Molecular Spectroscopy. 196 (1): 120–130. Bibcode:1999JMoSp.196..120T. doi:10.1006/jmsp.1999.7844. PMID 10361062. {{cite journal}}: templatestyles stripmarker in |title= at position 26 (help)

Headbomb {t · c · p · b} 19:50, 29 December 2021 (UTC)

If there is no list of CS1-safe templates, is there a list of coins-safe tags (if any tags are indeed compatible)? Until such issues are permanently resolved, template editors could consult that list and insert a notice re: usage in CS1 depending on the tags' existence in template code. 71.245.250.98 (talk) 21:07, 29 December 2021 (UTC)

I have reverted that edit because it doesn't do what you think it does. The sandbox rendering above, appeared to work because the {{H3O+}} template is not in the sandbox template (it was replaced with H<sub>3</sub>O<sup>+</sup>) so, of course, the 'fix' appeared to work.

The <chem>...</chem> markup is like <math>...</math> markup: the rendering that is visible is an image:

${\ce {H3O+}}$ ← <chem>H3O+</chem>

We might want to handle <chem>...</chem> markup in the same way that we handle <math>...</math> markup – some sort of error message in the metadata instead of a non-sensical stripmarker. Discussion is appropriate, I think.

—Trappist the monk (talk) 21:15, 29 December 2021 (UTC)

If <chem>...</chem> is like <math>...</math>, then it should be handled like math. The revert is nonsensical even if it didn't fix the above issue. Headbomb {t · c · p · b} 21:31, 29 December 2021 (UTC)

@Headbomb: It appears that {{H3O+}} uses {{chem}} (not <chem>...</chem>), and Template:Chem's documentation includes {{COinS safe|n}}, with a note stating that <chem>...</chem> is an alternative to {{chem}}. GoingBatty (talk) 23:21, 29 December 2021 (UTC)

Looking cursorily at the source code of {{chem}} and the subtemplates {{chem/atom}} and {{chem/link}}, as well as module:su nothing stands out as particularly offensive html-tag-wise. One wonders what trips COinS. Ten+ years in a row. 69.203.140.37 (talk) 13:59, 30 December 2021 (UTC)

Incidentally, none of the versions of the citation above are formatted correctly. The $\nu _{1}$ part is a mathematical equation and should be formatted as mathematics, either as <math>\nu_1</math> or as {{math|''ν''₁}}. Additionally, I'm pretty sure that letter in it is a Greek nu, not a Latin vee. The <math>\nu_1</math> should always work in titles but will stay black even when the title is linked by a url or free doi. The {{math|''ν''₁}} will look correct when linked and I think looks nicer here but may run into similar stripmarker issues.

• {{cite journal | title = Infrared spectroscopy of {{H3O+}}: the <math>\nu_1</math> fundamental band | first1 = Jian | last1 = Tang |first2 = Takeshi | last2 = Oka | journal = [[Journal of Molecular Spectroscopy]] | volume = 196 | pages = 120–130 | year = 1999 | doi = 10.1006/jmsp.1999.7844 | pmid = 10361062 | issue = 1| bibcode = 1999JMoSp.196..120T }}
• Tang, Jian; Oka, Takeshi (1999). "Infrared spectroscopy of H₃O⁺: the $\nu _{1}$ fundamental band". Journal of Molecular Spectroscopy. 196 (1): 120–130. Bibcode:1999JMoSp.196..120T. doi:10.1006/jmsp.1999.7844. PMID 10361062. {{cite journal}}: templatestyles stripmarker in |title= at position 26 (help)
• {{cite journal | title = Infrared spectroscopy of {{H3O+}}: the {{math|''ν''₁}} fundamental band | first1 = Jian | last1 = Tang |first2 = Takeshi | last2 = Oka | journal = [[Journal of Molecular Spectroscopy]] | volume = 196 | pages = 120–130 | year = 1999 | doi = 10.1006/jmsp.1999.7844 | pmid = 10361062 | issue = 1| bibcode = 1999JMoSp.196..120T }}
• Tang, Jian; Oka, Takeshi (1999). "Infrared spectroscopy of H₃O⁺: the ν₁ fundamental band". Journal of Molecular Spectroscopy. 196 (1): 120–130. Bibcode:1999JMoSp.196..120T. doi:10.1006/jmsp.1999.7844. PMID 10361062. {{cite journal}}: templatestyles stripmarker in |title= at position 26 (help)

—David Eppstein (talk) 18:00, 30 December 2021 (UTC)

Referencing equations in physics books

At Carnot cycle we want to reference https://www.gutenberg.org/files/50880/50880-pdf.pdf, specifically we want equations 39, 40 and 65 in sections §90 and §137. I'm not sure of the best way to do this.  Stepho  talk  00:59, 30 December 2021 (UTC)

Write something like <ref>See equations 39, 46 and 65 in {{cite ...}}</ref> or <ref>{{cite ...|at=Eqs 39, 40, 65}}</ref> Headbomb {t · c · p · b} 01:08, 30 December 2021 (UTC)

Although there's nothing wrong with doing it those ways, you could also use |contribution=Equations 39, 40, and 65 in Sections 90 and 137 within the citation template. Doing it that way has the advantage that you can still specify pages as a separate parameter rather than needing to format the page numbers as part of the |at= parameter, and that you can provide a direct link to the starting page of the contribution (if you're using a source like archive.org or Google books that provides such links) in the |contribution-url= parameter. —David Eppstein (talk) 01:59, 30 December 2021 (UTC)

Thanks. I went with |contribution=equations 39, 40 and 65 in sections §90 & §137, although I was tempted to use |section=equations 39, 40 and 65 in sections §90 & §137. I was able to add |page=.  Stepho  talk  11:18, 30 December 2021 (UTC)

Check pmc=value

"If the value is correct and larger than the currently configured limit of 8700000, please report this at Help talk:Citation Style 1, so that the limit can be updated."

Molecular mechanisms for understanding the association between TMPRSS2 and beta coronaviruses SARS-CoV-2, SARS-CoV and MERS-CoV infection: scoping review has PMC=8709906

-- Ben Best:Talk 21:32, 30 December 2021 (UTC)

access-date for archived pages?

For citations that are archived from the very start (i.e. cited only after the original website has lapsed), what should access-date in Template:Cite web contain: the last time the writer successfully accessed the original URL, or the last time the writer successfully accessed the archived URL? The documentation defines the parameter as “[t]he full date when the original URL was accessed” – so should the parameter perhaps not be present at all in that case? Obskyr (talk) 04:59, 4 January 2022 (UTC)

I personally remove access-date when an archive is provided. Otherwise, it should be the date the original URL was last accessed. Izno (talk) 06:34, 4 January 2022 (UTC)

I agree with Izno. I think having an access date in these circumstances is pointless and just causes confusion. -- Alarics (talk) 10:17, 4 January 2022 (UTC)

Alright, but wait a minute. I see a chart peak on Billboard's ever-changing site and add a cite to the "That Great Song" page. The weekly chart position changes, up or down, maybe, and then the page is archived. Billboard revamps their stupid site again and the page, as it once was, is gone forever, except at the archive (and maybe some other web site, and maybe in a paper magazine), although possibly with different chart placement. Is it really wrong to say, "I saw That Great Song charted at No. 9 on so-and-so date at this URL"? Isn't that we're supposed to do? — JohnFromPinckney (talk / edits) 20:18, 4 January 2022 (UTC)

There are 2 dates at play here, if I understand you correctly. The event date and the access date of the archive. The event date is a week, as Billboard charts by week, and obviously is a dynamic date - even if the song charts at the same position for many weeks, this will eventually change. Your access date sometime later will most likely be the date you access an archive of the event. The archive is static, and therefore archive access dates are thought to be unimportant. However the archive date is important, as it relates the archive to the event you want to cite. |archive-date= will suffice in this case, obviously as long as it is later than the event date. 65.88.88.57 (talk) 20:37, 4 January 2022 (UTC)

No. |access-date= is the date that the web page at the original URL was used to verify the content in our article, and |date= is the date that this original web page was published; |archive-date= is the date that Wayback Machine (or whoever) made an archive copy of the web page concerned. --Redrose64 🌹 (talk) 21:01, 4 January 2022 (UTC)

Depends on the archive. Crawlers such as the Wayback Machine store snapshots for some time (it is not entirely clear to me how the inventory of snapshots is handled, but it is not unusual for snapshots to disappear). The archived content (ie snapshots) of a web page @ the Wayback Machine is not static; only the content of the snapshots is. The number of snapshots per archive is likely changing with every crawl of the page. When a citation calls an archive in the Wayback Machine, it actually calls a particular snapshot that includes the pertinent information. Therefore |archive-date= is important. There may be several snapshots on that date, but CS1 currently does not provide snapshot resolution. But the original question was about the access date of the archive. To answer this properly, we have to know how each service handles its archives. Empirically, most people accept archives as static, regardless of the service provider. 65.88.88.201 (talk) 14:50, 5 January 2022 (UTC)

Adding Authors Wikidata ID

Given that a noted journalist or academic that authored the text thats being referenced will themselves be able to referenced, could we store their wikidata id (as well the first and surname) which in turn stores their various academic ID's (such as ORCID) and popularist ID's (such as twiter), perhaps linking to reasonator to make it readable? It would also solve the the variation in their names, for example they may use a formal version of their name in academic papers and casual for something in the popular press as well varations whether they use "special characters" in their name

The same could be used for the publicaton

So for example

Pöhls, Jan-Hendrik. "A new approach finds materials that can turn waste heat into electricity". The Conversation. Retrieved 2022-01-05.

Would become something like

Pöhls, Jan-Hendrik. "A new approach finds materials that can turn waste heat into electricity". The Conversation. Retrieved 2022-01-05.

Back ache (talk) 15:05, 5 January 2022 (UTC)

@Back ache: Instead of asking users to add even more data in references, I'd suggest that we could use the existing |author-link= and |work= parameters to provide links to articles about the authors and publications, create redirects for variations in their names, and add ID links in the External links section of those articles. Happy editing! GoingBatty (talk) 16:00, 5 January 2022 (UTC)

That could work, in my earlier example then I'd add author-link=d:Q104888284 Back ache (talk) 23:09, 5 January 2022 (UTC)

You will want to review previous discussions (and there may be more where the phrase 'qid' is not uttered). Izno (talk) 19:47, 5 January 2022 (UTC)

And the obvious search for Wikidata. Izno (talk) 19:48, 5 January 2022 (UTC)

Instead of adding ID links individually to articles, they should be handled through adding them to Wikidata and using the {{Authority control}} template on the articles. But in references, I tend to think that only authors with existing Wikipedia articles should be author-linked; we shouldn't instead link to Wikidata items for authors without articles. Also, I tend to think your proposed link style violates Wikipedia:Manual of Style/Accessibility#Links. —David Eppstein (talk) 20:25, 5 January 2022 (UTC)

Whilst there will always be a place for narrative-first (wikipedia), I also like to assemble facts (wikidata) first and let that tell a story that can be made into an artical, you could argue sufficient good-quality links tell a story in their right and with things like resonator and the semantic things coming that data-only entries will continue to increase Back ache (talk) 21:51, 5 January 2022 (UTC)

It is probably best not to consider citations "narrative". They are tools meant to ensure the actual narrative is factual. This is a vital undertaking that should be focused, uncomplicated, understandable and simply implemented. As was suggested above, overhead should be kept to a minimum. As you will see from the previous related discussions, there are also several as yet unanswered questions about Wikidata in general. 68.173.76.118 (talk) 02:23, 6 January 2022 (UTC)

OPPOSE Wikidata author IDs do not belong in citations. This is complete clutter. The only thing that might belong in a citation is the Wikidata QID for the article/chapter/book being cited, if the article/chapter/book has a corresponding Wikidata entry. Headbomb {t · c · p · b} 12:57, 6 January 2022 (UTC)

Template-protected edit request on 6 January 2022

Could somebody add "archive-link" (correct to " archive-url)? Thanks in advance. Leomk0403 (Don't shout here, Shout here!) 09:25, 6 January 2022 (UTC)

If you are asking for cs1|2 to support |archive-link= as an alias to |archive-url=, I would say that we ought not do that. link can be taken to mean more than just a url (a wikilink is a link...) Editors know and understand |archive-url= so I see no benefit to adding |archive-link= as an alias.

—Trappist the monk (talk) 14:12, 6 January 2022 (UTC)

I have added this to the Suggestions page, as requested. Someone who uses archive-link will receive a red error message with a helpful suggestion to use archive-url instead. – Jonesey95 (talk) 20:19, 6 January 2022 (UTC)

Error messages for non-usual date formats

The guidance of the CS1 help page states that 'Sources are at liberty to use other ways of expressing dates, such as "spring/summer" or a date in a religious calendar; editors should report the date as expressed by the source.' However, the templates as implemented do not appear to respect this, as the date errors are not suppressable. How should this be addressed? --Paul_012 (talk) 11:25, 6 January 2022 (UTC)

An example would be helpful. 71.247.146.98 (talk) 12:48, 6 January 2022 (UTC)

Continue reading, Paul_012. In cases where the date as expressed in the source is not compatible with the template software, the citation should be created without using a template. – Jonesey95 (talk) 13:25, 6 January 2022 (UTC)

Huh. Not sure how I missed that. Does anyone know how this advice originated? It seems rather suboptimal to abandon the templates altogether just because the dates don't fit. --Paul_012 (talk) 14:01, 6 January 2022 (UTC)

This edit.

—Trappist the monk (talk) 14:09, 6 January 2022 (UTC)

On the contrary, templates optimize common cases, sometimes with allowance for very few exceptions. The important item here is the citation, not how it is produced. 71.247.146.98 (talk) 14:13, 6 January 2022 (UTC)

Memento Project

This is not directly related to CS1, but it is something to be aware of. This project ("About Memento" link) is basically a meta-archive whose protocol (RFC 7089) includes logic to automatically access the optimal version of an archived page among different archives. Perhaps more importantly for CS1, there is no need for |archive-url=; the built-in logic in the Memento protocol parses the original URL and determines its status, and whether an archived version exists, which is then served transparently to the user. The current drawback is that the Memento protocol has to be called via a browser extension. It is conceivable that it may become a built-in feature. I am not aware of any Wikipedia template/script that applies this protocol currently. 65.88.88.62 (talk) 16:06, 11 January 2022 (UTC)

What exactly is the issue with TemplateStyles in arguments?

As discussed above, TemplateStyles tags (or rather their strip markers) flag up as an error: "Wikipedia". {{cite web}}: templatestyles stripmarker in |title= at position 1 (help). What exactly is the purpose of this? It makes it much more difficult for template editors to add TemplateStyles to any inline template, as there's a risk that someone has used that template in a citation and citations will then start issuing errors.

If it's a risk of corrupting COinS, why not just silently strip it from machine-readable parts of the output? By their nature the TemplateStyles strip markers only need to appear once to work. If even having it inside the displayed title (or wherever) is problematic, then it could be moved from there to before the rest of the citation. User:GKFX^talk 19:29, 11 January 2022 (UTC)

This is your example citation:

{{cite web|title={{smallcaps|Wikipedia}}|url=https://en.wikipedia.org}}

What cs1|2 gets (after {{smallcaps}} has been processed is this:

?'"`UNIQ--templatestyles-00000051-QINU`"'?<span class="smallcaps">Wikipedia</span>

(the '?' on either end of the stripmarker is the delete character, U+007F)

Of all of that, the only part that is the title, the only part that belongs in |title=, is 'Wikipedia'; the rest is extraneous junk that does not belong in |title=.

The strip marker detector is a relatively easy way to identify corrupted cs1|2 template parameter values. The detector looks for all flavors of strip marker. When templatestyles strip markers are found in |id= or |quote=, they are ignored because those parameter values are not made part of the citation's metadata. Math strip markers are removed from the metadata and replaced with 'MATH RENDER ERROR' message because Scribunto no longer allows modules to fetch the content of math strip markers. A math strip marker remains in the rendered parameter value so that MediaWiki can replace it with an image of the equation. cs1|2 can fetch the content of nowiki strip markers so it does so when creating metadata. All other strip markers are considered erroneous.

Silently removing strip makers is easy. It is more difficult and time consuming to remove the rest of the junk that templates can add to a parameter value. We had a relatively long and ultimately unproductive discussion about unnecessary html markup at Help talk:Citation Style 1/Archive 80 § HTML markup.

—Trappist the monk (talk) 23:12, 11 January 2022 (UTC)

Thank you, that was informative. I'm mostly interested in {{chem2}}; what did you think of the suggestion at Special:Diff/915129724/1046369074? If the citation templates accepted some indicator of the correct plain-text representation, it would be fairly straightforward to build a plain text representation within chem2 at the same time and put that out in an HTML attribute or equivalent. The input to chem2 is semi-readable to a chemist, which I think you asked, but not exactly presentable, so a specific plain text output would be necessary. Ideally that would also silence the strip marker error. User:GKFX^talk 23:31, 11 January 2022 (UTC)

I think that the markup-in-span scheme may be an idea worth pursuing. I think that it should be limited to only those kinds of templates that 'translate' markup-in-plain-text to some sort of standard presentation (as LaTeX or TeX is used for math). I don't know if semi-readable is good enough. I asked that question because en.wiki should never be in the business of making-up 'standards' for anything especially when there are already extant standards in the outer world. We have <chem>...</chem> tags so presumably what goes inside those tags (apparently some form of LaTeX) is standardized markup. That is the markup-in-plain-text that should be used by {{chem2}} and supplied in the markup-in-span scheme so that readers who consume a cs1|2 template via its metadata can read and understand (because it is standardized) the markup that makes an equation in |title=.

I also think that the markup-in-span proposal is something that deserves (requires?) buy-in from more than just you and me. Is {{math}} one such template that might use the scheme? And the templates that are used in it? What about nesting of one (or more) markup-in-span template inside another markup-in-span template? Are there other templates that might be suited to the scheme? If not, then perhaps it is not worth the effort to create and maintain the markup-in-span scheme. Styling templates like {{smallcaps}} have no reason to be included in the scheme because styling of cs1|2 citations is the responsibility of cs1|2.

In the markup-in-span scheme the span's class= attribute would be sufficient to turn off the stripmarker error.

—Trappist the monk (talk) 14:38, 12 January 2022 (UTC)

I'm unconvinced that the <chem> tag's markup (LaTeX with the mhchem library) is that important of a standard; it's just one library. The notation it uses like HC#CH → ${\ce {HC#CH}}$ is not something I encountered at university, and I wouldn't know that # meant triple bond if I hadn't read it in Wikipedia's documentation. It would be far better to output "HC≡CH" in that case, which is plain text and a correct notation. I think the question of what the exact plain text representation would be is one for WikiProject Chemistry; once you get to stuff like ¹⁶O2−2 it's less obvious; something LaTeX-ish in that case seems appropriate. For {{math}}, it looks like what matters is the templates inside math (e.g. {{radic}}) as math seems to just apply formatting. Nesting could be awkward, but if radic output "√(" (as the hidden plain text), then its first parameter, then ")", the citation template would just have to concatenate all the hidden plain text it saw and nesting would have worked successfully.

In terms of the HTML representation of this, I would have thought an attribute data-wiki-plaintext="HC≡CH" would be more appropriate than putting it as document text in a span and then having to hide the span with CSS. User:GKFX^talk 21:39, 12 January 2022 (UTC)

If you're going to use "something LaTeX" for some of these notations, you need to use it for all of them, because of Wikimedia's bad choices to render LaTeX in a way that is visually incompatible with other formatting styles. —David Eppstein (talk) 21:53, 12 January 2022 (UTC)

That's not what I meant, I meant that if I cited a paper called "Properties of O2−2", it might appear as "Properties of O2^{2-}" in the COinS metadata, as you can't output "O22-". On the article the appearance of chem2 would not change from its current HTML. User:GKFX^talk 21:58, 12 January 2022 (UTC)

I have no experience writing chemistry equations. But, I find it very hard to believe that the chemistry world doesn't have a standardized way of creating chemistry equations. Surely the researcher who submitted the paper called "Properties of O2−2" to the journal for publication, wrote that, and other, equations using a method that guaranteed that the publisher would typeset it correctly. After all, that is all that {{chem2}} and like templates are doing here. Some sort of mechanism is required to place all of the various parts of the equation in their proper positions. Is that something that generic word processors do these days? If not then what is the typesetting standard used by industry journals? Whatever that standard is, that should be the standard used at en.wiki. If there is no such standard then, I suppose, en.wiki can do whatever it wants when it comes to typesetting chemistry equations. You don't like LaTeX with the mhchem library, suggest a better standard.

Please don't chastise me for something that I did not write. You asked for my comments about this {{Chem2/sandbox}}. That sandbox uses the class= attribute. Were we to implement something like that, regardless of whether it uses class= or data-whatever=, cs1|2 would remove that attribute thing from its input parameter before rendering so no need to hide the span with CSS.

—Trappist the monk (talk) 23:37, 12 January 2022 (UTC)

The major issue is not how to render chemical formulae, but rather how to generate correct metadata. That is an issue whether you are using, e.g., LaTeX, MarkDown, wiki. What about separate parameters for display title and reference titles? --Shmuel (Seymour J.) Metz Username:Chatul (talk) 15:33, 13 January 2022 (UTC)

Correct, and as said below, this is not a CS1/2 issue. All such discussions should be redirected at the appropriate forum for metadata in Wikipedia, not here. This comes up over & over again, so there is no confidence that this is going to be resolved any time soon. Just one more time-wasting burden for editors who want to use CS1/2. The discussion above is proof enough - instead of removing the error, all kinds of unnecessary contortions are proposed to accommodate it. 65.88.88.47 (talk) 16:57, 14 January 2022 (UTC)

It is more difficult and time consuming to remove the rest of the junk that templates can add to a parameter value. This is not pertinent. Editors do not need templates to add junk to a parameter value, and the fact that it is indeed difficult to remove has nothing to do with this discussion. The main, longstanding issue is that COinS may interfere with legitimate citation editing. This is not new. A thorough search will discover complaints going back at least 12+ years, or ever since the introduction of the scheme in the defunct {{citation/core}}. Btw, the discussion on adding the metadata scheme (if memory serves, prompted by a request from Zotero-using editors) was minimal, as I recall. The problem is that COinS is based on OpenURL, which basically adds specific-content-location additions to a regular http address. Extraneous http artifacts will obviously generate unwanted results. It is incumbent on Wikipedia COinS to find a workable solution to that problem instead of limiting legitimate usage of templates that make editors' work easier. I've no idea what constituency of Wikipedia will agree to limit editors in favor of an external scheme, but it may be time to find out. Keeping also in mind that not all templates will generate COinS-based errors, which makes blanket statements about template use in citations somewhat arbitrary. Until Wikipedia COinS behaves, the suggestion of adding a switch to turn metadata off is an excellent one, and it should be implemented. 65.88.88.91 (talk) 21:10, 12 January 2022 (UTC)

[Template:Cite web] Website parameter being misused?

The {{Cite web}} docs clearly state that the website parameter should display the name of the site, and the examples back that up. Though for some reason, on lots and lots of articles that I see, it's used to display the domain name. For example, where I would think someone would put |website=[[Microsoft]] on a page on Microsoft's website, I often see |website=www.microsoft.com or something similar, instead. Have I misunderstood what the examples, docs, and templatedata say? Or is everyone using this parameter incorrectly. Thanks, ― Levi_OP^Talk 16:37, 13 January 2022 (UTC)

You have not misunderstood. Unfortunately, the doc was not as clear as it should have been in the past, and it is not unusual for the incorrect format to appear in older citations. Also, perhaps editors do not pay proper attention to the current documentation. 65.88.88.68 (talk) 16:45, 13 January 2022 (UTC)

Sooo should I fix this on any articles I see it on? This seems like a pretty big task that some bot could do instead considering just how many articles have this issue. ― Levi_OP^Talk 16:50, 13 January 2022 (UTC)

It's often bots and AWB that do it in the first place because they can easily determine via the URL but they can't know what the name should be. -- GreenC 16:54, 13 January 2022 (UTC)

(edit conflict) Microsoft is not a website, so you should not find |website=[[Microsoft]]. Those should be replaced with |publisher=[[Microsoft]]. |website=www.microsoft.com is fine, thought not really needed if you have |publisher=[[Microsoft]]. Headbomb {t · c · p · b} 16:55, 13 January 2022 (UTC)

Oh, thanks. I didn't know that this publisher option existed, so it would be better in this case. Although, it was just an example. I see it with other links where it is a website and not a company page or something of the sort. ― Levi_OP^Talk 17:16, 13 January 2022 (UTC)

In the case of websites, the publisher is the hosting entity, usually the domain-name owner. This applies when there is a different website creator/owner, as it happens with "free" websites offered by ad-supported web hosting services (actually such websites are usually sub-domains, but that's another story). However, the trade name or dba of the publisher is appropriate if different from the domain-name, so use |publisher=Microsoft rather than |publisher=microsoft.com. 65.88.88.75 (talk) 19:46, 13 January 2022 (UTC)

@GreenC: How would AWB "easily determine via the URL" and create a malformed reference? Maybe you were thinking of tools like Reflinks and/or reFill? GoingBatty (talk) 20:40, 13 January 2022 (UTC)

Well AWB by default can not, but users can create external scripts/programs that hook into AWB (Python, JS, PHP etc). Basically AWB handles the authentication, download and and upload of the page, and a user script processes the page to do whatever. Many bots run this way. Yes the user-initiated tools are also a factor. -- GreenC 20:45, 13 January 2022 (UTC)

|website=www.microsoft.com is not fine. It is the name of the host where the title (and maybe not the whole web site) can be found. It is different from the name of the web site, which in this case happens to be the same as the name of the publisher, Microsoft (although you could spell out the publisher as "Microsoft Corporation" if you were feeling pedantic, and the name of the site would still just be Microsoft). In general, my philosophy for sites where the publisher is more informative than the whole-site name is to use the "work" parameter to give some context to the specific title being cited — is it part of a larger thing, and which level of larger thing would tell readers the most useful information about the citation? For the same reason we neither use street numbers nor "Earth" to quickly describe the residence of someone, we should often neither use the most specific description of a larger work containing the title nor the most general description ("World Wide Web") to describe the work it comes from, but something intermediate, chosen to be informative. Maybe that's the title of a magazine or newspaper, rather than the department within that publication, or the group of publications ("Times-Mirror Newpapers") it comes from. In the case of [2], for instance, (one of the references in Microsoft), the publisher is "Microsoft", and it is indeed somewhere in Microsoft's vast web site, so it is not wrong to put |work=Microsoft, but a more informative and therefore better choice would be |work=Official Microsoft Blog. To complete the analogy, putting a domain name in the work parameter would be like writing that someone lives in the 02134 zip code — it is informative, roughly at the level a city name might be, but in a format primarily intended for conveying information unambiguously to computers, rather than for communicating to people. The text of an encyclopedia article (and a citation is part of that text) should be for communicating to people. —David Eppstein (talk) 23:00, 13 January 2022 (UTC)

Microsoft is not a website, it's a publisher. The name of the website, if anything is Microsoft.com. Headbomb {t · c · p · b} 04:12, 14 January 2022 (UTC)

Looking at first principles, why add a website/publisher: to facilitate verification. Sometimes no archives exist, so additional metadata is useful in finding a copy in databases such as LexisNexis and others. The more 'fancy' one gets with naming, the more likely a mismatch. For example if LN saved it as "Microsoft.com" then searching on "Official Microsoft Blog" might not find it. But searching on only "Microsoft" would find it. Thus it would probably be preferable to have simply |publisher=Microsoft - given V as the consideration concision and common name is important, similar to our article naming conventions, ease of finding things. The idea that precision is better for verification makes sense, unless other websites (LN) have a different idea what to call the website/publisher, which is probably a common problem because there are no standards. -- GreenC 05:49, 14 January 2022 (UTC)

If you're basing this on the principle that it should be useful for recovering sources whose address change, then encoding part of the address (the domain name) into the parameter value is exactly the wrong thing to do, because it doesn't provide you any information that you didn't already have in the address. Instead, if you give a textual name that the source uses (like "Official Microsoft Blog"), you are more likely to be able to use that name in searches to find it again. —David Eppstein (talk) 20:32, 14 January 2022 (UTC)

Adding the Index Theologicus

Hello. I think it would be a good idea to be able to add the Index Theologicus identifier to the templates the way the DOI and the JSTOR identifier are shown. For example, "IxTheo 158777335X" would be displayed with IxTheo hyperlinked and an URL at 158777335X linking to here; so it would look like: "IxTheo 158777335X". This would be useful for articles which do not have a DOI or a JSTOR identifier such as the one used in my example. What do you think? Veverve (talk) 03:56, 14 January 2022 (UTC)

The templates support general parameters in general. If you would like to add this as an identifier for a given use, you may use |id=, possibly in combination with some formatting template (like exists today with {{doi}}). Izno (talk) 07:30, 14 January 2022 (UTC)

@Izno: I think integrating this possibility directly as a parameter (as with JSTOR) would be more helpful, as I feel most people are really tech-savvy to think about the workaround you described (at least it is my case). Veverve (talk) 20:28, 14 January 2022 (UTC)

It will probably help your case to compare ixtheo to special-purpose identifiers like pmid or ssrn or zbl. jstor and doi are general-purpose ids. I suppose that ixtheo would be considered if there was a critical mass of editors and/or citations that used it. 65.88.88.69 (talk) 20:39, 14 January 2022 (UTC)

There are currently 29 uses of it in mainspace.

Show that it needs to be supported in the template first, in other words, that one can expect it to be needed on thousands of pages. Izno (talk) 21:35, 14 January 2022 (UTC)

IxTheo is an index of article, not an article host like JSTOR, so of course it is very unlikely to be used as an URL.

@Izno:Could you describe in details what workaround would you used to display the IxTheo identifier within the template? Veverve (talk) 17:00, 15 January 2022 (UTC)

Refer to my comment from 07:30, 14 January 2022 (UTC). Izno (talk) 17:37, 15 January 2022 (UTC)

Tracking category for issue= without volume= in Template:Citation

Can we get a tracker for citations with hidden issue/number? such as d AManWithNoPlan (talk) 12:10, 15 January 2022 (UTC)

For onlookers, the above is {{cite |title=d |issue=1}}. Izno (talk) 17:38, 15 January 2022 (UTC)

The example is a bit vague. Is it a book? "Issue" is irrelevant. Is it a serial? "Work" is missing. And so on. 65.88.88.71 (talk) 17:53, 15 January 2022 (UTC)

AManWithNoPlan, is this a real or hypothetical problem? Cite journal with issue works fine ("title". work (1).), as does cite magazine ("title". work. No. 1.). It is always useful to provide a real-world example and link to an article where it is or would be used. – Jonesey95 (talk) 20:12, 15 January 2022 (UTC)

I have seen it a couple times. Some book series use number so people will use that instead of volume. Here is an example:

Patrie, James (1982), The Genetic Relationship of the Ainu Language, Oceanic Linguistics Special Publications, University of Hawai'i Press, ISBN 978-0-8248-0724-5, JSTOR 20006692. One could argue that volume is the correct parameter. AManWithNoPlan (talk) 21:03, 15 January 2022 (UTC)

Thanks for the concrete example. It seems like |issue= should be displayed in that citation; maybe that's the real problem (I really want to write "issue", but I am resisting the urge) here. There are workarounds, of course, like using {{cite journal}} with |mode=cs2, but there is no obvious way to know that a workaround is needed unless there is an error message or a tracking category. I would rather see |issue= displayed in {{citation}} in this situation, which would obviate the need for tracking. – Jonesey95 (talk) 21:20, 15 January 2022 (UTC)

Metadata only supports |issue= in the periodical templates. The above example looks like a book that is number 17 of the series. Converting to {{cite journal}} (or {{citation}} with |journal=) will cause |series= to be dropped from the metadata; it's only supported by book citations. At jstor, the sequence number becomes part of the title so one might rewrite the above citation:

{{citation |surname=Patrie |given=James |title=No. 17. The Genetic Relationship of the Ainu Language |series=Oceanic Linguistics Special Publications |publisher=University of Hawai'i Press |year=1982 |isbn=978-0-8248-0724-5 |jstor=20006692 |postscript=.}}

Patrie, James (1982), No. 17. The Genetic Relationship of the Ainu Language, Oceanic Linguistics Special Publications, University of Hawai'i Press, ISBN 978-0-8248-0724-5, JSTOR 20006692.

or:

{{citation |surname=Patrie |given=James |title=The Genetic Relationship of the Ainu Language |series=Oceanic Linguistics Special Publications, No. 17 |publisher=University of Hawai'i Press |year=1982 |isbn=978-0-8248-0724-5 |jstor=20006692 |postscript=.}}

Patrie, James (1982), The Genetic Relationship of the Ainu Language, Oceanic Linguistics Special Publications, No. 17, University of Hawai'i Press, ISBN 978-0-8248-0724-5, JSTOR 20006692.

If there is a great quantity of |issue= in book citation templates, we might want to treat them as we do 'ignored' |chapter= (and aliases) parameters. This search (times out) suggests that we might want to do that because it will help to catch other misuses of {{cite book}}.

—Trappist the monk (talk) 23:09, 15 January 2022 (UTC)

The example is malformed. The correct parameter is |volume= not |issue=. These are terms with specific, longstanding meaning in publishing and bibliography. A book series consists of volumes. Book series volumes however may or may not consist of issues. In periodicals, "series" has a different meaning, and periodical series volumes almost always consist of issues. In book series, "issue" is never classified (and therefore cited) without the enclosing volume. So "volume" is the necessary value. In periodical series, "volume" is never classified without the included issues. So "issue" is the necessary value. Instead of arbitrarily redefining longstanding practice that is unrelated to citations, ensure that the citation system conforms, and the documentation is clear regarding how and why. This is a simple error, that is made more complicated by the use of {{citation}}, which does not explicitly signal the type of work to the editor. 68.173.76.118 (talk) 01:54, 16 January 2022 (UTC)

Like pretty much every dogmatic statement that one might want to make about the structure that bibliographic metadata must have, this one is wrong. There are definitely periodicals that use "issue" or "number" without a "volume" or "tome" or "heft" or whatever you might call it, and other periodicals that use "volume" without an "issue" or equivalent. (I just took part in setting up a new journal. As part of the setup, we had to choose whether to use only volumes, or both volumes and issues. We ended up choosing both but we could easily have ended up with volumes only and no issues. If it did, you could lie and say that each issue is issue 1 of its volume, but that would be a lie made to get the data to fit your Procrustean framework rather than an accurate representation of the data.) There are also book series that use "volume" for the number of a book within that series, in which there exist multi-volume books that also use "volume" as the number of a volume within the book. I don't remember ever seeing a book series that called the numbering of the books within that series "issues" without a volume, but I would be unsurprised to see one that did. In the example The Genetic Relationship of the Ainu Language, the source JSTOR 20006692 clearly states that it is "number" 17 in its series, "Oceanic Linguistics Special Publications". My preference for that would be to pretend that it is really a volume number and set |series=Oceanic Linguistics Special Publications |volume=17, but I can easily imagine that other editors would prefer to hue more closely to what the source actually says about its metadata. When they do, our templates should be prepared to handle it and do something reasonable rather than just dropping the number on the floor. —David Eppstein (talk) 02:10, 16 January 2022 (UTC)

I suppose long-standing industry practice is dogmatic as agreed by the practitioners. When book series are classified, the components are known as "volumes". These volumes may consist of sub-volumes/sub-parts, which subdivisions may be also called "issues", "volumes" (again), "parts", or whatever else. The important item among these, as far as classifying the work, and therefore finding it, is the volume. The vague "number" in this case means "volume number". When periodicals are classified, the important item is the issue. These may be collected in "volumes", "annuals", "collections" or whatever. But "series" in periodicals means something different, and is not related to "volume" etc. the way book series are. You can name your periodical issue anyway you want, including "volume" or "summer" or "orange". For purposes of classification (and eventual citation) that is still the issue. The vague "number" in this case means "issue number". So do not be surprised if your journal is classified by metadata providers as "issue: 'Volume 1'", for example. 68.173.76.118 (talk) 02:45, 16 January 2022 (UTC)

website or publisher parameter

Hi all.. May i know which parameter should be used in this news: [3], "website=Badminton World Federation" or "publisher=Badminton World Federation"? Stvbastian (talk) 11:16, 16 January 2022 (UTC)

It seems that {{cite press release}} is better, if the original is live. If it is not live, your source is the archive. Use {{cite web}} with |website=Wayback Machine. The publisher of that website is the Internet Archive. 172.254.162.90 (talk) 13:58, 16 January 2022 (UTC)

Never put Wayback Machine in |website=. Ever. Use the original website name, which is |website=Badminton World Federation. Izno (talk) 16:13, 16 January 2022 (UTC)

This is wrong. If the information is found in an web archive, not at the original website, that is what goes in the citation. That is how the reader will verify it, by visiting the archive's website. The archive is the work that contains the pertinent info. Your suggestion goes against any notion of citing verifiable information. Paramount is to show where the editor found the information, not where it may have existed some time in the past. 65.88.88.201 (talk) 16:33, 16 January 2022 (UTC)

Your particular opinion on the use of archives is known not to match the community's. Do not give advice framed generally which does not. Izno (talk) 16:58, 16 January 2022 (UTC)

My opinion has nothing to do with the use of archives. It has to do with actual, real-world verifiability of a citation. The WP:SAYWHEREYOUREADIT guideline regarding second-hand sources is a mess of contradiction and assumptions, especially regarding web-based archives. Plus even that badly-worded guideline does not forbid citing such archives; it presumes that one does not need to. There is even the added qualification, "So long as you are confident that you read a true and accurate copy, ..." This is worse than CS1 documentation. Luckily, WP:V being a policy, trumps the vague nonsense. 65.88.88.201 (talk) 17:34, 16 January 2022 (UTC)

I'd use {{cite press release}} with |publisher= (as "Badminton World Federation" does not need to be italicized), and include the live URL and archive-URL, like this:

• {{cite press release |last=Alleyne |first=Gayle |url=https://bwfbadminton.com/news-single/2017/03/19/bwf-launches-new-event-structure/ |title=BWF Launches New Event Structure |date=19 March 2017 |publisher=[[Badminton World Federation]] |url-status=live |archive-url=https://web.archive.org/web/20171201164159/http://bwfbadminton.com/news-single/2017/03/19/bwf-launches-new-event-structure/ |archive-date=1 December 2017}}
• Alleyne, Gayle (19 March 2017). "BWF Launches New Event Structure" (Press release). Badminton World Federation. Archived from the original on 1 December 2017.

GoingBatty (talk) 16:23, 16 January 2022 (UTC)

This is also incorrect. If a citation with the live URL pre-existed, but the URL is now dead, one may add the archive-related parameters. This is an editing convenience, rather than having to reformat/rewrite the citation. It is also true in the sense that the original had been visited when it was live. However, if this is a new citation with an archived URL, using the now dead original is misleading. The editor never actually found the information in the original website. It was found in a web archive that contains it. The verifiability of the wikitext depends on the archive website, not the original. The reliability of the cited information depends first, on the reliability of the archive. 65.88.88.201 (talk) 16:45, 16 January 2022 (UTC)

The live URL is not dead - try clicking the link. GoingBatty (talk) 16:59, 16 January 2022 (UTC)

Then your solution is fine. I followed the link given by the OP, which lands at the Wayback Machine. Also searched the section "News" on the BWF website, but found nothing prior to 2019. 65.88.88.201 (talk) 17:18, 16 January 2022 (UTC)

The |website= and |work= parameters are useful in determining the reliability of the source only if they refer to the original web site, not to the archival site. --Shmuel (Seymour J.) Metz Username:Chatul (talk) 21:17, 16 January 2022 (UTC)

Is that so in fact? Or is it a convenient shortcut to consider archive services automatically reliable? Consider that this discussion is about online sources, which may be subject to change. These online sources are then archived via other online resources whose particulars may also be subject to change. Isn't it prudent to examine such relationships more closely and refrain from making blanket statements about reliability? Are even all online archive services of online sources similar in methodology? And how do any differences in archiving methodology affect an archive's validity and/or reliability? There are some aspects to consider. And then there are other questions, of a more technical sort. 71.105.141.131 (talk) 01:11, 17 January 2022 (UTC)

RFC on updating modules has been closed

The RFC on whether to update the CS1 modules has been closed as "There is support for most changes proposed, and they may be rolled out. There is support for most changes proposed, and they may be rolled out. There is also support for the idea that most typical changes to cs1/2 are uncontroversial and don't need to undergo routine VPR RfCs to be rolled out." The exception to the approved changes is this: "there is no consensus on removal of deprecated parameters in this discussion, and further discussion will be necessary to roll that part out."

The list of proposed changes at that RFC is copied here (from that page):

list of prospective changes

changes in Module:Citation/CS1/sandbox detect generic author, editor, etc names; discussion emit error when |first= is wikilinked; discussion add Category:CS1 tracked parameter: $1 properties tracking category; discussion revise how date month-name auto-translation is enabled; discussion and discussion add support to allow editors to see citations that emit properties cats; discussion |url-status= without |archive-url= maint cat: Category:CS1 maint: url-status; discussion more consistent support of |type= with {{cite speech}}; discussion check all but url-holding and insource-locator parameters for inappropriate urls; discussion recognize stand-alone |script-chapter= in {{cite encyclopedia}}; discussion fix flaw in ref-duplicates-default detection; discussion added error summary preview; discussion reworked error messaging; discussion fix |archive-url= preview url; discussion tweaked IETF-like language handling; discussion changed formatting of volume and issue for non-journals; discussion moved hyphen_to_dash() to ~/Utilities; discussion detect leading '=' as extraneous punctuation; discussion changes in Module:Citation/CS1/Configuration/sandbox detect generic author, editor, etc names add Category:CS1 tracked parameter: $1 properties tracking category remove support for unused |isbn13= and |ISBN13=; discussion remove support for previously deprecated parameters |booktitle=, |chapterurl=, |episodelink=, |mailinglist=, |mapurl=, |nopp=, |publicationdate=, |publicationplace=, |serieslink=, |transcripturl= add support for nrf-gg, nrf-je language codes; discussion revise how date month-name auto-translation is enabled add support to allow editors to see citations that emit properties cats removed reliance on .error; discussion |url-status= without |archive-url= maint cat: Category:CS1 maint: url-status add support for |ssrn-access=; discussion add ab to script_lang_codes{}; more consistent support of |type= with {{cite speech}} check all but url-holding and insource-locator parameters for inappropriate urls add yue to script_lang_codes{}; added bogus name "Verfasser" to the list; discussion add keyword "deviated" to |url-status=; discussion added preview error summary added 'Login • Instagram' to generic titles; removed crh, nrg-gg, and nrf-je from language override added comma between volume and number; discussion added Mr. Privacy Statement, Ms. Cookie Policy and Dr. Submitted Content to list of bogus names; discussion revise kerning; discussion i18n |script-<param>= error message supplements; discussion added 'Usurped title' to generic titles; discussion added add bogus names: 'author', 'collaborator', 'contributor', 'editor', 'interviewer', 'translator'; discussion changes in Module:Citation/CS1/Whitelist/sandbox (last update 2021-05-25) removed deprecated parameter |transcripturl= deprecated |lay-date=, |lay-format=, |lay-source=, |lay-url=; discussion changes in Module:Citation/CS1/Date validation/sandbox extend allowed dates in |pmc-embargo-date= validation to two years; discussion revise month-name validation; add support to allow editors to see citations that emit properties cats; changes in Module:Citation/CS1/Identifiers/sandbox add support for |ssrn-access=; reworked error messaging; fix false positive doi error detection; discussion strip accept-this-as-written markup from all identifiers for metadata; discussion changes in Module:Citation/CS1/Utilities/sandbox (last update 2021-01-09) add support to allow editors to see citations that emit properties cats; reworked error messaging; added hyphen_to_dash() moved from main module; changes in Module:Citation/CS1/COinS/sandbox strip accept-this-as-written markup from |title=; changes in Module:Citation/CS1/sandbox/styles.css (last update 2021-01-09) Removed reliance on .error; Removed extra kerning classes; Removed unused cs1-subscription/registration styles; Moved .citation styles from MediaWiki:Common.css; Removed <code> selector;

To me, it looks like the next step is to possibly restore the sandboxes to their state as of 28 November 2021 (I think; this is the original RFC posting date), then back out the removal of support for the deprecated parameters. I encourage editors here to look at this outcome as positive. Removal of long-deprecated parameters has been delayed, but that is not a big deal. We will get our first module update in at least half a year, with many updates and improvements. – Jonesey95 (talk) 01:25, 17 January 2022 (UTC)

Changes since 28 November 2021:

• Module:Citation/CS1/sandbox – addition of a couple of TODO notes – no change needed
• Module:Citation/CS1/Configuration/sandbox – bump PMC limit – no change needed
• Module:Citation/CS1/Whitelist/sandbox – no changes
• Module:Citation/CS1/Date validation/sandbox – no changes
• Module:Citation/CS1/Identifiers/sandbox – no changes
• Module:Citation/CS1/Utilities/sandbox – no changes
• Module:Citation/CS1/sandbox/styles.css – no changes
• Module:Citation/CS1/Suggestions/sandbox – no changes

In the above list, [removal of] support for previously deprecated parameters |booktitle=, |chapterurl=, |episodelink=, |mailinglist=, |mapurl=, |nopp=, |publicationdate=, |publicationplace=, |serieslink=, |transcripturl= is only listed under ~/Configuration. Those parameters were listed above because support for them was withdrawn at this edit to Module:Citation/CS1/Whitelist (not by me). Removal of those parameters from ~/Configuration merely completes the process. Restoring them to ~/Configuration/sandbox will not make those parameters work again.

Apparently, no one has noticed that these parameters don't work. An example with |chapterurl=, |nopp=, |publicationdate=, and |publicationplace=:

{{cite book |chapter=Chapter |chapterurl=http://www.example.com |title=Title |publicationdate=2022 |publicationplace=Who knows |pages=23–56 |nopp=yes}}

"Chapter". Title. Who knows. 2022. 23–56. {{cite book}}: External link in |chapterurl= (help); Unknown parameter |chapterurl= ignored (|chapter-url= suggested) (help); Unknown parameter |nopp= ignored (|no-pp= suggested) (help); Unknown parameter |publicationdate= ignored (|publication-date= suggested) (help); Unknown parameter |publicationplace= ignored (|publication-place= suggested) (help)CS1 maint: location missing publisher (link)

You should see four Unknown parameter error messages; do you?

—Trappist the monk (talk) 02:22, 17 January 2022 (UTC)

I do see unknown parameter errors. I think that it would be foolish of us to ignore the explicit guidance in the RFC close, so IMO we should, even though it may seem dumb, restore those deleted parameters as deprecated, and then go through a brief discussion here to formally remove them. – Jonesey95 (talk) 02:30, 17 January 2022 (UTC)

But didn't we already do that? See Help talk:Citation Style 1/Archive 75 § further deprecations. The close says: So I think there is no consensus on removal of deprecated parameters in this discussion, and further discussion will be necessary to roll that part out. What kind of discussion? Another RfC? A discussion here on this page? Something else? Where?

—Trappist the monk (talk) 14:45, 17 January 2022 (UTC)

That discussion was about deprecating them. We did that. AFAICT, we have not yet formally decided to remove (unsupport) those parameters, or if we did, the RFC overturned it and says that "further discussion" is necessary to perform that removal. Rather than fight the hurricane, we should restore the parameters as "deprecated", and then have a new discussion about changing them to "unsupported". I don't want to jump through these absurd hoops either, but WP is run by consensus, and sometimes it is better to jump through hoops than to bite and growl. The only damage we take will be to our sense of what is right; we can handle it. – Jonesey95 (talk) 17:54, 17 January 2022 (UTC)

since these parameters are not used anywhere, I see no reason to add them back in. While removal might have been an error, adding them back is yet another one. AManWithNoPlan (talk) 15:23, 20 January 2022 (UTC)

The reason to add them back in is that the RFC close says that we have to. It's that simple. This is not a hill we should die on; let's not throw out the baby with the bathwater; choose your metaphor. It should be simple to put them back in as deprecated, have a brief discussion here about removing them, and then remove them. It's just jumping through a couple of hoops. Let's not let our wounded pride and self-righteousness cause long-term damage. To be clear: I think doing these steps is wrong and dumb, but it's our best way through. – Jonesey95 (talk) 16:05, 20 January 2022 (UTC)

Before this thread started, I had thought to do a sort-of status-quo update where the nonfunctional parameters would remain in ~/Configuration as they are now but not reinstate them in ~/Whitelist. Then, after some period of time, raise a discussion somewhere about removal of these vestiges of the deprecation (letting the sleeping-dog lie, as it were).

—Trappist the monk (talk) 16:51, 20 January 2022 (UTC)

I also see removal of one deprecated parameter listed in the Whitelist section. If we undid that change (I have done so in the Whitelist sandbox) and the change to Configuration, I think that would meet with the letter of the RFC close. – Jonesey95 (talk) 16:57, 20 January 2022 (UTC)

Ok, |transcripturl= switches back to deprecated:

{{cite episode/new |series=Series |transcript=Transcript |transcripturl=//example.com}}

Series. Transcript. {{cite episode}}: External link in |transcripturl= (help); Unknown parameter |transcripturl= ignored (|transcript-url= suggested) (help)

The others remain as unknown which is consistent with the current status quo:

{{cite book/new |chapter=Chapter |chapterurl=http://www.example.com |title=Title |publicationdate=2022 |publicationplace=Who knows |pages=23–56 |nopp=yes}}

"Chapter". Title. Who knows. 2022. 23–56. {{cite book}}: External link in |chapterurl= (help); Unknown parameter |chapterurl= ignored (|chapter-url= suggested) (help); Unknown parameter |nopp= ignored (|no-pp= suggested) (help); Unknown parameter |publicationdate= ignored (|publication-date= suggested) (help); Unknown parameter |publicationplace= ignored (|publication-place= suggested) (help)CS1 maint: location missing publisher (link)

Module:Citation/CS1/Suggestions/sandbox supports these unknown parameters whereas the live Module:Citation/CS1/Suggestions does not.

So the question now is: When do we do this update?

—Trappist the monk (talk) 18:00, 20 January 2022 (UTC)

ASAP. Headbomb {t · c · p · b} 18:12, 20 January 2022 (UTC)

Now. The RFC approved the list of changes, and above discussion has been up for almost four days. The only functional risk I can see in doing it now is that we are getting a new version of MediaWiki right about now as well, and it might be a bit tricky to tease out cause and effect if something goes a little pear-shaped. – Jonesey95 (talk) 00:08, 21 January 2022 (UTC)

For the record: the modules were updated per the discussion above on 22 January 2022. – Jonesey95 (talk) 00:14, 23 January 2022 (UTC)

Vancouver

Hi. Question about Vancouver-style fields (vauthors/veditors): can you point me to documentation or demonstration about reformatting the parser output? I'm looking for reasons to avoid enclosing the whole content in double parentheses:

Special markup can be used to enforce that a value will nonetheless be accepted as written. The markup for this is ((<value>)), i.e., wrap the entire parameter value in two sets of parentheses.

Thanks. fgnievinski (talk) 20:01, 25 October 2021 (UTC)

@Fgnievinski: I have moved your question to a page where it may be answered. --Izno (talk) 19:34, 19 January 2022 (UTC)

Fgnievinski, if you still have a question, an example citation, or a link to a page and a citation number about which you have questions, would help us answer your query. – Jonesey95 (talk) 00:09, 21 January 2022 (UTC)

Jonesey95 this issue came up in the context of developing a citation style language file (CSL) using Wikipedia's citation template: [4]. fgnievinski (talk) 03:49, 22 January 2022 (UTC)

Handle rtl names

If I made citation to Arabic book like

أبو حيان الغرناطي, محمد بن يوسف بن علي بن يوسف بن حيان أثير الدين الأندلسي (1990). رجب عثمان محمد; رمضان عبد التواب (eds.). ارتشاف الضرب من لسان العرب (1 ed.). مكتبة الخانجي بالقاهرة.

The commas direction is left-to-right but the text is right-to-left in "أبو حيان الغرناطي," and "رجب عثمان محمد;". We can not change the commas in Configuration file to be right-to-left because we use the same templates to cite English books.

So I suggest 2 sets of separator configurations one for default left-to-right and another to right-to-left and using is_rtl function of Module:Unicode data to determine the direction of the name and putting the right separator.--حبيشان (talk) 06:49, 19 January 2022 (UTC)

@حبيشان: I have moved your question to a page where it may be answered. --Izno (talk) 19:34, 19 January 2022 (UTC)

Are we talking about replacing , and ; with their Arabic versions: ، (U+‎060C ARABIC COMMA) and ؛ (U+‎061B ARABIC SEMICOLON)? ar:Module:Citation/CS1/Configuration specifies و (U+‎0648 ARABIC LETTER WAW) as the separator used in lists.

I'm not sure that using Module:Unicode data is the best plan. Instead, because Lua is a native Latn-script language, it might be sufficient to do a simple is_Latn() function that uses the built-in string.find(<parameter_value>, '%a'). Any Latn-script letter character would be sufficient to force cs1|2 to use Latn-script separator characters otherwise use the local language's separator characters which would be specified in ~/Configuration.

—Trappist the monk (talk) 23:26, 19 January 2022 (UTC)

@Trappist the monk: OK, But using is_rtl making the template universal. English Wikipedia may cite Arabic Book also Arabic Wikipedia cite English books how about citing Cyrillic, Thai or Chinese in Arabic Wikipedia these are not Latin-scripts but left-to-right? --حبيشان (talk) 16:49, 26 January 2022 (UTC)

|citation= is not a valid alias of: |quote=

Is there a valid reason? Does it need to be added to the aliases in the template to remove this error? The purpose of adding it as an alias here is to make easier to find, not to allow users to use as in the template. The RedBurn (ϕ) 09:40, 21 January 2022 (UTC)

As far as I know, |citation= has never been a cs1|2 parameter. I do not know what you mean by: The purpose of adding it as an alias here is to make easier to find, not to allow users to use as in the template. Clarify?

—Trappist the monk (talk) 12:16, 21 January 2022 (UTC)

I mean easier to find among the other template parameters. But users shouldn't be allowed to use it as a parameter (in source mode) instead of quote=. The RedBurn (ϕ) 12:24, 21 January 2022 (UTC)

@Trappist the monk: can you confirm that it has to be added in the template first? Is that a policy or just how the error detection works right now? The RedBurn (ϕ) 12:21, 21 January 2022 (UTC)

"I mean easier to find among the other template parameters" But it's not a parameter to begin with. Why would a non-existent parameter need to be 'easier to find' when it doesn't even exist? Headbomb {t · c · p · b} 12:54, 21 January 2022 (UTC)

Also, these terms have different meanings and cannot alias each other. 71.247.146.98 (talk) 12:59, 21 January 2022 (UTC)

In cs1|2 an alias of a parameter is a fully functional parameter in its own right. For example, the canonical form |page= has an alias |p= so

{{cite book |title=Title |page=123}}

Title. p. 123.

and

{{cite book |title=Title |p=123}}

Title. p. 123.

produce the exact same rendering. Adding yet-another-alias to a template suite that already has too many aliases is too many aliases. But, if there is a semantic value in the alias for an editor reading a cs1|2 template as wikitext then we might consider adding another alias. It is not possible to have non-alias aliases in cs1|2.

If you are asking about that abomination that is TemplateData, then perhaps another venue would be more appropriate; I don't know what that venue might be.

—Trappist the monk (talk) 13:03, 21 January 2022 (UTC)

I am indeed actually talking about TemplateData, I didn't notice that Template talk:Cite book/TemplateData redirects here. Sorry for the confusion this created with an actual parameter alias, which I specifically didn't want to create. I created this discussion after adding a TemplateData alias for |quote in Template:Cite_book/TemplateData, which you actually reverted afterward with the message "not an alias". The RedBurn (ϕ) 21:53, 21 January 2022 (UTC)

TemplateData can be confusing. The MediaWiki developers erroneously decided that it should live in templates' documentation, even though it is programming code that affects how the Visual Editor interacts with templates. By adding an alias to that template's TemplateData code, you were telling Visual Editor something that was untrue. That is why you were reverted. – Jonesey95 (talk) 23:02, 21 January 2022 (UTC)

RfC: Block reFill until fixed

Wikipedia:Village_pump_(proposals)#RfC:_Block_reFill_tool_until_fixed -- GreenC 21:58, 21 January 2022 (UTC)

Surname vs last

Would it be considered valuable to convert surname/given to last/first on pages that contain a mix of both types. One of the tasks of citation bot has always been "harmonize" styles. Surname is used on a tiny fraction of a percent of pages compared to last/first. AManWithNoPlan (talk) 13:40, 22 January 2022 (UTC)

I think this should be asked at WP:VP? I believe that is where CS1/2 development is discussed. First you would need an RfC to ascertain whether this is an uncontroversial change. If it is controversial a second RfC can decide its merits. Not joking, btw. 69.203.140.37 (talk) 13:55, 22 January 2022 (UTC)

I would be against this change. Particularly if it were applied to an article that consistently used surname/given but had had a ref with last/first added. Kanguole 14:00, 22 January 2022 (UTC)

Changing one alias or supported parameter name to a different alias or supported parameter name that is functionally equivalent will get you drawn and quartered in the public square if you get caught doing it, as we saw when we tried to deprecate |accessdate= and its five remaining unhyphenated siblings. – Jonesey95 (talk) 14:05, 22 January 2022 (UTC)

I think that it would would want to only be done if there was an overwhelming majority of first/last. AManWithNoPlan (talk) 14:46, 22 January 2022 (UTC)

This is not a valid argument when it comes to CS1/2, as Jonesey95 has suggested. Hence the earlier WP:VP proposition. Discussions here are more "theoretical", as in, what would actually happen if software development was unrelated to petulance. 65.88.88.57 (talk) 18:30, 22 January 2022 (UTC)

@AManWithNoPlan: I see you've started doing this. Please stop. Kanguole 20:40, 23 January 2022 (UTC)

@Kanguole: I think I am only doing it on ones with a clearly dominant style. Although my method of counting had a bug, which resulted in a couple pages, with a majority, but not massive majority being done. AManWithNoPlan (talk) 20:44, 23 January 2022 (UTC)

Even so, you need to establish consensus to do this. Kanguole 20:46, 23 January 2022 (UTC)

CITVAR encourages converting the minority to match the majority, although my counter was off which resulted in a couple of minority wins. AManWithNoPlan (talk) 20:55, 23 January 2022 (UTC)

CITEVAR does not justify changing between parameter aliases – you need consensus for that. Kanguole 20:58, 23 January 2022 (UTC)

It always amazes me what causes the most trouble on Wikipedia land. Flat-earthers get more respect than minor-editors 😀🤣😂. I will not do such edits again. AManWithNoPlan (talk) 21:05, 23 January 2022 (UTC)

@AManWithNoPlan: Note that you weren't marking such edits as minor. Some editors get concerned with edits that flood their watchlist that don't change how the article is displayed. GoingBatty (talk) 21:09, 23 January 2022 (UTC)

@GoingBatty: of course, then I would be accused of trying to hid them as "minor". AManWithNoPlan (talk) 21:12, 23 January 2022 (UTC)

Standardizing parameter names is clearly a (minimally) valuable activity. There is a group of editors, however, who feel negatively about the addition of diffs to their watchlists caused by this sort of editing to improve CITEVAR consistency, and their view is that the negative value of their watchlist having more entries outweighs the positive value of the citation parameter improvements. That's the state of things as of last year, in any event. – Jonesey95 (talk) 02:06, 24 January 2022 (UTC)

Is it really as of last year? Seems like a continuing practice. 50.74.109.2 (talk) 12:46, 24 January 2022 (UTC)

Bump PMID limits to 4000000

To prevent these bogus errors

• Chaves-Medina MJ, Gómez-Ospina JC, García-Perdomo HA (2021). "Molecular mechanisms for understanding the association between TMPRSS2 and beta coronaviruses SARS-CoV-2, SARS-CoV and MERS-CoV infection: scoping review". Archives of Microbiology. 204 (1): 77. doi:10.1007/s00203-021-02727-3. PMC 8709906. PMID 34953136.

Headbomb {t · c · p · b} 14:49, 22 January 2022 (UTC)

Generic names change

Why is "Houser" a generic |last= name?

I recently encountered an erroneous warning at the Super Mario 64 article. Can someone explain why we have "Houser" listed as a generic name? I have suppressed the error for now. — Coolperson177 (t|c) 17:05, 22 January 2022 (UTC)

@Coolperson177: if I were to guess, I'd say that Houser contains within it the word user, which is a generic name. If so, this would be a false positive. Imzadi 1979 → 17:24, 22 January 2022 (UTC)

Interesting. So we're using regex to detect generic names? — Coolperson177 (t|c) 17:32, 22 January 2022 (UTC)

For the most part, no. Simple string.find because it's faster and for most of the generic names is sufficient. For 'user' and 'superuser', Lua patterns.

—Trappist the monk (talk) 17:41, 22 January 2022 (UTC)

that↑. I've tweaked the sandbox some:

{{cite book/new |title=title |last=Houser}}

Houser. title.

{{cite book/new |title=title |last=a user}}

a user. title. {{cite book}}: |last= has generic name (help)

{{cite book/new |title=title |last=user login}}

user login. title. {{cite book}}: |last= has generic name (help)

{{cite book/new |title=title |last=a user login}}

a user login. title. {{cite book}}: |last= has generic name (help)

Also changed 'super' to various flavors of 'super user' because Super is also a surname:

{{cite book/new |title=title |last=Super}}

Super. title.

{{cite book/new |title=title |last=superuser}}

superuser. title. {{cite book}}: |last= has generic name (help)

{{cite book/new |title=title |last=super user}}

super user. title. {{cite book}}: |last= has generic name (help)

{{cite book/new |title=title |last=super-user}}

super-user. title. {{cite book}}: |last= has generic name (help)

Later this weekend, I update the live module.

—Trappist the monk (talk) 17:41, 22 January 2022 (UTC)

OK, thanks for explaining. — Coolperson177 (t|c) 17:50, 22 January 2022 (UTC)

add "Nienhauser'" to the list?

"Nienhauser" is another false positive.

{{cite book |last = Boorman |first = Howard L., Richard C. Howard, Associate Editor. |year = 1967 |title = Biographical Dictionary of Republican China Volume I: Ai-Ch'ü|publisher = Columbia University Press| location = New York |isbn = 0-231-08958-9|ref = none}}. , which finds fault with "first= ".ch (talk) 23:22, 23 January 2022 (UTC)

@CWH: Umm, what? cs1|2 finds fault with this:

{{cite book |last = Boorman |first = Howard L., Richard C. Howard, Associate Editor. |year = 1967 |title = Biographical Dictionary of Republican China Volume I: Ai-Ch'ü|publisher = Columbia University Press| location = New York |isbn = 0-231-08958-9|ref = none}}

Boorman, Howard L., Richard C. Howard, Associate Editor. (1967). Biographical Dictionary of Republican China Volume I: Ai-Ch'ü. New York: Columbia University Press. ISBN 0-231-08958-9. {{cite book}}: |first= has generic name (help)CS1 maint: multiple names: authors list (link)

not because of 'Nienhauser' (doesn't exist in that template) but because |first= is wholly malformed and contains the word 'Editor'. The name holding parameter |first= should hold only the given names and/or initials of the person whose surname is in |last=. One person per |last= / |first= pair.

Our article, Biographical Dictionary of Republican China, of which you appear to be the primary author, describes Boorman as an editor, not an author so perhaps this:

{{cite book |editor-last=Boorman |editor-first=Howard L. |editor2=Howard |editor-first2=Richard C. |date=1967 |title=Biographical Dictionary of Republican China |volume=I: Ai-Ch'ü |publisher=Columbia University Press |location=New York |isbn=0-231-08958-9 |ref=none}}

Boorman, Howard L.; Howard, Richard C., eds. (1967). Biographical Dictionary of Republican China. Vol. I: Ai-Ch'ü. New York: Columbia University Press. ISBN 0-231-08958-9.

—Trappist the monk (talk) 23:59, 23 January 2022 (UTC)

Apologies - my bad. I should have made clear that I was bringing up two different things. Thanks for explaining the problem with more than one editor in the Boorman parameter. Is there another parameter that would get around the problem rather than re-working all the parameters in all the references in all the articles that have this and other edited books? Maybe "authors="?

The "Nienhauser" question came up at Dream of the Red Chamber. Following the directions, the I "solved" the problem here by adding "((Nienhauser))." In any case, thanks again for your help.ch (talk) 16:56, 24 January 2022 (UTC)

@CWH: Use of |authors= is discouraged. There used to be |editors= but support for that has been withdrawn and, someday, support for |authors= will also be withdrawn. Individual authors should be named in individual |lastn= / |firstn= pairs or in |authorn=. Same for editors, interviewers, contributors, translators.

I have reverted the 'fix' for Nienhauser because the underlying issue has been fixed.

—Trappist the monk (talk) 18:39, 24 January 2022 (UTC)

” someday, support for |authors= will also be withdrawn.” That seems like a bad idea, considering first and last name are not universal concepts in the world (middlename, family name first, two familynames, no familyname are all concepts used by various cultures). There is a reason that ppl are advising developers to use a single namefield instead of a forced first name lastname, combo these days. —TheDJ (talk • contribs) 01:33, 26 January 2022 (UTC)

The enumerated |authorn= parameters won't be going away. All of those middlename, family name first, two familynames, no familyname ... concepts are easily handled by the enumerated parameters; one person per enumerated parameter. |authors= (plural) is free-form and, as you note, human names aren't standardized. To make |authors= usable by editors who consume cs1|2 citation via the metadata, some sort of code that is clever enough to extract the names of individual humans from the free-form list is needed. Alas, because the list of names is free-form, one cannot rely on standardized name separators. I do not have skill enough to write that code, perhaps you or someone you know has that skill. Write that code and we'll implement it.

—Trappist the monk (talk) 01:58, 26 January 2022 (UTC)

Would it be feasible to have |author1=, then |author-others=}}, or some such? In the Boorman example above, for instance, there were several other editors, but it would have taken more time than it was worth to me to list them all separately. OK, I was lazy, but it was a lazy man who invented the wheel. And the cites would still be to Boorman. ch (talk) 04:13, 26 January 2022 (UTC)

Template:Google maps producing error

• {{Google maps | title = Highway 78 – Length and Route | url = https://goo.gl/maps/YatAMR5UgfeqE2MH9 | access-date = January 14, 2022}}

is producing

• Google (January 14, 2022). "Highway 78 – Length and Route" (Map). Google Maps. Google. Retrieved January 14, 2022.

This started happening within the last day or two. - Floydian ^τ _¢ 19:02, 22 January 2022 (UTC)

@Floydian: I noticed the same thing and requested a fix at Template talk:Google maps#Request to remove author parameter a little while ago. GoingBatty (talk) 19:20, 22 January 2022 (UTC)

(edit conflict) I think I can answer your question. It's because of a recent change to Module:Citation/CS1/Configuration that adds error messages for generic names. See this discussion. A template editor needs to fix Template:Google Maps. — Coolperson177 (t|c) 19:26, 22 January 2022 (UTC)

In this case, it's not a generic author as Google is the creator/author of this mapping product and not some spurious placeholder. The template has been fixed to avoid the error messaging. Imzadi 1979 → 19:38, 22 January 2022 (UTC)

There is a problem with {{cite map}}, the parent template and/or the module. If it appeared recently, it may be related to the MW update being currently rolled out, or the (applied?) CS1 update. 65.88.88.57 (talk) 19:32, 22 January 2022 (UTC)

Not an error, per se, but rather an error check that's producing a false positive in this situation. Imzadi 1979 → 19:38, 22 January 2022 (UTC)

Yes, and as it seems that the module was updated today, this could have something to do with it. However GoingBatty had noticed the error earlier? 65.88.88.57 (talk) 19:41, 22 January 2022 (UTC)

Correction: I based the wrong observation above in an example at {{cite map}} that is producing an error. However the example includes the generic term "contributors". Sorry for the mixup. 65.88.88.57 (talk) 19:49, 22 January 2022 (UTC)

That situation is actually also correct: citations to OpenStreetMap should to attributed to the anonymous/pseudonymous editors of that website. Imzadi 1979 → 19:53, 22 January 2022 (UTC)

I don't really see a need to attribute Google as author here; its inclusion in both publisher and work seems sufficient for citation purposes. Izno (talk) 20:11, 22 January 2022 (UTC)

Agreed. Similarly with the generic contributors at the {{cite map}} example. It is obvious that contributors to an open source contribute the info. If one feels strongly about that, they could use a hidden comment in the author field, per common practice. But it may seem as overkill. 65.88.88.57 (talk) 20:20, 22 January 2022 (UTC)

Also note that the other specific-source map templates follow similar practice. {{Bing maps}} forces "Microsoft"/"Nokia" if no author, and {{Mapquest}} insists on "AOL". They are not the map authors, surely? 65.88.88.57 (talk) 20:27, 22 January 2022 (UTC)

Well, take a look at [5] and look through the suggested citations for this very talk page. All but one of the suggested citations use "Wikipedia contributors" as the author. Imzadi 1979 → 00:59, 23 January 2022 (UTC)

Other citation systems may need to state the obvious. Who else but an anonymous "Wikipedia contributors" would contribute to an anonymously authored Wikipedia article? But for Wikipedia, ease and speed in finding sources are important. And simply, trying to find a Wikipedia article by using "Wikipedia contributors" as an author keyword in any search facility is making it harder. Likely, thousands of unrelated hits will have the same "author". Much easier, and far less confusing to the average reader is to find the article by using the article name or part of it. This is a citation system for the average reader, not a specialist tool. This apart from the fact that such generic names are meaningless. 64.18.9.201 (talk) 02:04, 23 January 2022 (UTC)

False positive on CS1 errors: generic name - Neuhäuser

Could someone please tweak the Lua pattern for %f[%a]user%f[%A] in Category:CS1 errors: generic name so it doesn't produce false positives like 10 Canis Majoris and 59 Sagittarii? Simplified version below:

{{cite journal | last1=Tetzlaff | first1=N. | last2=Neuhäuser | first2=R. | title=title | journal=journal }}

• Tetzlaff, N.; Neuhäuser, R. "title". journal.

Thanks! GoingBatty (talk) 21:07, 22 January 2022 (UTC)

'ä' is not in %a.

{{cite book/new |title=title |last=äuser}}

äuser. title.

{{cite book/new |title=title |last=userä}}

userä. title.

{{cite book/new |title=title |last=ä user ä}}

ä user ä. title. {{cite book}}: |last= has generic name (help)

—Trappist the monk (talk) 23:12, 22 January 2022 (UTC)

This would benefit from mw.ustring which does consider it part of %a. Izno (talk) 23:14, 22 January 2022 (UTC)

At the expense of time for every name-holding parameter that has a value in the template.

—Trappist the monk (talk) 23:27, 22 January 2022 (UTC)

I also encountered this with "Hauser" on exception handling:

{{cite journal | last1=Hauser | first1=John | title=title | journal=journal }}

• Hauser, John. "title". journal.

Not sure what is going on, but this feature clearly is buggy. --Mathnerd314159 (talk) 01:50, 23 January 2022 (UTC)

@Mathnerd314159: Hi there! Trappist the monk has kindly already fixed the *user author issue in the sandbox and will be pushing out the fix later this weekend:

{{cite journal/new | last1=Hauser | first1=John | title=title | journal=journal }}

• Hauser, John. "title". journal.

Thanks! GoingBatty (talk) 02:13, 23 January 2022 (UTC)

Alright. I added a notice to Help:CS1 errors#Cite uses generic name, hopefully that will reduce confusion. @Trappist the monk: please revert it when the template is updated. --Mathnerd314159 (talk) 02:52, 23 January 2022 (UTC)

Editorial

Hi again! Articles such as 6th State Duma and 109th United States Congress have references with "Editorial" in the author parameter, which are now included in Category:CS1 errors: generic name. Is there another parameter to use for "Editorial" to differentiate the reference from a news article? Thanks! GoingBatty (talk) 22:22, 22 January 2022 (UTC)

|department= is probably the best parameter for it; |type= only if you must. --Izno (talk) 22:26, 22 January 2022 (UTC)

That said, I would look at such citations with deep suspicion per general V/RS principles. Izno (talk) 22:28, 22 January 2022 (UTC)

For example, editorials in The Wall Street Journal are attributed to "The Wall Street Journal Editorial Board", so it wouldn't be surprising that and editor would attribute the board in a citation. Perhaps this generic author situation needs to be rolled back and discussed further. Imzadi 1979 → 00:55, 23 January 2022 (UTC)

I encountered this false positive, too, in an article where I had |author1=Editorial Board. I've switched it to |department=, but that's a very niche thing for us to police with something as strong as an error message. I'd recommend that the filter trigger only on "editor", not "editorial". {{u|Sdkb}} ^talk 21:00, 23 January 2022 (UTC)

Sdkb |department= should be used as in the 'department' or section of a newspaper e.g. "Life" or "Editorials", hence why I suggested it in Batty's case. It should not be used for the author.

However, this is fixed in the sandbox: Editorial Board. "Title"., so you should undo your change. Izno (talk) 22:52, 23 January 2022 (UTC)

False positive on CS1 errors: generic name - Creditor

Could someone please tweak the Lua pattern for %f[%a]editor%f[%A] in Category:CS1 errors: generic name so it doesn't produce false positives for the last name "Creditor" as it does in Addisyn Merrick? Simplified version below:

{{Cite web|last=Creditor|first=Avi|title=title|url=//example.com}}

• Creditor, Avi. "title".

I found 86 such articles. Thanks! GoingBatty (talk) 00:47, 23 January 2022 (UTC)

I think this generic name flagging needs to be rolled back and discussed further before it's re-implemented. Imzadi 1979 → 00:56, 23 January 2022 (UTC)

There will be false positives. Before posting a note about a particular error, please check with the sandbox version to make sure that whatever you are seeing hasn't already been fixed. I'll be updating the module suite later in the weekend.

{{Cite web/new|last=Creditor|first=Avi|title=title|url=//example.com}}

Creditor, Avi. "title".

—Trappist the monk (talk) 01:07, 23 January 2022 (UTC)

False positive on CS1 errors: generic name - Ruser

The flag on Uyghur genocide#cite_note-AusUygrep628-253 for the |last5=Ruser seems to be a false positive due the name containing "user". There's also a "One or more {{cite web}} templates have maintenance messages" error in the same article that I'm unable to figure out. -- Marchjuly (talk) 13:43, 23 January 2022 (UTC)

Already fixed in the sandbox:

{{cite report/new|last1=Xu|first1=Vicky Xiuzhong|last2=Cave|first2=Danielle|last3=Leibold|first3=James|last4=Munro|first4=Kelsey|last5=Ruser|first5=Nathan|title=Uyghurs for sale: 'Re-education', forced labour and surveillance beyond Xinjiang|url=https://www.aspi.org.au/report/uyghurs-sale|publisher=[[Australian Strategic Policy Institute]]|pages=6–28|date=February 2020}}

Xu, Vicky Xiuzhong; Cave, Danielle; Leibold, James; Munro, Kelsey; Ruser, Nathan (February 2020). Uyghurs for sale: 'Re-education', forced labour and surveillance beyond Xinjiang (Report). Australian Strategic Policy Institute. pp. 6–28.

Two {{cite web}} templates use |url-status=live without |archive-url=. |url-status=live is meaningless without the template also has |archive-url= with an assigned value. The two templates are here and here. Follow the help link in the preview message to learn how to show maintenance messaging.

—Trappist the monk (talk) 14:36, 23 January 2022 (UTC)

Thanks for that Trappist the monk. -- Marchjuly (talk) 21:57, 23 January 2022 (UTC)

False positive on CS1 errors: generic name - Ed

The name Ed is now popping up a CS1 generic name error at Australian green tree frog. This recent change had worse pre-run bug testing than damn Microsoft. Also, why is it necessary to produce a big red error message rather than just a hidden tracking category, which would do the job just as well? It's like some people would rather dick around with the citation templates and make things harder on real content editors than actually productively create content Hog Farm _Talk 22:35, 25 January 2022 (UTC)

Regarding your small question, hidden tracking categories don't get fixed. Simple as that. There's a whole batch of them at Category:CS1 maintenance that only the dedicated actually work on. Izno (talk) 23:04, 25 January 2022 (UTC)

It's one thing to run a warning like this when there's few false positives. But if you're literally just using a string search for "user" (if I read that above correctly), then there's clearly too many false positives to do deface thousands of pages like this. This whole thing feels WP:POINTY. Hog Farm _Talk 23:11, 25 January 2022 (UTC)

Or just naive. ;) I agree though, there was not enough testing on the new additions to the 'there's probably crap in your citation' filter. Izno (talk) 23:15, 25 January 2022 (UTC)

Regarding "Regarding your small question": hidden tracking categories DO get fixed. I have fixed hundreds if not thousands of meassages/warnings/errors. I have watched some of these categories go from thousands of entries to zero. Yes, it requires dedication. The "Script warning" messages do not "deface" the articles since they only appear when an article is being edited. Personally, I like the messages. They inform me when I have introduced an issue. Or when I should look at the hidden categories for additional issues. User-duck (talk) 00:19, 28 January 2022 (UTC)

I do not know why this "generic name" edit was added. But if it is desired, please make it usable. The last time I looked there were over 30,000 articles with generic name "errors". Based on the string search approach, I would guess that a majority are false positives. Several years ago, I worked on articles in a category where the offending items were sub-categorized alphabetically. Maybe something similar could be done for generic names. I just looked it up; it was the Weather box template. The category is "Pages using weather box with unknown parameters". I had emptied this category. I see 19 articles have been added to the category because of "content" edits. User-duck (talk) 00:19, 28 January 2022 (UTC)

You can guess if you want. I just picked five articles at random from the category, and all five (100% of a tiny sample) had real errors like "author=John Smith, editor" or "author=edited by Jane Doe and Helen Brown" or "last=User | first=Super". They were all easy to fix by using parameters like |editor1= or looking at the source to find the actual author name. – Jonesey95 (talk) 00:44, 28 January 2022 (UTC)

False positives with Template:Cite tweet

Using this template like this gives the generic name error, including when its |author= param isn't used. Examples from 2020 Twitter account hijacking:

{{Cite tweet |number=1283591846464233474 |user=TwitterSupport |title= We detected what we believe to be a coordinated social engineering attack by people who successfully targeted some of our employees with access to internal systems and tools. |author=Twitter Support }}

Twitter Support [@TwitterSupport] (July 16, 2020). "We detected what we believe to be a coordinated social engineering attack by people who successfully targeted some of our employees with access to internal systems and tools" (Tweet) – via Twitter. {{cite web}}: |author1= has generic name (help)

{{Cite tweet |number=1283591846464233474 |user=TwitterSupport |title= We detected what we believe to be a coordinated social engineering attack by people who successfully targeted some of our employees with access to internal systems and tools. }}

@TwitterSupport (July 16, 2020). "We detected what we believe to be a coordinated social engineering attack by people who successfully targeted some of our employees with access to internal systems and tools" (Tweet) – via Twitter.

The |author= as passed to Cite web is, respectfully, Twitter Support [@TwitterSupport] and @TwitterSupport -Einstein95 (talk) 04:11, 26 January 2022 (UTC)

@Trappist the monk: The filter (Module:Citation/CS1/Configuration#L-489) is disliking Twitter being present in the author, which these citations use. -Einstein95 (talk) 06:25, 27 January 2022 (UTC)

English variants

I believe we made a change which makes it easier to display variants. This has had the knock on effect for English as well, which we normally hide.

• Title (in Simplified Chinese).
• Title. ... set to English
• Title.

We should probably hide the English variant as well. Izno (talk) 20:16, 22 January 2022 (UTC)

Fixed in sandbox I think:

• Title (in Simplified Chinese). ... set to zh-hans
• Title. ... set to en
• Title. ... set to en-us
• Title (in Spanish, American English, and German). ... set to es, en-us, de

—Trappist the monk (talk) 20:36, 22 January 2022 (UTC)

The adjustment that went out isn't catching unrecognized English codes; 21st New Zealand Parliament has en-NZ (New Zealand English) and .africa has en-ZA (South African English). I know you fiddled a bit with the implementation and from my glance earlier it looked like you were processing after transformation to the plain English name of the language. --Izno (talk) 01:46, 25 January 2022 (UTC)

From the examples above, MediaWiki recognizes en-us:

{{#language:en-us|en}} → American English

but, MediaWiki does not recognize en-NZ:

{{#language:en-NZ|en}} → New Zealand English

Because en-NZ is not recognized by MediaWiki, Module:Citation/CS1 declares it an unknown language and emits the maint cat and message; it does not extract the primary subtag for a retry. This is the problem that I have described below. Working on that.

—Trappist the monk (talk) 02:08, 25 January 2022 (UTC)

I guess we should process the trimmed code's version if there is a subcode and the subcode is not yet recognized? If this checks true emit the trimmed version's language as well as a Category:CS1 maint: trimmed language or similar, and only if false proceed on to unrecognized. Izno (talk) 03:42, 25 January 2022 (UTC)

I think that to categorize every unrecognized language/region pair is probably not a good idea until visual editor stops writing those unrecognized tags (de-DE, sv-SE, etc). These kinds of tags make up the majority of the articles listed in Category:CS1 maint: unrecognized language (305).

—Trappist the monk (talk) 17:30, 25 January 2022 (UTC)

I think you're agreeing with me? The results below seem to indicate it. Izno (talk) 18:05, 25 January 2022 (UTC)

I do not agree that we should have some sort of Category:CS1 maint: trimmed language category. Otherwise, I think we agree.

—Trappist the monk (talk) 19:06, 25 January 2022 (UTC)

Came here to post about this. Looking forward to the fix! czar 21:21, 23 January 2022 (UTC)

It isn't just English. Before the update, there were 109 articles with unrecognized languages. Now: Category:CS1 maint: unrecognized language (305). Apparently, visual editor adds region subtags to every language subtag whether needed or not. Apparently, ve sometimes makes up nonsense IETF-like language tags: es-LA Spanish as spoken in Lao People's Democratic Republic (see this diff). As a guess, I suppose that LA was supposed to mean Latin America but the subtag for that is 419 (see IANA language-subtag-registry file). MediaWiki recognizes es-419 but not es-LA:

Latin American Spanish ← {{#language:es-419|en}}

es-LA ← {{#language:es-LA|en}}

It seems that ve gives every language subtag some sort of region subtag even when there is no need for the region subtag. Samples of the many many tags not recognized by MediaWiki:

de-DE ← {{#language:de-DE|en}} – German as spoken in Germany

sv-SE ← {{#language:sv-SE|en}} – Swedish as spoken in Sweden

mr-IN ← {{#language:mr-IN|en}} – Marathi as spoken in India

All of these and the many many others are categorized in Category:CS1 maint: unrecognized language because MediaWiki does not recognize these tags as valid.

It is desirable to recognize regionally differentiated languages when they are supported by MediaWiki:

Guernésiais ← {{#language:nrf-GG|en}}

Jèrriais ← {{#language:nrf-JE|en}}

Brazilian Portuguese ← {{#language:pt-BR|en}}

European Portuguese ← {{#language:pt-PT|en}}

—Trappist the monk (talk) 15:24, 24 January 2022 (UTC)

Rewritten in the sandbox:

Cite book comparison

Wikitext	{{cite book|language=de-DE|title=Title}}
Live	Title (in German).
Sandbox	Title (in German).

Cite book comparison

Wikitext	{{cite book|language=nrf-GG|title=Title}}
Live	Title (in Guernésiais).
Sandbox	Title (in Guernésiais).

Cite book comparison

Wikitext	{{cite book|language=pt-BR|title=Title}}
Live	Title (in Brazilian Portuguese).
Sandbox	Title (in Brazilian Portuguese).

Cite book comparison

Wikitext	{{cite book|language=pt-PT|title=Title}}
Live	Title (in European Portuguese).
Sandbox	Title (in European Portuguese).

Cite book comparison

Wikitext	{{cite book|language=en-nz|title=Title}}
Live	Title.
Sandbox	Title.

Cite book comparison

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

Cite book comparison

Wikitext	{{cite book|language=English|title=Title}}
Live	Title.
Sandbox	Title.

Cite book comparison

Wikitext	{{cite book|language=ac|title=Title}}
Live	Title (in ac).{{cite book}}: CS1 maint: unrecognized language (link)
Sandbox	Title (in ac).{{cite book}}: CS1 maint: unrecognized language (link)

Cite book comparison

Wikitext	{{cite book|language=jibberish|title=Title}}
Live	Title (in jibberish).{{cite book}}: CS1 maint: unrecognized language (link)
Sandbox	Title (in jibberish).{{cite book}}: CS1 maint: unrecognized language (link)

Cite book comparison

Wikitext	{{cite book|language=ksh-x-colog|title=Title}}
Live	Title (in Colognian).
Sandbox	Title (in Colognian).

Cite book comparison

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

Cite book comparison

Wikitext	{{cite book|language=blackfoot, ksh-x-colog, jibberish, English, portuguese,en-nz, pt-PT, pt-BR, nrf-JE, nrf-GG, mr-IN, sv-SE, de-DE|title=Title}}
Live	Title (in Blackfoot, Colognian, jibberish, English, Portuguese, New Zealand English, European Portuguese, Brazilian Portuguese, Jèrriais, Guernésiais, Marathi, Swedish, and German).{{cite book}}: CS1 maint: unrecognized language (link)
Sandbox	Title (in Blackfoot, Colognian, jibberish, English, Portuguese, New Zealand English, European Portuguese, Brazilian Portuguese, Jèrriais, Guernésiais, Marathi, Swedish, and German).{{cite book}}: CS1 maint: unrecognized language (link)

—Trappist the monk (talk) 17:30, 25 January 2022 (UTC)

Live updated.

—Trappist the monk (talk) 00:47, 26 January 2022 (UTC)

Institution parm needs documentation

It's featured in the examples but not documented. I'm not confident that I could properly do it, myself. Leotohill (talk) 23:06, 22 January 2022 (UTC)

Leotohill Which examples? That parameter does not exist so far as I know. Izno (talk) 23:15, 22 January 2022 (UTC)

Module:Citation/CS1/Whitelist#L-98 which has a note wondering if we should constrain that parameter to {{cite thesis}} and Module:Citation/CS1/Configuration#L-315 as an alias of |publisher=.

—Trappist the monk (talk) 23:21, 22 January 2022 (UTC)

It's on the techreport examples. Weird how its talk page is this talk page, but anyway, the examples are there. Leotohill (talk) 23:45, 23 January 2022 (UTC)

All cs1 template talk pages redirect here. It's easier to have all discussion about the family of templates in a single place.

—Trappist the monk (talk) 00:04, 24 January 2022 (UTC)

Lay-url

'Lay-url' is mentioned as deprecated (CS1 maint as well) however it's documented in the parameter list (cite book). Presumably should be removed? Neils51 (talk) 00:00, 23 January 2022 (UTC)

 Done. – Jonesey95 (talk) 00:18, 23 January 2022 (UTC)

|lay-url= is also recommended in Wikipedia:Identifying reliable sources (medicine) (the WP:MEDPOP section). WhatamIdoing (talk) 16:44, 26 January 2022 (UTC)

left a note at: Wikipedia talk:Identifying reliable sources (medicine) § |lay-url= etc

—Trappist the monk (talk) 16:57, 26 January 2022 (UTC)

Please see discussion at WT:MEDRS (and please avoid using pipes in section headings, since the rest of us mere mortals don't know how to link to them). SandyGeorgia (Talk) 19:21, 26 January 2022 (UTC)

Please point me to where the consensus was formed to remove this. SandyGeorgia (Talk) 17:29, 26 January 2022 (UTC)

Likewise, why was this parameter deprecated? Boghog (talk) 19:06, 26 January 2022 (UTC)

Out of curiosity, why was it considered to deprecate a parameter encouraged by a project without consulting said project beforehand? Hog Farm _Talk 19:21, 26 January 2022 (UTC)

Particularly one that has been written into a very widely used and cited guideline, WP:MEDRS with

One possibility is to cite a higher-quality source along with a more-accessible popular source, for example, with the |lay-url= parameter of {{cite journal}}.

since at least the end of 2008 (that's a lot of years on a highly used guideline for a couple of editors to be undoing).WP:MEDRS has 389 page watchers, and has included the text about the lay source parameter, with text unchanged for all those years.

When deprecating a parameter with such wide and long-standing acceptance, why is the page most affected not notified of the proposal? This de facto, fait accompli method of operating on citation templates should be addressed by the community more broadly. SandyGeorgia (Talk) 19:44, 26 January 2022 (UTC)

Went through WP:MEDRS carefully. Nowhere is it suggested that lay sources should not be cited by themselves. On the contrary it is suggested that such sources be cited alongside citations from "ideal" sources like peer-reviewed bio-medical journals. The document describes "ideal" sources but does not out of hand exclude others, including the popular press. To help non-expert readers (the vast majority of users, surely) find sources and verify wikitext, citations should be simple. A factor of simplicity is that a single citation should correspond to a single source (with one exception, for archived versions of the same source). Adding multiple sources to a single citation is confusing for both data entry editors and the citation consumers. It is also unwieldy. I suggest you look at this as someone who knows nothing of medicine, scientific literature, or citations. That will likely put you among the vast majority of this encyclopedia's readers. 68.174.121.16 (talk) 19:35, 26 January 2022 (UTC)

Nowhere is it suggested that lay sources should not be cited by themselves. It is equally true that nowhere it is suggested that lay source must be cited by themselves. Also, why is it unwieldy? I think bundling lay sources with the primary source is cleaner because it makes clear what is the primary citation, and what is layman's translation of the original source. And why is it confusing for editors? Quite to the contrary, the |lay-source= and |lay-url= parameters are self explanatory. Boghog (talk) 20:37, 26 January 2022 (UTC)

While that's an interesting opinion about how MEDRS is applied, it doesn't address the core issue here, which is that one to three editors make broad changes that affect the entire encyclopedia, without bothering to even notice the page where this long-standing parameter is recommended. SandyGeorgia (Talk) 21:09, 26 January 2022 (UTC)

Here are a few previous discussions:

• Discussion about lay* parameters, suggesting that each source should use its own cite template (January 2018)
• Discussion about removal of lay-summary (June 2019)
• Link to discussion from June 2021
• Link to discussion from October 2021

There may be more in the archives of this talk page. – Jonesey95 (talk) 19:55, 26 January 2022 (UTC)

Thanks for all of that. Which all confirms the concern that wide-ranging decisions are being made by a couple of editors, who don't even consider notifying the page where the parameter has been recommended for more than ten years. This is so disrespectful of so many editors. SandyGeorgia (Talk) 21:08, 26 January 2022 (UTC)

The above list of links omits the village-pump notice of this change that was part of this rfc (in the gray collapse box under: changes in Module:Citation/CS1/Whitelist/sandbox (last update 2021-05-25).

—Trappist the monk (talk) 00:30, 27 January 2022 (UTC)

Yes, we’ve seen that RFC. How/who gets consensus out of that ? Who closed the RFC? Who determined that amounted to consensus, with split opiners? SandyGeorgia (Talk) 00:39, 27 January 2022 (UTC)

I also wonder if the use of English, rather than code and terminology, might allow more of us to access more of same. For example: RFC on proposal to change citation templates. SandyGeorgia (Talk) 00:40, 27 January 2022 (UTC)

You mean the RfC that was closed with the comment there is no consensus on removal of deprecated parameters in this discussion? --Ahecht (TALK
PAGE) 16:36, 27 January 2022 (UTC)

This change didn't remove any deprecated parameters. They're still there, and they still work. The only thing that's happened is that the template now adds a red warning message to the article. WhatamIdoing (talk) 16:49, 27 January 2022 (UTC)

It does not seem acceptable to deprecate a parameter that is widely in use without gaining a broader consensus than was obtained in this case. Most of the people who have been using this parameter for years had no idea that there were discussions to remove it. Since it is recommended by the medicine wikiproject and considered useful by many medicine editors, I do not think it is permissible to remove it. (t · c) buidhe 21:52, 26 January 2022 (UTC)

widely in use. Let us look at that. As I write this, there are:

• 5,116,342 pages that transclude cs1|2 templates
• 845,043 pages that transclude {{cite journal}}
• 2,354 pages that use |lay-url= with an assigned value (article name-space; all cs1|2 templates)
• 1,246 pages that use |lay-url= with an assigned value (article name-space; {{cite journal}} only)
• 43,167 articles (57,839 less 14,672 miscellany) claimed by WP:MED (see the Medicine assessment statistics box)

|lay-date=, |lay-format=, |lay-source= and |lay-url= may be in use, but widely in use, they are not.

it is recommended by the medicine wikiproject and considered useful by many medicine editors. Of course, but that does not make use of |lay-url= and related parameters a proper thing to do.

• the cs1|2 templates are general purpose templates; they are not the private property of WP:MED
• the |lay-*= parameters are a crude mechanism to insert a second source into a template that is designed to support only one source at a time
• the |lay-*= parameters lack essential bibliographic information: author(s), title, insource locators
• the |lay-*= parameter formatting is cryptic and nonstandard

Cite bundling is nothing new and is a better way to provide a lay-source companion to a preferred source. All that is needed is to write a correct cs1|2 template for the lay source and bundle it with the preferred source citation (adding |type=Lay source (or some similar text) would serve to differentiate the pair. Bundling would allow more than one lay source were that desirable. I can imagine a {{cite lay source}} wrapper-template that accepts all cs1|2 template parameters plus one |template=book | magazine | news | journal | ... parameter and automatically sets |type= to the preferred indicator text or, perhaps, adds a 'Lay source:' prefix to the rendering. You-all should stop looking at change as a bad thing and recognize that your world could be better.

—Trappist the monk (talk) 00:30, 27 January 2022 (UTC)

Thanks for posting the statistics. That matches my impression that it is used in certain circumstances, but not very widely. I suspect that it is also used less now than it used to be, even though there have been some great lay summaries of COVID-related sources during the pandemic. WhatamIdoing (talk) 00:34, 27 January 2022 (UTC)

Here is another number: 459. That number represent the total number of WP:MED articles that use |lay-url=.

I got that number by using WP:AWB and the no-limits plug-in to fetch a list of all article talk pages listed in Category:All WikiProject Medicine articles (because the talk page is where an article's association with WP:MED is established). I used AWB to filter out all non-mainspace talk pages. That left me a list of 48,726 talk pages. I used an external text editor to strip the 'Talk:' prefix and to convert the list into a format that a Lua module would understand. Then I fetched the list of articles that use |lay-url= and used the external text editor to make a Lua acceptable list. The lists are in Module:Sandbox/trappist the monk/layurl/data.

I wrote a simple lua function to one-after-another, fetch a title from the articles_using_layurl list and look for that title in the wp_med_articles list. The code to do that is at Module:Sandbox/trappist the monk/layurl.

You can see the list of wp_med_articles_using_layurl with this: {{#invoke:Sandbox/trappist the monk/layurl|main|list=}}.

—Trappist the monk (talk) 14:54, 27 January 2022 (UTC)

And two more numbers: 2 and 22. These numbers represent the total number of FA- and GA-class WP:MED articles that use |lay-url=. The lists for these were taken from Category:FA-Class medicine articles and Category:GA-Class medicine articles.

—Trappist the monk (talk) 15:35, 27 January 2022 (UTC)

This change is one of many that happened in the latest update. There was an RFC at the village pump about it, which is generally considered a sign of gaining broader consensus, even if most of the discussion was about other aspects of the changes. (That might be a sign that CS1 updates should happen more frequently, so that each change is smaller.) WhatamIdoing (talk) 00:31, 27 January 2022 (UTC)

It could be a sign that we should hold an RFC restricting changes to citation templates until/unless a broadly advertised community-wide RFC closed by independent closers and advertised at WP:CENT using plain English is held. We have thousands of errors now at the GA and FA level, no idea how many all over the Wikipedia, because someone’s personal preferences were installed. (PS the data above does not likely reflect those that editors have already spent the last few days changing). The attitude that 2,300 articles, and 300 FAs, and thousands of GAs are insignificant is … special. SandyGeorgia (Talk) 00:57, 27 January 2022 (UTC)

Well, there are other ways of looking at this. These are some facts: WP:V is a cornerstone policy. Citation systems are tools to apply the policy. These tools should be as easy and simple to use as possible, for both the small minority of editors and the far greater majority of readers. It is no use trying to verify something if the verification process is confusing or convoluted, or in any case not immediately obvious as far as possible, to the non-expert reader.

Please try to understand that people involved in this area look at the overall impact. I'm sure your project could devise a far more comprehensive data-entry form (that is what these templates are) that is well-tailored to your area of interest. If you are so inclined, please do design one, nobody is stopping you. However, this citation system is a general-purpose system that purports to help turn wikitext somebody wrote to fact verifiable by the average reader. The focus is on simplicity, ease and speed. Are you saying that a citation that guides the user to a multiple-choice of sources is more effective, efficient, and understandable than a simpler one that immediately leads the reader to the proving source? And as far as entering data in these templates is concerned, doesn't the probability of error increase with every additional piece of info the editor enters? Assuming that the editor can keep these sources in sync.

If there is one RfC that perhaps should be initiated is one that largely decouples the development of the proving function from special interests such as your project. This is stated without any adversarial inclination or any intent to insult. Your input about citing medical sources is invaluable, and I believe everybody here would listen carefully, and try to apply it as much as possible. But experts in any field are comfortable with complexity in their field. The job of citation designers in Wikipedia should be to simplify. I would suggest you let them do that. 68.173.76.118 (talk) 02:02, 27 January 2022 (UTC)

68, someone from WP:MED did design a template. Their name was User:Eubulides, they were behind the lay parameter, and they helped write MEDRS. And it was recommended in MEDRS for more than ten years. And now it has gone poof from a widely respected guideline page as per the desires of about three editors and for reasons yet to be explained other than personal preferences. The parameters someone from WP:MED did design allowed for exactly what medical content sourcing needs, which is not to be adding full citations to lay press. Izno’s idea to add a second citation to the lay press, even if bundled is a) just as hard for novice editors to understand or implement, and b) likely to lead to encouraging citations to the laypress that breach MEDRS. SandyGeorgia (Talk) 02:32, 27 January 2022 (UTC)

In June 2021 I said there were 2300 uses of the parameter. Today's number reflects that number fairly reasonably. Regarding "require an RFC for every change", the last RFC literally closed a week ago said "no, we don't want that".

As Ttm has said, these can be supported today by filling out a second citation template using any of the available bundling mechanisms (including simply putting two templates inside one <ref> statement). This allows the editor to provide the full citation data for the lay source so that those sources can be assessed for their own quality of use (as they should be) as well as for their (re)findability. Izno (talk) 02:18, 27 January 2022 (UTC)

Who is Tim? So you assume editors who can’t manage a parameter can manage a bundled citation, and you encourage citing medical content to the lay press? SandyGeorgia (Talk) 02:34, 27 January 2022 (UTC)

Ttm.

Do not put words in my mouth (see passive aggression). I did not say "cite medical content to the lay press", and you may trivially reread what I did say to confirm it. If anything, the lay-* parameters already encourage "citing medical content to the lay press". These parameters are apparently that MED wants their cake and to eat it too (both ban mediocre sourcing while also providing parameters... for mediocre sourcing). That is fundamental inconsistency on your part. (If in fact you did not mean to be passive-aggressive, here is some phrasing you can use instead to indicate that you have interpreted X as another statement Y: "I understand what you said (X) to mean 'Y'. Is that correct?")

I have not made any point regarding whether an editor can manage a bundled citation, an unbundled citation, or otherwise, though if you wish to ask me about it: I would personally suggest that |lay-url= is so specialized that no average editor is going to use it regardless, so your point is essentially irrelevant. Hence why it's been used only some 2000 times in nearly 15 years. Izno (talk) 02:56, 27 January 2022 (UTC)

Do not put psychiatric labels on other editors. My apologies for my eyesight on the Tim. Yes, your suggestion encourages sourcing to laypress, by writing a citation template to laysources; you appear to presume all/most editors understand citation bundling and the difference. Regarding the characterization of med editors having their cake and eating it, too, see the aformentioned reference to passive-aggressive discussion. And only is still disrespectful. SandyGeorgia (Talk) 03:02, 27 January 2022 (UTC)

Citation bundling would look something like this:

<ref>{{cite journal |last=Expert |first=Alice |url=https://www.example.com/extra-peer-reviewed-paper |title=Systematic Review of Scientific Papers |work=Journal of Imp. Sci. |date=December 2021 |pmid=1234567 |doi=10.1136/bmj-2021-066995}} Lay summary in: {{cite news |last=Journalist |first=Joe |url=https://www.example.com/news-article |title=Explainer: Latest Scientific Breakthrough |date=15 December 2021 |work=Big Times}}</ref>

and it would look something like this to any reader who happened to look at the:

• Expert, Alice (December 2021). "Systematic Review of Scientific Papers". Journal of Imp. Sci. doi:10.1136/bmj-2021-066995. PMID 1234567. Lay summary in: Journalist, Joe (15 December 2021). "Explainer: Latest Scientific Breakthrough". Big Times.

You could add a line break or other formatting to separate the two more obviously if you wanted to, but I think it would not be a disaster. WhatamIdoing (talk) 03:40, 27 January 2022 (UTC)

I know how to bundle citations. Most people reading this page probably know how to bundle citations, because we’re in a backwoods obscure part of Wikipedia. What do we accomplish with this besides a) removing an easier way to do the same, and b) obscuring the lines of acceptable medical sourcing to novice editors, and c) opening the door for those citations to later become unbundled and separated? We had a method perfectly tailored to MEDRS needs, and I’ve yet to see a logical reason for the removal. SandyGeorgia (Talk) 03:52, 27 January 2022 (UTC)

I won't comment on the whether or not using lay-url is easier, as I don't know about this parameter. Solely on the question of what a newbie would do, personally I think putting two citations in one footnote is the obvious thing to do if you want to use two citations to refer to the same underlying source. The citation to the lay summary doesn't necessarily need to use a template: it could just be some plain text that links to the desired location. I appreciate there may be other reasons for wanting to have a specific parameter in the citation template. isaacl (talk) 04:24, 27 January 2022 (UTC)

The entire point of WP:CITEVAR is that editors should be able to choose how they format their refs, while mass changes to references are disallowed. Deprecating parameters in this way is an end run around CITEVAR because it disallows certain ways that many editors format refs, and if implemented will force changes to thousands of articles based on the preferences of a few people in poorly attended discussions. (t · c) buidhe 03:29, 27 January 2022 (UTC)

Except to the extent that CITEVAR discourages edit warring over the use of citation templates vs manually formatted citations, it is not meant to (read: "I did not mean to, and I wrote CITEVAR") control details such as, how, exactly, an editor achieves the thing that the reader sees.

Also, CITEVAR currently contains a potentially relevant exception: "except when moving away from deprecated styles". WhatamIdoing (talk) 05:00, 27 January 2022 (UTC)

Hence, the end run (don’t like a citation style, get it deprecated on no to minimal consensus). Game over. SandyGeorgia (Talk) 05:02, 27 January 2022 (UTC)

The parameters were deprecated as part of a VPR RFC (VPR has 3,500 page watchers) that was linked from this page. – Jonesey95 (talk) 05:17, 27 January 2022 (UTC)

Yes, but the expect behavior outlined at Wikipedia:Requests for comment#Publicizing an RfC includes

*Talk pages of relevant WikiProjects

From the comments that I am reading above, it seems many of the affected WikiProjects were not notified. It is all well & good that VPR has 3,500 watchers, but that's like 2.75% & 0.008% of active users & all users respectively. I would wager that there are far more active users who are part of affected WikiProjects. Peaceray (talk) 07:19, 27 January 2022 (UTC)

Hmm, I can't help but notice that neither Template:Cite journal/doc nor its archived version mention that lay-summary is important to the medicine project, or even hint at it. Jo-Jo Eumerus (talk) 10:39, 28 January 2022 (UTC)

A proposal

A med-specific wrapper to {{citation}} or any other appropriate CS1 template. The wrapper may add parameters more specific to medicine. Under the condition that native CS1 templates that lead to lay sources are not invalidated or considered "inferior". The rationale for this condition is as follows:

• If a lay source is good enough to be used in |lay-source= then it should be good enough to stand on its own
• There is very little in WP:MEDRS that differs from the more general WP:RS. One could make the case that a specific RS document about a single discipline is redundant. As far as I can tell, any differences in the two documents are not substantive, and at most would necessitate a single paragraph addition to WP:RS
• Considering that this is a general-purpose encyclopedia geared to the non-expert reader, it is imperative that information is presented, and verifiable to suit that audience. Lay sources that pass WP:RS should be preferable

Assuming that such a wrapper template is designed and used alongside the native templates, I suggest that in keeping with the above, the template presents the lay source as the main source, and the expert source as additional: as the one the lay source is based on. 65.88.88.47 (talk) 15:29, 27 January 2022 (UTC)

This is pretty much what I was suggesting above when I suggested {{cite lay source}}. So, I've hacked {{lay source}}. Different name because these sources apparently do not want to be viewed as 'citable'.

{{lay source}} requires its own parameter |template= which gets the name of the cs1|2 template that is appropriate to the lay source; defaults to {{cite web}} if omitted. Otherwise, {{lay source}} accepts any cs1|2 template parameter except |ref= (so that the rendered lay citation can't be linked-to from the article text by {{sfn}}, etc). Using Editor WhatamIdoing's example from above we would write:

{{lay source |template=cite news |last=Journalist |first=Joe |date=15 December 2021 |title=Explainer: Latest Scientific Breakthrough |work=Big Times |url=https://www.example.com/news-article}}

Lay summary in: Journalist, Joe (15 December 2021). "Explainer: Latest Scientific Breakthrough". Big Times.

No pretty error checking yet. Not needed. I suck a documentation but there is some now.

—Trappist the monk (talk) 17:01, 27 January 2022 (UTC) 19:23, 27 January 2022 (UTC) (documentation mention)

This is pretty much what I was suggesting above when I suggested {{cite lay source}}. Indeed. However, I thought this proposal would be more readily accepted if the interested parties had the lead in designing the wrapper. Also, if a lay source is judged reliable after scrutiny (i.e. represents salient facts correctly and without bias) it is as eminently citable as any other so-judged reliable source. Including sources such as scientific journals. More so, I would think, if the source is more readily understandable and therefore more likely to prove the wikitext verifiable to the reader. 65.88.88.69 (talk) 18:22, 27 January 2022 (UTC)

Inertia, I think, will keep interested parties from taking the lead in designing the wrapper. As for the eminently citable case: switch {{lay source |template=cite <whatever> ...}} to {{cite <whatever> ...}} and suddenly, a normal cs1|2 template.

—Trappist the monk (talk) 19:23, 27 January 2022 (UTC)

I don’t think a help talk citation page is the place to rewrite, reinterpret, and redefine a 15-year-old guideline, which is what the entire discussion above is doing. SandyGeorgia (Talk) 06:23, 28 January 2022 (UTC)

Isn't this a bit dramatic? The only change is adding/substituting a reliable lay source as standalone. Which is half-a-change since the guideline does not expressly forbid it. And also conforms to the simple rule of one source per citation, as the most accessible sort of citation. 71.247.146.98 (talk) 13:32, 28 January 2022 (UTC)

This proposal puts a lay source (non-peer-reviewed) on the same footing as a MEDRS-compliant source. If you want to propose that, the place is at WT:MEDRS, not here. SandyGeorgia (Talk) 15:58, 28 January 2022 (UTC)

• I personally think this would be a decent middle path forward where everyone gets some of what they want --Guerillero ^{Parlez Moi} 11:43, 28 January 2022 (UTC)
• I strongly oppose any remedy that involves converting lay-urls to actual citation templates. This is not what we should be doing in support of WP:MEDRS.
  Separately, for that same reason the text at Template:Cite_journal#Deprecated is disputed; will someone please add the disputed tag to the protected template, lest editors begin doing just that? We don’t usually cite medical content to lay sources, and this method leads to doing just that. Lay-urls are adjuncts to medrs sources only. SandyGeorgia (Talk) 15:26, 28 January 2022 (UTC)

B proposal

RestoreUn-deprecate |lay-url= and related parameters pending consensus on their deprecation per WP:BRD. Their deprecation was based on an all-or-nothing RFC where the closure specifically said there is no consensus on removal of deprecated parameters in this discussion, deprecating the lay- parameters was buried in a list of 60 other items, and the relevant talk pages (WT:MEDRS, WT:WikiProject Medicine) were not notified. While the RFC came to the conclusion that most typical changes to cs1/2 are uncontroversial and don't need to undergo routine VPR RfCs to be rolled out, it's clear from the above discussion that this particular change was non uncontroversial. --Ahecht (TALK
PAGE) 16:35, 27 January 2022 (UTC)

@Ahecht, we don't need to "restore" it, because it's still there and still working. WhatamIdoing (talk) 16:50, 27 January 2022 (UTC)

"Restoring" here means to stop throwing red deprecation errors. Headbomb {t · c · p · b} 17:21, 27 January 2022 (UTC)

@WhatamIdoing: That seems like a half-truth. Technically, they are still there, but the change in code is currently producing {{cite book}}: Cite uses deprecated parameter |lay-date= (help). Peaceray (talk) 17:38, 27 January 2022 (UTC)

That seems to be a Catch-22: If they leave the code working, but they show you a red error, then we complain that they're telling us about plans to remove the code in the (perhaps distant) future. But if they don't show us a red error, then we will complain that they never told us about it.

See also VPT last year, when Javascript that's been deprecated for seven years was finally removed, and script writers came out of the woodwork to complain that nobody had ever told them, and that they couldn't possibly be expected to read the many public notices, follow any of the discussions, or check for error messages themselves, because if their code worked in 2011, then it really ought to keep working until the heat death of the universe. As you can tell, I'm not impressed with their claims. WhatamIdoing (talk) 18:00, 27 January 2022 (UTC)

That is true. This has produced a far different reaction the JavaScript situation, as this blow back has been immediate. We should be grateful that there are the deprecation errors to warn us.

What is unclear is the path for backing out what appears to be an unpopular deprecation. I propose we change the language from:

Restore |lay-url= and related parameters pending consensus on their removal per WP:BRD.

to:

Undeprecate |lay-url= and related parameters pending consensus on their removal per WP:BRD.

Peaceray (talk) 18:41, 27 January 2022 (UTC)

I would emphasize appears to be ... unpopular. I would not expect supporters of the deprecation to raise banners across Wikipedia. Not wanting to minimize your concern, but several imo workable alternatives have been suggested. 65.88.88.69 (talk) 18:53, 27 January 2022 (UTC)

Peaceray, I strongly recommend against trying to make anyone do anything "per BRD", as BRD is explicitly an optional process. Wikipedia:What editors mean when they say you have to follow BRD is quite different from what BRD actually is. The relatively low level of page views suggests that less than 1% of editors have actually read BRD, so I suppose we shouldn't be too surprised if people cite it as proof that you have to do the opposite of what it actually says. Otherwise, I think that's a not unreasonable request (i.e., un-deprecate until it's been discussed separately). I might emphasize request, though, as the citation templates are a serious piece of engineering these days (so it might not be as easy as I hope), and even if it is easy, Ops may not be happy if we change them every time someone dislikes a change. If the request isn't granted, we could have the discussion anyway. The order in which the two things happen isn't actually critical. WhatamIdoing (talk) 20:27, 27 January 2022 (UTC)

All reference to the lay-*parameters could also be removed from the CS1/2 docs and helps to discourage usage, except in medical articles. AManWithNoPlan (talk) 20:33, 27 January 2022 (UTC)

AManWithNoPlan, where are you seeing lay-* parameters in CS1/CS2 documentation, aside from notes about their deprecation? – Jonesey95 (talk) 21:05, 27 January 2022 (UTC)

I meant "do not add them back to docs". Thank you for the clarifying question. AManWithNoPlan (talk) 21:23, 27 January 2022 (UTC)

@WhatamIdoing: I was specifically swapping out the word Restore for Undeprecate while leaving intact the rest of Ahecht's original proposal. I am open to any alternative wording for the B proposal that moves us towards the goal of un-deprecating the lay summary parameters. Would you please suggest an alternative wording, if you are so inclined? Peaceray (talk) 23:31, 27 January 2022 (UTC)

The talk about "blowback" and “pitchforks” and if you “know a fourth way” is unhelpful, since the whole problem could have been avoided by notifying relevant pages, which is the kind of courtesy that is commonly expected in all areas of Wikipedia. The justification for removal (or at least the only one I've seen) that the template was only used a few hundred or thousand times is a testament to how seriously MEDRS is taken; we don't add lay sources lightly, and when we do, they should not appear to be a citation, rather an adjunct. The parameter that was there was doing precisely what it needed to do. Whichever word is used (restore, undeprecate, undo, fix, correct this problem), please undo what was done, and please in the future find better ways of communicating. If this isn't undone quickly, please provide a list of articles at WT:MED so interested editors can remove the unsightly errors, affecting our readers, without having to interpret some code to generate the list ourselves. SandyGeorgia (Talk) 06:39, 28 January 2022 (UTC)

Ttm, thank you for posting the list at WT:MED, but that means that the disputed remedy at the cite journal template now needs a disputed tag, lest editors start making those recommended changes. SandyGeorgia (Talk) 15:35, 28 January 2022 (UTC)

• Support It's clear that this change does not have broader consensus. These parameters should never have been deprecated to begin with. (t · c) buidhe 06:58, 28 January 2022 (UTC)
• This is my second choice to A, above --Guerillero ^{Parlez Moi} 11:44, 28 January 2022 (UTC)

Sample for discussion

A good example, from the most recent medical FA, Menstrual cycle:

• Emera D, Romero R, Wagner G (January 2012). "The evolution of menstruation: a new model for genetic assimilation: explaining molecular origins of maternal responses to fetal invasiveness". BioEssays (Journal article). 34 (1): 26–35. doi:10.1002/bies.201100099. PMC 3528014. PMID 22057551. See BBC Earth lay summary, 20 April 2015.

The journal article is recent secondary review that complies with WP:MEDRS, and is what the text in the article is sourced to. The lay article from the BBC offers an overview in simpler language; an adjunct for the reader, but not something one would ever cite medical content to; even well written lay sources often have medical errors, and this one has a lot of opinion. But it serves to help the reader understand the terminology so they can then better digest the actual source should they care to (WAID is fond of reminding us that readers don't click on sources anyway). We provide it in a case like this for a simple overview, but we don’t source content to it. It's an adjunct, not a stand-alone, and not the source used.

And while IP68 is stating that our sources have to be accessible; no they don't. The text we write based on our sources should be accessible; the statements about MEDRS above are reinterpretations of MEDRS, and if that is to be done, that should happen at WT:MEDRS. SandyGeorgia (Talk) 06:42, 28 January 2022 (UTC)

After examining both sources, I would say that the lay source closely follows the journal article and seems much more understandable, without the technicalities of the expert source. The lay source seems reliable and informative, and verifies the wikitext where called to do so. Why not use it as the main source? Who is the audience for this? Bio-medical professionals? Don't they have extensive libraries of material they can consult easily?

I believe that the compound citation is unnecessarily convoluted. If I want to verify the wikitext any one reliable source will do, assuming I can parse the cryptic citation. It could be, that this is just too much for the lay reader.

Other than that, imo the article suffers from the same drawbacks like many other science-based articles as far as the expert source goes. It should be clearly stated in the article that this citation (and the wikitext supported by it) refers to a proposed model, that the authors argue explains the molecular origins, etc. In an encyclopedia targeting any reader such language is important; don't assume that readers implicitly know this is so. I must admit I don't give FA articles the benefit of the doubt. To me,FA status is a vanity project. 71.247.146.98 (talk) 12:47, 28 January 2022 (UTC)

SandyGeorgia, thank you for providing this straightforward example of how to help readers by providing a link to a layperson's summary of a technical article. I think that the way you have formatted the link to the lay source is appropriate and helpful for readers, and it ensures that editors and bots will not confuse two URLs as intending to point to two versions of the same cited source. I would be happy to document this method on the tracking category page as an example of how to extract a lay-url and its title from an otherwise self-contained cite template, which is supposed to cite and link to a single source. – Jonesey95 (talk) 14:10, 28 January 2022 (UTC)

Thank you, Jonesey95; it’s a bit of an extreme example because the topic is so dense, but hopefully serves as a good example nonetheless.

IP71, it is our job to make our content accessible. It is not our job to judge the accuracy of non-peer-reviewed sources or to make sure our sources are accessible to all education levels; we do that in our text. (And the source is used appropriately in the text, where four models and their drawbacks are explained; but that is off-topic for this discussion.) SandyGeorgia (Talk) 15:33, 28 January 2022 (UTC)

I beg to differ. Anyone can make any content accessible. But editors have an obligation to make content verifiable by the people most likely to access it. Having understandable wikitext is one part of it only. Having understandable sources that verify the wikitext completes it. Otherwise, if the source is unintelligible, the text is for all purposes unverifiable to the reader. It is also the editors' job to gauge the accuracy, objectivity and pertinence of any source, peer-reviewed or not, since these properties largely define reliability. As for the use of the source, I agree that this is another discussion. But my original skepticism remains: I was not referring to the content of the article. If its authors consider it an (scientific) "argument" that is putting forth "propositions", that should be made clearer. I believe few Wikipedia readers know how peer reviews work, and how a paper can progress from hypothesis to theory to application and perhaps to generally accepted practice. 65.88.88.47 (talk) 16:19, 28 January 2022 (UTC)

I believe that Jonesey95's suggestion is an extremely bad idea. Opens a Pandora's box of issues, once you go down that road. 65.88.88.47 (talk) 16:23, 28 January 2022 (UTC)

Please add disputed tag to cite journal template

I strongly oppose any remedy that involves converting lay-urls to actual citation templates. This is not what we should be doing in support of WP:MEDRS, but it is what the cite journal template currently recommends (based on zero consensus). The text at Template:Cite_journal#Deprecated is disputed; will someone please add the disputed tag to the protected template, lest editors begin doing just that? We don’t usually cite medical content to lay sources, and this method leads to doing just that. Lay-urls are adjuncts to medrs sources only. SandyGeorgia (Talk) 15:30, 28 January 2022 (UTC)

@SandyGeorgia: The template documentation is only semi-protected, so you should be able to edit it by going to Template:Cite_journal and clicking the "edit" link at the top of the green box, or you can go to Template:Cite_journal/doc#Deprecated and edit from there. GoingBatty (talk) 16:03, 28 January 2022 (UTC)

I’ve tried … there are layers I can’t figure out how to get through. Will try again, SandyGeorgia (Talk) 16:04, 28 January 2022 (UTC)

Can’t do it … perhaps you can go in to edit mode and drill down to help me find what page I can actually edit. (This is symptomatic of what happens when regular editor have to engage these discussions; it’s all designed in such a way that … we can’t.) SandyGeorgia (Talk) 16:06, 28 January 2022 (UTC)

@SandyGeorgia: I added {{disputed}} to Template:Cite journal/doc#Deprecated in this edit. Feel free to tweak the wording so it makes more sense. GoingBatty (talk) 16:17, 28 January 2022 (UTC)

Thank you ever so much; I see where I went wrong. I was attempting to place the tag on the actual wording under “replace with”, and I can’t figure out how to get to that place. Thanks again, most appreciated, as the concern is that editors will start adding citation templates to medical content using lay sources, which is not on with MEDRS. SandyGeorgia (Talk) 16:22, 28 January 2022 (UTC)

Cite map

Another case of the false positives, though this one might warrant discussions. I'm getting errors for uses of {{cite map}} with a link in the "inset" parameter, which I thought to be valid. A few examples are at Interstate 90#References. SounderBruce 02:38, 23 January 2022 (UTC)

I am fairly certain a URL has never been supported in that parameter and there is also no documentation to that effect; I doubt when it was integrated into the module some 5 years ago that was discussed either. External links are almost exclusively supported in url parameters (the only exception is |pages= off the cuff). Izno (talk) 02:44, 23 January 2022 (UTC)

I think it would be worth adding the support, as quite a few maps I use have separate pages for the main map and inset(s). SounderBruce 03:57, 23 January 2022 (UTC)

CS1 maint: url-status

Moved from Category talk:CS1 maint: url-status

 – that talk page now a redirect —Trappist the monk (talk) 12:14, 23 January 2022 (UTC)

Is this category working correctly? I see that articles gain tihs warning with url-status=live, unfit or usurped. With that setting, they don't need to have archive-url= or archive-date= values. What's the point? Seems more useful to only cause an error on references that set url-status=dead -- Mikeblas (talk) 00:54, 23 January 2022 (UTC)

Convenience link: Category:CS1 maint: url-status

—Trappist the monk (talk) 12:14, 23 January 2022 (UTC)

Yes, I think so. |url-status=<dead | live | unfit | usurped | deviated> (any valid value) without |archive-url= conveys no meaning to the template. It is |url-status= that controls how cs1|2 templates are rendered when |archive-url= is present and has an assigned value. All of these correctly emit the maintenance message and, when in a categorizable namespace, add the article to Category:CS1 maint: url-status.

{{cite book |title=Title |url-status=live}} → Title.{{cite book}}: CS1 maint: url-status (link)

{{cite book |title=Title |url-status=dead}} → Title.{{cite book}}: CS1 maint: url-status (link)

{{cite book |title=Title |url-status=usurped}} → Title.{{cite book}}: CS1 maint: url-status (link)

{{cite book |title=Title |url-status=unfit}} → Title.{{cite book}}: CS1 maint: url-status (link)

{{cite book |title=Title |url-status=deviated}} → Title.{{cite book}}: CS1 maint: url-status (link)

|url-status=dead is not a substitute for {{dead link}}.

—Trappist the monk (talk) 12:56, 23 January 2022 (UTC)

I think that url-status=live is used to indicate that the URL is live, and that an archive-url is not necessary. Why should that state place the article in a maintenance category? -- Mikeblas (talk) 22:27, 23 January 2022 (UTC)

Which is not its purpose. Its purpose is to indicate when the URL is live and there is an archive, such that the live URL is displayed in the preferred position. Either add an archive or remove the parameter. Izno (talk) 22:54, 23 January 2022 (UTC)

(edit conflict)

You are misunderstanding the purpose of |url-status=live. The only purpose of |url-status=live is to specify which of |url= or |archive-url= links |title= when the citation is rendered:

{{cite book |title=Title |url=//example.com}}

Title. – |url= links |title=

{{cite book |title=Title |url=//example.com |url-status=live}}

Title.{{cite book}}: CS1 maint: url-status (link) – |url= links |title=; |url-status=live contributes nothing

{{cite book |title=Title |url=//example.com |archive-url=//archive.org |archive-date=2022-01-23}}

Title. Archived from the original on 2022-01-23. – |archive-url= links |title=; |url= links 'the original' static text

{{cite book |title=Title |url=//example.com |archive-url=//archive.org |archive-date=2022-01-23 |url-status=dead}}

Title. Archived from the original on 2022-01-23. – |archive-url= links |title=; |url= links 'the original' static text; |url-status=dead contributes nothing

{{cite book |title=Title |url=//example.com |archive-url=//archive.org |archive-date=2022-01-23 |url-status=live}}

Title. Archived from the original on 2022-01-23. – |url= links |title=; |archive-url= links 'Archived' static text because |url-status=live

{{cite book |title=Title |url=//example.com |archive-url=//archive.org |archive-date=2022-01-23 |url-status=usurped}}

Title. Archived from the original on 2022-01-23.{{cite book}}: CS1 maint: unfit URL (link) – |archive-url= links |title=; |url= suppressed because |url-status=usurped

cs1|2 adds articles to Category:CS1 maint: url-status when cs1|2 templates include non-contributing |url-status=live, |url-status=usurped, |url-status=unfit, |url-status=deviated. It is expected that a future cs1|2 update will categorize non-contributing |url-status=dead.

—Trappist the monk (talk) 23:30, 23 January 2022 (UTC)

Cite journal pages

The documentaion for |cite journal= in the TemplateData section indicates |page= and |pages= uses p. or pp. but this is not correct. Is there a way to get this to show as there is a |no-pp= to supress it? Keith D (talk) 14:03, 23 January 2022 (UTC)

?? There is a "no pp" param defined in TemplateData, further down. 69.203.140.37 (talk) 14:42, 23 January 2022 (UTC)

|no-pp= suppresses the 'p.' or 'pp.' annotation in a rendered citation:

{{cite book |title=Title |page=123 |no-pp=yes}}

Title. 123.

{{cite book |title=Title |pages=123–132 |no-pp=yes}}

Title. 123–132.

Nothing wrong with the page, pages, no-pp text in Template:Cite journal § TemplateData.

—Trappist the monk (talk) 14:46, 23 January 2022 (UTC)

I believe KeithD is concerned that the current rendering of pages in {{cite journal}} (default |no-pp=yes) should be made more explicit in TemplateData. 69.203.140.37 (talk) 14:54, 23 January 2022 (UTC)

Right, Mea culpa. In {{cite journal}} |no-pp= is ignored:

{{cite journal |title=Title |journal=Journal |page=123 |no-pp=yes}}

"Title". Journal: 123.

{{cite journal |title=Title |journal=Journal |pages=123–132 |no-pp=yes}}

"Title". Journal: 123–132.

So, the |no-pp= entry in Template:Cite journal § TemplateData may (should) be removed. Further, for |page=, the 'documentation' text might be changed from:

Page in the source that supports the content; displays after 'p.'

to:

Page in the source that supports the content; displays after a colon-space pair

and for |pages=, the 'documentation' text might be changed from:

Pages in the source that support the content (not an indication of the number of pages in the source; displays after 'pp.'

to:

Pages in the source that support the content (not an indication of the number of pages in the source); displays after a colon-space pair

—Trappist the monk (talk) 15:09, 23 January 2022 (UTC)

What I am looking for is a way to display p. or pp. when using {{cite journal}}, as bots modify {{cite magazine}} to {{cite journal}} thus loosing the p. or pp. which is there for consistency in article. Keith D (talk) 15:17, 23 January 2022 (UTC)

The most recent update to the cs1|2 module suite normalized |volume=, |issue=, |page(s)= parameter renderings for non-journal citations (which see). Journal citations continue with the style used for academic/scholarly journals.

If a bot is changing {{cite magazine}} to {{cite journal}} when the source is not an academic or scholarly journal, then the issue should be taken up with the bot's operators/maintainers. If a bot is changing {{cite magazine}} to {{cite journal}} when the source is an academic or scholarly journal, then the bot is doing the correct thing. {{cite magazine}} should not be used to cite academic or scholarly journals; use {{cite journal}} for such citations. The reverse is also true: {{cite journal}} should not be used to cite general readership periodicals; use {{cite magazine}} for such citations.

—Trappist the monk (talk) 15:39, 23 January 2022 (UTC)

The problem is that just using a |page= or |pages= just gives a single number which a reader has no idea that it is a page number. You need a way of getting the p. or pp. show to claify what the number is and to make the cite style consistent in an article, regardless of the template used. Using |no-pp=no would solve the problem or a new parameter to allow the output. Keith D (talk) 18:41, 24 January 2022 (UTC)

Real life example please?

—Trappist the monk (talk) 18:44, 24 January 2022 (UTC)

This seems to be about

• the East Riding News in Brandesburton, Beverley and Holderness (UK Parliament constituency), Woodmansey and Middleton on the Wolds, and
• The Times (Hull and Lincolnshire Times) in Welwick.

Those are magazines or newspapers rather than journals. Kanguole 21:11, 24 January 2022 (UTC)

The consistency you apparently desire is not one that we have had issues with in the general, and certainly has not been an issue at e.g. FAC. Fundamental rule: Use the template the name of which matches the source you're citing and let the template do the rest.

Now, it might be reasonable to flip cite journal to render like the other templates, but we recently discussed that as pointed to by Ttm above ("which see"). If you would prefer that end goal, you can start another discussion specifically for cite journal (which we left as a possible future path therein), but I anticipate that will need to be an RFC. Izno (talk) 19:08, 24 January 2022 (UTC)

Bump S2CID limits to 250000000

To prevent bogus errors in cases like

• Howard S. Levie (January 1974). "The Indo-Pakistani Agreement of August 28, 1973". American Journal of International Law. 68 (1): 95–97. doi:10.2307/2198806. JSTOR 2198806. S2CID 246007433.

Headbomb {t · c · p · b} 14:13, 23 January 2022 (UTC)

Two CS1 messages for the same issue

When using "Editor" in the |author= parameter, two CS1 messages are now given: "|author= has generic name" and "CS1 maint: extra text: authors list". Could someone please tweak the modules to remove the overlap so only the error is displayed?

{{cite magazine |author=Editor |title=Title |magazine=Magazine}}

• Editor. "Title". Magazine. {{cite magazine}}: |author= has generic name (help)

Thanks for your consideration. GoingBatty (talk) 15:36, 23 January 2022 (UTC)

Tweaked:

{{cite magazine/new |author=Editors |title=Title |magazine=Magazine}}

Editors. "Title". Magazine. {{cite magazine}}: |author= has generic name (help)

{{cite magazine/new |author=Editor |title=Title |magazine=Magazine}}

Editor. "Title". Magazine. {{cite magazine}}: |author= has generic name (help)

{{cite magazine/new |author=Editorial |title=Title |magazine=Magazine}}

Editorial. "Title". Magazine.

{{cite magazine/new |author=Edited |title=Title |magazine=Magazine}}

Edited. "Title". Magazine. {{cite magazine}}: |author= has generic name (help)

But that leaves the test for the abbreviated 'ed.' and 'eds.' annotations (real life example):

{{cite magazine/new |author=ed. |title=Title |magazine=Magazine}}

ed. "Title". Magazine. {{cite magazine}}: |author= has generic name (help)

{{cite magazine/new |author=eds. |title=Title |magazine=Magazine}}

eds. "Title". Magazine. {{cite magazine}}: |author= has generic name (help)

Should these be made errors as well? I'm inclined to say yes.

—Trappist the monk (talk) 16:35, 23 January 2022 (UTC)

@Trappist the monk: Thank you for your quick response! I'm also inclined have those show as errors, as well as variations such as |author=Joe Smith, ed., |author=Joe Smith (ed.), |last=Smith|first=Joe, ed. and |last=Smith|first=Joe (ed.) Thanks! GoingBatty (talk) 17:02, 23 January 2022 (UTC)

Tweaked again:

{{cite magazine/new |author=Joe Smith, ed. |title=Title |magazine=Magazine}}

Joe Smith, ed. "Title". Magazine. {{cite magazine}}: |author= has generic name (help)

{{cite magazine/new |author=Joe Smith (ed.) |title=Title |magazine=Magazine}}

Joe Smith (ed.). "Title". Magazine. {{cite magazine}}: |author= has generic name (help)

{{cite magazine/new |last=Smith|first=Joe, ed. |title=Title |magazine=Magazine}}

Smith, Joe, ed. "Title". Magazine. {{cite magazine}}: |first= has generic name (help)CS1 maint: multiple names: authors list (link)

{{cite magazine/new |last=Smith|first=Joe (ed.) |title=Title |magazine=Magazine}}

Smith, Joe (ed.). "Title". Magazine. {{cite magazine}}: |first= has generic name (help)

{{cite magazine/new |author=Ed Smith |title=Title |magazine=Magazine}}

Ed Smith. "Title". Magazine.

{{cite magazine/new |author=ed. Joe Smith |title=Title |magazine=Magazine}}

ed. Joe Smith. "Title". Magazine. {{cite magazine}}: |author= has generic name (help)

—Trappist the monk (talk) 17:53, 23 January 2022 (UTC)

Cateat lector: accepting this change (ed. and eds., etc) will shift all of the content of Category:CS1 maint: extra text: authors list‎ (0), Category:CS1 maint: extra text: contributors list‎ (0), Category:CS1 maint: extra text: editors list (0), Category:CS1 maint: extra text: interviewers list‎ (0), and Category:CS1 maint: extra text: translators list‎ (0) to Category:CS1 errors: generic name (23,956). To my mind, not a bad thing. Articles have been accumulating in CS1 maint: extra text: authors list since April 2017 but because very few editors have maintenance-message display enabled, relatively few of the that category's articles have been fixed. Perhaps as errors, the tally will decrease...

—Trappist the monk (talk) 18:43, 23 January 2022 (UTC)

I am fine with moving these, but it may be valuable to keeping the name lists categories separated so that the parameters without issues currently can be kept at low counts. Izno (talk) 23:07, 23 January 2022 (UTC)

I suppose that's possible but not contemplated in the current code. We might consider individual categories at another update. For the nonce, I have promised to update sometime today so individual categorization will have to wait.

—Trappist the monk (talk) 23:38, 23 January 2022 (UTC)

I'll live. Izno (talk) 00:25, 24 January 2022 (UTC)

Finding cite errors

When editing kernel (operating system), I get the message "Script warning: One or more {{cite journal}} templates have errors; messages may be hidden (help). " and the hidden category CS1 errors: missing periodical. I can't find a broken {{cite journal}}; the Mark I Eyeball shows a |journal= for every {{cite journal}}. How do I associate the error message with the relevant markup? --Shmuel (Seymour J.) Metz Username:Chatul (talk) 17:48, 23 January 2022 (UTC)

@Chatul: Hi there! The issue is the "Hansen, Per Brinch (2001)" reference in the "Sources" section. It's hard to find if you look through the source code because it uses {{cite paper}}, which is a redirect to {{cite journal}}. I also suggesting alphabetizing the "Sources" section. Happy editing! GoingBatty (talk) 17:52, 23 January 2022 (UTC)

Was the (help) link in the preview message box not helpful? If not, why not?

—Trappist the monk (talk) 17:56, 23 January 2022 (UTC)

The help link did not provide context. When I followed, it landed on the first section of Help:CS1 errors. 68.132.154.35 (talk) 18:02, 23 January 2022 (UTC)

templates have maintenance messages

Many pages now display the message Script warning: One or more {{cite web}} templates have maintenance messages in the preview. For example nirmatrelvir/ritonavir, remdesivir, and COVID-19 vaccine. The help page is not useful. What are the maintenance messages? Why don't they appear in preview mode. On the Nirmatrelvir/ritonavir and COVID-19 vaccine pages there are also the messages Script warning: One or more {{cite journal}} templates have errors and again I don't see any messages in the preview. --Whywhenwhohow (talk) 06:38, 24 January 2022 (UTC)

Whywhenwhohow Did you click the link at the end of the message? It should explain. What did you not understand about it if you did? Izno (talk) 07:19, 24 January 2022 (UTC)

@Izno: It says there that error messages are visible to all readers but there aren't any error messages shown. It also states users should make some changes to view the maintenance messages. That is a hurdle that should not be necessary. The maintenance messages should be visible in preview. --Whywhenwhohow (talk) 07:50, 24 January 2022 (UTC)

@Whywhenwhohow: On Nirmatrelvir/ritonavir, do you see the messages/errors in references #32 #31 and #34? On COVID-19 vaccine, do you see the messages/errors in references #99 & #189 & #208? GoingBatty (talk) 17:51, 24 January 2022 (UTC)

@GoingBatty: No, there are no messages/errors for those references. --Whywhenwhohow (talk) 02:06, 25 January 2022 (UTC)

@Whywhenwhohow: Does the image on the right help you?

Reference errors and messages on Nirmatrelvir/ritonavir and COVID-19 vaccine

@Trappist the monk: I know editors have to include text in their CSS file to see the green maintenance messages. Do users who haven't changed their CSS file see Script warning: One or more {{cite web}} templates have maintenance messages ? GoingBatty (talk) 02:57, 25 January 2022 (UTC)

@GoingBatty: I don't see any of those. When I edit/preview the COVID-19 drug development article I see the message next to citation #19 about {{cite web}}: Cite uses deprecated parameter |lay-url= (help) but I don't see any other messages. --Whywhenwhohow (talk) 05:45, 25 January 2022 (UTC)

@GoingBatty: The message for citation #34 states that cite journal requires a journal but the citation is a cite document. {{cite document |title=EPIC-HR: Study of Oral PF-07321332/Ritonavir Compared With Placebo in Nonhospitalized High Risk Adults With COVID-19 |url=https://clinicaltrials.gov/ct2/show/NCT04960202 |publisher=clinicaltrials.gov |date=19 November 2021}} It looks like the citation bot changed cite web to cite document --Whywhenwhohow (talk) 05:59, 25 January 2022 (UTC)

@Whywhenwhohow: Since {{cite document}} redirects to {{cite journal}}, which requires the |journal= parameter, I submitted User talk:Citation bot#Converting Cite web to Cite document creates a CS1_error to ask them to stop converting the citation templates from {{cite web}} to {{cite document}}. GoingBatty (talk) 13:29, 25 January 2022 (UTC)

@Izno:,@Headbomb: Any thoughts on why some of the red error messages appear (e.g. lay-url) but not others (e.g. missing journal param)? --Whywhenwhohow (talk) 05:25, 26 January 2022 (UTC)

Missing journal parameter particularly is a hidden error. Lay-url is not. Izno (talk) 07:09, 26 January 2022 (UTC)

@GoingBatty: I tried to include the relevant text in my CSS file to see the green maintenance messages, but it wouldn't accept a change in either my common.css or skin.css. (No change seen after the attempted edit.) --David Biddulph (talk) 10:42, 25 January 2022 (UTC)

@David Biddulph: Are you saying you couldn't change your CSS file, or you successfully changed your CSS file but you don't see any difference in articles after making the change? If it's the latter, you might need to purge your browser cache. GoingBatty (talk) 13:29, 25 January 2022 (UTC)

@GoingBatty: The former. On trying to add that text to the CSS file, the "Changes" button shows no change, or saving then looking at the history shows no edit. --David Biddulph (talk) 13:33, 25 January 2022 (UTC)

You are talking about User:David Biddulph/common.css? Perhaps an editor with interface editing privileges can help. Ping @User:Izno.

—Trappist the monk (talk) 14:06, 25 January 2022 (UTC)

You have sufficient CSS already in User:David Biddulph/common.css#L-4: .citation-comment {display: inline !important;} /* show all Citation Style 1 error messages */. Your CSS needs no further change. In A_Different_Kind_of_Weather for example, you should see a green message after (current) citation 4 to The Encyclopedia of Popular Music. Izno (talk) 18:10, 25 January 2022 (UTC)

The preview messages (in the yellow box) are visible to anyone, logged-in or not.

—Trappist the monk (talk) 14:06, 25 January 2022 (UTC)

@Trappist the monk: I think the preview messages are a great way to help users who might otherwise not notice the red errors which everyone should be able to see, but may be buried in the references section. However, I suggest the preview messages only include the green maintenance messages for those who have added the CSS to see the messages after each citation template. GoingBatty (talk) 15:00, 25 January 2022 (UTC)

You may wish to review the instituting discussion; I don't recall if that came up but I feel like it might have when I tried to use the standard classes for such things (and then was reverted? memory is bad). Izno (talk) 18:45, 25 January 2022 (UTC)

@Trappist the monk: any help here? Headbomb {t · c · p · b} 15:57, 24 January 2022 (UTC)

And for those who don't know what we're talking about here, see this, which is what is shown upon previewing the current version of Nirmatrelvir/ritonavir. Headbomb {t · c · p · b} 15:59, 24 January 2022 (UTC)

Isn't this the same issue as in § Finding cite errors? 65.88.88.201 (talk) 16:48, 24 January 2022 (UTC)

Perhaps, but not just yet.

—Trappist the monk (talk) 18:27, 24 January 2022 (UTC)

FWIW - it also happens when previewing an edit on CareCloud. The specific cite errors are not being shown, but the alerts are. TimTempleton ^{(talk) (cont)} 12:30, 25 January 2022 (UTC)

Personally, I like the new "... templates have maintenance messages" in the preview. It should alert editors if they introduce a maintenance issue. I have changed my CSS style sheet several times to see more messages when editing. I understand why there are different levels of messaging BUT I do not know what the levels are or how the messages are assigned to a level. I just realized the processing of cite templates changed. The process for changing and implementing templates is unknown to me. I just discovered there is a new url-status= value, "deviated". I will now need to reread the documentation (hope it has been updated). I attribute most of my frustration to differences in the way I and other (some, most) editors think. User-duck (talk) 19:18, 25 January 2022 (UTC) PS: I find the new "generic name" messages frustrating, why are they an "error" (red), too many false positives, Ed is a perfectly valid first name. I will not work on a category with 30,000+ entries, obviously not important enough for editors and too general to efficiently tackle. User-duck (talk) 19:18, 25 January 2022 (UTC)

Error from URL in via

An article I monitor has this passage:

A 2020 analysis of the schools that send the most students per capita to the highest-ranked U.S. medical, business, and law schools placed the college 10th for medical schools, 16th for business schools, and 10th for law schools.

References

It started throwing an error message today because of the URLs in |via=. I want to keep the URLs, as they are far more accessible than the book. But I don't see another place to put URLs to webpages that reproduce the content on three cited pages in a book. Is there a better way to structure this, or if not, is there a way to suppress the error message? {{u|Sdkb}} ^talk 21:16, 23 January 2022 (UTC)

I suggest the id parameter which is intended for links, unlike via which is not. Someone else might have a better idea. AManWithNoPlan (talk) 21:28, 23 January 2022 (UTC)

I wouldn't want to do that, as these aren't IDs, so it'd be a misuse of that parameter. {{u|Sdkb}} ^talk 21:32, 23 January 2022 (UTC)

I have now looked closer and at the URLs and ID is less than ideal - still better than via. Seems like each link is a different reference or kind of like a chapter/section of the same reference. AManWithNoPlan (talk) 21:53, 23 January 2022 (UTC)

Hmm, abusing |chapter= also throws an error, since it's looking for me to use |chapter-url= instead. Maybe I'll just turn it into three refs so I can do that. That'll also allow better archiving, which as GoingBatty pointed out is a concern for something with annual updates. Cheers, {{u|Sdkb}} ^talk 22:18, 23 January 2022 (UTC)

I found another solution, which is to use |at=. {{u|Sdkb}} ^talk 22:23, 23 January 2022 (UTC)

|at= is also not appropriate. That is for an in-source location. Izno (talk) 23:00, 23 January 2022 (UTC)

@Sdkb: Hi there! Are you citing what you read in the book, or what you read on the web pages? There's also a difference between 2020 archive of https://www.collegetransitions.com/dataverse/top-feeders-medical-school and the current web page, so the Wikipedia article might have to be updated each year. GoingBatty (talk) 21:47, 23 January 2022 (UTC)

@GoingBatty, both. I appreciate WP:SAYWHEREYOUGOTIT but I wanted to include the book to help indicate that there's a publisher standing behind the work.

Looking at Help:Citation Style 1#Accept-this-as-written markup, |via= isn't currently supported. Could that be changed? {{u|Sdkb}} ^talk 22:01, 23 January 2022 (UTC)

Via has one job - to describe the url. If one is going to abuse a parameter, id is historically the one abused, but as noted above, that is less than perfect. AManWithNoPlan (talk) 22:10, 23 January 2022 (UTC)

Sdkb, a citation template is meant for one citation, and is explicitly not for "see also" links internal to the citation (we have in fact recently deprecated the |lay-*= parameters, which were hacked on in similar fashion). If these are of value, they should be in separate citation templates so they can be fully described for the appropriate reader. Izno (talk) 23:05, 23 January 2022 (UTC)

@Izno, thanks; I've split it into three citations (and also undid for the "editorial" thing above). {{u|Sdkb}} ^talk 23:46, 23 January 2022 (UTC)

Page parameter in Template:Cite journal

The "page has extra text" error is visible in situations like this:

{{cite journal |title=Title |journal=Journal |page=p 15}}

• "Title". Journal: p 15. {{cite journal}}: |page= has extra text (help)

The error also shows for |page=p. 15, |page=page 15, |page=pages 15–19, and other varieties as expected.

However, it does NOT show an error for uppercase "Page" or "Pages":

{{cite journal |title=Title |journal=Journal |page=Page 15}}

• "Title". Journal: Page 15.

{{cite journal |title=Title |journal=Journal |page=Pages 15–19}}

• "Title". Journal: Pages 15–19.

And I checked the sandbox, just to be sure:

{{cite journal/new |title=Title |journal=Journal |page=Page 15–19}}

• "Title". Journal: Page 15–19.

{{cite journal/new |title=Title |journal=Journal |page=Pages 15–19}}

• "Title". Journal: Pages 15–19.

Would it be possible and reasonable to adjust the module to also identify these as errors? Thanks! GoingBatty (talk) 00:32, 24 January 2022 (UTC)

Long-time known deficiency that will one-day get fixed. Today is not that day.

—Trappist the monk (talk) 01:03, 24 January 2022 (UTC)

Also, this:

• {{cite journal|title=Title|journal=Journal|page=Sentencecaseofanything 10}}

is

• "Title". Journal: Sentencecaseofanything 10.

and,

• {{cite journal|title=Title|journal=Journal|volume=Dosametoharmonizewithnonjournals 1|page=Sentencecaseofanything 10}}

is

• "Title". Journal. Dosametoharmonizewithnonjournals 1: Sentencecaseofanything 10.

There! (Almost)-instant fake "cite magazine". 50.74.109.2 (talk) 00:35, 25 January 2022 (UTC)

Formatting change to issue parameter breaking stuff

One of the changes in the recent update (I think this one) has caused problems. Some magazine instances have e.g. |issue=Fall 2020, which I had understood to be acceptable usage, and which previously displayed as Smith, Bob. "Title". Foobar Magazine (Fall 2020). Publisher. p. 4. They now display as Smith, Bob. "Title". Foobar Magazine. No. Fall 2020. Publisher. p. 4. It's not possible to enter "Fall 2011" into any of the date parameters, and some magazines use that system instead of numbers. How should we resolve this? {{u|Sdkb}} ^talk 01:34, 24 January 2022 (UTC)

Formatting of volume/issue/page for {{cite magazine}} has not changed. It's not possible to enter "Fall 2011" into any of the date parameters Why do you think that?

{{cite magazine |author=Smith, Bob |title=Title |magazine=Foobar Magazine |date=Fall 2020 |page=4}}

Smith, Bob (Fall 2020). "Title". Foobar Magazine. p. 4.

—Trappist the monk (talk) 01:51, 24 January 2022 (UTC)

Formatting of volume/issue/page for {{cite magazine}} has not changed. Hmm, maybe cite magazine was always that way, as I just converted the ref to that from cite news today. But I checked against an archived screenshot and it definitely did change from putting the issue in parentheses to putting it after a "No." that isn't always applicable. An issue name isn't always a number.

And hmm, I thought CS1 yelled at you for putting something it sees as a non-date in a date field, but I guess not. It's still questionable on MOS:SEASON grounds. The main point remains: An issue name isn't always a number, and this change forces it to be, potentially breaking thousands of articles that haven't been using it as such. {{u|Sdkb}} ^talk 02:01, 24 January 2022 (UTC)

The "issue name" cannot be satisfactorily resolved without a dedicated parameter, but one has to measure its utility vs. increasing complexity and bloat. Empirically, a small minority of periodicals use issue names. A good number of those use "special" date-names such as seasons, holidays etc. Many reference resources also classify such issues by (scheduled) publication date. A biblio provider may also classify the "Summer 2022" issue as dated June 2022 if this is when the magazine is expected/scheduled to be published. So the cited source can be found by the publication date. I believe that CS1/CS2 strikes a good balance by allowing the date-name in |date=. Yet one more issue-related parameter such as "issue-name" seems overkill. And, if you can use an actual date in date or/and an actual issue number you can also add something like this:

• |quote-page=Cover|quote=(issue-name).

71.105.141.131 (talk) 02:37, 24 January 2022 (UTC)

Redlink category on Help:CS1 errors

Could someone please replace or remove the redlink Category:CS1 tracked parameters at Help:CS1 errors#Properties category highlighting? Thanks! GoingBatty (talk) 15:05, 25 January 2022 (UTC)

Category:CS1 tracked parameters created with some draft text. Editors are welcome to flesh out the description there. – Jonesey95 (talk) 18:17, 25 January 2022 (UTC)

Discussion at Template talk:Cite wikisource § Multiple scan pages?

 You are invited to join the discussion at Template talk:Cite wikisource § Multiple scan pages?. Also, should that talk page be merged to here? {{u|Sdkb}} ^talk 23:52, 25 January 2022 (UTC)

If the citation system was properly documented, the documentation for editors and readers would have appropriate help pages and the doc for this template should be merged in the respective pages. The technical documentation (for developers) would be in different pages because the peculiarities of {{cite wikisource}} utilize native MW scripting, not Lua. This includes the |scan= parameter, which right now can be called once per template, with guidance to apply a single value (therefore not multiple scan targets). 65.254.10.26 (talk) 00:13, 26 January 2022 (UTC)

Example template suggestions

For author, editor roles following generic-name changes. As you can see they work, for now.
Example 1

• {{cite book|last=Authorlast|editor-last=Editorlast|title=Title}}
• Authorlast. Editorlast (ed.). Title.

Example 2

• {{cite book|last1=Authorlast1|editor-last1=Editorlast1|title=Title}}
• Authorlast1. Editorlast1 (ed.). Title.{{cite book}}: CS1 maint: numeric names: authors list (link)

Example 3

• {{cite book|author=Authorname|editor=Editorname|title=Title}}
• Authorname. Editorname (ed.). Title.

65.254.10.26 (talk) 01:13, 26 January 2022 (UTC)

How to have multiple URLs for the same source (e.g., for discontinuous pages)

Sometimes multiple URLs are useful to direct the reader to multiple pages within the same source. I've found it useful mostly in early work in natural history when the reader might also want to see an associated plate for the text, e.g. (with irrelevant parameters removed):

• {{cite book|title=Nassidæ, Turbinellidæ, Volutidæ, Mitridæ|page=127|url=https://biodiversitylibrary.org/page/11043993|postscript=; [https://biodiversitylibrary.org/page/11044213 Pl. 27], Fig. 110.}}
• Nassidæ, Turbinellidæ, Volutidæ, Mitridæ. p. 127; Pl. 27, Fig. 110. {{cite book}}: External link in |postscript= (help)CS1 maint: postscript (link)

• {{cite book|title=Nassidæ, Turbinellidæ, Volutidæ, Mitridæ|page=127; [https://biodiversitylibrary.org/page/11044213 Pl. 27], Fig. 110.|url=https://biodiversitylibrary.org/page/11043993}}
• Nassidæ, Turbinellidæ, Volutidæ, Mitridæ. p. 127; Pl. 27, Fig. 110.

This also is occasionally useful when citing articles in newspapers when an article is continued on a page very far from the initial one. I don't have an example off-hand, but for older newspapers there quite often isn't a single URL for the entire source, rather you're linking to individual scanned pages and if the article is on A1 and A42 it can be convenient to the reader to have a URL to both pages.

However neither putting a url in |page= or |postscript= seems to be approved so I was wondering what the way to cite sources like this would be in a way that doesn't require the reader to have to put in the effort to find a second page that can be quite far from the first. It seems when people fix "External link in |<param>=" they often just remove the URL which I think ends up being a net loss. Is there a "right" way I can include multiple links within a single citation parameter? Umimmak (talk) 04:53, 26 January 2022 (UTC)

URLs in |page= are still supported without error messages. URLs in |postscript= have never been supported, as far as I know. |postscript= Controls the closing punctuation for a citation, and the modules have gradually been adjusted to detect nonconforming text. Editors are always free to add more information after the closing braces of the citation template. – Jonesey95 (talk) 05:01, 26 January 2022 (UTC)

Okay that makes sense. I wish people fixing these errors didn't just remove the URLs then but noted about the ways this can be resolved, thanks. Umimmak (talk) 05:11, 26 January 2022 (UTC)

cite conference date/place written, presented, published

What is the proper markup for indicating all three datees and places in {{cite conference}}:

1. Date and place the authors wrote the paper
2. Date and place the authors presented the paper at the conference
3. Publication date and place for the conference proceedings

Also, should |conference= include Proceeding of or a similar prefix, ot just the name of the conference itself? --Shmuel (Seymour J.) Metz Username:Chatul (talk) 14:03, 26 January 2022 (UTC)

Of most importance is publication |date= and |location= (along with |publisher=). |title= is the title of the authors' paper, |book-title= is the collection of papers (often titled Proceedings ...). |conference= is free-form so can hold the name, dates, and location of the conference (if not already part of |book-title=. Where and when the authors wrote a paper that is presented at a conference seems to me of little value when an en.wiki reader is looking for a copy of that paper. You are citing a published paper in a proceedings so the basics are the same as if you were citing a chapter in a book or an entry in an encyclopedia.

—Trappist the monk (talk) 15:00, 26 January 2022 (UTC)

The only one that's important is the publisher's location. The others are not bibliographically important, though in many cases the title of the book/proceedings will include the location of the confrence. Headbomb {t · c · p · b} 16:01, 26 January 2022 (UTC)

Discussion at VPT involving Cite Encyclopedia

See WP:VPT § Broken template. 71.247.146.98 (talk) 12:59, 27 January 2022 (UTC)

Category:CS1 Latin American Spanish-language sources (es)

I am seeing this redlinked category showing up at the bottom of Huaynaputina. As far as I know {{lang}} does not produce such a category with the parameters of the page, but perhaps someone here knows why it's showing up? Jo-Jo Eumerus (talk) 10:26, 28 January 2022 (UTC)

This citation has |language=es-419 which MediaWiki interprets as {{#language:es-419|en}} → Latin American Spanish. cs1|2 takes language names from MediaWiki.

Category created. But some work still needed to include all parts of the language tag in the category name.

—Trappist the monk (talk) 12:53, 28 January 2022 (UTC)

"Cite document" needs its own template. Redirecting to cite journal is illogical and unfriendly. There are many genuinely free-standing documents that are not web pages and not reports.

An article that I watch (Backslash) cites some old documents that just happen to be accessible by https. They are PDFs. They are not journals, they are not reports, tech or otherwise, they are not web pages. They are documents. Take this one for example:

• cite document |title = Bulletin 125, issue 2: Description and Adjustments of the Teletype Wheatstone Perforator |publisher= Teletype Corporation |date=May 1938 | orig-date= August 1937 |url = http://www.navy-radio.com/manuals/tty/tty125.pdf |page=ii

Almost as a general principle, if the target is a pdf, then it is a document not a web page. The fact that (currently) we use http[s] to access the host directory is just coincidental: a while back we would have used FTP. Would anyone have suggested a template:cite ftp? (rhetorical question, they probably would).

The solution is simple: copy {{cite report}} changing "(report)" to "(document)".

Salix alba raised this here in June last (Help talk:Citation Style 1/Archive 77#cite document ) and got a fatuous reply that I'm amazed they accepted. Pinging @Jason Quinn: who previously complained at template talk:cite document#Should not be a redirect and @MJL: who proposed that the redirect include R with possiblities. --John Maynard Friedman (talk) 12:29, 28 January 2022 (UTC)

I had replied to the user in the archived discussion. I thought I explained the issue, and if one finds the reply "fatuous", I can't help it.

Again, though, citations involve only published material. Therefore the publishing media are important. If the document was originally published online, by a website, that is how the citation editor should present it as. Notice that in this case the pdf icon gives further info about the source format, which also has its own dedicated parameter. A reader following such citation is looking for a webpage which embeds or links to a pdf document. That last technical detail is minor. 71.247.146.98 (talk) 13:10, 28 January 2022 (UTC)

71.247.146.98 - How would you suggest we cite the 1930s document mentioned above? How would you suggest we cite it if we did not have a URL? GoingBatty (talk) 14:50, 28 January 2022 (UTC)

My first reaction was to cite the document as a periodical because 'Bulletin 125 issue 2'. But that doesn't work because no periodical name. So that makes me wonder if a wrapper template around {{cite report}} isn't a better solution. An example (using {{lay source}} because it's handy and will serve as a crude demonstration – ignore the 'Lay summary in: ' prefix):

{{lay source |template=cite report |type=Document |title=Bulletin 125: Description and Adjustments of the Teletype Wheatstone Perforator |issue=2 |publisher=Teletype Corporation |date=August 1937 |url=http://www.navy-radio.com/manuals/tty/tty125.pdf |via=Navy-radio}}

Lay summary in: Bulletin 125: Description and Adjustments of the Teletype Wheatstone Perforator (PDF) (Document). Teletype Corporation. August 1937 – via Navy Radio.

I left out |page=ii because there is no page ii in the document; also date of the change-notice is not the date of the document

In a real version of the wrapper template, |type=Document would be set internally; all other parameters are whatever an editor would want them to be.

—Trappist the monk (talk) 15:31, 28 January 2022 (UTC)

I agree with the use of {{cite report}}. But this is not a lay source, it is from the actual manufacturer. So no need for a wrapper. I would also use |type=loose leaf based on the visible perforations of the original. 65.88.88.47 (talk) 15:45, 28 January 2022 (UTC)

71.247.146.98 "Fatuous" might have been a little cruel, perhaps "mathematically trivial". In essence it said "it is what it is, because that is how it is".

To return to my example, the document was first published in 1938 as field support bulletin, on paper, possibly as a pamphlet or maybe just pages clipped together. Not a book, a document. It has been scanned and reproduced online, as PDF. In this case (as in many) the medium is not the message; in fact the medium is as irrelevant as whether it was first composed using a pen or a pencil, which typewriter was used to type it up and which kind of printing press used to print it.

Since hard cases make bad law, I would argue that any document distributed (or accessed) as a .pdf is not a web page. It is not formatted like a web page, it doesn't use HTML. In fact its only connection with web technology is the ubiquitous nature of the WWW as an easy distribution method. In fact I have seen quite a few PDFs that are clearly camera ready copy, complete with crop lines and colour balance verification marks in the outer margins.

I know wp:other stuff exists, but why is it reasonable to have {{cite technical report}} but no support for the far more common generic document? --John Maynard Friedman (talk) 14:53, 28 January 2022 (UTC)

Can we not split hairs? If a document is published online, that is what it is. The format is recognized because the publishing platform can accommodate various types of documents, pretty much like a printing facility can bound hardcover, softcover, leather etc. It was not suggested that {{cite web}} be used indiscriminately. Per the documentation, it should be used for online material when other options have been excluded. In the particular case, Trappist suggested a solution above, using {{cite report}}. 65.88.88.47 (talk) 15:53, 28 January 2022 (UTC)