Help talk:Citation Style 1

Citation templates

... in conception

... and in reality

Param suggestion: |page-url=

A lot of the citations that I see pointing to references on archive.org include urls to the specific pages in the |page= parameter as in |page=[https://archive.org/details/cihm_07495/page/n255 237]. It seems like an additional parameter, perhaps named |page-url=, would be handy to keep track of this information separately. So far, I've been leaving the links like this because they don't appear to be breaking anything yet. Slambo (Speak) 15:43, 20 July 2021 (UTC)

It should be an alias of |url=, not a new parameter. Only 1 URL, the more specific one should be entered in citations, with the page, or the first page in a page range. In any case, I would remove the url from the page param and insert the url param. If the citation includes a page number, it is understood that the link may lead to the pertinent page. If one needs to link multiple pages, short refs would be more apt imo. 50.74.114.218 (talk) 17:46, 20 July 2021 (UTC)

Why? The URL of the publication provides access to information on the context of the cited pages. --Shmuel (Seymour J.) Metz Username:Chatul (talk) 14:04, 21 July 2021 (UTC)

That is correct. But also potentially confusing, in the sense of having two URLs pointing to different things, i.e. information/context about the work (the work's URL) and the in-work location (the page's URL). I am not certain the average reader will be able to navigate this with ease. I suppose personally I would include the work's URL in the full citation, and the page URLs on short references. But this is just a preference. 65.88.88.126 (talk) 16:54, 21 July 2021 (UTC)

We recently had a related discussion at Help talk:Citation Style 1/Archive 78#How to extlink the components of a multi-component publication.

These page links are typically added by bots. When I first saw them added to articles a couple of years back I too thought they would be a bad idea (because they add clutter to the |pages= parameters), however, they are not as bad as they might look at first sight: Like you already observed, they are not breaking anything (in any of the page-related parameters, that is), because the links are automatically removed before using the page information for metadata.

Regarding the suggestion of having (only) one alias to |url= for a "page link" and for the proposal to have numbered page parameters (in the other thread), this wouldn't work:

To the contrary of what the IP stated, the |pages= parameter often contains a list of pages or even page ranges, and it is not at all desirable to split them up into individual pages or use short references for them. Splitting up into individual pages is only necessary when it is particularly important to document the exact locations where multiple independent statements are sourced. In the vast majority of cases, this is not important, and combining all references to a single publication and providing a list of pages is sufficient. In most cases, it is easy enough to flip through these pages to find the one supporting a specific statement, so having individual references for each of them would only add redundancy and clutter to the article. Short references add an extra layer of indirection and don't allow for backlinks, therefore they are often inconvenient to use - they kind of solve one problem by adding a bunch of other problems. Per WP:CITEVAR, they are not a requirement at all to use and many people do not (want) to use them because of their shortcomings. So, suggesting anything that would force us to split up citations is simply no solution at all.

Regarding numbered page links (as suggested in the other thread), this would require not only numbered page link parameters but also numbered page parameters, as otherwise it would be next to impossible to know which link belongs to which page. While this would be technically a workable solution, it would not be a good one, because it would make the list of pages even more difficult to read and add an enourmous amount of parameter clutter to citations. It would also make the code much more complex and difficult to maintain. I mean, we do have numbered parameters for the various types of contributors, but we don't have them because this would be a particularly great idea but simply because the template has a need to know the given name, surname and optionally the link to generate the proper representation for display and metadata purposes from this, and the complexity of naming schemes makes it impossible to just provide a name list and let the template reliably extract the informational bits from it. It would work in some cases, but not in general, that's why we need a set of numbered parameters for the names. However, although there is a huge variety in page numbering schemes, they are still much simplier than names and therefore the code can be made smart enough to reliably extract all the necessary information from a single parameter argument.

Finally, there was a complaint that it would be a bad design decision for parameters to accept multiple types of input. I can see where this comes from, and it sometimes holds true, but not for citation templates in Wikipedia. I consider our approach to be kind of object-oriented (or at least we try to give this impression to users). There are limits, but ideally, you could throw any kind of "data objects" holding the relevant information at a parameter and the template would be able to figure everything out by itself. From the viewpoint of users, the most intuitive way to give a link is to use our standard Mediawiki wikitext syntax. Also, it simply should not matter if they provide a single page, a page range, a list of single pages, a list of page ranges, any kind of combination of them, a linked page, linked page range, list of linked pages or linked ranges, you got it... (Not in the case of page-related parameters, but for completeness, in some cases, parameters also accept some symbolic keywords in addition to text objects.) What can be more simple and intuitive from a user's perspective than to allow them to use the normal Wikitext syntax and just provide a list of data items? Actually, it can't be easier than this. (Unfortunately, we can't do this for names, at least not without introducing a special syntax, which would defeat the idea.)

One more thought on this: As stated above already, I too do not particuarly like these long strings such as |page=[https://archive.org/details/cihm_07495/page/n255 237] (but I've come to accept them given that they add useful information for readers and that citations would only become longer when using special parameters for this). However, in many cases the first part of these links is the same as the link provided in the |url= parameter, like in |url=https://archive.org/details/cihm_07495. For these cases, I can envision some kind of shortcut notation like |page=[*/page/n255 237] |url=https://archive.org/details/cihm_07495. This obviously would not work for all cases, but it would reduce the clutter and redundancy in many cases already.

Somewhat related:

• Help_talk:Citation_Style_1/Archive_72#Smart_substitution_token_to_reduce_redundancy_among_input_parameters
• Help_talk:Citation_Style_1/Archive_72#Add_wayback-timestamp_parameter

--Matthiaspaul (talk) 12:11, 21 July 2021 (UTC) (updated 13:45, 13 August 2021 (UTC))

You say Short references add an extra layer of indirection and don't allow for backlinks,; however, I see back references to, e.g., 3270Intro, in IBM 3270#References. Admittedly it's a bit clunky, but it works. --Shmuel (Seymour J.) Metz Username:Chatul (talk) 14:04, 21 July 2021 (UTC)

I meant backlinks from the "base citations" back to the various short references. In your example, if you arrive at e.g. the "3270Intro" citation, there are no links to go to all the short references pointing to this entry; you would have to search for them by going through all the references. However, if I would arrive there, I would want to see all the other locations citing from this publication. With an extreme amount of work something like this could be constructed manually, but it would be prone to errors and very difficult to maintain. In your specific example of "3270Intro" there are only two short references pointing there, so they could be easily merged into one with no loss of information. Even in cases such as "3270DS", which have many more short references, most of them are referring to adjacent pages in chapter 3, so it is probably enough to refer to chapter 3 and perhaps the page range, but not to individual pages, and thereby avoid most if not all those short references. If there is a particularly important statement to be referred to, |quote= and |quote-pages= can be helpful as well. If the individual page numbers should be preserved, {{rp}} can be used for the individual pages and |pages= for the combined pages. This way, the additional layer of indirection can be avoided and automatic backlinks are possible.

--Matthiaspaul (talk) 15:00, 21 July 2021 (UTC)

Using <ref name=foo />{{rp|bar}} works well when you are only adding a page number to the base citation, but what is the equivalent to {{sfn|foo|p=bar|loc=baz}}? --Shmuel (Seymour J.) Metz Username:Chatul (talk) 21:52, 21 July 2021 (UTC)

I would just append it, separated by a comma, like in <ref name="foo" />{{rp|bar, baz}}. Alternatively, you could probably use something like {{rp|at=p. bar, baz}} oder {{rp|at=baz}}. Even page links can be used in combination with {{rp}}, although this may sometimes require to use of numbered parameters like |1=[Update 2021-08-11: Calling conventions have been improved, this is now no longer necessary].

However, WP:CITEVAR applies and you can use {{sfn}} etc. if you want. My point above was mostly that multiple pages are perfectly fine in a citation (even when used to support multiple independent statements in an article) and that there is no requirement and often no benefit splitting citations into individual short references - it comes with a price, and the disadvantages are often larger than the advantages - as usual, it depends on the circumstances. I made this point to illustrate why we need to support multiple pages and why proposals which would allow us to deal only with single (or related) pages in a citation do not lead anywhere.

--Matthiaspaul (talk) 12:53, 22 July 2021 (UTC)

Adding multiple page numbers that support different statements in a single citation is not a problem, but isn't this discussion about page links? It seems to me a full citation with multiple page links is unwieldy and full of clutter. A short ref with the specific page link for the specific wikitext seems more intuitive and easier to understand. 65.88.88.127 (talk) 17:10, 22 July 2021 (UTC)

Using {{rp|bar|at=baz}}, {{rp|bar, baz}} and {{rp|at=p. bar, baz}} gives me , and . The second and third have the right information, but the location is likely to be long and should be in the reference list rather than inline. --Shmuel (Seymour J.) Metz Username:Chatul (talk) 19:35, 22 July 2021 (UTC)

Still an issue with book volumes

All these months later, and the issue with book volumes is still not being addressed. I understand why we don't want an explicit "volume" with a journal/magazine. I do not understand the issue with books. If Birds of North America has 13 volumes, displaying "Birds of North America. 2." does not, to most humans, clearly indicate that the 2 refers to volume 2 – particularly given that the average reader probably has no idea that there are 13 volumes in the set. Why can template not behave differently depending on whether the item is a book or a journal?! I know it's possible to do so, so somebody must have some rationale for why we don't. Please explain! MeegsC (talk) 20:25, 27 July 2021 (UTC)

Inertia, basically.

Previous discussions have yielded two proposed alternative styles for rendering |volume=, |number=/|issue= (only used with journals) and |pages=:

	Journal	Not journal	Notes
Current	3 (4): 12–56.	3, pp. 12–56.	Long volume names are not bolded, but |volume=vol. 3 is considered an error.
Proposal 1	3 (4): 12–56.	vol. 3, pp. 12–56.
Proposal 2	vol. 3, no. 4, pp. 12–56.		Non-journals would not have a number or issue.

The current definition of "journal" is

• {{cite journal}}, or
• {{citation}}/{{cite map}}/{{cite interview}} with |journal= specified.

I believe we should offer these alternatives for wider consideration. Kanguole 09:37, 28 July 2021 (UTC)

{{cite magazine}}?

—Trappist the monk (talk) 11:07, 28 July 2021 (UTC)

Adding magazine to the current row:

	journal	magazine	others
Current	3 (4): 12–56.	Vol. 3 no. 4. pp. 12–56.	3, pp. 12–56.
Proposal 1	3 (4): 12–56.	vol. 3, no. 4, pp. 12–56.
Proposal 2	vol. 3, no. 4, pp. 12–56.

Kanguole 14:10, 28 July 2021 (UTC)

I support the proposed standardization, but I think that the "scientific" nomenclature might still be desirable to have in heavily academic articles, therefore, I suggest to introduce a |periodical-style= oder |serial-style= (or whatever) parameter to select the desired format if this is not the default already. (At a later stage, this could be supported by templates similar to the |cs1-dates= parameter of templates {{use dmy dates}}/{{use mdy dates}} to globally switch the display format for all citations in an article instead of having to use it in individual citations. I had some experimental code for this a year ago, but it would have to be adjusted to the current significantly changed code base.)

I believe that having such an option to override the default would significantly raise community acceptance of a general change to a more standardized format - without it, I already see the next tumult emerging from militant proposers of one of these formats. With such a parameter implemented, we would still instantly have a consistent format in the majority of articles (the goal, we want to achieve), but allow editors to override the default to address special needs in specific citations (and articles). Best of both worlds.

We could either use Proposal 1 as the default formats for the various templates and the parameter would allow to override the default and select the other format, or, we could choose Proposal 2 as the new general default format for all citation types and the parameter would have to be used in individual citations to switch to the scientific format.

--Matthiaspaul (talk) 16:53, 28 July 2021 (UTC)

I would be strongly against introducing another style configuration parameter. It would be another knob for people to twiddle and fight over, and we already have plenty of those clogging our watchlists. I would rather have a less-preferred option than that.

As for raising acceptance, I don't think anyone out there loves bold volumes for books. The choice between the other two should be settled at an RFC. Kanguole 17:11, 28 July 2021 (UTC)

Design by rfc; how appalling.

I too, am opposed to yet-another-style-parameter. {{cite journal}} renders the academic-journal-style. If you don't like that, use {{cite magazine}} oder {{cite periodical}}. No need for special parameters.

—Trappist the monk (talk) 17:58, 28 July 2021 (UTC)

If we want people to be able to use cite magazine - then it needs to be added to Wikipedia:RefToolbar/2.0 - otherwise most editors will just use the templates which the tools force upon them.Nigel Ish (talk) 18:29, 28 July 2021 (UTC)

You'll get no opposition from me but, good luck with that:

• Wikipedia talk:RefToolbar/Archive 2 § Enhanced toolbar drop down templates
• Wikipedia talk:RefToolbar/Archive 2 § Cite magazine
• Wikipedia talk:RefToolbar/Archive 3 § Request for Wikipedia to add the "cite magazine" citation template to RefToolbar
• Wikipedia talk:RefToolbar/Archive 3 § Request for Wikipedia to add the "cite magazine" citation template to RefToolbar, 2021

Maybe, if enough editors make noise about it, someone will do the necessary (thankless) labor that will give them what they want. Perhaps you?

—Trappist the monk (talk) 19:12, 28 July 2021 (UTC)

Well, if as indicated by the discussions on the RefToolbar page, the tool is not being maintained, then it should be deactivated.Nigel Ish (talk) 20:34, 28 July 2021 (UTC)

I think that you are mistaken. Multiple javascript pages implement WP:RefToolbar. The tool is mostly stable so there is little to do to it. Still, these parts of it were updated this year:

• MediaWiki:Gadget-refToolbar.js
• MediaWiki:RefToolbar.js
• MediaWiki:RefToolbarMessages-en.js
• MediaWiki:RefToolbarMessages-de.js – this is the English Wikipedia; why do we care about the German version here?

As I said before, if enough editors make noise about it, someone will do the necessary (thankless) labor that will give them what they want. If you want the change, recruit enough editors who also want the change, or, failing that, do it yourself.

—Trappist the monk (talk) 13:10, 29 July 2021 (UTC)

Design by RfC has proven to result in inconsistent, incoherent and typically less-powerful solutions. But forcing our own (typically great ;-) ideas onto the community is also no option. I mean, even here in this dedicated place where most of us have quite some experience with citation formats we often have vastly different views in regard to the best solution to a problem, clearly indicating that we have a diverse array of needs and therefore need flexibility to address them. That's why I think we should give the users some guidance (in form of reasonable defaults and good documentation) but also the necessary flexibility so that they can (if they need to) get the results they want to suit more special requirements. Otherwise, they will either complain about our templates or not use them. Both is unsatisfactory for them and us - and for the project as a whole.

I agree that in principal it would be enough to let {{cite journal}} use the scientific format and {{cite magazine}} the verbose format - basically that's a style-parameter in disguise. However, we have readers switching between these templates based on the nature of the periodical which would defeat the idea to choose the template based on the display format.

To sum it up, without a style-parameter to optionally override the default I could still support proposal 1, but not proposal 2.

--Matthiaspaul (talk) 02:05, 29 July 2021 (UTC)

@Matthiaspaul: we have readers switching between these templates based on the nature of the periodical - I do that frequently (example), because I often find that some people are inappropriately using {{cite journal}}, {{cite news}} and {{cite web}} for magazines - for me, it's not a case of choos[ing] the template based on the display format but of choosing the most appropriate template for the source. Each of these four has documentation that gives such advice:

• {{cite journal}} - academic and scientific papers published in bona fide journals
• {{cite magazine}} - articles in magazines and newsletters
• {{cite news}} - news articles in print, video, audio or web
• {{cite web}} - web sources that are not characterized by another CS1 template

I believe that the people who do not use {{cite magazine}} do so partly because they don't read the documentation, but mainly because it's not offered by the cite tool that they use (see post by Nigel Ish at 18:29, 28 July 2021 (UTC) and the reply by Trappist. So long as that remains the case, there will always be the need to amend the citation. --Redrose64 🌹 (talk) 09:58, 29 July 2021 (UTC)

Yeah, that's right. In fact, I'm doing this as well, but I'm reasonably happy with the difference in output formats between {{cite journal}} and {{cite magazine}}. I think we should continue to maintain this idea by choosing the most suitable parameter |journal= oder |magazine= based on the nature of the periodical. Typically, we would use |journal= in {{cite journal}} and |magazine= in {{cite magazine}}, but following Trappist's comment to choose the template depending on the desired output format above, we would need to acknowledge that some people might have deliberately chosen to use {{cite journal}} for |magazine= oder {{cite magazine}} for |journal=, and that, if this makes sense in a particular article rendering as a whole, we should leave this alone.

--Matthiaspaul (talk) 10:14, 29 July 2021 (UTC)

I think that what you are saying without actually voicing it is that {{cite journal}}, {{cite magazine}}, {{cite news}} all become redirects to the canonical template {{cite periodical}}. {{cite periodical}} then renders volume/issue/page in the style dictated by the |work= parameter alias that is used in the template. That would likely be a significant challenge, mostly elsewhere than in Module:Citation/CS1. Some one or some series of bots would need to convert existing templates; tools like WP:RefToolbar would need updating, etc. I rather like this idea but I foresee torches and pitch forks because en.wiki editors hate, hate, hate change...

—Trappist the monk (talk) 13:10, 29 July 2021 (UTC)

I generally favor some form of Proposal 1. Let {{cite journal}} use the shorter format. In {{cite magazine}}, get the page number next to the volume and issue number. (Currently if a publisher is specified, it splits the volume/issue from the page number.) In {{cite map}}, et al., tie the output to whether |journal= oder |magazine= is used.

For books though, I'd leave volume number next to title as a function of the title and retain the page number at the end, but otherwise add the "vol." text to the volume number for consistency. Imzadi 1979 → 22:46, 28 July 2021 (UTC)

Proposal 2 is the only scheme that makes sense for a project like Wikipedia. It is easily understandable by readers. The comma separator will have to be explained to editors since it violates style. This is because of the current rigid implementation of separators into "style 1" and "style 2", that carries no functional utility. 64.18.9.208 (talk) 23:40, 28 July 2021 (UTC)

• Support Proposal 2 Although I would be happy enough with Proposal 1. Agree with Imzadi about not splitting title from volume. I thought that the maintainers already turned this down. Hawkeye7 (discuss) 23:49, 28 July 2021 (UTC)
  • I'd personally prefer Proposal 2, but I think there would be too much inertia to completely move away from the abbreviated journal format. Imzadi 1979 → 00:16, 29 July 2021 (UTC)
• Strongly prefer 1, but could live with 2. Status quo is unacceptable. Headbomb {t · c · p · b} 01:22, 29 July 2021 (UTC)
• Support Proposal 1; I agree that the status quo doesn't work at all. And proposal 2 certainly "isn't the only one that makes sense", despite what an anonymous IP might assert. I'm assuming that if the "number" field is left blank, that parameter won't appear at all – i.e. vol. 2, pp. 12–56. MeegsC (talk) 10:28, 29 July 2021 (UTC)

Are you saying that readers are better served by different (and convoluted) renditions of issue and volume depending on the use of a template they know nothing about? And why is an assertion by something called "MeegsC" any better on the face of it? 64.18.9.201 (talk) 11:16, 29 July 2021 (UTC)

• Prefer Proposal 2 but also support Proposal 1 and strongly prefer either to the status quo. I think (based on no evidence, obvs) that the majority of editors who add citations to journal articles are probably happy with the academic shorthand since they are accustomed to it; hence the change will annoy them since style changes are always annoying. On the other hand, (still based on no evidence) our average reader probably hardly ever looks at an academic journal and is left to guess what the terse encoding means. I think we should prioritize clarity for the reader over the comfort of familiarity for the editor. This goes doubly for books where the shorthand is not, as far as I know, widely used. Wham2001 (talk) 11:11, 29 July 2021 (UTC)
• Strong support for Proposal 1. This gives the output for journals and books I'd expect to see in scientific literature. Books use Volume or Vol, while journals just have the number, which may be in bold (most?), italics (a few) or with no emphasis. —  Jts1882 | talk  12:17, 29 July 2021 (UTC)
• Proposal 2 - is unambiguous, where proposal 1 leaves ambiguity and leaves you scrtching your head as to what the numbers mean. And the opportunity of mixing styles in a single article is not very good. Keith D (talk) 12:50, 29 July 2021 (UTC)
• Strong Support for Proposal 1. From a biology viewpoint the vast majority of of scientific journal citations are in an APA style-style which renders volume 8, issue 10 as 8(10) or 8(10) or 8(10). I feel it would be strange to include "vol." in a biology citation, but not unheard of. However, per MeegsC there really needs to be a change, there are so many scientific books published in volumes and cited with words to note the volumes. Jack (talk) 14:11, 22 August 2021 (UTC)
• Proposal 1 - there is no way we can do proposal 2 without getting a lot of immediate friction from the community that will inevitably result in a workaround like the proposed |periodical-style= above which introduces yet more complication. Image the problem of creating a citation via automated means and trying to determine the right style to use for a particular article; then we need to have something like {{use dmy}} cluttering the top of every article. No, don't go that route. Proposal 1 maintains what already exists for {{cite journal}} which is by far the largest of all and will have the least friction while fixing the problem with the other smaller templates. -- GreenC 14:40, 22 August 2021 (UTC)

Wikipedia is not a science publication. It is also not a special-purpose vehicle for professionals of any sort, including those in the field of biology. There is also the argument that a solution tailored to the entire community (its readers) has to be bypassed because a minority (its editors, or a subset thereof) may cause a fuss. Not very surprising. "Wikipedians" :) often act with a sense of ownership, and also often throw fits. In the meantime Wikipedia, rather unselfconsciously, proclaims its own worthlessness. 195.123.233.197 (talk) 15:55, 22 August 2021 (UTC)

Definitely agree with the IP here. Articles are not WP:OWNed by any particular individuals, and if we decide here that using vol. 3 no. 2 is better than using 3 (2), a proposition I strongly agree with, then it is right and proper, for the benefit of our readers that we allow that to propagate to all articles which cite journals.  — Amakuru (talk) 10:51, 23 August 2021 (UTC)

Who is "we"? Experience has shown, repeatedly, the community all million plus are sensitive to changes of status quo, and when "we" decide to changes things for their "readers" own good according to our expert and correct opinions, the 'pitchforks' come out and trenches are dug. IMO this is a more significant change then say |accessdate= vs. |access-date= and you know how that went, the battle lines now so hardened it is a dead issue, it will never get fixed. Once wide-scale attention is made to the issue, you loose control. Stay as close as possible to status quo and fix the small things that really need fixing, it will be successful. Come back later and deal with cite journal as a separate issue because chances are it will be no-consensus. -- GreenC 20:47, 23 August 2021 (UTC)

You are correct that any challenge to the status quo will cause a disturbance. Whether that should dissuade from applying the better solution is the question. If it does, mediocrity wins again. This is a norm here. After all, this is a project where without any sense of irony or self-awareness, the majority of its content is designated suspect by default. There is a small minority of so-called "good articles". Which one would think, should immediately give rise to the question, why should an encyclopedia publish articles that it has itself designated as non-good? Compared to such institutional schizophrenia the pitchforks no doubt already being sharpened over this thread seem like toothpicks. 195.123.233.197 (talk) 00:21, 24 August 2021 (UTC)

• Proposal 2. I've long thought that the 3(2) format is not ideal for use in an encyclopedia, where most readers are not specialists and may not automatically know what it means. It's far better to explicitly spell out what is meant, using the vol. and no. nomenclature, as per the Chicago or MLA citation style. This should apply to any publication be it a journal, book, magazine or anything else.  — Amakuru (talk) 10:47, 23 August 2021 (UTC)
• Proposal 1. However, I would like a means to request that {{cite magazine}} use the same nomenclature as the publisher for the issue. --Shmuel (Seymour J.) Metz Username:Chatul (talk) 19:18, 23 August 2021 (UTC)

Implementation

It seems to be universally agreed that bold volume numbers for non-journals are unacceptable, but opinion is divided on whether to retain them for journals, i.e. there is no consensus for change there. So I've changed the sandbox to extend the magazine formatting to all non-journals.

Cite book comparison

Wikitext	{{cite book|first=Ann|last=Author|pages=12–34|title=Book|volume=3|year=2000}}
Live	Author, Ann (2000). Book. Vol. 3. pp. 12–34. {{cite book}}: |last= has generic name (help)
Sandbox	Author, Ann (2000). Book. Vol. 3. pp. 12–34. {{cite book}}: |last= has generic name (help)

Cite journal comparison

Wikitext	{{cite journal|first=Ann|journal=Journal|last=Author|number=5|pages=12–34|title=Article|volume=3|year=2000}}
Live	Author, Ann (2000). "Article". Journal. 3 (5): 12–34. {{cite journal}}: |last= has generic name (help)
Sandbox	Author, Ann (2000). "Article". Journal. 3 (5): 12–34. {{cite journal}}: |last= has generic name (help)

Citation comparison

Wikitext	{{citation|first=Ann|last=Author|pages=12–34|title=Book|volume=3|year=2000}}
Live	Author, Ann (2000), Book, vol. 3, pp. 12–34 {{citation}}: |last= has generic name (help)
Sandbox	Author, Ann (2000), Book, vol. 3, pp. 12–34 {{citation}}: |last= has generic name (help)

Citation comparison

Wikitext	{{citation|first=Ann|journal=Journal|last=Author|number=5|pages=12–34|title=Article|volume=3|year=2000}}
Live	Author, Ann (2000), "Article", Journal, 3 (5): 12–34 {{citation}}: |last= has generic name (help)
Sandbox	Author, Ann (2000), "Article", Journal, 3 (5): 12–34 {{citation}}: |last= has generic name (help)

Kanguole 19:11, 10 September 2021 (UTC)

Separator between volume and number

Looks good. Here are two more for comparison (no change):

Citation comparison

Wikitext	{{citation|date=2000|first=Ann|last=Author|magazine=Magazine|number=5,7|pages=12–34|title=Article|volume=3,5}}
Live	Author, Ann (2000), "Article", Magazine, vol. 3, 5, no. 5, 7, pp. 12–34 {{citation}}: |last= has generic name (help)
Sandbox	Author, Ann (2000), "Article", Magazine, vol. 3, 5, no. 5, 7, pp. 12–34 {{citation}}: |last= has generic name (help)

Cite magazine comparison

Wikitext	{{cite magazine|date=2000|first=Ann|last=Author|magazine=Magazine|number=5,7|pages=12–34|title=Article|volume=3,5}}
Live	Author, Ann (2000). "Article". Magazine. Vol. 3, 5, no. 5, 7. pp. 12–34. {{cite magazine}}: |last= has generic name (help)
Sandbox	Author, Ann (2000). "Article". Magazine. Vol. 3, 5, no. 5, 7. pp. 12–34. {{cite magazine}}: |last= has generic name (help)

However, I think we should put at least a comma (possibly a dot in CS1) between the volume and the number info. It looks odd to me that there is no separator between them even in the simple cases above, but even more so in more complicated cases (for illustration purposes I changed the |volume= and |number= parameters to contain lists).

--Matthiaspaul (talk) 14:48, 15 September 2021 (UTC)

Yes, the current presentation of {{cite magazine}} is unchanged, and now extended to other non-journals. However, the combination of |volume= and |number= should only occur with magazines and journals, so their formatting is independent of this change. Kanguole 15:27, 15 September 2021 (UTC)

I'd add that I've never seen lists in |volume= oder |number= in the wild – it's usually 3/4 or 3–4. If an article is published in several parts with different page ranges in different issues/volumes, they would have to be separate cites. Kanguole 15:34, 15 September 2021 (UTC)

I have, although rarely and not in combination in both |volume= and |number=. I used it here as an example to show more clearly, that there is something missing between the volume and the number. I basically "hijacked" this thread for the possible discussion of adding a comma (or dot), because this would be another minor change likely accepted (if even noticed) by the masses, and because this thread already has a nice list of rendered citation templates for quick comparison of the output.

--Matthiaspaul (talk) 16:48, 15 September 2021 (UTC)

Done. --Matthiaspaul (talk) 14:19, 24 September 2021 (UTC)

error messaging

This is a sidetrack off of Help talk:Citation Style 1/Archive 77 § summary messaging in the preview warning header. Over the past few days I have been reworking how error messaging is handled in the various modules (primarily Module:Citation/CS1 and Module:Citation/CS1/Identifiers which emit the most errors). In the previous conversation, I suggested that it would be a good thing to move all error messages to the end of the citation. As it is right now, some error messages are made part of the template's rendering which, to me, looks bad.

The live module has a table called z.message_tail which holds all of the error messages that are rendered following the citation. To load that table, it is necessary for the code to call set_message() in Module:Citation/CS1/Utilities. That function returns the error message as a plain message or as a message wrapped in <span>...</span> tags appropriately classed for hidden or visible error messages. The function that called set_message() then has to use the returned message as an appendage on a parameter's data or as a replacement for it; or, the function must insert the returned message into the z.message_tail table. Moving all error messages to the end of the citation means that set_message() can insert the message in z.message_tail as part of its normal operation and so the code is simpler and more consistent.

I have done that. The change primarily impacts Module:Citation/CS1/sandbox and Module:Citation/CS1/Identifiers/sandbox but also impacts Module:Citation/CS1/Utilities/sandbox. I have renamed z.message_tail to z.error_msgs_t so that the name reflects its content.

As part of this I have spent a bit of time refining the assembly of the various parts of the finished citation (the citation itself, the anchor ID and the css classes in the <cite> tag, the metadata, the error messages, the maintenance messages, and the categories (roughly the 100ish lines of code beginning at about line 3844 of Module:Citation/CS1/sandbox). This includes the error and maintenance summaries and the error message prefixes discussed in the previous conversation, sorting of error and maintenance messages. Empty citations will no longer produce metadata because why bother:

{{cite book}}

{{cite book}}: Empty citation (help)

'"`UNIQ--templatestyles-00000070-QINU`"'<cite class="citation book cs1"></cite> <span class="cs1-visible-error citation-comment"><code class="cs1-code">{{[[Template:cite book|cite book]]}}</code>: </span><span class="cs1-visible-error citation-comment">Empty citation ([[Help:CS1 errors#empty_citation|help]])</span>

{{cite book/new}}

{{cite book}}: Empty citation (help)

'"`UNIQ--templatestyles-00000073-QINU`"'<cite class="citation book cs1"></cite> <span class="cs1-visible-error citation-comment"><code class="cs1-code">{{[[Template:cite book|cite book]]}}</code>: </span><span class="cs1-visible-error citation-comment">Empty citation ([[Help:CS1 errors#empty_citation|help]])</span>

—Trappist the monk (talk) 22:02, 28 July 2021 (UTC)

I wonder if some kind of "error framing" could be done (at least in preview) to make it easier for editors to spot the errors. Mockup:

{{cite journal |last=Smith |first=John |date=9999 |title=Title of Things |journal=Journal of Stuff |volume=Vol. 34 |issue=1 |pages=23–45 |doi=10.4321/3210 |pmid=012345}}

Smith, John (9999). "Title of Things". Journal of Stuff. Vol. 34 (1): 23–45. doi:10.4321/3210. PMID 012345. {{cite journal}}: |volume= has extra text (help); Check date values in: |date= (help)

I assume it would complicate the code too much but still wanted to mention it to spread the idea.

--Matthiaspaul (talk) 00:59, 29 July 2021 (UTC)

In your example above

<span class="cs1-visible-error citation-comment">*</span><span class="cs1-visible-error citation-comment">*</span>

the two message spans could be combined into one:

<span class="cs1-visible-error citation-comment">**</span>

to reduce the size of the resulting HTML. However, I understand that this might not always be possible if they are interwoven with hidden messages, so I'm mentioning this just in case you see an easy way to do it anyway.

--Matthiaspaul (talk) 12:07, 1 August 2021 (UTC)

Yeah, they could be combined but it is much easier in the code to have them as separate spans because we can't always and forever know that the first error message after the prefix will be a visible error message. However, that does highlight a flaw in the prefix design; if all error messages emitted by a citation are hidden, then the prefix should also be hidden. As it is, it is always visible. I'll think about that ...

—Trappist the monk (talk) 15:10, 1 August 2021 (UTC)

Citations emitting only hidden error messages will also hide the error message prefix:

{{cite journal/new |title=Title}}

"Title". {{cite journal}}: Cite journal requires |journal= (help)

'"`UNIQ--templatestyles-0000007A-QINU`"'<cite class="citation journal cs1">"Title".</cite><span title="ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Ajournal&rft.genre=article&rft.atitle=Title&rfr_id=info%3Asid%2Fen.wikipedia.org%3AHelp+talk%3ACitation+Style+1" class="Z3988"></span> <span class="cs1-visible-error citation-comment"><code class="cs1-code">{{[[Template:cite journal|cite journal]]}}</code>: </span><span class="cs1-visible-error citation-comment">Cite journal requires <code class="cs1-code">&#124;journal=</code> ([[Help:CS1 errors#missing_periodical|help]])</span>

—Trappist the monk (talk) 16:29, 1 August 2021 (UTC)

Do not emit duplicate IDs in any case. Our objective is to comply with HTML and that does not. Thanks. I'll revert the lot of the sandbox if that remains in the code. The supposed gain is not worth that. Izno (talk) 14:12, 3 August 2021 (UTC)

Presumably this is related to discussion that occurred at Help talk:Citation Style 1/Archive 77 § summary messaging in the preview warning header regarding links from the preview warning messages to citations elsewhere in the previewed article. Where were you and your objections when we first discussed this? You were around and even edited this page during the period of that conversation. Instead of swooping in with drama and threats after the fact, it would have been better for you to participate in the discussion as it was on-going.

The point is taken and I have removed the spans and go-to links.

—Trappist the monk (talk) 15:37, 3 August 2021 (UTC)

Busy trying not to care about Matthias' outlandish requests? :) Izno (talk) 15:51, 3 August 2021 (UTC)

Not funny, and not outlandish at all. It's all about user-friendliness and usability.

The anchors/spans are added only if there is a problem in a citation. So articles without problematic citations will never have them. Also, above I proposed to add them only in preview in order to not invalidate HTML in normal article view. Even web designers who otherwise care about good HTML often deliberately ignore trivialities like this, in particular if it is known to not cause any harm.

Further, all articles with citations lacking disambiguation contain identical anchors and thereby contain invalid HTML - and not only in preview or with actual citation errors, but in normal article view for as long until the disambiguation gets fixed. And in this case, a doubled anchor actually causes "harm" as it makes subsequent citations "unreachable". When we discussed this when making |ref=harv the default, we decided to ignore this because the benefit far outweights the problem. Nobody complained about it.

We should do the same here as well, in particular as in this case the doubled anchors do not create any practical problem for browsers at all and do only exist in preview and when citations have errors, anyway. So, ignoring the "no double anchors" doctrine would be a valid engineering decision. If we do not, we should immediately switch off harv-style anchors as well.

--Matthiaspaul (talk) 17:28, 3 August 2021 (UTC)

HTML structure of a citation

However, there is a related, more general issue. This is unrelated to preview messages and the restructuring of error messages, but since we are talking about the structure of the HTML for a citation, I'm bringing this up anyway.

The general structure of a citation (in the sandbox, that is, including the preview message) is as follows:

<span id="cite-book-error"></span><cite id="CITEREF*" class="citation book cs1">Citation with appended messages</cite><span title="ctx_ver=Z39.88-2004&rft_val_fmt=*" class="Z3988"></span>

Citation with appended messages

Some browers and tools allow to highlight the scope of elements and navigate from element to element or otherwise take advantage of knowing the scope of data elements (screenreaders and browsing assistance tools, web development tools, web harvesters). Right now, they see a citation as an empty preview error span, the actual citation with optional messages appended, followed by the COinS info.

This is somewhat suboptimal. The preview error span should span over the whole citation including messages and COinS data.

In addition to this, the COinS span should ideally span over the citation and messages as well in order to declare the context of the COinS data. This would result in the following nested structure:

<span id="cite-book-error"><span title="ctx_ver=Z39.88-2004&rft_val_fmt=*" class="Z3988"><cite id="CITEREF*" class="citation book cs1">Citation with appended messages</cite></span></span>

Citation with appended messages

The only adverse effect of this rearrangement I can see right now is that the browser will now display the COinS data as tooltip, which might be confusing. So, if the contents of the COinS span really must be empty, it might be possible to do it the other way around and embed it into the cite element. The preview error span could still wrap around both:

<span id="cite-book-error"><cite id="CITEREF*" class="citation book cs1">Citation with appended messages<span title="ctx_ver=Z39.88-2004&rft_val_fmt=*" class="Z3988"></span></cite></span>

Citation with appended messages

In both of these two cases, the proper extraction of COinS data by existing tools would have to be tested, because in the examples I could find on the web they always suggest that this is an empty element (or only containing a space) immediately following the citation. At least wrapping the preview span around both of them will work regardlessly:

<span id="cite-book-error"><cite id="CITEREF*" class="citation book cs1">Citation with appended messages</cite><span title="ctx_ver=Z39.88-2004&rft_val_fmt=*" class="Z3988"></span></span>

Citation with appended messages

--Matthiaspaul (talk) 12:07, 1 August 2021 (UTC)

Umm, the general structure of a sandbox citation is not quite what you say it is. See for example this:

{{cite book/new |title=Title |access-date=2021-08-01}}

Title. {{cite book}}: |access-date= requires |url= (help)

<templatestyles src="Module:Citation/CS1/sandbox/styles.css"></templatestyles><span id="cite-book-error"></span><cite class="citation book cs1">''Title''.</cite><span title="ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Abook&rft.genre=book&rft.btitle=Title&rfr_id=info%3Asid%2Fen.wikipedia.org%3ABlue" class="Z3988"></span> <span class="cs1-visible-error citation-comment"><code class="cs1-code">{{[[Template:cite book|cite book]]}}</code>: </span><span class="cs1-visible-error citation-comment"><code class="cs1-code">&#124;access-date=</code> requires <code class="cs1-code">&#124;url=</code> ([[Help:CS1 errors#accessdate_missing_url|help]])</span>[[Category:CS1 errors: access-date without URL]]

so what we have is:

<span id=<cite book error anchor>></span><cite>The Citation</cite><span <COinS metadata>></span><messaging><categories>

I created empty error-anchor and maint-anchor spans because that is how {{anchor}} implements anchors. It is easy enough to wrap the entire rendering from <cite> to the end of the last category in the error-anchor and maint-anchor spans. If we did that, we could add an undefined class so that editors can style the anchored citations; don't know how beneficial that would be ...

I am unwilling to change how the metadata span is handled without someone having conducted extensive research to prove that your suggestion does not break external tools. Apparently metadata works now so ain't-broke-don't-fix applies.

—Trappist the monk (talk) 14:55, 1 August 2021 (UTC)

Error-anchor and maint-anchors now wrapp entire citation from <cite> to the end of the last category:

{{cite book/new |title=Title |access-date=2021-08-01 |authors=Authors}}

Title. {{cite book}}: |access-date= requires |url= (help); Unknown parameter |authors= ignored (help)

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

—Trappist the monk (talk) 16:19, 1 August 2021 (UTC)

Looks good, thanks.

I agree, moving the COinS info will require more research in regard to what works with existing tools, and what might not. That's why I was bringing this up.

Unfortunately, the standard itself is not very clear about it, so implementations might vary in regard to what they expect. As far as I understand it, there should be no inherent dependency of the COinS span from <cite>, therefore from the viewpoint of data extraction, it should not matter, if one gets embedded into the other.

Regarding the contents of the COinS span, they suggest to use a space in environments where an empty span would be removed in some HTML optimization processes. From this we can at least derive that the span does not need to be empty.

They also talk about the possibility to place some default text in there, leaving it open to interpretation if COinS-aware browser plug-ins are meant to replace this text with some link/icon to a pop-up etc., or if they are meant to insert such links/icon after the text. If we find a browser plug-in which would replace the text, we obviously cannot place the citation there, otherwise this would be the most-"natural" place for it. It would be interesting to learn from the community which tools they use and how they behave on the following two test citations:

Manually crafted citation with <cite> inside COinS span:

Statement of Principles. The International Conference on Cataloguing Principles (CCP). Paris, France. 1961-10-18 [1961-10-09].

Manually crafted citation with COinS span inside <cite>:

Statement of Principles. The International Conference on Cataloguing Principles (CCP). Paris, France. 1961-10-18 [1961-10-09].

--Matthiaspaul (talk) 11:18, 3 August 2021 (UTC)

Given that the COINS span outputs its content as a title, putting cite inside the span is a non-starter. Everything internal will have a hover over title completely meaningless to users and defeating the other over hovers we have (links predominantly). Izno (talk) 14:10, 3 August 2021 (UTC)

Undesirable behaviour of issue= in cite magazine when the issue is a month or months

No doubt this is in the archives but I can't find it. Take for example this citation:

• Paul Lunde. "The Beginning of Hijri calendar". Saudi Aramco World Magazine. No. November/December 2005. Retrieved 1 January 2019.

The issue is "November/December 2005", it is nonsense to show it as "no. November/December 2005". The same problem would occur with "issue=Spring 2021" etc. Surely in the case where issues are numbered, the correct argument to use is "number="? How does it make sense to add a "no." prefix to "issue"? --John Maynard Friedman (talk) 09:46, 12 August 2021 (UTC)

Aren't those better handled as dates? (Doing so would require changing November/December to November–December)Nigel Ish (talk) 10:56, 12 August 2021 (UTC)

Agreed. In such cases, issues are dated, not numbered. 100.2.235.66 (talk) 11:46, 12 August 2021 (UTC)

No, that gives a very ugly result:

• Paul Lunde (November–December 2005). "The Beginning of Hijri calendar". Saudi Aramco World Magazine. Retrieved 1 January 2019.

which I admit is used and works fine for {{cite news}}. In this example, the 'issue=' setting puts the information in the logical place (after the title) in the citation: the only problem is that addition of the inappropriate 'no.' Why is that intrusion ever needed?

Using (a test) number= gives

• Paul Lunde. "The Beginning of Hijri calendar". Saudi Aramco World Magazine. No. 567. Retrieved 1 January 2019.

where the element is positioned logically and the insertion of 'No.' is entirely appropriate. --John Maynard Friedman (talk) 13:24, 12 August 2021 (UTC)

Here is the pdf of the Saudi Aramco World magazine issue in question. Note that this issue is volume 56 number 6 and the date is November/December 2005 so:

{{cite magazine |url=https://archive.aramcoworld.com/pdf/2000/200506.pdf |title=Patterns of Moon, Patterns of Sun |first=Paul |last=Lunde |magazine=Saudi Aramco World |date=November–December 2005 |volume=56 |issue=6 |access-date=2021-08-12}}

Lunde, Paul (November–December 2005). "Patterns of Moon, Patterns of Sun" (PDF). Saudi Aramco World. Vol. 56, no. 6. Retrieved 2021-08-12.

—Trappist the monk (talk) 14:04, 12 August 2021 (UTC)

Touché! I shall go and stand in the corner for the rest of the class for not having checked a citation after I cleaned it up.

BTW, why did you use "issue=6" and not "number=6"? Are they in fact synonymous, two names for the same bit of programming? If so, then that would explain everything and it will be obvious that my proposal (that issue= should not insert No. ) must get spiked. --John Maynard Friedman (talk) 17:51, 13 August 2021 (UTC)

|issue= and |number= are aliases.

—Trappist the monk (talk) 18:11, 13 August 2021 (UTC)

@John Maynard Friedman: Further to what Trappist wrote, the documentation explicitly shows that |number= is an alias for |issue=. So they must be expected to behave identically. --Redrose64 🌹 (talk) 22:56, 13 August 2021 (UTC)

@Redrose64: Add failure to RTFM to my sins. Detention as well for my pains.

(But they should be different, they have different meanings, so it was not just a lazy assumption. [xref Matthias P remark below]. In my sample citation, the issue is November/December, the number is 6. The date of publication is most likely to have been October. Most "in your local newsagent" magazines come out best part of a month before their declared issue date .) --John Maynard Friedman (talk) 23:23, 13 August 2021 (UTC)

(edit-conflict) |issue=6 is not wrong at present, but |number=6 would be better in this case to improve forward compatibility. At present, both parameters are treated as aliases and produce identical output. But different periodicals use different nomenclatures. It is therefore a good idea to use |issue= when the publication uses "Issues" as well, and |number= when they use "Numbers", so that the template can adapt and generate the appropriate prefix "Iss." or "No.". If the publication itself does not prescribe a certain nomenclature, it is best to use issues for volume-relative numbering schemes (as well as non-numeric issue names/titles) and number for absolute numbering schemes (because that's what most periodicals use - but not all).

Also, when we will finally add support for periodicals featuring both, a number and an issue (requested multiple times and planned for a long while), we will have to better distinguish between them to generate the proper output.

As discussed above, a date belongs into the |date= parameter, but there are cases where issues have actual names or titles. This still looks reasonably good in conjunction with |issue= ("Special issue") but not with |number=.

--Matthiaspaul (talk) 18:23, 13 August 2021 (UTC)

I suggest you put aside notions of "ugly". Most citation systems use terse, functional statements. Aesthetics rarely if at all enter the discussion. That doesn't mean that formatting cannot be improved, but such improvement must primarily enhance understanding and utility. 64.18.9.209 (talk) 14:32, 12 August 2021 (UTC)

I think that misses the point. The description "November/December 2005" is an adjectival phrase that relates to the magazine, not to the author. Fine, forget "ugly": let's be honest and say "amateurish". --John Maynard Friedman (talk) 17:51, 13 August 2021 (UTC)

That part of the style is consistent with the academic citation styles on which it is based.Nigel Ish (talk) 18:03, 13 August 2021 (UTC)

Well, the entire Wikipedia citation ecosystem, including CS1/2 has many, many faults in design, implementation, and documentation, not all which stem from misconceptions of what a citation system geared to non-expert users (readers) should be. But this case is fairly straightforward and easily addressable. The issue number and/or date are useful in locating the source, and if known should be made available, in a way that is obvious and clear. If the issue series is dated rather than numbered, use that information anywhere it makes sense. There is nothing wrong, ugly or amateurish in entering the issue date in the date field. This is correct. The formatting of the date itself is a different issue and does not affect the needed data. 69.193.187.30 (talk) 21:19, 13 August 2021 (UTC)

There may be nothing wrong with entering the issue date in the date field, but there are occasional instances when it won't work; notably, when journals use wacky dates like "Michaelmas" and "Trinity" for their issues [1]. —David Eppstein (talk) 21:36, 13 August 2021 (UTC)

OK, some magical process will turn static forms that apply certain generic positional & formatting rules - the so-called CS1/CS2 citation statements - into dymamic AI appliances that will perfectly account for every single special case under the sun, no matter how rare. Even though the current existing non-magical documentation at least hints otherwise, and even though 1. templates are not the only way to present CS1/CS2 citations and 2. CS1/2 citations are not the only way to reference. 68.173.76.118 (talk) 22:27, 13 August 2021 (UTC)

The templates can already accommodate some "non-date dates" - i.e. seasons, Easter and Christmas according to Help:Citation_Style_1#Dates - whether the templates are modified to accommodate others will depend on how often they are used.Nigel Ish (talk) 11:03, 16 August 2021 (UTC)

I think for this to be useful, we should support more or less complete sets. An editor of Christian topics would certainly wonder why s/he can enter "Christmas 2020", but not "Pentecost 2020", which both are used in clerical publications.

• https://www.ox.ac.uk/clarendon/offer-holders/clarendon-chronicle Hilary, Trinity, Michaelmas
• http://thecresset.org/archive.html Michaelmas, Advent-Christmas, Lent, Easter, Trinity
• https://web.archive.org/web/20200712075311/http://neurologicalsociety.org/journal1/index.php/clinneurosci/issue/view/1 Michaelmas
• https://heinonline.org/HOL/LandingPage?handle=hein.journals/ljusclr179&div=2&id=&page= Trinity/Michaelmas
• https://www.jstor.org/stable/155458 Qtr.
• https://www.loc.gov/standards/datetime/
• Help_talk:CS1_errors/Archive_2#Holiday_bad_date
• Help_talk:CS1_errors/Archive_2#Seasons_and_quarters_are_not_allowed_in_date_field
• Help_talk:CS1_errors/Archive_2#Quarterly_date_issues
• Help_talk:CS1_errors/Archive_3#Date_with_range_in_both_season_and_year
• Template_talk:Cite_journal/Archive_5#Citation_of_Journals_with_named_issues
• Help_talk:CS1_errors/Archive_2#Quarterly_date_issues
• Help_talk:CS1_errors/Archive_2#Seasons_and_quarters_are_not_allowed_in_date_field
• Help_talk:Citation_Style_1/Archive_3#Quarterly_periodicals
• Help_talk:Citation_Style_1/Archive_6#cite_journal_and_quarterly_publications
• Help_talk:Citation_Style_1/Archive_6#Quarterly_journal_date_format
• Help_talk:Citation_Style_1/Archive_6#Two_months_in_the_date_parameter
• Help_talk:Citation_Style_1/Archive_7#Date_parameter
• Help_talk:Citation_Style_1/Archive_8#Allow_"Quarter"_dates_in_Date_parameter?
• Help_talk:Citation_Style_1/Archive_10#Date_metadata
• Help_talk:Citation_Style_1/Archive_11#Cite_magazine_with_combined_season_date.
• Help_talk:Citation_Style_1/Archive_14#Quarterly_date_issues_(redux)
• Help_talk:Citation_Style_1/Archive_31#Multiple_years_and_seasons_in_a_date
• Help_talk:Citation_Style_1/Archive_61#Date_format_-_"Midsummer_1911"
• Help_talk:Citation_Style_1/Archive_67#Needs_exception_for_unusual-format_dates
• Help_talk:Citation_Style_1/Archive_67#Journal_with_nonstandard_date_format
• Wikipedia:Help_desk/Archives/2020_June_26#Dates_in_cite_news_template
• Help_talk:Citation_Style_1/Archive_68#named_dates:_Easter
• Help_talk:Citation_Style_1/Archive_68#Needs_exception_for_unusual-format_dates_(2)
• Help_talk:Citation_Style_1/Archive_69#Publication_date

Let's try to come up with some list of named dates to be supported:

• Michaelmas, Martinmas, Advent, Christmas, Candlemas, Hilary, Epiphany, Lent, Easter, Pentecost, Trinity
• Midspring, Midsummer, Midautumn, Midwinter
• Carnival
• Holiday
• First Semester, Second Semester
• Winter Semester, Summer Semester
• First Quadrimester, Second Quadrimester, Third Quadrimester

--Matthiaspaul (talk) 03:08, 18 August 2021 (UTC) (updated 13:25, 18 August 2021 (UTC), 17:54, 27 August 2021 (UTC))

In some cases, suffixed with the word 'term', as in Michaelmas term, Easter term, Epiphany term, Hilary term, Lent term, Summer term and Trinity term. --John Maynard Friedman (talk) 20:51, 18 August 2021 (UTC)

For this to be useful, may I suggest to stop proposing additional unnecessary complexity. Especially when there are other issues with the existing modules. Wikipedia is not a science publication or a clerical publication, or whatever your area of expertise or interest may be. There is more than enough badly presented complexity already. How many citations dated "Pentecost (year)" justify the additional coding and documentation (and for non-Christians, additional explanation)? There is |issue= and |date=, and also |quote= where you can quote the date period verbatim. One or more of those 3 should be sufficient for a small minority of cases. 184.75.82.14 (talk) 21:35, 18 August 2021 (UTC)

I agree completely. These notations invariably indicate the issue of the periodical, not its date. But it seems that there is no consensus here for that view, despite it being the style used everywhere else. --John Maynard Friedman (talk) 22:20, 18 August 2021 (UTC)

It would certainly be easier if this would always be the case. Unfortunately, the real world is often more complicated than this. Please read up the old discussions which led to general support for seasons, quarters and named dates in our citation templates. As you write, sometimes these names can be seen as part of the issue (and then should also be reported as named issue in |issue=), but sometimes publications carry an |issue= in addition to a named date (and often no "normal" date at all). In these latter cases, these named dates need to be actually handled as a date in |date=, also for proper metadata generation. If not, it will become more difficult to locate these sources and obtain a copy of these publications in libraries, as they are often not found when stored under a different search key. There are even a number of dedicated COinS keys reserved for seasons (rft.ssn), quarters (rft.quarter) and named dates (rft.chron), clearly indicating that such dates are actually used in the publishing industry and that they need to be supported in the library business.

As editors of this encyclopedia, we have a duty to reproduce reference parameters as we find them (per our core policies on verifiability WP:V, neutral point of view WP:NPOV, and no original search WP:NOR), so we cannot simply "translate" a "Christmas issue" into a "December 24 issue" or a "Second Quarter issue" into an "April–June issue" just because we don't like these special dates - it would invalidate the reference making it difficult to find the publications. Also, we may be making invalid assumptions, as in some locales Christmas is in January, and quarters may start in different months depending on context.

As developers and maintainers of our citation templates we should make sure that editors are able to create citations faithfully reflecting what they find in the sources (perhaps after some minor normalization) without having to trick the templates or fall back to non-templated citations.

Editors like David Eppstein, Imzadi, Andy Dingley or Carcharoth have repeatedly asked to add support for them, not because they particularly "like" them, but simply because they run into them occasionally in their editing work. Many other editors don't have the stamina to come here asking but either give up on citation templates or invent unsupported workarounds which will lead to more inconsistency, more difficult maintainability, and lower accuracy and reliability.

Commentors in this forum should seek for ways how to make life easier for readers and editors, not unnecessarily worry about (often enough incorrectly) anticipated implementation difficulties most of them cannot fathom anyway or trying to set priorities - they can leave that to the few volunteering programmers.

What we do need your input for is when you see areas not fully or adequately covered by our templates yet and what kind of difficulties you run into or questions you might have when entering non-mainstream citations. Sharing these experiences with us will help to improve the templates and hence the quality of this encyclopedia (and quite a number of other projects taking indirectly advantage of our citations as well). Lamenting over the assumed complexity of a potential implementation does not - in the current somewhat schizophrenic situation, where people are criticizing our citation templates for non-performance in certain areas and at the same time are actively hindering the developers to implement the necessary improvements, it will only slow down the process and thereby progress as a whole. Citations are diverse and therefore complex by their underlying nature, we can't change this, but what we can help do is making it easier and more reliable to enter them anyway.

The good news in this case is that, thanks to Trappist's great work, the infrastructure to support such special dates already exists in our templates since a couple of years (including the code for proper metadata generation), so adding more named dates does not actually add more complexity to the templates - it is, with minor exceptions, just adding more entries to an already existing table of named dates.

--Matthiaspaul (talk) 11:34, 19 August 2021 (UTC)

You make several assumptions and statements above that are not based on fact. First, there are several large and small issues with the module design and with the implementation of that design. Secondly, the documentation (at all levels: for readers, editors, and developers) is hardly adequate. These existing issues should imo be addressed first.

The policies of Wikipedia you mention apply mainly (and in some cases exclusively) to wikitext in article space. They also apply to things like having different citations that verify claims of all viewpoints present in the article, the citations mostly involving third-party sources with some past history of reliability. They do not apply to how citations themselves are structured. Instead, understandable citations are required to apply some of these policies. And that is it. Everything else: modules, templates, COins, formatting rules, etc. is irrelevant. Readers, who are Wikipedia's consumers, and the targeted recipients of its policies, do not need any of these add-ons to verify whatever nonsense one writes in article space. So, may I suggest that we make sure readers know why citations should exist. Make sure that they are presented in an understandable manner. Make sure that readers know what they consist of and why. And show them how they can verify the claims made in wikitext. Once you have a good idea about how to do all that, you can use it as the input for a citation system. You can even automate parts of that citation system, as one example, by using forms (templates). Any form standardizes a process, and thereby limits it, in order to be efficient, avoid the law of diminishing returns, for positive benefit/cost ratio etc. No form will ever account for all cases, but it can account for the basic, and most common cases. The basic cases are not a mystery. They are the minimal information needed to easily and quickly find the source that verifies the wikitext, because that is the point, and not how to embroider a citation.

When readers try to discover a source, they have several options: libraries, museums, bookstores etc., other repositories of sources, and of course electronic searches online. The institutions/trade entities may or may not keep their own catalogs, but they as well as the online search engines, closely follow the way marketing, trade, and bibliographic databases are indexed. Traditionally (and presently) these indices may use the author name, the source name, and a subset of the publication info: the publishing source, the publishing date, the published version, the publishing location, etc. And also one or more marketing, classification or content-location identifiers. Every time a reader asks a person or a piece of software to find them a source, someone or something will eventually or immediately consult one or more of those (relatively few) classification databases, whether they realize it or not. As pointed out in another post, in these classification databases date indices do not order text data, but date data. The calendars used are reduced to certain date formats that include numbers and a small number of keywords (days of week, month-names etc). Personally I have not ever encountered a periodical classification database that includes keywords such as "Christmas" in their date indices. I have seen such keywords in the very rare "Issue name" field, but mostly in special fields such as "Notes", "Other", "Misc."

So yes, even with their existing problems, CS1 templates can account for a "Christmas (year)" issue, by using one or more parameter as suggested in the previous post above. The source will be found. Resources can be used where needed in order to make a citation system that responds to readers first. Then we'll see about rare cases and if it is worth doing anything about them. 65.88.88.76 (talk) 21:09, 19 August 2021 (UTC)

It is certainly important both to the editor and the reader that the reference matches as far as is reasonable how the date is presented by the publication - we shouldn't expect people who are trawling through piles of magazines (or possibly having to buy back issues) to have to infer dates which differ between the actual paper copy and the citation. The key question is how often these non-standard dates are used - ones like seasons, quarters and to a lesser extent Christmas and Easter are used sufficiently frequently (I've seen most of these in real life, often without a corresponding 'normal' date) for them to be already implemented (after much discussion) - how frequently are the suggested extra examples (and other possible examples such as say Passover or Eid) actually used?Nigel Ish (talk) 21:47, 19 August 2021 (UTC)

Yeah, but back then our citation templates were really lacking support for them at a fundamental level. So this was a bigger issue. The infrastructure to support them first had to be implemented. Now, the effort isn't much more than adding a few more entries to a table.

The point here is that most editors running into these things in real life won't come here asking us to add support for them, and even if the occasional editor finds the way into our forum, it is very inefficient to add them one after another over a period of a decade or so. If someone can run into examples using "Christmas" or "Easter" it is quite obvious by extension, that there will also be publications using some of the other important Christian liturgical dates, maybe a little less common but this doesn't really matter as it doesn't add complexity, and, in fact, someone found examples for "Trinity", etc. a couple of years later. That's why I think we should do this a little bit more systematically, and add them in sets, rather than individually. We'd stop annoying those editors running into them but not reporting them here until someone finally comes around, and it will free our minds to work on other, probably more important things.

Regarding frequency of occurrence, fortunately they are rare. But they are also cheap to add. Until I was pointed to them in discussions I never saw those liturgical dates in publications, but I don't normally edit religious articles so the likelihood was low that I would run into them. Evidence has been given that they are actually used. Regarding the other entries, I personally ran into Midsummer, Carnival (as Karneval), and the various semester variants. Doing some dedicated research I also saw midwinter, midautumn and midspring, but I wouldn't have run into them if I wouldn't have searched for them. The quadrimester entries are derived from EDTF, a standard set up by the Library of Congress and many bibliographical institutions from all over the world (meanwhile also adopted by ISO). Obviously they saw a need to support them, and they are experts in the fields. Personally, I never saw them as "quadrimeters", only as "trimesters" (but apparently that's the same).

--Matthiaspaul (talk) 00:10, 20 August 2021 (UTC)

@Nigel Ish. These days, it is probable that the number of readers going through stacks of periodicals or buying back issues in order to verify a wikitext claim is smaller than the number of times an issue dated or labeled "Christmas (year)" appears in Wikipedia citations. It is much more likely they will ask someone or some thing for help. It was explained above what is likely to happen then. As was also pointed out before, there are ways to present rare dating info right now, even with rigid elements like templates. Sure, these ways may be stretching the use of the templates, but that is because the rare dating stretches the notion of "date". The entire point is that when there are other, more substantial issues regarding CS1, this and other minor (because rare) items can wait further judgement in time. In the meantime, one of the available fixes can be used. 64.18.10.203 (talk) 04:41, 20 August 2021 (UTC)

I have a list of 2.4 million journal and magazines like:

journal-of-black-psychology_2014-08_40_4
journal-of-primary-prevention_1982_spring_2_3
journal-of-occupational-and-environmental-medicine_1959-07_1_7

Note the "spring". The four seasons are most common. There are many "supplement, "index", "special issue". Also "first quarter". Many date ranges such as "jan-apr" (or "january-april"). And "winter-spring". Combos like "fourth quarter supplement" and "january-october cumulative". About 80 "christmas". About 20 "midsummer". Nothing with "semester" or "quadrimester". -- GreenC 05:17, 20 August 2021 (UTC)

"With Smith, John" in work lists

Many pages for academics have a "Works" or "Books" section that lists out their authored books, etc. (example). For these, I often like to use the CS1 citation templates, just without the surrounding ref tags and without the author parameters, as the author can be presumed to be the subject of the page. However, this gets tricky when there are multiple authors, as listing out only the other authors would be confusing and give the impression that the subject wasn't actually involved. For these instances, I could just write out With {{citation|last=Smith|first=John|title=..., but I feel like that wouldn't be good for the metadata. Is there a way to do this better within the citation template itself? If not, could we create it? {{u|Sdkb}} ^talk 05:17, 27 August 2021 (UTC)

You're looking for the parameter |author-mask= and its cousins |author-maskn=, I believe. — JohnFromPinckney (talk / edits) 06:16, 27 August 2021 (UTC)

Thanks! I just tried it here; hopefully I did it right. {{u|Sdkb}} ^talk 06:34, 27 August 2021 (UTC)

You're welcome. You got close, but you've surely already seen that Headbomb and Redrose have tweaked the cites for you. HE, — JohnFromPinckney (talk / edits) 08:52, 27 August 2021 (UTC)

The proper solution has been found already but I'd like to add an additional remark against just leaving out (some or all of) the names (or in other cases omitting the title), as this would create incorrect metadata for the citation. Since our citations are machine-readable and are harvested by external parties, this would cause such incomplete citations to be distributed elsewhere (which can cause confusion and various synchronization or merging problems further down the chain, which eventually not only affects those third-parties but also ourselves when our editors use such external data in other articles).

So, the proper solution is, as correctly stated above, to provide all the data to make a citation self-complete, and then use special parameters (|author/editor/translator/...-maskn= for the names) to suppress certain values from the local output of the citation. (A similar case exists for titles, and we already have some means to mute titles but we are still lacking a proper method to specify a title for metadata but mask it in the local output - I hope we can address this when we add support for descriptive titles, which should show up locally without text decoration, but should not normally be made part of the metadata, or at least not without being specially marked).

--Matthiaspaul (talk) 18:35, 27 August 2021 (UTC)

Thanks; that's helpful to know! {{u|Sdkb}} ^talk 20:45, 27 August 2021 (UTC)

Same book source, different pages?

Good day,

Currently working on a major edit of MCW Metrobus, some of which involves adding book sources to previously unsourced content. But when using Template:Cite book, what general guidance is there for providing multiple sources from the same book? As in, one source uses the book on one set of pages, while another source uses the book on a different set of pages? Is there, perhaps, a way these sources can be 'combined' so there is no repetition, or is repetition the only way?

Cheers, Hullian111 (talk) 17:58, 27 August 2021 (UTC)

Hi Hullian, there are several ways how to accomplish this.

The easiest and most common method is to just combine the multiple pages into a list of cited pages in the |pages= parameter, and optionally merge the corresponding quotes from the source into the |quote= parameter (which has a separate |quote-pages= parameter, if the quotes are from a subset of those pages given in the |pages= parameter only). Once you have defined this citation through something like <ref name="YourRefName">{{cite book |YourCitationParameters=...}}</ref>, you can then invoke this citation by <ref name="YourRefName"/> whereever it is needed to support an article statement.

If you need to specify individual pages (or quotes) at the various places where you invoke your citation, you can append {{rp}} like this: <ref name="YourRefName"/>{{rp|YourPageNo}}. Some people like to combine this into a wrapper template {{r|YourRefName|p=YourPageNo}} - this gives exactly the same output but is shorter and easier to read.

All these methods are basically just variants of one main scheme how to produce citations. The advantage of all of them is that they require only one "References" section and that you can define the core citation either in the article body (so called "inline references") or, if you want to avoid the clutter a long citation definition might create in the middle of the wikitext for the article prose, it can be defined down in the "References" section (this is called "list defined references").

All the linking down to the citations and the backlinks from there up to the invocation is carried out automatically by Mediawiki without any necessary manual intervention.

There are a number of other citation methods as well, among them so called short references ({{sfn}}). Similar to {{rp}} they allow to specify short references with page numbers, but the linking works considerable different (the links are created by the templates, not by the underlying Mediawiki software which, depending on author names, dates and titles used in the core citation, can sometimes cause ambiguous or dangling pointers requiring manual fixup). Also, they require two special sections in the article, one for the short references (often named "References" or "Notes"), and another for the core citations (often named "Bibliography"). While it keeps the links in the prose extremely short even for citations with page number, this comes at the expense of an extra layer of indirection (the "References" section), which can add significant clutter to an article. Also, there are no backlinks from the core citations in the "Bibliography" section to the short references, which makes it more difficult to find and visit all invocations of a citation resolving to a single publication.

I think I would start with the first method because it is by far the most commonly used method, it covers the majority of scenarios well, and is the easiest to master. If you then need to specify individual pages this can be easily added using {{rp}} in a second step.

--Matthiaspaul (talk) 19:29, 27 August 2021 (UTC)

I think it is inaccurate to say that short references require two separate reference sections. A solution to this problem, using only a single references section, is: use a footnote containing the full reference for the first occurrence of the book among the references, and then use short citations created by {{sfn}} oder {{sfnp}} for subsequent citations to different pages in the same book. Also, I would advise against using {{rp}}; it is an abomination that mixes up footnote markers with citation metadata and requires readers to remember one piece of a citation while they look up the other. I would prefer for all instances of it to be replaced by less-bad referencing styles. —David Eppstein (talk) 19:41, 27 August 2021 (UTC)

@Matthiaspaul:That’s a lot of wordage - I think I kind of understand what Matthias is going for in the first para. By the first method, I assume you mean typing out individual pages broken up by a comma? I’ve discovered you can type practically whatever you want in the page number section, so is that valid for a citation? Or do I have to break it down into individual cites?

@David Eppstein: Yeah, I have to agree on that. Breaking down cites like that seems overly complicated, and page numbers don’t exactly help when I’m linking to Google Books pages for the URL sections. The print copy I have of Wharmby’s Metrobus book probably won’t line up with the eBook version, so that’s bound to confuse readers. Especially since Google Books doesn’t provide page numbers.

Sorry if I’ve misunderstood anything, its late in the evening, and I’ll try and closely read what Matthias has proposed tomorrow. Hullian111 (talk) 22:12, 27 August 2021 (UTC)

Please do not put things in the |page= oder |pages= parameter that are not page numbers. You can instead use |contribution=, |chapter=, or |at= (but |at= and |pages= cannot both be used in the same citation). For {{sfn}} there is also |loc=. —David Eppstein (talk) 22:17, 27 August 2021 (UTC)

That's something I happily agree with David. |pages= supports comma-separated lists of pages, page ranges and linked pages in any combination, but please don't put other information into the parameter. |page= is for singular pages, and |at= is for other location information (sheets, columns, paragraphs, etc.) for which the prefix p. or pp. would be misleading. These prefixes also do not belong into the parameter, they are generated by the template itself.

--Matthiaspaul (talk) 22:28, 27 August 2021 (UTC)

(edit-conflict) That's interesting, David, because I come to just the opposite conclusions. ;-) In your suggested use of {{sfn}} with the core citation defined at the first occurence, the citation ends up in the same section as the short references, and, as it also serves as the core citation for the following short references, it either cannot contain page information for the first invocation (putting the first invocation at disadvantage), or it would have to carry a combined list of pages for all invocations (and thereby would create misleading metadata for the first invocation), or it would carry the page information for the first invocation only (and then show wrong page information for all the other invocations linking to it). Certainly a way to avoid the symmetrical two-section setup, but hardy ideal. Also, in order to keep the space occupied by the often very long lists of short references smaller, this section is often formatted as multi-column list with a small column width, but this does not work well when long citations are part of this section as well - to the effect that the list of references cannot be broken into multiple narrow columns and thus occupies a lot of display space creating huge areas of white space.

I also don't understand your comment on {{rp}}. All it does is append some terse superscript page information to the superscripted links. It does not deal with metadata at all and therefore cannot cause it to be mixed up.

Regarding your comment that it "requires readers to remember one piece of a citation while they look up the other", this is exactly the situation I find myself in when having to sift through articles containing short references created with {{sfn}} (because of the missing backlinks from the core citations to the short references or the invocations). One of the advantages of {{rp}} or {{r}} is just that they do not have this problem and automatically provide the backlinks necessary to jump between all pages cited from a single publication. To me, this is a serious shortcoming of the former.

To the OP it is important to know that the different systems obviously have different pros and cons (otherwise we wouldn't need them all ;-), and that WP:CITEVAR applies.

--Matthiaspaul (talk) 22:19, 27 August 2021 (UTC)

@Matthiaspaul: @David Eppstein: Morning all - now I’m able to look at this with a fresh head, with the recent arguments for and against in mind, I’m slowly coming round to think that {{rp}} might be my best bet for my intents and purposes. I will admit, I am still a bit of a novice at this whole Wikipedia thing despite massively picking up on editing this year, so thanks for additional clarification what shouldn’t go in the Template:Cite book page numbers area. Think I may have phrased it wrong by typing ‘anything’...

As I understand it, using {{rp}}, would this and be suitable solutions for my page number problem? Or would the other ones be an optimal way to go? Hullian111 (talk) 08:38, 28 August 2021 (UTC)

Yes, except that I would use it like this: See the added |pages=131, 185 parameter, merging the pages info from all short references like {{rp}}. This gives complete metadata, including page info, in the full citation. It may look a bit odd in the source code of this thread, because the definition of the full citation is located where we are actually only citing page 131, but it creates the correct output anyway, and the definition could be added into the References section further down. I'm creating one here to illustrate this with a third citation:

References

--Matthiaspaul (talk) 09:03, 28 August 2021 (UTC)

(edit-conflict) The alternative using {{sfn}} would look like this:

References

Bibliography

• Williams, Paul (15 January 2019). Manchester Buses (corrected ed.). Amberley Publishing Limited. pp. 131, 185, 190.
• Williams, Paul (1 August 2021). The New Manchester Buses (fully revised 3rd ed.). Amberley Publishing Limited. p. 102.

See, the actual links are a bit shorter because they don't show the page info embedded, but at the expense of an extra section, so you have to click twice to see the actual citation info. And once you reached the core citation, there are no links back to the individual short refs. Also, the linking itself relies on anchor names created by the citation templates (derived from the author surnames and year, and this can easily led to ambiguous anchor names and invalid HTML (when there are two publications by the same author in a year or two authors of the same name) or dangling pointers (if someone does not recognize that the citation in the bibliography section is referenced from the short references further up and changes or deletes it). There are sometimes also discrepancies between the anchor name created by the citation template and the assumed anchor name used in the short references (not in this example, of course). These errors can be fixed, but they are difficult to detect and therefore it often takes months or years until someone finally finds and fixes them (there are some tools to assist in this process). All in all this style requires careful testing and maintenance. This cannot happen with the style I am recommending further up because it does not rely on these self-created link names but only on those created and used by the underlying Mediawiki software (which reliably displays error messages when there are errors).

--Matthiaspaul (talk) 10:30, 28 August 2021 (UTC)

@Matthiaspaul: Thanks, think that's it! Testing it in Sandbox, I think that method you've suggested works well and should satisfy the issue for the four and potentially more page cites I need to insert into the article. Might take me a while to fully break it down, but I think that's my query solved. I'm going to be working on this MCW Metrobus page for a while over on Docs and Sandbox before I publish it, so if you happen to stop by, let me know if I'm doing it right. Still learning as I go along, after all.

Cheers, Hullian111 (talk) 11:40, 28 August 2021 (UTC)

@Hullian111: Have a look at Swindon railway station#History, references 1 through 7 inclusive. Is this what you are wanting? --Redrose64 🌹 (talk) 09:46, 28 August 2021 (UTC)

This is in fact an example of the unsymmetrical {{sfn}} style David was recommending. However, in addition to the general issues with {{sfn}} described by me above, it creates misleading (and incomplete) metadata (only valid for the first citation) and "nicely" illustrates the excessive white space caused because short and long references are mixed in the same section so that columns must be wide enough for the long references. I think, in this example, it's still tolerable, but there are examples with much longer lists of short references, where it really impacts the visual appearance of an article. On the other hand, when the in-article-location information becomes much longer than a short page or page range, the {{rp}} style can become distracting as well. So, what's best in a particular article depends on the circumstances.

--Matthiaspaul (talk) 10:46, 28 August 2021 (UTC)

To the OP: take a look at WP:LDR and also templates {{harv}} and {{sfn}}. The short citations can be displayed with {{reflist}} and the full citations with something like the {{refbegin}}/{{refend}} combination. 68.173.76.118 (talk) 23:12, 28 August 2021 (UTC)

Zotero not reading COinS

I have noticed several times recently that Zotero (in Firefox) is not detecting the COinS metadata emitted by our citation templates; for example on List of London medical students who assisted at Belsen.

I see the same problem when I am not logged in, so I don't think it has anything to do with my gadgets or user scripts.

Are there any known issues with our COinS?

One possible cause (related to JavaScript, so possibly not relevant), is described on "Connector intermittently does not recognize COinS", on the Zotero forums. It also suggests a fix, but not one we can apply in templates.

Can anyone suggest another cause, or fix? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 13:49, 28 August 2021 (UTC)

How recently is recently? The last cs1|2 module-suite update was 10 April 2021. Are you the only editor who is experiencing this problem with our citations? Do you have a problem getting the metadata from {{cite patent}} citations? That template does not use the cs1|2 module suite to emit metadata.

—Trappist the monk (talk) 14:10, 28 August 2021 (UTC)

In the last couple of weeks, though it is not something I do every week. I have not examined other editors' systems. Zotero found COinS on Template:Cite patent/testcases on first attempt. On re-examining "List of London medical students...", the issue seems intermittent, and not predictably reproducable. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 15:20, 28 August 2021 (UTC)

Haven't seen this yet.

When you run into this again, can you check the source code of the loaded web page if it actually contains the COinS data (and perhaps post an example here)?

Just a wild guess, but perhaps there is some instance removing the COinS span for being an empty span? In the current implementation they can be found immediately following the closing </cite>:

<cite>...</cite><span title="ctx_ver=Z39.88-2004..." class="Z3988"></span>

Also worth trying is to check if this also happens with JavaScript disabled.

--Matthiaspaul (talk) 17:32, 28 August 2021 (UTC)

s2cid limit reached

Just a heads up that there are starting to be articles populating in Category:CS1 errors: S2CID that seem to be correct with values greater than 237000000. --Lightlowemon (talk) 13:55, 31 August 2021 (UTC)

Proposition: "narrator" alias

For audiobooks, mainly. Whenever the various situations are sorted out and proper development restarts. This alias may be useful. 66.108.237.246 (talk) 13:39, 1 September 2021 (UTC)

Audiobook probably use {{cite media}} with |others=Narrated by Simon Vance. The free-form |others= allows for multiple narrators; or, "Full-cast" such as BBC radio adaptations of a book that are too many to list, or some staring roles. --GreenC 14:58, 1 September 2021 (UTC)

There are also other situations for a narrator role apart from audiobooks, such as TV programs, films, and also things like scripts (of plays etc). I don't know if it as common as the translator role that has its own alias, but I wouldn't be surprized. 65.88.88.46 (talk) 15:15, 1 September 2021 (UTC)

There are many roles (not a complete list): Author, Composer, Contributor, Cover artist, Cover designer, Designer, Director, Editor, Forward, Illustrator, Introduction, Narrator, Photographer, Preface, Translator. -- GreenC 15:25, 1 September 2021 (UTC)

|others= works fine for these roles. Almost none of them help with WP:V, which is the main purpose of these templates. – Jonesey95 (talk) 16:09, 1 September 2021 (UTC)

There is a rare case when the narrator info can contribute to verification. In many works (and unfortunately so, imo) the narration is acted rather than read straight. It is conceivable that the narrator's inflection may change the meaning for some listeners. Wikitext may claim a "fact" that depends on such meaning. There should be some indication that the wikitext claim is due to the narrator (as de facto editor) and not necessarily due to the author. But this may be better suited to a more complete citation system. 65.88.88.46 (talk) 17:09, 1 September 2021 (UTC)

Adding an observation made in this discussion about the illustrator role. Audiobook titles can be found by using the "narrator" info, even when the author is not used. The major trade databases (wholesale & retail) index the "narrator" field, and the narrator is prominently displayed in browse lists along with the author. 65.88.88.76 (talk) 21:00, 2 September 2021 (UTC)

{{hyphen}} converted to dash

Help:Citation Style 1#pagehyphen says For a hyphenated page, use |page=12{{hyphen}}34. This will not only properly display a hyphen... However, I don't believe this is true, as "{{cite book|title=Title|pages=1{{hyphen}}2}}" renders as "Title. pp. 1–2." with a dash. --Ahecht (TALK
PAGE) 02:27, 2 September 2021 (UTC)

|page= and |pages= are not the same thing. Compare your example:

{{cite book|title=Title|pages=1{{hyphen}}2}}

Title. pp. 1–2.

and the same citation according to the documentation:

{{cite book|title=Title|page=1{{hyphen}}2}}

Title. p. 1-2.

—Trappist the monk (talk) 02:40, 2 September 2021 (UTC)

@Trappist the monk Got it. I added to the "pages" section to clarify. While I have your attention, the "Accept-this-as-written markup" section says Markup can be applied to the entry as a whole or to individual list entries, but that doesn't seem to work for numbers with commas:

{{cite book|title=Title|pages=1, ((1,234))}}

Title. pp. 1, 1,234.

I understand that the logic for handling this case would be more complex than what the module currently does, and would require pre-processing the string before splitting it. If this behavior is intended, should the documentation clarify? --Ahecht (TALK
PAGE) 15:56, 2 September 2021 (UTC)

I saw your tweak to the documentation but the module is smart enough to handle the hyphenated case you demonstrated:

{{cite book |title=Title |pages=1-2–3-4}} – a range of hyphenated page numbers without the need for {{hyphen}} and {{endash}}

Title. pp. 1-2–3-4. – works properly

But if you prefer to use the templates:

{{cite book |title=Title |pages=1{{hyphen}}2{{endash}}3{{hyphen}}4}}

Title. pp. 1-2–3-4. – still works properly

We should reserve recommendation of the accept-this-as-written markup for those cases where it is truly needed so I am going to revert you.

—Trappist the monk (talk) 16:08, 2 September 2021 (UTC)

@Trappist the monk: I suppose a better example would be {{cite book|title=Title|pages=((1{{hyphen}}2)), ((3{{hyphen}}4))}} where those are intended to by hyphenated page numbers. Any objection to me adding that to the help page? --Ahecht (TALK
PAGE) 19:29, 2 September 2021 (UTC)

No objection. You might want to note the difference between your example and this:

{{cite book|title=Title|pages=((1{{hyphen}}2, 3{{hyphen}}4))}}

Title. pp. 1-2, 3-4.

because of what happens when a space character is omitted:

{{cite book|title=Title|pages=((1{{hyphen}}2,3{{hyphen}}4))}}

Title. pp. 1-2,3-4.

—Trappist the monk (talk) 19:41, 2 September 2021 (UTC)

illustrator

Propose adding illustrator to {{cite book}} and others:

|illustrator-last1= |illustrator-first1= |illustrator-link1=

.... 0mtwb9gd5wx (talk) 19:02, 2 September 2021 (UTC)

There is also similar topic above. Personally, I cannot conceive of any situation where the express addition of a book illustrator would help verify a book's content. It is highly unlikely that illustrators of books are indexed in reference databases, and therefore very hard to find the source (or help find the source) by that particular information. In contrast, relating to the "narrator" discussion linked previously, I have seen several trade databases that index the "narrator" field, as this is considered an important role in audiobooks. 65.88.88.76 (talk) 20:41, 2 September 2021 (UTC)

Just adding that my above opinion is limited to {{cite book}}. 65.88.88.76 (talk) 20:44, 2 September 2021 (UTC)

I wondered about this too. I would think that there are many cases where the illustrator is notable and it would be nice to have a wikilink to them. Laterthanyouthink (talk) 05:51, 5 September 2021 (UTC)

The situation is uncommon enough that |others= may be used, as in |others=illus. [[Quentin Blake]]. --Redrose64 🌹 (talk) 08:16, 5 September 2021 (UTC)

Suggestion for a change to a template

Please forgive me if this idea has has already been "considered" and rejected ... or something like that.

My suggestion was already entered in a place ("Wikipedia:Teahouse") that was perhaps ill-advised (and any link to the "new" section is liable to itself become a "", once that new section gets "archived"). (right?)

However, a "DIFF" URL which serves as a link to an "edit" ... remains valid for a longer time ... as long as the old ["non-latest"] versions of the page (in this case, a 'Teahouse' page) that got edited, are still extant. Here is an example of such a "DIFF" URL:

https://en.wikipedia.org/w/index.php?title=Wikipedia:Teahouse&diff=prev&oldid=1042098412

... and, even if ^H^H when that ['Teahouse' page] section does get "archived", there is probably some text inside the entries of that section, which is unique enough to be searched for, such that ... one could find the 'lost' ("archived") section, even after it has been "moved" to a different URL.

...In fact, I could even update the URL shown below! ... if I don't forget. In the mean time (at least until that that new section gets "archived"), my "suggestion" can be seen here:

Wikipedia:Teahouse#Suggestion for a change to a template

So ... there is no necessity for the suggestion to be "repeated" here. (right?)

--Mike Schwartz (talk) 06:39, 3 September 2021 (UTC)

The |url-access= parameter takes four possible values: "[free]", "subscription", "registration", "limited". The parameter |url-status= takes: "dead", "live", "unfit", "usurped" (and soon also "deviated"). As far as I was able to understand you, you were trying to add |url-access=paywall to a citation at Political family pointing to [2], but that was rejected by the citation template with an error message, so you switched to |url-status=unfit instead, adding a HTML comment:

"not really [exactly] unfit; but access to the web page at the "url" [...] is subject to some possible inconvenience or other issue, due to a paywall ['if applicable']; ... while it is free for anyone [...] to access the web page at the "archive-url"".)

If this is really what you meant to do, then |url-status= is the wrong parameter to be used (or even |url-status=live would be valid) and you should have instead added either |url-access=registration oder |url-access=subscription depending on the type of "paywall" you see.

I'm not sure what you meant by "if applicable". If I have a look at the URL (and comparing with |archive-url= [3]), I can see what appears to be the whole article (free and without any kind of registration), so |url-access= would be inappropriate. Or is there a longer version of the article available after subscription? If so, then a combination of |url-access=subscription and |url-status=limited would be the way to go.

Are you seeing some other kind of access restriction? Do you think we are missing a state not already covered properly by the existing set of predefined values?

--Matthiaspaul (talk) 07:59, 3 September 2021 (UTC)

Here's a link to the documentation. Also, when you have a question, it helps to give a concise statement of it, in plain English. – Jonesey95 (talk) 13:40, 3 September 2021 (UTC)

THANK YOU to all who responded.

I was able to find this section -- (which is probably a permanent home for [all or ... "at least" some] discussion about this [a certain] "suggestion") -- by clicking on a direct link to it, that was provided by someone.

(However, in order to find that direct link, after my original "suggestion" section

[which had initially been placed at 'Wikipedia:Teahouse#Suggestion for a change to a template', ... sorta clumsily perhaps]

had already been archived, I had to do a SEARCH, and ... being able to access the full text of the "diff" at https://en.wikipedia.org/w/index.php?title=Wikipedia:Teahouse&diff=prev&oldid=1042098412 was helpful to me, in terms of enabling me to "guess" some search terms that might lead me to THIS archived version: Wikipedia:Teahouse/Questions/Archive_1122#Suggestion for a change to a template ... which is where I was able to find a certain direct link [THANKS!] to this section of this ["Talk:"] page.)

I would like to (and I intend to ... if I don't forget) respond to some of the remaining questions, -- such as

• "Are you seeing some other kind of access restriction?"

and

• "Do you think we are missing a state not already covered properly by the existing set of predefined values?" --

and also to (probably) try to explain (if necessary) what I meant by using the phrase << "making the URL in the "archive-url" field primary" >>.

However I don't have enough time right now, so ... maybe later.

Thanks, --Mike Schwartz (talk) 17:32, 15 September 2021 (UTC)

Accept-this-as-written markup doesn't work on individual items with commas

The Accept-this-as-written markup section says Markup can be applied to the entry as a whole or to individual list entries, but that doesn't seem to work for numbers with commas, e.g. {{cite book|title=Title|pages=999, ((1,001))}} returns Title. pp. 999, 1,001.. This could be solved by adding the following to the top of hyphen_to_dash():

str = str:gsub("(%(%(.-%)%))", function(m) return m:gsub(",", "，"):gsub(";", "；") end)

After that line replaces commas and semicolons with their full-width equivalents, do the split, and then return

str:gsub("，", ","):gsub("；", ";")

at the end of the function. I've mocked it up in the sandbox here. --Ahecht (TALK
PAGE) 17:30, 3 September 2021 (UTC)

{{cite book|title=Title|pages=((999, 1,001))}} returns Title. pp. 999, 1,001. Headbomb {t · c · p · b} 17:47, 3 September 2021 (UTC)

@Headbomb Yes, but the documentation says that it can be applied to individual list entries as well, and doesn't need to be applied to the entire entry. The sandbox version with my changes, e.g. {{cite book/sandbox|title=Title|pages=999, ((1,001))}}, does return Title. pp. 999, 1,001. --Ahecht (TALK
PAGE) 20:36, 3 September 2021 (UTC)

I'm sure your contribution is appreciated, but isn't it easier to correct the documentation so that is in sync with the current production code? Also, the editor documentation follows module coding in that it focusses on field-level operations, including field-list separators. I think that this is a good design/coding decision presently. The formatting of individual field-list entries (such as the issue of notation in this discussion) can be handled by the special markup as pointed out. The complexity of the imo already tottering editor documentation will be increased in applying your otherwise good solution. Not a good thing, I think. 65.88.88.126 (talk) 21:43, 3 September 2021 (UTC)

It is important that the syntax works globally as well as for individual entries in the list, but there are several subtleties, so we need to be careful. As an example, the code in the sandbox reintroduces a bug trashing the data when only the outer list elements have the syntax, but not those in between, see:

• Help_talk:Citation_Style_1/Archive_73#Fixed_evaluation_of_accept-this-as-is_syntax_in_parameters_supporting_item_lists

See also:

• Help talk:Citation Style 1/Archive 78#Incorrect spacing
• Help talk:Citation Style 1/Archive 78#Replacing "--" by "–"...

--Matthiaspaul (talk) 00:19, 4 September 2021 (UTC)

@Matthiaspaul Good point, that's a test case I hadn't evaluated. The sandbox version is fixed now, and all the examples in that Archive 73 section evaluate identically for the normal and sandbox version. --Ahecht (TALK
PAGE) 05:06, 4 September 2021 (UTC)

At some point, this constant "fixing" of minutiae and special cases will have to either give way to rational redesign and the more pressing issues or it will collapse under its own complexity. This particular issue is unnecessary, and avoidable. There are already 2 ways to handle this: apply the markup to the entire field, or avoid the thousands notation. I would love to see how the documentation will explain the proposed changes so that it makes sense. In-source fields already have complicated documentation, now the entire scope of the module changes to handle a case that appears in probably <0.001 of all citations. The current scope is adequate: the editor is given instruction on the field (argument) level, which includes list separators. The formatting of individual list entries is a whole other level. It would be far simpler to document this at the module level and tell editors that these templates do not use thousands notation, and that doing so may result in display problems. 104.247.55.106 (talk) 14:13, 4 September 2021 (UTC)

@104.247.55.106: No change to the documentation is needed whatsoever if my change is implemented. This simplifies the documentation, because you can simply keep the current documentation that states that the "Accept-this-as-is" syntax works on individual list items or the entire string. The alternative is to change the documentation to state that you can sometimes use the accept-this-as-is notation on individual list items, but not always. --Ahecht (TALK
PAGE) 18:12, 4 September 2021 (UTC)

Is the novelty of editors having to apply markup to parts of parameter values (as yet one more option that applies to a miniscule number cases) a simplification? It doesn't seem so. But not to belabor the issue. This is just my opinion. 24.103.101.218 (talk) 23:27, 4 September 2021 (UTC)

This change introduces substantial complexity to the code, which is already not lacking in obscurity. A further concern is the additional runtime. Though small, it will be additional for everyone, just to support an exceptional case. And why do we want to support commas (or semicolons) in page numbers anyway? I would rather simplify both code and documentation by saying it only works on the entire string. Kanguole 09:14, 5 September 2021 (UTC)

Add languages

Hi,

How can I add ajp (South Levantine) and apc (North Levantine) to the list of supported ISO 639-2 three-character codes?

Other Arabic varieties are already supported: aeb (Tunisian), arq (Algerian), ars (Najdi), ary (Moroccan), arz (Egyptian), shu (Chadian); so I think Levantine varieties (South and North) should be as well as they are among the most spoken and most widely understood in the Arab world. A455bcd9 (talk) 08:18, 7 September 2021 (UTC)

Hi @Ira Leviton:,

Just saw your edit on Levantine Arabic. You wrote that there was no solution. Is it really the case? How come other Arabic varieties are supported but not ajp and apc? Couldn't we follow the same process that led to their inclusion in the list of supported codes?

Thanks for any help you can provide :) A455bcd9 (talk) 08:45, 9 September 2021 (UTC)

That is precisely the reason. MediaWiki doesn't recognize ajp and apc:

{{#language:ajp|en}} → ajp

{{#language:apc|en}} → Levantine Arabic

but:

{{#language:aeb|en}} → Tunisian Arabic

You can write:

|language=South Levantine Arabic

|language=North Levantine Arabic

The language still won't be recognized but at least the rendered citation won't be quite so cryptic:

{{Cite book |title=Gospel of St. Mark in South Levantine Spoken Arabic |last1=Bishop |first1=E. F. F. |last2=George |first2=Surayya |date=1940 |location=Cairo |language=ajp |oclc=77662380}}

Bishop, E. F. F.; George, Surayya (1940). Gospel of St. Mark in South Levantine Spoken Arabic (in ajp). Cairo. OCLC 77662380.{{cite book}}: CS1 maint: location missing publisher (link) CS1 maint: unrecognized language (link)

{{Cite book |title=Gospel of St. Mark in South Levantine Spoken Arabic |last1=Bishop |first1=E. F. F. |last2=George |first2=Surayya |date=1940 |location=Cairo |language=South Levantine Arabic |oclc=77662380}}

Bishop, E. F. F.; George, Surayya (1940). Gospel of St. Mark in South Levantine Spoken Arabic (in South Levantine Arabic). Cairo. OCLC 77662380.{{cite book}}: CS1 maint: location missing publisher (link) CS1 maint: unrecognized language (link)

You can suggest that MediaWiki support ajp and apc by filing a ticket at Phabricator.

—Trappist the monk (talk) 11:48, 9 September 2021 (UTC)

Thanks.

Actually I did open a ticket in July 2021: here and I thought the issue was solved (in particular by this commit).

So apparently this is yet another issue. A ticket was opened in 2018 (and updated in June 2021) regarding Wikidata entries here. It's maybe related? So I opened a new ticket there. A455bcd9 (talk) 12:17, 9 September 2021 (UTC)

@A455bcd9:

The full list of languages and codes recognized by Mediawiki is at Template:Citation_Style_documentation/language/doc. Many of the entries at are stuck there indefinitely because of language codes that are not recognized by Mediawiki. All have hidden notes in their coding stating so; I have added some of those notes.

I will also try to add a ticket as you did, to have all of those unrecognized language tags added.

Ira Leviton (talk) 21:59, 9 September 2021 (UTC)

Thanks!

It would be really helpful because this issue is broader than just the citation templates: it apparently also affects Wikidata where entries in these languages cannot be added. A455bcd9 (talk) 07:41, 10 September 2021 (UTC)

Wikidata additions require extra effort and should have their own task(s). Izno (talk) 13:20, 10 September 2021 (UTC)

language name/tag overrides, removal of

Another conversation reminded me that there have been changes to MediaWiki's language-name support.

It used to be that MediaWiki assigned 'Crimean Turkish' to language tag crh but now:

{{#language:crh|en}} → Crimean Tatar

cs1|2 got round that by overriding the tag crh to 'Crimean Tatar'; that override is no longer necessary.

I have tweaked the language handling code some to better handle IETF-like language tags that are supported by MediaWiki. Doing that allows the removal of nrf-GG (Guernésiais) and nrf-JE (Jèrriais) from the override table.

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

Title (in Crimean Tatar).

{{cite book/new |title=Title |language=Crimean Tatar}}

Title (in Crimean Tatar).

{{cite book/new |title=Title |language=nrf-gg}}

Title (in Guernésiais).

{{cite book/new |title=Title |language=Guernésiais}}

Title (in Guernésiais).

{{cite book/new |title=Title |language=nrf-je}}

Title (in Jèrriais).

{{cite book/new |title=Title |language=Jèrriais}}

Title (in Jèrriais).

Overrides not broken: {{cite book/new |title=Title |language=ksh-x-colog}}

Title (in Colognian).

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

Title (in Colognian).

and non-overrides not broken: {{cite book/new |title=Title |language=es}}

Title (in Spanish).

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

Title (in Spanish).

and unrecognized language tags and names not broken: {{cite book/new |title=Title |language=xax}}

Title (in xax).{{cite book}}: CS1 maint: unrecognized language (link)

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

Title (in abcdefgh).{{cite book}}: CS1 maint: unrecognized language (link)

—Trappist the monk (talk) 15:18, 9 September 2021 (UTC)

[Template:Cite book] no way to indicate what the original language and title?

Does Template:Cite book not have some parameters to add the original language and title of a work? Veverve (talk) 17:59, 11 September 2021 (UTC)

Veverve, You're supposed to use the actual title in the actual language in the cite - do not translate it to English. Roger (Dodger67) (talk) 18:24, 11 September 2021 (UTC)

@Dodger67: The situation is: if I have a book which was translated into English (no by me, but by the book's translator), is there no place I can indicate the book's original language and title? Veverve (talk) 18:27, 11 September 2021 (UTC)

(ec) That applies if you are citing the original, non-translated work, in which case the original title goes in |title= and an Enlish translation can (if necessary) go in |trans-title= . If you are citing a translation of the work into English, which has an English language title, then the English-language title goes in the title field.Nigel Ish (talk) 18:31, 11 September 2021 (UTC)

Veverve That applies to published translations, if you cite the original non-English work you could provide a brief quote from the source as well as your translation of it, see Template:Cite book#Quote for the relevant parameters. Roger (Dodger67) (talk) 18:42, 11 September 2021 (UTC)

I am in the citing a translation of the work into English, which has an English language title case. So, in which parameter can I add the original language and the original, before translation title? Veverve (talk) 18:51, 11 September 2021 (UTC)

At a push it could go into |orig-date= field (i.e. smthing like |orig-date=First published 1934 as "Le Jardin de Les Flics" , although I don't know whether this is pushing the field too much. The citation is meant to give enough information to allow the reader to find it and verify its contents.Nigel Ish (talk) 19:02, 11 September 2021 (UTC)

(edit-conflict) Since it wasn't mentioned explicitly already, if the cited book is not in English, the language should be specified in the |language= parameter.

This does not apply if you are citing from a published English translation of a book originally written in another language, of course. If it is useful to indicate that the book is a translation you could specify the translator using |translator-last=/|translator-first=. If the original language is important to know as well, you could add a comment following the citation, that is, between the closing }} of the template and the closing </ref>. I typically format them like "(NB. This is a translation of the original work titled "xyz" in French.)". In some cases, it might be even useful to mention the original foreign-language edition in either another citation like <ref name="TranslatedWork">...</ref><ref name="OriginalWork">...</ref>, or bundled into the same <ref>...</ref> entry like <ref>Work translated into English; Work in original language.</ref>

--Matthiaspaul (talk) 19:08, 11 September 2021 (UTC)

Along with the translator parameters mentioned above, for translated-in-English books the free-form parameter |orig-year= could be used, e.g |orig-year=originally published [year] in [language] as [foreign title]. Optionally following the foreign title I often add the (foreign) location: publisher after a dot separator. I believe the foreign original may be easier to find with the addition of location and publisher, but I have no real proof-of-concept. 68.173.76.118 (talk) 01:37, 12 September 2021 (UTC)

Publication-place and publisher are certainly useful as well (also for the translated work), but if all this information is known already, this makes up a citation in its own right rather than meant only as a hint. I think, moving it into a separate {{cite book}} (as suggested above) is more appropriate then, even if the ISBN or exact page number may not be known in the original edition. This way, proper metadata would not only be generated for the translation but also for the original work, and thereby it may become very easy to locate a copy of the original work.

--Matthiaspaul (talk) 08:50, 12 September 2021 (UTC)

Adding one more unneeded citation will likely add clutter. I can see the usefulness to the verifying reader of the translator parameter (there may be different translators with same publisher). I can also see the usefulness of the original edition info such as |orig-year= which can help point to a work's 1st edition. This is a detail, and another long discussion, but the gist of it is, the 1st edition is in most cases considered the definitive edition (outside of editions that contain author-made revisions/corrections). There may be subtle differences between editions depending on the publisher/work editor. Comparing such differences is important in the hopefully very rare cases where a wikitext contributor may claim a fact based on the edition difference. Or goes edition-shopping to help establish a claim as fact. It is good to give the reader a hint in finding the original, but since the usefulness is very narrow, I cannot see adding a whole new citation for it. 65.88.88.57 (talk) 11:53, 12 September 2021 (UTC)

HTML markup

@Trappist the monk: Greetings! To answer your question raised in this revert, Sbb started a thread at User talk:Beland#Use of Templates, HTML, and HTML entities within citation templates. I think that happened because I was going around changing articles (including citations) to conform with MOS:FRAC and Wikipedia:Manual of Style/Superscripts and subscripts, and the current guidelines result in HTML markup instead of Unicode precomposed fractions, superscripts, and subscripts. I couldn't find an authoritative COinS specification that explains how to handle superscripts, fractions (including those not available as precomposed characters), italics, and other markup in fields. I thought Sbb was advocating without opposition that Unicode characters be used instead of markup, and I was starting to change the guidelines to reflect that when we got your attention. Sbb also pointed out there has been opposition at Wikipedia talk:Manual of Style/Superscripts and subscripts. So, it would be good to discuss so I can get some clarification on what the consensus is here so I can update my spellcheck code and guideline pages if necessary. There are several possibilities for what to do:

• Use Unicode characters whenever possible (but markup is difficult to avoid in 100% of cases)
• Use HTML when necessary to follow MOS guidelines, but avoid templates because they tend to spew unwanted HTML markup, and expect downstream consumers to parse <sup>...</sup> etc.
• As Headbomb suggested, follow Wikipedia guidelines for display purposes, but write some code so that citation templates give downstream COinS consumers output translated into no-markup Unicode, or whatever is needed in any particular case.

Thoughts? -- Beland (talk) 02:59, 12 September 2021 (UTC)

I'm not Trappist, but I strongly disagree with your suggestion to use Unicode substitutes in references, and its implication that these can be adequate substitutes for mathematics formatting in reference titles. They are not adequate substitutes. In particular, they are very limited in their application and frequently incompatible in appearance with the proper mathematics formatting that is required when their limits are reached. —David Eppstein (talk) 04:33, 12 September 2021 (UTC)

The COinS metadata is carried in the title="..." attribute of an empty HTML <span>...</span> element that also has the attribute class="Z3988". HTML attributes cannot contain markup of any kind, so if it can't be sanitised to remove the markup, it must be omitted in the first place. --Redrose64 🌹 (talk) 07:22, 12 September 2021 (UTC)

@Redrose64: Markup can appear there, but it does need to be encoded. The examples Sbb left on my talk page use percent-encoding, so for example <sup> would be encoded as %3Csub%3E. It looks like other fields (like the URL of the page) also use percent-encoding, so downstream consumers would be expected to percent-decode out of course? The result of that decoding could be HTML or no-markup Unicode or MathML or whatever. -- Beland (talk) 16:49, 12 September 2021 (UTC)

My conclusion would be, rather, that if COINS cannot represent accurate references, then we should drop COINS instead of using it as an excuse to force our references to be inaccurate. The tail is wagging the dog. We must be able to cite papers like, say, Pintér, Ákos; de Weger, Benjamin M. M. (1997). "${\textstyle 210=14\times 15=5\times 6\times 7={\binom {21}{2}}={\binom {10}{4}}}$". Publicationes Mathematicae Debrecen. 51 (1–2): 175–189. MR 1468225.. If our COINS conversion produces garbage like "rft.atitle=MATH+RENDER+ERROR" because COINS is incapable of representing such titles, prevents us from including the nowrap preventing the horrible line break between double quote and start of title, or worse, prevents us from even being allowed to specify such titles, then the problem is COINS. Find some other way of getting your metadata-scraping fix. —David Eppstein (talk) 07:24, 12 September 2021 (UTC)

This "MATH+RENDER+ERROR" thing is a placeholder inserted by us for math objects for which we cannot generate sensible metadata. As was correctly pointed out already COinS basically wants plaintext, but since all data gets encoded we are not limited to what the HTML title= attribute would allow for and could also pass down almost any kind of other stuff. The problem is that "other stuff" doesn't make sense at the receiver. I think, for as long as the title occasionally contains simple markup like <sup></sup> this is easy enough to be parsed correctly even by humans, but most math stuff is more complicated.

What do other COinS producers do in such cases?

Was/is there some standard notation how to transliterate math into ASCII for example in old newsgroup posts? If so, we could try to translate math blocks into this and make it part of the metadata.

In some cases stripping off all markup and leaving only plain text and digits might also create a string which could still be good enough for humans to recognize a title or to work as a search pattern, but it would hardly be ideal.

Yet another solution could be to provide a so called descriptive title |descriptive-title= in addition to the proper title |title= and if the proper title is too complicated to use for metadata, pass down the descriptive title instead. --Matthiaspaul (talk) 09:34, 12 September 2021 (UTC)

Regarding your remark on nowrap preventing the horrible line break between double quote and start of title, I haven't seen this yet. Can you provide an example? --Matthiaspaul (talk) 09:43, 12 September 2021 (UTC)

I now saw that you added an example using nowrap above, so this is no longer necessary. To illustrate your remark here is the example without the nowrap:

Pintér, Ákos; de Weger, Benjamin M. M. (1997). "${\textstyle 210=14\times 15=5\times 6\times 7={\binom {21}{2}}={\binom {10}{4}}}$". Publicationes Mathematicae Debrecen. 51 (1–2): 175–189. MR 1468225.

--Matthiaspaul (talk) 11:53, 12 September 2021 (UTC)

The main thing to keep in mind is that citations are information-discovery helpers, and the data they carry must be in the format easiest to be found, which is, exactly as the source information presents it, "funny" characters and all. By "source information" I mean the index entry for the work in the various classification databases, which is what a reader will be presented with when discovering the source. Whatever WP:MOS says is secondary. And, the suggestion of dropping COinS if it cannot appropriately represent this data is apt. 65.88.88.57 (talk) 12:12, 12 September 2021 (UTC)

COinS does not really "represent" anything by itself, it is a method to transfer data using OpenURL in a structured way. We would not have any problems to pass the math blob in David's example to the receiver, the problem is that the receiver will most likely not be able to make any sense of it, and rather then just dropping onto them what for them is just a blob of strange binary data, we insert a placeholder hoping that at least the remainder of the title is useful enough for the receiver to make sense of it.

I'm not aware of another metadata standard which would have a reliable solution to this problem. Are you?

Regarding the index entry you mentioned, how would a work such as in David's example be represented in your classification databases? The question is in regard to the visual appearance as well as how it is encoded there. Is this something that can be derived from the proper title, or is it a descriptive title?

--Matthiaspaul (talk) 12:53, 12 September 2021 (UTC)

As was remarked on above by David regarding COinS or any metadata, this is looking at the problem from the wrong end. Metadata representation of any kind (let's forget the underlying problems with OpenURL for the moment) is secondary. This is about presenting data (to the human reader). Reference databases, including specialized databases of mathematics works, build their indices by using data entered as they appear on the work itself, unless the reference/classification database has weird data-entry quirks. Citations should pass the index data "as is", because that is the easiest way to find the underlying source, with very, very few exceptions. It is that simple. If Unicode, COinS or whatever else cannot handle that, then out they should go. 98.0.246.242 (talk) 13:52, 12 September 2021 (UTC)

Matthiaspaul: The list at https://publi.math.unideb.hu/searchb.php shows this paper as "210 = 14 × 15 = 5 × 6 × 7 = {21 2} = {10 4}". That clickable link leads to https://publi.math.unideb.hu/load_jpg.php?p=391 which displays a JPEG. -- Michael Bednarek (talk) 14:00, 12 September 2021 (UTC)

Thanks, Michael, this was helpful. But we need more such examples, also more complicated ones to derive patterns from it. --Matthiaspaul (talk) 20:18, 12 September 2021 (UTC)

Other sites' failure to display reference titles properly should not be an excuse for us to fail at the same thing. The pdf link from that site to the actual paper shows how it should be formatted. —David Eppstein (talk) 21:48, 12 September 2021 (UTC)

It looks like I was misunderstood by the IP and by David. I never said this, quite the opposite - I am not searching for excuses but for solutions.

But turning off COinS, as was suggested, is not a good idea, as it still transmits useful info. In the worst case only the offending data should be muted - and basically that's what we do right now with our "MATH+RENDER+ERROR" placeholder (although we should try to do better).

A PDF, as suggested, won't help either, it's just a binary and not much different from passing over a photo of the printed book title or graphical image of our local rendering. For one, we cannot assume that a picture or a PDF can be viewed on the receiver's end, but it also can't be used for searches. What we need is some machine- and human-readable formula notation encoded as text so that a search pattern can be derived from it. That's why I was asking what other COinS producers are transmitting in such cases and how such work titles are stored in the (text) title entry of external databases.

--Matthiaspaul (talk) 16:37, 15 September 2021 (UTC)

Two things. 1) No unicode characters. Those are a blight, and should be purged on sight. 2) Readers and accurate rendering of information are the priority. If COinS can't handle something, screw COinS. If magic codefu can be done to convert something non-COinS compliant to something COinS compliant behinds the scene (e.g. ''H''<sub>x</sub>20<sup>6</sup> → H_{x}20^{6} or whatever the COinS standard is), great, but it should not require editors to sacrifice accurate rendering. Headbomb {t · c · p · b} 14:51, 12 September 2021 (UTC)

A few considerations and a question:

• I assume because of general application of MOS:CONFORM to citations (not just quotations), we generally already change punctuation and other special characters to fit Wikipedia style rather than leave it exactly as in the source material. Mostly this is about using straight quote marks. A more exotic case is when someone tweets in all blackboard bold - that gets rendered as all capital letters in the Wikipedia citation.
• When I'm cleaning up special characters in citations, I often find a corrupted title in the document we're citing, whether due to mojibake or some other mishandling. I always correct that so that a human reading Wikipedia with their eyes can see the true title, but if they are searching certain databases they might not find that title verbatim. So while I like the idea of "copy exactly so people can find the original" in theory, in practice we are aggregating from lots of different databases, which may have incompatible and in some cases broken representations. The alternative is "use a consistent representation on Wikipedia" and if our representation is sensible, hope that other databases will use the same or at least be able to normalize our representation to theirs when searching (not to mention web sites that search Wikipedia). Worst case, it should be possible to find the full text of a journal article without the title as a search parameter by using journal, author, and date, though this is clearly not ideal.
• What Wikipedia outputs for COinS may in fact impact the standard accepted format (and whether or not COinS becomes popular), since there seems to be no formal standard for markup issues and we're a major web site and not many sites use it. We could also look at the other sites listed on COinS and see how they handle special characters.
• For science and math articles, MOS:FRAC says we can either use {{sfrac}} or ASCII fractions like "1/2". For general articles we're supposed to use only {{frac}}. So if we're taking the MOS:CONFORM approach, is the desired outcome to change MOS:FRAC to advise using only ASCII fractions in citations, for all types of articles? (Unless part of a more complicated math formula, of course.) Or should we use e.g. ¹/₂ to approximate {{frac}} at the expense of polluting COinS output with HTML markup?

-- Beland (talk) 17:29, 12 September 2021 (UTC)

We should cite formulas in references the way the reference formatted it, even when our style guidelines would tell us to use a different style for the same-meaning formula in our own text. So, for instance, it would be correct to cite: Bandukwala, J.; Shay, D. (February 1974). "Theory of free, spin-½ tachyons". Physical Review D. 9 (4): 889–895. doi:10.1103/physrevd.9.889. I've used the Unicode ½ here, but I think it would be better to use {{frac|1|2}} 1⁄2 and that our template's failure to allow that is a bug: Bandukwala, J.; Shay, D. (February 1974). "Theory of free, spin-1⁄2 tachyons". Physical Review D. 9 (4): 889–895. doi:10.1103/physrevd.9.889. {{cite journal}}: templatestyles stripmarker in |title= at position 22 (help) —David Eppstein (talk) 18:57, 12 September 2021 (UTC)

The COinS data for this title includes a stripmarker (which doesn't make sense to pass on, hence the warning):

&rft.atitle=Theory+of+free%2C+spin-%7F%27%22%60UNIQ--templatestyles-0000001B-QINU%60%22%27%7F%3Cspan+class%3D%22frac%22+role%3D%22math%22%3E%3Cspan+class%3D%22num%22%3E1%3C%2Fspan%3E%26frasl%3B%3Cspan+class%3D%22den%22%3E2%3C%2Fspan%3E%3C%2Fspan%3E+tachyons

We could strip off the stripmarker and pass on the remaining HTML. Decoded, this would result in the following string:

Theory of free, spin-<span class="frac" role="math"><span class="num">1</span>⁄<span class="den">2</span></span> tachyons

which renders (almost) nicely as:

Theory of free, spin-1⁄2 tachyons

but only if we can assume a HTML rendering engine at the receiver's end (which we cannot, unfortunately).

Automatically stripping out the attributes would give this much cleaner looking HTML:

Theory of free, spin-<span><span>1</span>⁄<span>2</span></span> tachyons

or in this easy case even:

Theory of free, spin-1⁄2 tachyons

for:

Theory of free, spin-1⁄2 tachyons

It is certainly better to pass this through than to mute the metadata completely, but this obviously isn't a good solution working in all cases either.

Presumably, the code already extracts useful text for COinS metadata from some specific math stripmarkers (the alt= attribute with PNGs, plain text with TeX, or the contents of <annotation> elements with MathML), but this obviously doesn't cover all cases. It might be worth trying to further improve this, but we probably also need a |descriptive-title= to allow editors to specify themselves what should be passed on as metadata.

--Matthiaspaul (talk) 20:18, 12 September 2021 (UTC)

If you think "Theory of free, spin-1⁄2 tachyons" renders "almost nicely" you must be using a very different browser setup than mine, where the 2 is huge and overwritten by the /. Also, we should not be rewriting references to make them fit into COINS; the only thing that should get rewritten is what appears in the COINS metadata. As for "plain text with TeX": no. What you get with the current implementation from TeX is "MATH+RENDER+ERROR" in the COINS metadata. —David Eppstein (talk) 21:44, 12 September 2021 (UTC)

Well, that's why I wrote "almost". ;-) Basically, we are in agreement here. What's important here is that it carries over the semantic information, not that it looks pretty. Our CSS definitions are not available at the receiver's end (and shouldn't), that's why my example looks a bit distorted. But there will always be differences in the output of different rendering engines. It would matter if this would be used for our local display of citations (where we should not compromise on the quality of its appearance), but it does not really matter for metadata purposes. What we need is not a particularly nice visual representation of the metadata, but an accurate semantic description of the math.

--Matthiaspaul (talk) 16:37, 15 September 2021 (UTC)

Previous discussion: Help talk:Citation Style 1/Archive 19 § math ml rendering changes and metadata

Tracked in Phabricator
Task T138229

It used to be that we could extract the content of a math stripmarker and from that content extract a more-or-less human-readable copy of an equation that we could put into the metadata. What was in the math stripmarker depended on the math preferences setting of the editor who last saved the article. Here is what we used to get for this equation example:

<math display=inline>210=14\times15=5\times6\times7=\binom{21}{2}=\binom{10}{4}</math>

for the various math preferences settings:

MathML with SVG or PNG fallback (recommended for modern browsers and accessibility tools)

<span class="mwe-math-element"><span class="mwe-math-mathml-inline mwe-math-mathml-a11y" style="display: none;"><math xmlns="http://www.w3.org/1998/Math/MathML" alttext="{\textstyle 210=14\times 15=5\times 6\times 7={\binom {21}{2}}={\binom {10}{4}}}">
  <semantics>
    <mrow class="MJX-TeXAtom-ORD">
      <mstyle displaystyle="false" scriptlevel="0">
        <mn>210</mn>
        <mo>=</mo>
        <mn>14</mn>
        <mo>&#x00D7;<!-- × --></mo>
        <mn>15</mn>
        <mo>=</mo>
        <mn>5</mn>
        <mo>&#x00D7;<!-- × --></mo>
        <mn>6</mn>
        <mo>&#x00D7;<!-- × --></mo>
        <mn>7</mn>
        <mo>=</mo>
        <mrow class="MJX-TeXAtom-ORD">
          <mrow>
            <mrow class="MJX-TeXAtom-OPEN">
              <mo maxsize="1.2em" minsize="1.2em">(</mo>
            </mrow>
            <mfrac linethickness="0">
              <mn>21</mn>
              <mn>2</mn>
            </mfrac>
            <mrow class="MJX-TeXAtom-CLOSE">
              <mo maxsize="1.2em" minsize="1.2em">)</mo>
            </mrow>
          </mrow>
        </mrow>
        <mo>=</mo>
        <mrow class="MJX-TeXAtom-ORD">
          <mrow>
            <mrow class="MJX-TeXAtom-OPEN">
              <mo maxsize="1.2em" minsize="1.2em">(</mo>
            </mrow>
            <mfrac linethickness="0">
              <mn>10</mn>
              <mn>4</mn>
            </mfrac>
            <mrow class="MJX-TeXAtom-CLOSE">
              <mo maxsize="1.2em" minsize="1.2em">)</mo>
            </mrow>
          </mrow>
        </mrow>
      </mstyle>
    </mrow>
    <annotation encoding="application/x-tex">{\textstyle 210=14\times 15=5\times 6\times 7={\binom {21}{2}}={\binom {10}{4}}}</annotation>
  </semantics>
</math></span><img src="https://wikimedia.org/api/rest_v1/media/math/render/svg/4012a8a0261dae95c0a7443dbf67dcb58800df0c" class="mwe-math-fallback-image-inline" aria-hidden="true" style="vertical-align: -1.005ex; width:40.087ex; height:3.343ex;" alt="{\textstyle 210=14\times 15=5\times 6\times 7={\binom {21}{2}}={\binom {10}{4}}}"/>

LaTeX source (for text browsers):

<span class="mwe-math-fallback-source-inline tex" dir="ltr">$ {\textstyle 210=14\times 15=5\times 6\times 7={\binom {21}{2}}={\binom {10}{4}}} $</span>

PNG images:

<img src="https://wikimedia.org/api/rest_v1/media/math/render/png/4012a8a0261dae95c0a7443dbf67dcb58800df0c" class="mwe-math-fallback-image-inline" aria-hidden="true" style="vertical-align: -1.005ex; width:40.087ex; height:3.343ex;" alt="{\textstyle 210=14\times 15=5\times 6\times 7={\binom {21}{2}}={\binom {10}{4}}}" />

For PNG we took the content of the alt= attribute; for LaTeX we took everything between the paired $...$; for MathML we took the content of the <annotation>...</annotation> tag.

And then, suddenly, that ability was taken away from us; see the Phabrication link. Because a math stripmarker is wholly and completely meaningless to anyone consuming a cs1|2 citation via the metadata, I replaced the stripmarker with the text: MATH+RENDER+ERROR. Except for that, all of the rest of the metadata are correct:

<span ...>...
&rft.genre=article
&rft.jtitle=Publicationes+Mathematicae+Debrecen
&rft.atitle=MATH+RENDER+ERROR
&rft.volume=51
&rft.issue=1%E2%80%932
&rft.pages=175-189
&rft.date=1997
&rft_id=%2F%2Fwww.ams.org%2Fmathscinet-getitem%3Fmr%3D1468225%23id-name%3DMR
&rft.aulast=Pint%C3%A9r
&rft.aufirst=%C3%81kos
&rft.au=de+Weger%2C+Benjamin+M.+M.
</span>

so readers consuming the citation via the metadata are likely to be able to locate the source (especially if the title has more to it than an equation). Despite this 'fix', what actually ends up in &rft.atitle= is dependent on the preference settings of the editor who last saved the article:

PNG:

&rft.atitle=%3Cspan+class%3D%22nowrap%22%3E%7B%5Cdisplaystyle+210%3D14%5Ctimes+15%3D5%5Ctimes+6%5Ctimes+7%3D%7B%5Cbinom+%7B21%7D%7B2%7D%7D%3D%7B%5Cbinom+%7B10%7D%7B4%7D%7D%7D%3C%2Fspan%3E

LaTeX:

&rft.atitle=%3Cspan+class%3D%22nowrap%22%3E210%3D14%5Ctimes+15%3D5%5Ctimes+6%5Ctimes+7%3D%7B%5Cbinom+%7B21%7D%7B2%7D%7D%3D%7B%5Cbinom+%7B10%7D%7B4%7D%7D%3C%2Fspan%3E

MathML

&rft.atitle=%3Cspan+class%3D%22nowrap%22%3EMATH+RENDER+ERROR%3C%2Fspan%3E

I think that this behavior is new since the last time that I looked at this issue because I seem to recall that all three cases put MATH+RENDER+ERROR in the metadata. Alas, we cannot force editors to use PNG or LaTeX rendering, nor can we force MediaWiki to give us back the ability to extract content from math stripmarkers.

The only way that I can think of to include math markup in |title= is to have an alternate |math-title= or some such that requires some sort of special-secret-markup that is not <math>...</math> tags to wrap whatever would normally be in <math>...</math> tags so, for example:

|math-title=A title with some text and $210=14\times15=5\times6\times7=\binom{21}{2}=\binom{10}{4}$ and yet more text

The module would then make a copy of the value assigned to |math-title= and then remove the special-secret-markup and put the result into the metadata. Then, the module would replace the special-secret-markup with actual opening and closing <math>...</math> tags, and then preprocess a special template that renders the math title. That rendering then goes into |title=. Yeah, pretty ugly, and I have no idea if it would work.

This search finds about 650 articles that contain |title= with a <math> tag (not all |title= parameters are associated with cs1|2).

—Trappist the monk (talk) 23:19, 12 September 2021 (UTC)

Very simple proof of concept. I have hacked a sandbox module. It takes a string of text as single parameter |math-title= that may, or may not, have $ delimited math text. If it finds a matched pair of $ delimiters, it replaces the delimiters with <math display=inline> and </math> and then preprocesses that string to get a math rendering that can be used in the citation's title:

{{#invoke:Sandbox/trappist_the_monk/math|math-title|math-title=$210=14\times15=5\times6\times7=\binom{21}{2}=\binom{10}{4}$}}

math title: ${\textstyle 210=14\times 15=5\times 6\times 7={\binom {21}{2}}={\binom {10}{4}}}$; metadata: $210=14\times15=5\times6\times7=\binom{21}{2}=\binom{10}{4}$

The raw value from |math-title= might be used in the metadata as-is because the $ delimiters are 'native' to LaTex / TeX.

To be done: support for escaped \$ (literal '$' appearing in math text), support for '$' appearing in plain text that is not math text – for |math-title=, requiring editors to escape '$' when it appears in text that is not math text seems a reasonable restriction for this parameter. No doubt there is other stuff to do with this hack before we consider implementing it in the cs1|2 module suite.

—Trappist the monk (talk) 16:24, 14 September 2021 (UTC)

I like your approach to grab the data before MediaWiki gets it by playing man in the middle. This is brilliant. I didn't know that such a pre-processing of the formula would be possible. We should definitely try to further build on this.

But: Even if we are able to pass on a perfectly workable string as metadata, we still cannot be sure that it can be correctly interpreted at the receiver's end, so it is good to have this, but we still need a more general solution to cover other cases as well.

Since publishers of works containing formulas or other "visually complex stuff" in their titles will have to pass some textual representation of such titles to customers it is quite likely that some publisher-provided text-only alternative titles are already stored and established as standard alternative titles in external databases. In some cases, they might even be known by our contributing editors, so it would be useful if they could be entered as alternative text titles into our citations without having to give up on the nice "presentation" titles in |title= for our local purposes.

David's |text-title= and my |descriptive-title= are basically the same idea, except that in his, the contents of |text-title= would completely replace the contents of |title= for metadata purposes (similar to how your |math-title= would replace |title= for both, our local rendering as well as the metadata), whereas my |descriptive-title= could be used instead of a normal |title= (if not given), but could also be combined with |title= (when both are given). The contents of the descriptive title should be displayed without text decoration when rendered (not sure if in front or following the normal title if both exist), and should be put into [square-brackets] in metadata to indicate that this is not the original title (probably prefixing the normal title if both exist). The different representation styles would allow to tell them apart when both are displayed or combined into the single &rft.atitle= oder &rft.btitle= COinS key.

I think, our ideas are similar enough to be combined so that |descriptive-title= would effectively become your |math-title= when it contains some $TeX$. (And for the rare case, where the $TeX$ stuff should not be interpreted in your suggested way, we have our ((accept-this-as-written)) syntax to indicate this.) This way, the editor would have the flexibility to provide either the |title= or the |descriptive-title= (including its special handling for math), or both.

This would also cover all cases for which we have discussed a need for something like a |descriptive-title= in the past, non existing titles, dynamic titles, visual or acoustical only titles, functional titles, alias titles, unrepresentable titles, because too long, in unsupported scripts, or misleading in our context...

In past discussions we have also established two more special cases: The case where no actual title exists and we want to indicate this by a standardized descriptive title (keyword "none" to display the localized "no title"), and the case where a title does exists, but should not be displayed for some reason (keyword "off"), for example in an article listing many revisions of a work), but where we would still want to issue the complete metadata for it. Last year, I started to implement this by introducing these keywords to |title=none/off, but realized we would still need something more like a |descriptive-title= parameter to specify the title for metadata.

We now have the chance to combine this and cover all these use cases with one new parameter.

--Matthiaspaul (talk) 16:37, 15 September 2021 (UTC)

Adding support for a |descriptive-title= is scope creep. What we are trying to solve is the display of math in titles. So we should limit it to such with a name that makes it obvious the purpose of that parameter. Izno (talk) 18:02, 15 September 2021 (UTC)

Perhaps it is scope creep in this particular thread, but not in general. Our whole discussion including Trappist's proposal is tangential to the original question raised by the OP, nevertheless the discussion was quite productive so far.

However, thinking about how to possibly combine open requirements when they are related is a good design approach. Many of the incoherences of the existing template design were caused by former ad hoc solutions to fix isolated problems. In the past years we were able to correct some of these bad design decisions to improve the interface but there are still weak spots and we also have a long list of still needed features which haven't been implemented yet because of lack of time or because it was felt that something was still missing to round out the design of a feature. Descriptive titles are among them - I had hoped that it would be possible to implement them without a need for a new parameter at all, but then we would have to introduce some special syntax to the normal |title=. It's still a possibility, but when we are now tinkering with the idea of introducing a dedidated |math-title=, it is important to also think about more general descriptive titles. After all, a title for a textual math representation is some kind of descriptive title. Otherwise, we easily end up with a whole new bunch of special title parameters, something, I think, we both want to avoid. Therefore, it is a valid question how to possibly combine this at least in the design, even if not all parts of the actual solution would be implemented at the same time.

--Matthiaspaul (talk) 22:17, 15 September 2021 (UTC)

Hmm, some sources when ASCIIfying article titles, appear to use TeX-like markup inside special markers like "##" or "$". Examples: [4] [5]. And here's an example of <em>...</em> where we'd probably want to use '', but I think the em tag gets emitted in the final HTML: [6]. -- Beland (talk) 23:49, 13 September 2021 (UTC)

I'm not sure that the following is a good idea, myself, but one possible way through this would be to add a |text-title= parameter to the template to use as the text version of the title, and simultaneously to allow templates like {{frac}} oder {{nowrap}} or whatever in titles when a text-title is present. That wouldn't address the inability to extract meaningful text from <math> formulas, but I'm sure Citation bot could be persuaded to add text-titles for those. One reason it's a bad idea is that the parameter would only produce invisible markup and therefore there wouldn't be much incentive for editors to make it accurate. —David Eppstein (talk) 00:34, 14 September 2021 (UTC)

Templates inside a cs1|2 template are expanded before the cs1|2 template is expanded. So, what cs1|2 sees when an editor writes:

|title=A {{frac|1|2}} Title

is this:

A '"`UNIQ--templatestyles-00000127-QINU`"'<span class="frac"><span class="num">1</span>&frasl;<span class="den">2</span></span> Title

The templatestyles stripmarker refers to Template:Fraction/styles.css which is where class="frac", class="num", and class="den" are defined. None of that styling is available to readers who consume the citation through the metadata. Module:Citation/CS1 might remove the stripmarker, all class= attributes, and any <span>...</span> tags without attributes:

A <span role="math">1⁄2</span> Title

We might also strip other attributes, style= might be one, and remove other html tags.

This same mechanism, where the editors writes this:

|title={{nowrap|don't wrap this text}}

cs1|2 gets as this:

<span class="nowrap">don't wrap this text</span>

where the nowrap class is defined in MediaWiki:Common.css. cs1|2 would include this in the metadata:

don't wrap this text

If this is a workable solution and if the code that implements it doesn't take too much of the limited processor time, we will need a list of commonly used attributes and html tags that can be stripped from every parameter value that is made part of the metadata.

—Trappist the monk (talk) 11:46, 14 September 2021 (UTC)

I suspect that the <em>...</em> is inappropriate use where <i>...</i> would have been a better choice. Apparently the $ is a standard part of LaTeX and TeX used to delimit the beginning and end of math text; using a standardized delimiter is always better than making up our own delimiters. I've changed my example above to use the $ delimiters.

—Trappist the monk (talk) 11:46, 14 September 2021 (UTC)

To clarify, $ delimits in-line math text, which TeX renders in a smaller font size. --Shmuel (Seymour J.) Metz Username:Chatul (talk) 14:48, 14 September 2021 (UTC)

Math text in a cs1|2 parameter that contributes to the citation's metadata is always inline math text so the $ delimiters are appropriate, right?

—Trappist the monk (talk) 15:07, 14 September 2021 (UTC)

The math in reference titles should only be inline, yes. $ ... $ for inline math and $$ ... $$ for display math is old-school TeX markup. The modern alternative (better for being less ambiguous wrt actual dollar signs, and also with some technical advantages in actual TeX for making it easier to hang hooks in the code) is \( ... \) for inline math and \[ ... \] for display math. The Wikimedia developers have vetoed allowing these to be shortcuts for math markup in the Wikimedia codebase, but I suppose that doesn't prevent them from being used in templates that intercept them and convert them to <math display=inline> ... </math> and <math display=block> ... </math> respectively. Would this actually work? Can math tags in template output still be expanded, or is math tag expansion only done before the templates are expanded? If this could be done in the existing |title= parameter, I think that would be better than introducing a new multiplicity of confusing variations of title parameters. —David Eppstein (talk) 18:32, 15 September 2021 (UTC)

For the same reasons it was vetoed there, use in the general parameter I think is a bad idea. Izno (talk) 20:47, 15 September 2021 (UTC)

Perhaps you could articulate those reasons, and convince me that it isn't one of (1) we are deliberately sabotaging LaTeX-based math because we still want people to use MathML instead, or (2) we don't care about whether mathematics works on Wikipedia because it isn't an important enough subset of our use and we don't want to pay the ongoing development costs of keeping it working? Because neither of those reasons applies to mathematics formulas in citation titles. —David Eppstein (talk) 21:14, 15 September 2021 (UTC)

Because you don't know what might be citation titles that look like your preferred <math> tag replacements. Izno (talk) 21:24, 15 September 2021 (UTC)

That would be a valid reason to avoid $ ... $. It's not a valid reason to avoid \( ... \) because very few references use that syntax (very likely, zero references) and because if they do we can fall back to the format-as-typed escape codes already used elsewhere in the citation templates. —David Eppstein (talk) 22:09, 15 September 2021 (UTC)

(edit-conflict) Actually, if it would be possible to include the functionality of the proposed |math-title= (or whatever) into the normal |title=, as David suggests, this would be better from the user's perspective than to introduce a dedicated parameter for this. The question, however, is how conflictive such $TeX$ stuff would be within normal titles. If collisions would be rather rare, we still have our ((accept-this-as-written)) syntax to force the template to take the title verbatim (which is already supported by |title= to override the removal of end interpunctation).

If it can't be combined into the existing |title= parameter then the question is how at least text titles for math (which fall under the category of descriptive titles) can be combined with more general descriptive titles interfacewise, so that we eventually need only one new parameter rather than two for semantically close purposes.

Not thinking about this now at least conceptually is exactly what leads to incoherent interface design, something we should try to avoid.

--Matthiaspaul (talk) 22:22, 15 September 2021 (UTC)

ok, so here's a version of my test hack that uses the \( ... \) delimiters:

{{#invoke:Sandbox/trappist_the_monk/math|math_test2|math-title=Entropy-Based Uncertainty Measures for \(L^2(\mathbb{R}^n),\ell^2(\mathbb{Z})\), and \(\ell^2(\mathbb{Z}/N\mathbb{Z})\) With a Hirschman Optimal Transform for \(\ell^2(\mathbb{Z}/N\mathbb{Z})\)}}

math title: Entropy-Based Uncertainty Measures for ${\textstyle L^{2}(\mathbb {R} ^{n}),\ell ^{2}(\mathbb {Z} )}$, and ${\textstyle \ell ^{2}(\mathbb {Z} /N\mathbb {Z} )}$ With a Hirschman Optimal Transform for ${\textstyle \ell ^{2}(\mathbb {Z} /N\mathbb {Z} )}$; metadata: Entropy-Based Uncertainty Measures for \(L^2(\mathbb{R}^n),\ell^2(\mathbb{Z})\), and \(\ell^2(\mathbb{Z}/N\mathbb{Z})\) With a Hirschman Optimal Transform for \(\ell^2(\mathbb{Z}/N\mathbb{Z})\)

That's a real title I found somewhere (except that in its current guise it uses <math>...</math> tags).

<math>...</math> tags in parameter values are expanded into math stripmarkers before cs1|2 gets parameter values. After cs1|2 has rendered the citation, MediaWiki replaces each math stripmarker with its associated expansion. Using $...$ oder \( ... \) instead of <math>...</math> tags allows us to apply <math>...</math> tags and then expand them into math stripmarkers (to be replaced by MediaWiki after cs1|2 final rendering) at the time of our choosing.

The only reasons that I can think of to not support this directly in |title= is that we have to inspect every |title= value for the \( ... \) delimiters and it is possible that some title somewhere legitimately uses the TeX delimiters. Inspecting every |title= value is relatively inexpensive because all we have to look for is the opening \( delimiter so if Title:find ('\\%(') then ... end – attempt to convert delimiters to <math>...</math> tags only when a \( delimiter is present. I found only two instances of the opening \( delimiter; one is vandalism and the other a malformed title. It would not be so simple with the $...$ delimiters so if we proceed with this solution and choose to use $...$ delimiters, implementing |math-title= along-side |title= is the better choice.

—Trappist the monk (talk) 21:54, 15 September 2021 (UTC)

I would be fine with \( ... \) to mark TeX blocks, for as long as our (( ... )) wrapping syntax would disable the feature.

--Matthiaspaul (talk) 22:46, 15 September 2021 (UTC)

\( ... \) TeX delimiters experiment moved to Module:Citation/CS1/sandbox. I have disabled the <math>...</math> 'allowance' so parameters with <math>...</math> tags will emit the stripmarker error:

{{Cite book/new |title=<math display="inline">3987^{12} + 4365^{12} = 4472^{12}</math>}}

${\textstyle 3987^{12}+4365^{12}=4472^{12}}$.

math in a book title:

{{Cite book/new |title=\(3987^{12} + 4365^{12} = 4472^{12}\)}}

\(3987^{12} + 4365^{12} = 4472^{12}\).

math in a book chapter:

{{Cite book/new |chapter=\(3987^{12} + 4365^{12} = 4472^{12}\) |title=Title}}

"\(3987^{12} + 4365^{12} = 4472^{12}\)". Title.

math in a journal title:

{{Cite journal/new |title=\(3987^{12} + 4365^{12} = 4472^{12}\) |journal=Journal}}

"\(3987^{12} + 4365^{12} = 4472^{12}\)". Journal.

math in a book title with accept-as-written markup:

{{cite book/new |title=((\(3987^{12} + 4365^{12} = 4472^{12}\)))}}

\(3987^{12} + 4365^{12} = 4472^{12}\).

math in a book title metadata:

'"`UNIQ--templatestyles-0000013B-QINU`"'<cite class="citation book cs1">''\(3987^{12} + 4365^{12} = 4472^{12}\)''.</cite><span title="ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Abook&rft.genre=book&rft.btitle=%5C%283987%5E%7B12%7D+%2B+4365%5E%7B12%7D+%3D+4472%5E%7B12%7D%5C%29&rfr_id=info%3Asid%2Fen.wikipedia.org%3AHelp+talk%3ACitation+Style+1" class="Z3988"></span>

—Trappist the monk (talk) 23:22, 16 September 2021 (UTC)

Disabling the default <math> formatting in references is (1) going to cause a huge number of errors with existing citations, and (2) going to cause enormous confusion with editors who don't understand why the mathematics delimiters should be different in this context than everywhere else. I think emitting an error message is the wrong way to go. Better would be to continue to allow the math stripmarkers, but to put them into a tracking category so that a bot or AWB can run around behind the scenes converting the delimiters. I think such conversion is going to continue to be needed on a slow but ongoing basis, rather than being a one-time thing that can be enforced as an error once a change is made. —David Eppstein (talk) 00:54, 17 September 2021 (UTC)

Of course, the error message help would explain the problem, and the article is also put into category Category:CS1_errors:_invisible_characters. The COinS metadata for the citation with the MATH+RENDER+ERROR is still issued just like before (after all, it's still possible that MediaWiki will be fixed somewhen in the future). I think that's exactly how it should be, but an alternative would be to change the error message into a warning.

--Matthiaspaul (talk) 01:17, 17 September 2021 (UTC)

We don't have any warning messages. If this change is accepted, I expect to remove the parts of Module:Citation/CS1/COinS that decoded the math stripmarker content – it won't be needed.

—Trappist the monk (talk) 01:24, 17 September 2021 (UTC)

For some unknown reason I often call our maintenance messages "warnings" - probably have worked with systems which could issue warnings and errors rather than maintenance and error messages... ;-)

Removing the code that decoded the math stripmarker contents, this would not affect the code for SVG and LaTeX math extraction, only for MathML, right?

Brings up the question if we should normalize the slightly different output from the SVG, LaTeX and now MathML via \( ... \) extraction methods, because, from a COinS consumer's perspective, that's our internal business and should always give identical output, shouldn't it?

--Matthiaspaul (talk) 19:10, 17 September 2021 (UTC)

If we keep this proposed solution, all of the code that decoded the math stripmarker contents should go away because we won't need to extract anything from SVG, LaTeX, or MathML, whichever of those the last publishing editor had selected for math rendering – everything we need is right there in the parameter value.

—Trappist the monk (talk) 20:00, 17 September 2021 (UTC)

But this holds true only for new edits, what about the old ones? And what if some editors continue to use the SVG or LaTeX methods, should we prompt them with an error message and force them to rewrite the citation using \( ... \) although their edits did not actually cause us problems?

We should definitely keep the new solution, it's great. I'm just not sure the old handling should be removed (at least not until the new markup is fully established)...

--Matthiaspaul (talk) 22:03, 17 September 2021 (UTC)

I get the impression that you do not understand how the old mechanism works. When I edit an article that just happens to have a cs1|2 template with <math>...</math> markup in a |title= parameter, and then publish that article, the live cs1|2 module will create the metadata string for that citation (coins_replace_math_stripmarker()) using the math settings in my preferences because MediaWiki renders that math image into a stripmarker before cs1|2 gets the content of |title=. Since the stripmarker was created using my settings, the metadata will be derived from my settings. The resulting metadata are then cached for everyone until some other editor saves the article and their math preference setting is different from mine.

The cached metadata will remain as is until something causes MediaWiki to refresh the article. If/when the proposed \( ... \) TeX delimiters are introduced, as noted elsewhere in this discussion, an awb or some such script will be required to replace the <math>...</math> markup which will cause an article refresh and so new metadata using the \( ... \) TeX delimited wikitext straight from the appropriate parameter. Because we feed the metadata directly from the \( ... \) TeX delimited wikitext, there is no need (and no ability to) decode a math stripmarker so the code that decoded the math stripmarker content (even if it still worked) will no longer be need so should be removed. If we ever need it, we can always get it back from a previous version of the module.

—Trappist the monk (talk) 01:13, 18 September 2021 (UTC)

Thanks, Trappist. I think I understood the mechanism well, but its always good to get reconfirmation by reading your explanation. What I did not understood was that you really meant a refresh run to be a mandantory part of the introduction process, instead I thought we'd leave that as optional (if some volunteer cares enough to do it) and otherwise the articles would remain with their old cached data until someone happens to edit them (which could take weeks, months, years).

I guess, there will still be editors who continue to use the <math>...</math> markup at least for a while and it would have been convenient for them if they could continue to use it for entries which either do not contribute to the metadata, or to entries contributing to metadata, if they have selected SVG or LaTeX, not MathML. However, this would put the burden to switch to \( ... \) on the next editor with MathML settings and would also leave the citation source code in a mix of markups, which might not be desirable for other parties which read our wikitext rather than metadata, so yes, I agree, a hard switch is probably the better approach here.

--Matthiaspaul (talk) 09:48, 20 September 2021 (UTC)

I don't know that a huge number of errors with existing citations is an accurate description. If these search results are to be believed, there are:

~650 articles that have <math>...</math> tags in |title=

~25 articles that have <math>...</math> tags in |chapter=

I think that editors will learn quickly enough about the change in markup if they can see an error message that has a link to an explanation; maintenance category messaging is hidden from all editors who have not chosen to show those messages.

If we are to keep this change it isn't difficult to write an awb script that will change the <math>...</math> tags to \( ... \) TeX delimiters. That script can be run on the same day that the change goes live (if it goes live) and be done after a couple of hours.

—Trappist the monk (talk) 01:24, 17 September 2021 (UTC)

This should also work for the title- and chapter-related |script-= parameters which become part of the metadata. Are there other parameters ending up in metadata where math-like constructs could show up occasionally? What about the journal name, work, author etc. names and publisher entries?

And what shall we do with other parameters which definitely might contain math, but are not part of metadata like the corresponding |trans-= parameters, and |quote=, |script-quote= and |trans-quote=. Should we support the \(...\) syntax there as well as an alternative for syntax compatibility/consistency, or should we insist on <math> there?

--Matthiaspaul (talk) 19:10, 17 September 2021 (UTC)

If we keep this proposed solution, certainly all of the 'title-holding' parameters and the quotation parameters should support \( ... \) TeX delimiters for math markup. |journal=? |work=? |publisher=? |author=? I don't think so; at least not until a need has been sufficiently demonstrated. Quick searches for <math>...</math> tags in those parameters either timed out with no results or returned no results. We should only support one form of math markup.

—Trappist the monk (talk) 20:00, 17 September 2021 (UTC)

Guidance for science etc.

Given the new proposed solution for <math>...</math> markup and the above comments, I'm wondering where we've come down on how to handle simple markup. I see contradictions between editors like "No unicode characters. Those are a blight, and should be purged on sight." vs. "exactly as the source information presents it, 'funny' characters and all". David Eppstein said titles should be formatted "the way the reference formatted it, even when our style guidelines would tell us to use a different style", but then used {{frac}} instead of ½. Our style guide says to use {{sfrac}} for science articles, so that seems to satisfy neither the goal of looking consistent with the style of body text nor the goal of being exactly the same as the original document for ease of search.

What are we proposing as the solution for simple markup, like a chemical formula? If we're following the sources exactly, we might use no-markup Unicode vs. <sup>...</sup> depending on what the original document does, though if it's on paper or PDF it will be impossible to tell. If we're avoiding Unicode compatibility characters, then we still have at least three choices:

• Something about H₂O₂. {{cite book}}: templatestyles stripmarker in |title= at position 17 (help) - {{chem2|H2O2}} - Copy-paste: Something about H 2O 2
• Something about \(H_2 O_2\). - \(H_2 O_2\) - Copy-paste: Something about H 2 O 2 {\textstyle H_{2}O_{2}} {\textstyle H_{2}O_{2}}
• Something about H₂O₂. - H₂O₂ - Copy-paste: Something about H2O2
• Something about H₂O₂. - Unicode subscripts - Copy-paste: Something about H₂O₂

Though it's unclear to me how well any database or web search engine is going to handle the difference between say, "H2O2" as a search parameter and an internally stored "H₂O₂". -- Beland (talk) 17:19, 18 September 2021 (UTC)

Certainly not {{chem2}}; your example renders this mishmash:

'"`UNIQ--templatestyles-0000014B-QINU`"'<span class="chemf nowrap">H<sub class="template-chem2-sub">2</sub>O<sub class="template-chem2-sub">2</sub></span>

The copypasta is not as you have shown it but actually like this because the markup includes <br /> tags:

Something about H
2O
2.

Most cs1|2 templates appear in reflists which reduce text size to 90% so a font size of 70% (already smaller than allowed for accessibility; see MOS:SMALL) is just harder to read.

Also, certainly not Unicode subscripts because the already-hard-to-read Unicode subscript characters are harder-to-read when made smaller in reflists.

—Trappist the monk (talk) 21:50, 18 September 2021 (UTC)

OK, that leaves the TeX-like syntax and HTML sup/sub tags. The Tex-like solution isn't ready yet, and presumably the COinS citation code could process simple <sub>...</sub> tags and friends cleanly? A rule like "use HTML sup/sub tags instead of Unicode subscripts and superscripts" would be easy to follow and easy to enforce, so I'm thinking maybe do that for now?

What about fractions like movie reviews of Naked Gun 33⅓: The Final Insult? Is it OK to use {{frac}} and {{sfrac}}? -- Beland (talk) 03:29, 20 September 2021 (UTC)

I discussed {{frac}} above at my 11:46, 14 September 2021 post.

Templates inside cs1|2 parameter values are expanded before cs1|2 gets the value so when an editor writes:

|title=Naked Gun 33{{sfrac|1|3}}

cs1|2 gets:

|title=Naked Gun 33'"`UNIQ--templatestyles-00000150-QINU`"'<span class="sfrac">&NoBreak;<span class="tion"><span class="num">1</span><span class="sr-only">/</span><span class="den">3</span></span>&NoBreak;</span>

The templatestyles stripmarker refers to Template:Sfrac/styles.css which defines the classes: sfrac, tion, num, den, and sr-only. As with {{frac}}, none of that styling is available to readers who consume the citation through the metadata so for them, the markup is just meaningless clutter.

—Trappist the monk (talk) 13:33, 20 September 2021 (UTC)

Not sure where the above discussion landed, exactly. It seems we could either put in code to strip that stuff out, or we could make a clean template. How about a {{citefrac}} that just does ¹⁄₂ (¹&frasl;₂)? If we decide later that COinS conventions have shifted and Unicode fractions are preferred, we can simply change that template rather than all the articles that use it. Actually, if we do universally adopt some sort of Tex-like syntax, having {{citefrac}} would also make it easy to switch over to that, too.-- Beland (talk) 01:00, 23 September 2021 (UTC)

Trappist and I suggested that we could attempt to filter/cleanup/simplify the HTML before we create the title metadata. Removing anything CSS-related, unnecessary attributes, empty elements, etc. This would not be a solution for complicated HTML, but would allow to have at least simple HTML markup in the title.

In addition to "simplified HTML" and the \( ... \) solution for math, I continue to maintain that we need something like an optional |descriptive-title= (or |text-title= per David) as a fallback, so that editors can use fancy stuff in |title= for pretty local display purposes (without compromising for COinS), while still being able to exactly match a title, if known, as it may be used in an external database (regardless of what representation or transliteration may be used there) so that it can be used as search pattern there as well.

--Matthiaspaul (talk) 08:42, 23 September 2021 (UTC)

A filter/cleanup/simplify solution may not be sufficient. In my sandbox I've hacked some code that removes:

• stripmarkers
• <br /> tags (used in {{chem2}})
• class= attributes from <span> tags
• style= attributes from <span> tags
• title= attributes from <span> tags
• extraneous whitespace
• <span> without attributes and its matching </span>

For the simple cases:

Naked Gun 33{{code|{{sfrac|1|3}}}}

Naked Gun 33'"`UNIQ--syntaxhighlight-00000157-QINU`"'

Naked Gun 33⁠1/3⁠

we get:

{{#invoke:Sandbox/trappist_the_monk/math|span_test|1=Naked Gun 33{{sfrac|1|3}}}}

Naked Gun 33⁠1/3⁠

Naked Gun 33⁠1/3⁠

but for complex cases:

{{chem2|[{(\h{5}C5Me4)SiMe2(\h{1}NCMe3)}(PMe3)Sc(\m{2}H)]2}}

'"`UNIQ--templatestyles-0000015F-QINU`"'<span class="chemf nowrap">&#91;{(η<sup>5</sup>-C<sub class="template-chem2-sub">5</sub>Me<sub class="template-chem2-sub">4</sub>)SiMe<sub class="template-chem2-sub">2</sub>(η<sup>1</sup>-NCMe<sub class="template-chem2-sub">3</sub>)}(PMe<sub class="template-chem2-sub">3</sub>)Sc(μ<sub>2</sub>-H)]<sub class="template-chem2-sub">2</sub></span>

[{(η⁵-C₅Me₄)SiMe₂(η¹-NCMe₃)}(PMe₃)Sc(μ₂-H)]₂

we get:

{{#invoke:Sandbox/trappist_the_monk/math|span_test|1={{chem2|[{(\h{5}C5Me4)SiMe2(\h{1}NCMe3)}(PMe3)Sc(\m{2}H)]2}}}}

&#91;{(η<sup>5</sup>-C<sub class="template-chem2-sub">5</sub>Me<sub class="template-chem2-sub">4</sub>)SiMe<sub class="template-chem2-sub">2</sub>(η<sup>1</sup>-NCMe<sub class="template-chem2-sub">3</sub>)}(PMe<sub class="template-chem2-sub">3</sub>)Sc(μ<sub>2</sub>-H)]<sub class="template-chem2-sub">2</sub>

[{(η⁵-C₅Me₄)SiMe₂(η¹-NCMe₃)}(PMe₃)Sc(μ₂-H)]₂

Maybe that's good enough, I don't know, but is this good enough?

{{chem2|C2H3O2(-)}}

'"`UNIQ--templatestyles-00000167-QINU`"'<span class="chemf nowrap">C<sub class="template-chem2-sub">2</sub>H<sub class="template-chem2-sub">3</sub>O<span class="template-chem2-su"><span>−</span><span>2</span></span></span>

C₂H₃O−2

and stripped of markup:

{{#invoke:Sandbox/trappist_the_monk/math|span_test|1={{chem2|C2H3O2(-)}}}}

C<sub class="template-chem2-sub">2</sub>H<sub class="template-chem2-sub">3</sub>O−2

C₂H₃O−2

—Trappist the monk (talk) 14:05, 23 September 2021 (UTC)

Not sure if this would be reasonably safe for the general case, but in the examples above the result could be further improved if we would insert a   when a <span role="math"> gets eliminated, and when the text before and after a <span>x<br/>y</span> to be eliminated would be framed in <sub>y</sub> and <sup>x</sup> (perhaps only if inside a class="chemf"?).

--Matthiaspaul (talk) 20:13, 23 September 2021 (UTC)

I've been thinking about your {{chem2|C2H3O2(-)}} example a bit, and ideally, the stripped markup in that example should look just like the input. The the "2" subscript should bind closer to the "O" than the "-" charge.  — sbb (talk) 01:22, 24 September 2021 (UTC)

I'm sure this could be further improved, but I've hacked a "CS1/CS2-compatible" version of {{chem2/sandbox}} [7], which creates hidden metadata reproducing the input, see modified chem2 (this isn't the best possible metadata that could be created, but it was trivial to implement for our illustration purposes here). This is similar to how metadata is embedded into SVG and LaTeX math (which the current implemention of CS1/CS2 can extract already). CS1/CS2 templates could be easily made aware of this extension, so they could extract this data as well and use it for their metadata. This way, templates like {{chem2}}, which produce really difficult output for the HTML simplifier, could actively assist CS1/CS2 in their metadata creation. Over time, more templates could be enhanced this way and thereby be made "CS1/CS2-compatible".

--Matthiaspaul (talk) 10:01, 25 September 2021 (UTC)

If this is to be adopted and used by cs1|2, it would probably be best to not anchor-encode the {{chem2/sandbox}} input. Why anchor encoding? Before cs1|2 parameter values are added to the metadata, they are percent-encoded so, in its present form, what the metadata will get is:

[Cl4Re\qReCl4](2−) ← {{chem2/sandbox|[Cl4Re\qReCl4](2−)}} – anchor encoding

%26%2391%3BCl4ReqReCl4%26%2393%3B%282%E2%88%92%29 – percent encoding of the anchor-encoded input

when the metadata should get:

%5BCl4ReqReCl4%5D%282%E2%88%92%29 ← [Cl4Re\qReCl4](2−) – percent encoding

But, that's not wholly correct because the \q is treated as an escaped q so the result is missing the \ (%5C). This particular {{chem2}} input needs to be tweaked to escape the back slash:

%5BCl4Re%5CqReCl4%5D%282%E2%88%92%29 ← [Cl4Re\\qReCl4](2−) – percent encoding

And, I gotta wonder, are the input symbols that {{chem2}} accepts standardized so that consumers of the metadata will know what they mean when the metadata are decoded? If not then those symbols need to be replaced with the actual thing that they represent, don't they?

—Trappist the monk (talk) 12:09, 25 September 2021 (UTC)

Yeah, this is still a demo for illustration purposes. Anchor-encoding isn't optimal here (but was handy for the quick demo). We might switch to a more suitable encoding. Either case, the extractor would have to decode it back before further processing, otherwise we would get the overencoded results as illustrated by you above. The encoding would have to ensure that no spaces remain in the string. " would be a forbidden character as well. IIRC, the allowed charset for class names is (or was) limited in some HTML versions (would have to look this up), so we would have to make sure to not use other reserved characters as well.

(Also, I think, the scheme could be further improved if we would not only embed the desired metadata output (i.e. MeTaDaTa-OuTpUt:), but optionally also the (parameter) input (i.e. MeTaDaTa-InPuT:). This might allow the extractor not only to replace the complete output of a template by its metadata (as in the current {{chem2}} example) but allow metadata fragments to be inherited from internally called templates instead of having to handle everything monolithically on the level of the outer template (example: {{chem}}, which internally uses {{su}} - still thinking about the details...)

are the input symbols that {{chem2}} accepts standardized so that consumers of the metadata will know what they mean when the metadata are decoded? I guess, this very much depends on the template, so even if this would be a standard notation in this particular case (I don't know if it is), it probably won't be in the general case. However, this is still a demo with the main purpose to illustrate how easy it would be to enhance templates in general. In a proper implementation, {{chem2}} would probably not just forward its own input as metadata, but actually generate the metadata by processing the input (like it does for its normal output, but) in a form which would be text-only or use only very simple markup. What can be considered to be the best metadata very much depends on the purpose/function of the template. The advantage of this approach would be that the developers or users of the template probably know best what is the optimal text-only metadata that can be generated from the input (developers would program the template to generate the optimal metadata for the context the template is used in, and users would always be able to override it using the |metadata= parameter), whereas the generic HTML simplifier in CS1/CS2 has no knowledge on the context and semantics and can only simplify based on universal structural rules.

--Matthiaspaul (talk) 13:53, 25 September 2021 (UTC) (updated 09:33, 26 September 2021 (UTC))

I've meanwhile simplified the magic and changed the encoding from anchor-encoding (which was shorter and more human-readable, but also combined various different space characters into one type and therefore was not fully reversible) to a combination of text-decoding (to level the playing-field also for input containing HTML entities) and percent-encoding (for transparent transportation of the metadata, in particular to encode the invalid space and quote characters). HTML 4 seems to have had more restrictions on the character set used in class names (including the percent-sign which is used by percent-encoding), but they have gone with HTML5 (they are still valid for CSS, but we don't use this "MeTaDaTa:" dummy-class for this CSS purposes, so it doesn't affect us).

(BTW. mw.text.decode() seems to have a bug as it properly processes   but ignores  .)

--Matthiaspaul (talk) 12:10, 26 September 2021 (UTC)

Also not a general solution out of the box, but one that could be used to make template output metadata-safe:

We could add code to critical templates like {{chem}} oder {{chem2}} so that they issue their input in a HTML title= attribute. We could then use this instead of the actual HTML for metadata purposes (similar to what we do with math SVG and LaTeX extraction). Given that the HTML title= might be used by the template for other purposes already, and that it is also shown to users as tooltip (which might not be desirable if it contains stuff like "[{(\h{5}C5Me4)SiMe2(\h{1}NCMe3)}(PMe3)Sc(\m{2}H)]2"), I am using the title= attribute only for illustration purposes here and we might find another HTML attribute or establish a special "steganographic" notation where/how we could transparently hide those entries for possible extraction by CS1/CS2. Templates might even have a standardized optional parameter like |metadata= to override what the template would otherwise use for this. Templates enhanced this way could get a sticker like "CS1/CS2-compatible" or such. Sure, this would work only for those templates which have been enhanced this way, but all we would have to do now is to specify a standard for this and implement a generic extraction mechanism which would take over whenever CS1/CS2 finds this special HTML attribute/notation in a citation's title. Over the years more and more templates could be adapted accordingly.

--Matthiaspaul (talk) 12:19, 24 September 2021 (UTC)

To further illustrate this, this could be a span framing the normal template output of a template like {{chem2}} (following a similar idea as COinS, but for our internal purposes only):

<span class="MeTaDaTa:[{(\h{5}C5Me4)SiMe2(\h{1}NCMe3)}(PMe3)Sc(\m{2}H)]2">normal_template_output</span>

If our template metadata extractor would run into something like this (triggering on the "MeTaDaTa:" magic), it would replace the whole span including normal_template_output (and, if present, also the corresponding stripmarker) by what follows the MeTaDaTa: (which probably needs to be encoded in an actual implementation). For a template call like {{chem2|[{(\h{5}C5Me4)SiMe2(\h{1}NCMe3)}(PMe3)Sc(\m{2}H)]2}} this would result in [{(\h{5}C5Me4)SiMe2(\h{1}NCMe3)}(PMe3)Sc(\m{2}H)]2. Would the template be called like {{chem2|[{(\h{5}C5Me4)SiMe2(\h{1}NCMe3)}(PMe3)Sc(\m{2}H)]2|metadata=This is a text-only transcription of the chemical formula}} instead, it would result in This is a text-only transcription of the chemical formula. |metadata=off/none would disable the metadata (nothing would be following the "MeTaDaTa:" magic then). If the extractor does not find the triggering magic, or if the extracted data would be an empty string, it would proceed with the HTML simplification demoed above...

--Matthiaspaul (talk) 12:50, 24 September 2021 (UTC) (updated 09:33, 26 September 2021 (UTC))

This is how a CS1/CS2-compatibly modified {{frac}} template [8] could look like:

{{frac/sandbox|1|2|3}}

'"`UNIQ--templatestyles-00000179-QINU`"'<span class="frac MeTaDaTa::%E2%80%891%C2%A02%2F3" role="math">1<span class="sr-only">+</span><span class="num">2</span>&frasl;<span class="den">3</span></span>

Visual rendering: 1+2⁄3

Extractable metadata: " 1 2/3"

{{frac/sandbox|1|2|3|metadata=Custom-Metadata}}

'"`UNIQ--templatestyles-0000017E-QINU`"'<span class="frac MeTaDaTa::Custom-Metadata" role="math">1<span class="sr-only">+</span><span class="num">2</span>&frasl;<span class="den">3</span></span>

Visual rendering: 1+2⁄3

Extractable metadata: "Custom-Metadata"

{{frac/sandbox|1|2|3|metadata=off}}

'"`UNIQ--templatestyles-00000182-QINU`"'<span class="frac MeTaDaTa::" role="math">1<span class="sr-only">+</span><span class="num">2</span>&frasl;<span class="den">3</span></span>

Visual rendering: 1+2⁄3

Extractable metadata: "" so it will be ignored

Same for {{sfrac}} [9]:

{{sfrac/sandbox|1|2|3}}

'"`UNIQ--templatestyles-00000186-QINU`"'<span class="sfrac">&NoBreak;1<span class="sr-only">+</span><span class="tion"><span class="num">2</span><span class="sr-only">/</span><span class="den">3</span></span>&NoBreak;</span>

Visual rendering: ⁠1+2/3⁠

Extractable metadata: " 1 2/3"

{{sfrac/sandbox|1|2|3|metadata=Custom-Metadata}}

'"`UNIQ--templatestyles-0000018A-QINU`"'<span class="sfrac">&NoBreak;1<span class="sr-only">+</span><span class="tion"><span class="num">2</span><span class="sr-only">/</span><span class="den">3</span></span>&NoBreak;</span>

Visual rendering: ⁠1+2/3⁠

Extractable metadata: "Custom-Metadata"

{{sfrac/sandbox|1|2|3|metadata=off}}

'"`UNIQ--templatestyles-0000018E-QINU`"'<span class="sfrac">&NoBreak;1<span class="sr-only">+</span><span class="tion"><span class="num">2</span><span class="sr-only">/</span><span class="den">3</span></span>&NoBreak;</span>

Visual rendering: ⁠1+2/3⁠

Extractable metadata: "" so it will be ignored

Similar for {{chem2}} [10]:

'"`UNIQ--templatestyles-00000191-QINU`"'<span class="chemf nowrap">&#91;{(η<sup>5</sup>-C<sub class="template-chem2-sub">5</sub>Me<sub class="template-chem2-sub">4</sub>)SiMe<sub class="template-chem2-sub">2</sub>(η<sup>1</sup>-NCMe<sub class="template-chem2-sub">3</sub>)}(PMe<sub class="template-chem2-sub">3</sub>)Sc(μ<sub>2</sub>-H)]<sub class="template-chem2-sub">2</sub></span>

Visual rendering: [{(η⁵-C₅Me₄)SiMe₂(η¹-NCMe₃)}(PMe₃)Sc(μ₂-H)]₂

Extractable metadata: "[{(\h{5}C5Me4)SiMe2(\h{1}NCMe3)}(PMe3)Sc(\m{2}H)]2" (could be further improved by improving the metadata generated in the {{chem2}} template)

And for {{nowrap}} [11].

--Matthiaspaul (talk) 22:40, 24 September 2021 (UTC) (updated 11:45, 26 September 2021 (UTC))

I don't know that there is sufficient support to proceed. Editor David Eppstein objects to the \(...\) markup so that may go away. Removing certain html markup may or may not be adequate; I don't know, I'm not a chemist so I don't know if the resulting output to the metadata would be at all useful.

—Trappist the monk (talk) 14:05, 23 September 2021 (UTC)

This appears to be the thread of misunderstandings... I didn't understood David as if he would object the \(...\) at all, quite the contrary. He was concerned that issueing a visible error message would upset people, but that was before we discussed alternatives.

Regarding HTML cleanup, I'm no chemist either, but even if it might not be good enough to allow for really nasty things such as {{chem2}}, it would certainly be an improvement for many of the simple cases like the example:

Theory of free, spin-<span class="frac" role="math"><span class="num">1</span>⁄<span class="den">2</span></span> tachyons

→ Theory of free, spin-1⁄2 tachyons

--Matthiaspaul (talk) 16:11, 23 September 2021 (UTC)

Perhaps we should just change {{frac}} to use <sup> and <sub> instead of <span>s? The sup/sub can be styled for on-Wiki use, and stripped of class attributes that are meaningless to COinS consumers.  — sbb (talk) 01:26, 24 September 2021 (UTC)

Format citations differently than body text

I don't see a contradiction between rendering a title as it appears in the work, and avoiding Unicode. The two are unrelated. Exact rendering in citations does not mean exactitude in presentation items like typefaces. It does include items with semantic significance. A formula will be recognized as such regardless of the typeface used, including the easy-to-read sans-serif typefaces traditionally used in citations. There is an issue with items such as subscript/superscript readability, but I believe it is minor, and there are ways around it.

The main thing is this: I would not use WP:MOS or any other Wikipedia wikitext formatting guideline as yardsticks. Citations are not wikitext, and should be formatted according to their own requirements. Whether the cited material is a science item or not makes no difference. 64.18.9.208 (talk) 00:04, 19 September 2021 (UTC)

Though the above examples do render in different typefaces, that's beside the point. Behind the scenes they use different representations. Though "₂" and "₂" might look like the same number in different fonts, in fact they are different Unicode characters, and correctly interpreting the second one requires parsing HTML.

It's fine if there are special cases like coping with COinS, but suspending all MOS rules when it comes to citations would make the encyclopedia look quite unprofessional, increase skepticism, and make it a little harder to read. It would have far-reaching implications, and I don't think that's within the scope of what's being proposed. -- Beland (talk) 03:29, 20 September 2021 (UTC)

Wikipedia is un-professional, in both meanings of the term. First, as a general-purpose encyclopedia for non-expert readers. Secondly, as a project whose majority of content is unverified and therefore, drivel. As was remarked in another discussion here, the so-called "good articles" are a miniscule minority. So this is a project that unflinchingly publishes information that fails to pass its own mark. Which brings up the question of whether any "good article" criteria such a project decides upon can be trusted.

With such basis, it is imperative imo that citations stand apart, as the only way of turning the garbage heap into reliably usable information. They should not at all resemble wikitext body. They should stand out as its proof. Keeping in mind the target audience, they should be clear, unadorned, and easy to read, so that they can be easily found. It doesn't matter to a reader exactly how a subscript is rendered, only that it is. Use any easy-to-understand rendering, even if it is literal ("subscript 2"). Experts may cringe, but Wikipedia's audience will probably thank you.

Users (editors) I assume have similar expectations of the developers, but that would be a separate comment. 66.108.237.246 (talk) 13:05, 20 September 2021 (UTC)

OK, I guess we just have different goals, then. I'm working toward a professional-looking, credible, well-referenced, and verified encyclopedia. Writing something like "subscript 2" not only looks horrible, it's harder to understand (especially for students) than simply having a ₂. Doing a search in a journal article database on "subscript 2" will almost certainly give bad results. -- Beland (talk) 00:47, 23 September 2021 (UTC)

The use of the literal "subscript 2" was offered only as an example of a non-expert reader's pov, and not as a concrete suggestion. Obviously the proper way would be the title verbatim, semantically, and this is a discussion that should end with the technical minutiae, not start with them. To again point out the obvious, no student should be using Wikipedia for anything related to their work. It is normally (in the statistical sense) unreliable, improperly or not all referenced, badly edited, and of dubious neutrality. And this is just the reader-facing pages. Any work outside of fixing these is just dressing up garbage in a pretty dress. May I suggest a beginning? Remove the "good articles" category and project. Assuming for the moment that the present "good article" criteria are valid, "good articles" are such a dismal minority, it is embarrassing. Instead add a warning to all other articles. Because the normal, obvious expectation of an encyclopedia is that it publishes good articles. Making clear (on a prominent and continuing basis) the fact that this is currently an unprofessional project is the greatest possible service to readers. And it is going to put everyone interested in fixing it in the right frame of mind. 64.18.9.196 (talk) 02:27, 23 September 2021 (UTC)

Moving toward a resolution

Are there any objections or comments on doing the following to get the ball rolling:

• Use <sub>...</sub> and <sup>...</sup> instead of {{chem}} and {{chem2}} for chemistry formulas in citations.
• Use {{citefrac}} instead of {{frac}} or {{sfrac}} for vulgar fractions in citations.

?

I don't often see more complicated math in citations, but would we want to make a {{citemath}} that uses <math>...</math> for now and can be switched over to \(...\) when that change is ready to be deployed? (And then easily changed again later if handling of TeX-like math formulas needs to change.) -- Beland (talk) 01:19, 23 September 2021 (UTC)

Folgen Sie WP:MOS, if COinS chokes, COinS chokes. Headbomb {t · c · p · b} 02:32, 23 September 2021 (UTC)

Well, the question is what the MOS should recommend. It seems like these techniques would allow us to keep a consistent style with body text without changing the MOS recommendation for that, and without causing COinS to choke. -- Beland (talk) 00:36, 24 September 2021 (UTC)

I might be missing the point, but if we want to make as little compromises regarding COinS-compatibility as possible, I don't see how something like {{citefrac}} would actually improve the situation in general (besides that it is nice to know if a template is CS1/CS2-safe or not). As far as I understood you, this is meant to be a "lightweight" version for vulgar fractions to be used in citations. But while being lightweight it may produce more COinS-compatible output (which is good), it will also produce less nice-looking titles in citations (which is not so good)...

IMO it is (more) desirable (because more flexible and universal) to try and clean up the HTML automatically, as demonstrated above. This won't work in all possible cases, but the results shown by Trappist above are already quite good IMO, and with a few more tweaks could become quite useable for our purposes. This and the \( ... \) trick for math are IMO a significant improvement over the current state of affairs. For those cases where the processing would not be desirable and we would want to pass the title to the metadata unchanged, we have our ((accept-this-as-it-is)) markup. For those cases, where we have both, a nice-looking title for local display and a (not so nice looking) alternative title used in external databases we want to match exactly to improve searches, we would have |descriptive-title= (which would also be useful for many other purposes, as mentioned further above). With this in place, we may need only a few general recommendations how to provide titles instead of having to address this explicitly in the MOS.

However, given that some significant developer efforts have been trashed by the "mob" recently, and thereby precious developer resources burnt, it would be great if those who agree with these proposals could actually indicate this instead of just remaining silent (as it happens to be the case here so often). This would help to convince the developers that it is worth to devote their volunteering time on these and other things.

--Matthiaspaul (talk) 11:41, 24 September 2021 (UTC)

@Matthiaspaul: Well, if some day the code is implemented to make regular {{frac}} COinS-friendly, we could always just drop the exception from the MOS and redirect {{citefrac}} to it or bot-substitute. If someone wants to say, "hey I'll have that code done in the next couple weeks", I'm happy to wait. If not, then while we're waiting for "some day" it would be good to make progress cleaning up on all the existing Unicode superscripts and subscripts in citations that no one seems to want. You did mention this solution produces "less nice-looking titles". I'm trying to make a lightweight solution that looks exactly the same as {{frac}}. Could you explain what differences you see, maybe with an example? Maybe there's a lightweight fix. -- Beland (talk) 18:20, 24 September 2021 (UTC)

Let's have a look at what Trappist's demo further above can do already:

Example:

{{frac|1|2|3}}

produces this non-sensible code in the citation's |title=, prompting the current implementation to throw a stripmarker error message:

'"`UNIQ--templatestyles-00000196-QINU`"'<span class="frac">1<span class="sr-only">+</span><span class="num">2</span>&frasl;<span class="den">3</span></span>

which would be rendered by a browser as part of a citation in Wikipedia as:

1+2⁄3

The proposed generic "HTML simplifier" would derive the following code for metadata purposes, which could be passed on as COinS-metadata:

1+2⁄3

or with a bit more tweaking:

<span role="math">1+2⁄3</span>

or even:

1+2⁄3

This is not perfect for human consumption but much better than the original code already. A user would be able to make sense out of it (although it may not necessarily match the work's title used in external databases, for which we would need |descriptive-title=). Assuming the COinS consuming entity would be able to process HTML, a HTML engine at their end would make this out of the simplified HTML:

1+2⁄3

Let's assume the {{frac}} template would have been made "CS1/CS2-compatible" following my proposed "template internal metadata" demo above, the metadata extractor could, for example, get this even more text-only result:

 1 2/3

for which no HTML engine would be needed at the receiver's end.

Regarding existing Unicode superscripts and subscripts, while I agree that the HTML sub- and superscripts look nicer if used in formulas and are generally to be preferred, in non-scientific articles an occasionally interspersed Unicode super- or subscript character in citation titles might not be a bad idea at all. At least they are COinS-safe out of the box and neither require a HTML engine at the receiver's end nor a TeX-savy human to be decoded. I would not use them in technical articles, but also would not want to ban them in non-technical articles. So, it all depends on the context IMO. What does this mean in regard to MOS or more-citation related guidelines? We could offer some generally recommended best practises there, but we should not rule out any of the possible formats in general. And what does that mean in regard to CS1/CS2? We will have to cope with whatever editors throw at us, therefore we probably need all, special \( ... \) markup, HTML simplifier, template internal metadata, and |descriptive-title= to cope with all possible cases optimally.

Regarding "hey I'll have that code done in the next couple weeks", the next CS1/CS2 update isn't scheduled yet but I guess it could be in mid-October.

--Matthiaspaul (talk) 22:04, 24 September 2021 (UTC)

To reiterate what was stated a couple of times above, this is looked at from the wrong end. The only resolution to this is the one that maximizes the utility of the citation to the average reader. Experts, practitioners and students in every academic field have vast resources available to them, resources that are properly vetted. The average person would mostly or only have Wikipedia, but here's the tendency to make this one resource too some sort of experts' preserve (albeit an unvetted one). Why not start from what the reader sees? Make that as clear and faithful to the original as possible. Then decide on the tools/guidance that editors should have in order to implement the reader requirements. Keep the guidance straightforward and tight. This is only a set of special cases of a single parameter in a sprawling module collection. Largesse in editor choices cannot be afforded in everything. Editors will have to learn to throw what the guidance states. Once the tools and guidance for editors is decided, the module could theoretically be developed in a hopefully carefully designed, rational, bugfeee way. But all development is theoretical. Because there are unresolved issues regarding any CS1/CS2 development. 68.173.76.118 (talk) 00:07, 25 September 2021 (UTC)

suppress display of "(report)" in cite report

The documentation for Cite report omits mention of option to suppress the display of not-helpful-IMO "(report)" in the reference created. Include "|type=none" to suppress that. I use this for National Register of Historic Places document refs. --Doncram (talk) 01:47, 13 September 2021 (UTC)

@Doncram:  Added to Template:Cite report/doc#Title. GoingBatty (talk) 02:20, 13 September 2021 (UTC)

metadata and accept-this-as-written markup

Discussion at Help talk:Citation Style 1 § HTML markup caused me to notice that the accept-this-as-written markup is preserved when |title= is added to the metadata. I have fixed that:

{{cite book |title=((Title))}}

Title.

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

{{cite book/new |title=((Title))}}

Title.

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

I have not looked into the other places where accept-this-as-written markup may be used.

—Trappist the monk (talk) 23:18, 15 September 2021 (UTC)

It's good that you mentioned this because I am sure I checked this in the past and your comment made me recheck it again now. Turns out, we have the same problem with |doi=, |issn=, |eissn=, |pmid= and |volume=.

--Matthiaspaul (talk) 17:37, 22 September 2021 (UTC)

|volume= fixed:

{{cite journal/new |title=Title |journal=Journal |volume=((12345))}}

"Title". Journal. 12345.

'"`UNIQ--templatestyles-000001AB-QINU`"'<cite class="citation journal cs1 cs1-prop-long-vol">"Title". ''Journal''. 12345.</cite><span title="ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Ajournal&rft.genre=article&rft.jtitle=Journal&rft.atitle=Title&rft.volume=%28%2812345%29%29&rfr_id=info%3Asid%2Fen.wikipedia.org%3AHelp+talk%3ACitation+Style+1" class="Z3988"></span>

Accept-as-written markup is documented for these identifiers: |doi=, |eissn=, |isbn=, |issn=, and |sbn= – the |sbn= value, even when valid, is not made part of the citation's metadata. For all other identifiers, invalid values are not made part of the citation's metadata even when wrapped with accept-as-written markup. A simple fix ensures that all valid identifier values wrapped with accept-as-written markup, and invalid |doi=, |eissn=, |isbn=, and |issn= values that are wrapped with accept-as-written markup do not include the accept-as-written markup in the citation's metadata. I have applied that fix:

{{cite journal/new |title=Title |journal=Journal |doi=((12345))}}

"Title". Journal. doi:12345.{{cite journal}}: CS1 maint: ignored DOI errors (link)

'"`UNIQ--templatestyles-000001AF-QINU`"'<cite class="citation journal cs1">"Title". ''Journal''. [[doi (identifier)|doi]]:[https://doi.org/12345 12345].</cite><span title="ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Ajournal&rft.genre=article&rft.jtitle=Journal&rft.atitle=Title&rft_id=info%3Adoi%2F12345&rfr_id=info%3Asid%2Fen.wikipedia.org%3AHelp+talk%3ACitation+Style+1" class="Z3988"></span><span class="cs1-maint citation-comment"><code class="cs1-code">{{[[Template:cite journal|cite journal]]}}</code>: CS1 maint: ignored DOI errors ([[:Category:CS1 maint: ignored DOI errors|link]])</span>

{{cite journal/new |title=Title |journal=Journal |eissn=((12345))}}

"Title". Journal. eISSN 12345.{{cite journal}}: CS1 maint: ignored ISSN errors (link)

'"`UNIQ--templatestyles-000001B3-QINU`"'<cite class="citation journal cs1">"Title". ''Journal''. [[eISSN (identifier)|eISSN]]&nbsp;[https://search.worldcat.org/issn/12345 12345].</cite><span title="ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Ajournal&rft.genre=article&rft.jtitle=Journal&rft.atitle=Title&rft.eissn=12345&rfr_id=info%3Asid%2Fen.wikipedia.org%3AHelp+talk%3ACitation+Style+1" class="Z3988"></span><span class="cs1-maint citation-comment"><code class="cs1-code">{{[[Template:cite journal|cite journal]]}}</code>: CS1 maint: ignored ISSN errors ([[:Category:CS1 maint: ignored ISSN errors|link]])</span>

{{cite journal/new |title=Title |journal=Journal |isbn=((12345))}}

"Title". Journal. ISBN 12345.{{cite journal}}: CS1 maint: ignored ISBN errors (link)

'"`UNIQ--templatestyles-000001B7-QINU`"'<cite class="citation journal cs1">"Title". ''Journal''. [[ISBN (identifier)|ISBN]]&nbsp;[[Special:BookSources/12345|<bdi>12345</bdi>]].</cite><span title="ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Ajournal&rft.genre=article&rft.jtitle=Journal&rft.atitle=Title&rft.isbn=12345&rfr_id=info%3Asid%2Fen.wikipedia.org%3AHelp+talk%3ACitation+Style+1" class="Z3988"></span><span class="cs1-maint citation-comment"><code class="cs1-code">{{[[Template:cite journal|cite journal]]}}</code>: CS1 maint: ignored ISBN errors ([[:Category:CS1 maint: ignored ISBN errors|link]])</span>

{{cite journal/new |title=Title |journal=Journal |issn=((12345))}}

"Title". Journal. ISSN 12345.{{cite journal}}: CS1 maint: ignored ISSN errors (link)

'"`UNIQ--templatestyles-000001BB-QINU`"'<cite class="citation journal cs1">"Title". ''Journal''. [[ISSN (identifier)|ISSN]]&nbsp;[https://search.worldcat.org/issn/12345 12345].</cite><span title="ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Ajournal&rft.genre=article&rft.jtitle=Journal&rft.atitle=Title&rft.issn=12345&rfr_id=info%3Asid%2Fen.wikipedia.org%3AHelp+talk%3ACitation+Style+1" class="Z3988"></span><span class="cs1-maint citation-comment"><code class="cs1-code">{{[[Template:cite journal|cite journal]]}}</code>: CS1 maint: ignored ISSN errors ([[:Category:CS1 maint: ignored ISSN errors|link]])</span>

—Trappist the monk (talk) 23:04, 24 September 2021 (UTC)

Dates were moved?

Maybe my memory is failing me, but has CS1 always output dates like this:

McClure, Tess (16 September 2021). "Aukus submarines banned from New Zealand as pact exposes divide with western allies". The Guardian. Retrieved 16 September 2021. (source)

I never remembered the dates being in parenthese like that. Is that new? –MJL ‐Talk‐^☖ 18:06, 16 September 2021 (UTC)

This has always how it's been unless you have none of the authorship parameters: "Main Page". Wikipedia. 2021., and this case has an outstanding request for change since half a decade ago that is non-trivial to implement. Izno (talk) 18:45, 16 September 2021 (UTC)

hyphen_to_dash() moved

Because of a conversation at Template talk:Sfn § Add automatic endash for page number range?, I have moved hyphen_to_dash() from Module:Citation/CS1/sandbox to Module:Citation/CS1/Utilities/sandbox. The move allows Module:Footnotes/sandbox to have access to all of the necessary functionality without unnecessary code duplication.

—Trappist the monk (talk) 20:12, 16 September 2021 (UTC)

Umm, no. It is not a good idea to be adding stuff to the cs1|2 module suite that is not used by cs1|2. It is the responsibility of {{r}}, {{rp}}, and {{ran}} to use the output from hyphen_to_dash() as-it-is, to modify that output as necessary to suit their needs, or do what needs doing on their own. The cs1|2 module suite is not all things to all templates. I am going to revert.

—Trappist the monk (talk) 18:55, 25 September 2021 (UTC)

Well, then we must have misunderstood each other, because that's what I was talking about in regard to the functional differences between the implementations at Template_talk:Sfn#Add_automatic_endash_for_page_number_range?. ;-)

Unfortunately, if we don't want that extra parameter in CS1 (since we don't need it in CS1), we can't merge the two functions because {{r}} and friends depend on this. But no problem, the current merge still had a bug anyway which I was in the process of fixing.

--Matthiaspaul (talk) 20:18, 25 September 2021 (UTC)

Perhaps, perhaps not. I was thinking that something like this in Module:String2 would do what you want:

function p.hyphen2dash (frame)
	local utilities = require ('Module:Citation/CS1/Utilities/sandbox');		-- import functions from cs1|2
	local str, accept = utilities.has_accept_as_written (frame.args[1]);		-- strip accept-as-written markup if present
	local spacing = frame.args[2];

	if str and not accept then													-- string not wrapped in accept-as-written markup
		str = utilities.hyphen_to_dash (str);									-- convert hyphens to dashes
		if spacing then															-- when set
			str = str:gsub (', ', ',' .. spacing):gsub ('; ', ';' .. spacing);	-- override default spacing
		end
	end
	return str;																	-- and done
end

—Trappist the monk (talk) 21:51, 25 September 2021 (UTC)

Volume/Issue not compatible with many journals

I don't know how to describe many journals, especially non-English, which don't identify "volume", but are usually marked as issue/year and/or issue from beginning. "Issue" field displays at the end and des not accept any other text. Pibwl ←« 12:34, 20 September 2021 (UTC)

Could you provide an example. 66.108.237.246 (talk) 12:38, 20 September 2021 (UTC)

You can omit |volume=. It is not required. – Jonesey95 (talk) 13:24, 20 September 2021 (UTC)

Okay, after some research I know, that what I really meant is a magazine, not journal, with template:Cite magazine. And indeed, "issue" field works well here. However, it would have been much easier, if "issue" and "volume" fields were included in "Most commonly used parameters" section on template:Cite magazine page. Thanks. Pibwl ←« 15:09, 20 September 2021 (UTC)

Go forth and edit the documentation. Izno (talk) 17:06, 20 September 2021 (UTC)

Place holder title "Subscribe to read..."

Some of the placeholder titles for websites that have content behind a paywall/subscription have their subscription advertisement (e.g. "Subscribe to read | Financial Times") as the placeholder title. Tanaya001 (talk) 13:04, 21 September 2021 (UTC)

At least this one says it was added with reFill 2. Kanguole 13:12, 21 September 2021 (UTC)

Not really a cs1|2 issue because cs1|2 can only render what it is given. If editors choose to use that hopelessly broken, unmaintained tool and then don't cleanup after it leaves a mess, someone else will have to do the cleanup. cs1|2 does aid in the cleanup by emitting an error message when it detects certain bogus article titles:

{{Cite web|url=https://www.ft.com/content/0029e6e2-7344-11ea-95fe-fcd274e920ca|title=Subscribe to read | Financial Times|website=www.ft.com}}

"Subscribe to read | Financial Times". www.ft.com. {{cite web}}: Cite uses generic title (help)

Beyond that, little can be done by cs1|2.

—Trappist the monk (talk) 13:38, 21 September 2021 (UTC)

Proposal: Use the document icon instead of the external link icon for documents

Following up from this VPR discussion, I'd like to propose that we change the external link icon for CS1 citations in which |format= is set to a document file type such as .xls so that it uses the document icon () rather than the external link icon (). This will give a more appropriate signal to readers that clicking on the link will download a file for them, rather than taking them to a website page.

In technical terms, I'm told by SD0001 that we would do this by modifying Module:Citation/CS1/styles.css similar to what it already does with links to Wikisource. Thoughts? {{u|Sdkb}} ^talk 04:11, 22 September 2021 (UTC)

Not a good idea. We should train users so they understand that clicking anything with the external link icon is external and a potential security hazard (it might not be a hazard now, but could be in a couple of years when scammers get hold of the website). A friendly document icon tells the unwary that this link is blessed by Wikipedia. Johnuniq (talk) 05:27, 22 September 2021 (UTC)

We already have a separate PDF icon for PDFs, among others; this isn't really any different than that. {{u|Sdkb}} ^talk 07:09, 22 September 2021 (UTC)

Clicking on an online document will not necessarily explicitly download it. As is often the case with the useless pdf icon (I wonder if the majority of Wikipedia readers know what it signifies), browsers may use an embedded pdf viewer. Just like every other webpage, that item will be downloaded in local cache by default >90% of the time. The templates use the format parameter where the literal extension name with a wikilink to an explanation can be entered. Without any need for fancy icons that may break in a future MW iteration, or CSS workarounds. Instead of interminable ideas about minor presentation details, may I suggest, with all respect, to work towards adding proper citations to the vast majority of articles that need them. 64.18.9.196 (talk) 12:30, 22 September 2021 (UTC)

It's difficult to indicate two independent properties in one symbol.

I, too, consider it important to tell users they are about to click on an external link for security/privacy reasons, but I also think that it is useful for them to know if the external link content typically can be processed with built-in browser capabilities or needs some plug-in or external program to be viewed, or if it is text, graphical, audible, animated, as, depending on the environment the user is in, it may be technically difficult or inappropriate to consume (i.e. when loading an image using a text browser, or when loading a sound file on a computer without sound, or where sound may disturb other people).

It might be possible to superimpose the "external link" and various types of "document" icons to indicate some of these properties at the same time.

Alternatively, we could override MW and stop showing the PDF icon for external PDF files and consistenty show the external link icon for any kind of external links instead. The file format can be specified by |format= which adds some "(format)" text. CS1/CS2 even has some code to auto-detect PDFs based on the file-extension - we could add a few more common file types (per above criteria) to that list.

--Matthiaspaul (talk) 19:50, 23 September 2021 (UTC)

cite news documentation

Should there be some text added about the general lack of need for the use of editors for newspapers and such. In many cases, the editors probably had nothing to with the article. AManWithNoPlan (talk) 16:00, 24 September 2021 (UTC)

No, if authors and/or editors are specified, they belong into the citation, no exceptions. --Matthiaspaul (talk) 16:36, 24 September 2021 (UTC)

Newspaper/newsagency (and less frequently) magazine articles may not carry a byline, and also there may be cases of newspapers/magazines with the same name. There is some merit in adding the editor, to find quickly the right news source, especially when the publisher/location is unknown/absent. Another consideration would be when articles are reprinted under different editors (in the same or another news source). In the unlikely case of differences in original vs. reprint, the respective editor should be indicated. Also, all reference databases for news sources include the editor and sometimes sub-index the works by that field, which means the source could theoretically be found quicker by adding the editor info. 65.88.88.91 (talk) 16:40, 24 September 2021 (UTC)

I am thinking more like the newspaper the new york times. AManWithNoPlan (talk) 16:48, 24 September 2021 (UTC)

I would not add the editor in such cases unless of course the item is signed by her/him or perhaps, in the case of citations of editorials. Afaik, the NYT has an "editorial board", so maybe the correct way to depict this would be to use |department=editorial. 65.88.88.91 (talk) 16:56, 24 September 2021 (UTC)

Matthiaspaul, are you saying that every reference cited to The Guardian needs to include the name of the editor of The Guardian? -- Alarics (talk) 20:55, 24 September 2021 (UTC)

If the editor is actually specified as "The Guardian" that would be appropriate, but in most such cases, staff writers are not mentioned at all, and "The Guardian" would be just the name of the news outlet. For staff writers we typically write something like |editor=<!-- staff writer, no byline --> (although I personally don't like this very much (for its bad machine-readability) and instead propose to standardize the case by introducing a special keyword like |editor=staff for it, which could be (actively) ignored by the template for now, but could also be evaluated if we would happen to run into a use case for this in the future - without |editor=, we never know if no editor was specified in the publication or if the author providing the citation was just too lazy to add it.) --Matthiaspaul (talk) 21:26, 24 September 2021 (UTC)

There are enough valid use cases for adding editors to periodical citations that I definitely wouldn't want this to be an error, even though it's usually not the right thing to do. One that comes to mind is when the periodical publishes a special issue or special section (which you can name using the |department= parameter) and you want to cite both an individual title and author within that section or issue, and the editors of the whole section or issue. —David Eppstein (talk) 08:00, 25 September 2021 (UTC)

[Template:Cite book] hyperlink for second editor

Is there no way to add a WP hyperlink for a second editor at Template:Cite book? Veverve (talk) 05:44, 25 September 2021 (UTC)

Of course there is. |editor2-link=. You should be splitting out your editors into separate parameters (|editor2-last= and |editor2-first=, or at least |editor2=) to make this work. —David Eppstein (talk) 07:55, 25 September 2021 (UTC)

Errata problem

Recent edits at Fea's tree rat and Common remora have produced "Lua error in Module:Cite_iucn at line 180: attempt to concatenate a nil value". That is seen by previewing the following.

{{cite iucn
|author=Smith
|title=Example
|errata=2017
|volume=2015
|page=1
|doi=10.2305/IUCN.UK.2015
}}

Johnuniq (talk) 10:00, 25 September 2021 (UTC)

Thanks. Fixed.

—Trappist the monk (talk) 11:07, 25 September 2021 (UTC)

From Rock tapaculo, {{cite iucn|year=2016}} gives "Lua error in Module:Cite_iucn at line 124: attempt to index field 'title' (a nil value)." Johnuniq (talk) 07:05, 26 September 2021 (UTC)

Thanks. Fixed.

—Trappist the monk (talk) 11:39, 26 September 2021 (UTC)

Page, pages, total pages, page range

I generally use the {{sfn}} citation style, with the sources in an alphabetical list at the end of the article. This lets me cite different pages in each source at different places in the article. In the {{sfn}} I give the page or pages being cited, e.g.

{{sfn|Smith|2001|p=19}}

{{sfn|Jones|2002|pp=12–13}}

In the source definition, I would like to give the total number of pages, and in the case of a journal article, the page range, e.g.

*{{citation |title=Precise citations |last=Smith |year=2001 |total-pages=248}}

*{{citation |title=Recent citation style changes |last=Jones |year=2002 |journal=Modern Pedantics |page-range=9–39 |total-pages=31}}

This would display something like

• Smith (2001), Precise citations (248 pages)
• Jones (2002), "Recent citation style changes", Modern Pedantics, pp.9–39 (31 pages)

Any problem with introducing this? It must have been discussed before. Aymatth2 (talk) 13:19, 25 September 2021 (UTC)

Add that information after the citation template if you must, as you have done above. It is not a typical or encouraged practice in the English Wikipedia, even though it appears to be common for other languages. Also, you don't need "31 pages" when the complete page range is already listed. – Jonesey95 (talk) 14:26, 25 September 2021 (UTC)

(edit-conflict) It has been discussed before. There are users who think that the total page information does not belong into a citation, but there are also users who requested it.

In fact, it is rarely given in citations, although I have seen examples where it was actually given. Above you give the example of a bibliography, this is another example where the total number of pages is actually quite common to be given.

Personally, I always provide the information when I have it available from a reliable source (the publication in front of me, not some Amazon or Google books listings as they are very often wrong), because I actually find this information quite useful myself when I find it in a reference. It helps to get a grip on if the publication is substantial enough to be worth the trouble of getting a copy in general, and it allows to quickly verify the (often inaccurate) page range info and estimate copying and postage costs when obtaining a work from a library.

Since CS1 does not have a parameter for this yet, so far I add the information following the citation in parentheses (like (xi+425 pages)), just like you do, but I would prefer to have a dedicated |total-pages= parameter for this, because this would ensure a consistent format instead of each editor having to invent his own nomenclature. It would be machine-readable, thereby we would also help to correct the many incorrect total-page info entries in the wild. There even is a COinS entry for this (&rft.tpages), also indicating that this is sometimes useful info to have. Wikidata has d:Property:P1104 for this and {{cite Q}} is already prepared to support this once CS1/CS2 would add support for it. Some citation templates in other language-entities of Wikipedia have a parameter for this as well.

--Matthiaspaul (talk) 14:31, 25 September 2021 (UTC)

The French w:fr:Modèle:Ouvrage has |passage= and |pages totales=. I suppose technically there is a difference between a citation, where we say "this is where this information comes from" and a bibliography entry, where we say "here is what we know about this source." The citation could be short {{sfn}}, giving the page and pointing to the bibliography entry, which is the style I prefer. Giving both page range and total pages is redundant, but that is what JSTOR does, e.g. [12]. Aymatth2 (talk) 16:22, 25 September 2021 (UTC)

The JSTOR approach maybe a hold-over from older days, where such approaches would be used in articles that did not have continuous pagination, and the ToC was not useful in inferring the page range of an article. The actual page range in a biblio entry may not have been an unbroken range at all, just the article's first and last pages. The page count would be useful in showing the actual number of pages the article occupied, since the ToC would not be able to show it. In books, the total pages are shown in bibliographic/reference databases, but this is for reasons other than citing sources. Even the most used trade references (Nielsen's Bookdata, Bowker's Books In Print) in my experience do not show the total pages (or bytes, or running times) unless you drill down into a record's "Detail View". 65.88.88.126 (talk) 16:53, 25 September 2021 (UTC)

So a 4-page article could be spread over 6 pages by full-page ads. Simpler maybe to show pp.7–12 (4 pages) than the more accurate pp.7,9–10,12 (4 pages). Aymatth2 (talk) 20:51, 25 September 2021 (UTC)

For another example, the German citation template de:Template:Literatur has |Umfang= for this.

You are right, there is a difference between a citation and a bibliography entry, but CS1/CS2 templates are intended and designed to be used for both purposes.

--Matthiaspaul (talk) 17:10, 25 September 2021 (UTC)

The main argument for not adding |total-pages and |page-range parameters is it would make the template documentation even longer to support information most editors would not bother to provide. The reasons for adding them are that it ensures consistent formatting and supports greater mechanization in generating or checking bibliography entries. Aymatth2 (talk) 20:51, 25 September 2021 (UTC)

The total number of pages is irrelevant. This has been brought up several times before, see the archives of this page. --Redrose64 🌹 (talk) 21:35, 25 September 2021 (UTC)

@Redrose64: A citation identifies the source, and as you say the total number of pages in the source does not help with that. But as Matthiaspaul points out, CS1/CS2 templates are intended and designed to be used for bibliography entries as well as citations. In Konstantine Lortkipanidze#Publications it is reasonable to list the number of pages in the subject's works. The template renders "|pages=303" as "p. 303", which does not look like a page count. (303 pages) would be more obvious. In Konstantine Lortkipanidze#Sources there is perhaps less value in giving the page count, but there seems no reason to omit the information if available. Aymatth2 (talk) 00:36, 26 September 2021 (UTC)

p. 303 is obvious, it's a single page. p. 303-310 is equally clear as a range of pages. It's a red herring to say 303-310 might only be 3 pages interspersed with adverts as the point of the template in either a citation or a bibliography is to identify, for the reader, where to find the information. It is not to comment, directly or by inference, on how voluminous the author's work is. Nthep (talk) 06:47, 26 September 2021 (UTC)

The purpose of a bibliography entry is also to identify the source, and the total number of pages is not relevant to that. A list of an author's works is a special case, and I would argue that it does not justify adding a parameter that should not be used elsewhere. There is always the option of adding text after the template. Kanguole 08:51, 26 September 2021 (UTC)

Wikipedia probably contains several hundred thousand lists of authors' works. A bibliography in a book or scholarly article often gives the total number of pages. I suppose a minimalist would say all that is needed is page number and DOI, while a maximalist would say we should describe the source as fully as possible. It seems to be more a question of taste than of principle. Aymatth2 (talk) 12:35, 26 September 2021 (UTC)

I dispute the second claim. The standard style guides (Chicago, APA, MLA) are fairly consistent on what information to include, and none of them recommend the total number of pages. Kanguole 12:47, 26 September 2021 (UTC)

I was more thinking of a bibliography holding a list of an authors works. When citing periodical articles the cite would typically give author+page, and the bibliography would give the page range for the article. We can do that with {{sfn}}. But if we are combining the cite and source definition as with <ref>{{citation...}}</ref> at present we cannot give both the page and page range. Aymatth2 (talk) 13:26, 26 September 2021 (UTC)

Citation tool for Google Books - Server Error

http://reftag.appspot.com/ does not seem to be working? Chesdovi (talk) 13:41, 26 September 2021 (UTC)