Help talk:Citation Style 1

Citation templates

... in conception

... and in reality

Guidance about indexing by first name?

Is there any guidance about how to handle instances where authors should be indexed by first rather than last name? E.g. Chinese names where family name comes first, or Thai names where given name (which comes first) is the polite term of address? For example, should I call a Thai given name "last=" so the correct name comes first, as you would see in an index? Calliopejen1 (talk) 17:00, 17 September 2020 (UTC)

If you are uncomfortable using first/last in such cases, you may use |given= and |surname=. --Izno (talk) 17:50, 17 September 2020 (UTC)

What do you mean by indexed?

Whatever name you give |last= or |surname= will appear first in the rendered citation. |first= or |given= is always follows and is separated from |last= or |surname= with a comma and a space character. The only way to get cs1|2 to render a person's names in a particular order with particular punctuation is to do it manually with |author=. This same applies to the other name lists (contributor names, editor names, interviewer names, translator names). But none of this has anything to do with indexing.

What do you mean by indexed?

—Trappist the monk (talk) 18:00, 17 September 2020 (UTC)

I assume that an author name in a citation should be rendered in the way it would be listed in an index, which is what I'm referring to. There are plenty of external guidelines about this, e.g. Chicago Manual of Style 16.76-16.87. Thai names should appear in an index by first/given name. To respond to Izno, simply using given/surname doesn't work for Thai names because the given name is what they should be referred to by, though it comes first. I suppose I could just do author=, but then I would need to add ref={{harvid|first|year}} because short-form citations (which should use only the given name) wouldn't work properly. Calliopejen1 (talk) 18:10, 17 September 2020 (UTC)

Before electronic indexing this was important. Indeed, citation element order followed the indexing in printed reference works. The primary index often being published main-author-name with publish-date being a secondary index. Today though such reference works are electronic databases with flexible options regarding indexing and sub-indexing (the present discussion). Which makes the positioning of citation elements more of a presentation issue. There is however an existing guideline: present the author name the way you saw it published. Presumably, that would be the easiest way to find it. The parameter |author= fits the bill. 65.88.88.69 (talk) 18:38, 17 September 2020 (UTC)

I agree that it is a presentation issue, but I don't think that presentation is unimportant. For example, I wouldn't want us to be using the wrong part of the name in short-form citations because {{harvnb}} links to "last"/"surname" by default. That would as akin to doing a short-form citation with "Melissa" or "Jennifer" (i.e. inappropriate). And highlighting the wrong portion of the name through inversion is also odd, as is alphabetizing a work in the wrong place in a works cited list. I do think that "author" combined with ref= is probably the way to go. I'm not sure if any other cultures have this particular issue that can't be sorted out by doing given/surname. Possible it's unique to Thai names.... Calliopejen1 (talk) 18:48, 17 September 2020 (UTC)

...existing guideline: present the author name the way you saw it published. Is there? Where?

—Trappist the monk (talk) 18:46, 17 September 2020 (UTC)

It is in the same page where it is said that titles should render as published. We are not allowed to be creative with most citation elements if we want verification to be as easy ss possible. There are presentation options with dates for example (within the given dating system). But when one is trying to present a date in a foreign system, it is better to do so verbatim. 65.88.88.69 (talk) 19:23, 17 September 2020 (UTC)

What page is this, out of curiosity? Also interested in the dating issue -- should we be giving Thai solar calendar dates for Thai sources? That seems pretty unhelpful to readers, who may want to know at a glance what year a work was published (i.e. is it an up-to-date source or not?). I checked two Thai works on Worldcat, and one had no date, while another had a Gregorian date. I assume the dates in Thai library catalogs are the usual Thai solar calendar dates though... Calliopejen1 (talk) 19:34, 17 September 2020 (UTC)

I was referring to the general guidelines re: verification. It was not my intent to be mysterious or snarky, and hopefully it will not be seen so. The question the way I understand it, is how to present foreign terms to an English-speaking audience for purposes of verification. Doesn't this answer itself? The technicalities of implementation (the parameter "author", custom short reference anchors etc) will then present themselves in the discussion. 65.88.88.69 (talk) 20:00, 17 September 2020 (UTC)

I don't have access to the on-line CMOS but a cursory look-through of this copy of "Indexes" 15th edition (different chapter number but apparently same title) seems to indicate that "Indexes" is about indexes, not about citation style. But, yeah, if the affect you are wanting to achieve is given name followed by surname and linkable from a short-form template, then |author=<given> <surname> and |ref={{sfnref|<given>|<year>}} will do that. You might want to leave <!--<hidden comments>--> so that editors who visit the article after you have finished with it know your intent.

—Trappist the monk (talk) 18:46, 17 September 2020 (UTC)

I agree it is about indexes. But where we have works cited lists, I assume we want them alphabetized in the same way/order they would appear in an index, no? Isn't that implicit in our inversion of first/last names? Calliopejen1 (talk) 18:49, 17 September 2020 (UTC)

Yeah, generally, per WP:CITE we sort by surname – that guideline seems to be mute on the topic of non-western name order. But, this is Wikipedia; I have seen (western) given-name-first reference lists sorted by surname. Why would anyone do that? I don't know, but, as long as it is consistent in the article, WP:CITEVAR protects that style.

The topic of non-western-name-order comes up here periodically. We just haven't determined how-best to deal with it. It is complicated because transliterations of Chinese and Japanese names are apparently not reversible – it is possible to transliterate a to Latin script but not possible to transliterate back to the original – so 'properly' supporting these kinds of names is more than just rendering the transliterated names without the inversion indicator (comma).

—Trappist the monk (talk) 19:15, 17 September 2020 (UTC)

See also:

• Help_talk:Citation_Style_1/Archive_45#New_parameter:_af
• Help_talk:Citation_Style_1/Archive_49#Last/First,_First/Last
• Help_talk:Citation_Style_1/Archive_60#"Eastern_name_order":_should_one_use_|author=_or_|author-mask=_?
• Help_talk:Citation_Style_1/Archive_64#Citing_native_scripts_of_the_author's_name_and/or_title_of_a_work_in_Citation_Style_1

--Matthiaspaul (talk) 04:14, 22 September 2020 (UTC) (updated 19:33, 29 October 2020 (UTC), 02:45, 8 November 2020 (UTC))

(edit-conflict) I would also advise to use the |given= and |surname= parameter variants rather than the |first= and |last= ones. While the order of display for names is "last, first" or "surname, given" at present, this does not necessarily remain so forever. Our style guide may change or we may introduce an |af= ('author format') parameter (as suggested by Headbomb) in the future to control the display order. (See also: Help_talk:Citation_Style_1/Archive 71#First/last_or_given/surname_canonical_form?)

What is important for semantical reasons is that the part of the name that fits into the concept of a family/group name belongs into |surname= (or |last=) and the part of the name that fits into the concept of an individual name into the |given= (or |first=) parameter variant, regardless of their order of display in citations. I think, this is also important for proper meta-data creation.

If, by applying this rule, the current display order or interpunctuation does not look correct for some reason, the display can be overridden using the corresponding -mask parameter variant (like |author-given=Given |author-surname=Surname |author-mask=Given Surname or |author-mask=Surname Given). This is more complicated than just using |author=, but better (at least for as long as the concept of a family and an individual name applies - not sure if this holds true everywhere on this planet).

Now, the anchor is derived from what's in the |surname= or |author= parameter. If it is true that, in the case of Thai names, it should better be derived from what's in the |given= parameter, it might be worth considering a new option like |ref=thai (or |ref=given) for this. (Or, if this should still run under the |ref=harv moniker, a new parameter like |ref-mask=given could be used for this, or this could be even be combined with the proposed |af= into something like |name-mode=Western/Eastern/Chinese/Japanese/Thai/Malay/Indian/Indian-surname/Icelandic/Hungarian/... to control the name display order and style as well as Harvard ref-ID composition and proper meta-data creation by a single parameter.)

--Matthiaspaul (talk) 19:36, 17 September 2020 (UTC) (updated 18:25, 24 September 2020 (UTC))

I may be missing something here. When "indexing" is mentioned, I understand it to mean bibliographic/citation reference indexing. As mentioned earlier, nowadays such databases can be searched via several indices, including combinations. So discovering a work with a "foreign" author name is much easier. But it seems that this is about how such works are indexed in "internal" Wikipedia lists, a presentation issue. I believe they should follow the published rendition. As stated above regarding {{harv}} a custom anchor could work in these cases. 65.88.88.69 (talk) 19:49, 17 September 2020 (UTC)

(edit conflict) Yeah, it's true that a custom anchor can be created manually using {{harvid}} (and is the way to do it now), but assembling an anchor this way is a bit like "open-heart-surgery". (Ideally, the whole information about how CITEREF anchors look like should be "internal" to template editors and no normal editor should have any need to deal with it, so that the implementation could be changed whenever a need would arise for this.)

If, however, this "given name thing" is a general concept for Thai names (I don't know), it would be worth to capsule the assembly of these anchors away from the user and invoke the creation of suitable anchors by some kind of citation template option. This way, the given name and date would not have to be repeated as arguments for {{harvid}}, following the idea of having to provide one piece of information only once for traceability, to ease its maintenance, and also to save some storage space. (In my example above this principle isn't followed for the |author-mask= parameter as well, but this is another possible "shortcoming" of the current implementation, whereas in a hypothetical future version it might be possible to have the template create a suitable display mask automatically if it knows it's a Thai name (this proposal goes in this direction, although related to display styles not naming conventions in general). However, the problem is that on a global scale there are many different naming conventions and once we enhance the current implementation we should ideally find a solution that works good for all of them. Therefore, we are still in learning mode tinkering about possible solutions whenever such a topic comes up.)

--Matthiaspaul (talk) 20:24, 17 September 2020 (UTC)

@Matthiaspaul: One semi-related note in case in case the template's handling of these sorts of things comes up again in the future... My understanding is that Cambodian names are first=surname, last=given name, but the proper mode of address (or anchor) is given name. Right now it's fine just to use first/last for these. (That's what I did, after giving it some thought, in Ratanakiri Province. But it's another instance where given is the proper term of address, but it falls in a different place in the name. You recommend doing given/surname variants, but that wouldn't work for Cambodian names unless you're also going to do author-mask and a custom anchor. Calliopejen1 (talk) 20:09, 17 September 2020 (UTC)

Thanks, this sort of info is always useful. Another example are Hungarian names. Eastern name order has a bit on this, but unfortunately does not name Thai names specifically. --Matthiaspaul (talk) 16:21, 19 September 2020 (UTC)

But we have Thai names... --Matthiaspaul (talk) 16:24, 19 September 2020 (UTC)

@Matthiaspaul: The thing is that Thai names don't use Eastern name order. They use Western name order, but the polite way to address someone is by their first name (i.e. given name). Calliopejen1 (talk) 04:47, 22 September 2020 (UTC)

BTW I assume the reason Thai names are how they are is that Thai people didn't use family names until relatively recently, and the family-name initiative was a reform to "modernize" Thai names. Perhaps the Western way of doing things was viewed as more "modern" at the time (?). This also may be why last names as a term of address didn't really catch on... Calliopejen1 (talk) 04:52, 22 September 2020 (UTC)

Providing an option to switch the composition of reference anchors from "last" to "first" (or other schemes, if necessary for some locales) would be very easy. Above, I suggested to add something like |ref=thai for this purpose or combine this into something like a |name-mode= parameter, which would allow us to select from a number of predefined combinations of display order and anchor composition styles.

However, meanwhile it occured to me that a work may have more than one author and that different settings may be necessary for different authors, if, for example, an English, a Thai, a Hungarian, an Icelandic and a Chinese author collaborated.

In order to enter the names in their various forms (native script, transliterated and/or translated) we need the generic parameter prefixes |script-= and |trans-= to be available as prefixes to name parameters (this has been requested many times already, we "just" need to implement it somewhen). This will ensure that the information can be provided accurately on a technical level.

Likewise, for reliable data entry on a semantical level, editors would choose from the parameter postfixes |-first=/|-last=/|-given=/|-family=/|-forename=/|-surname= the (one or) two that most accurately agree with the naming scheme present in an author's name. (This thread (Help_talk:Citation_Style_1/Archive 71#First/last_or_given/surname_canonical_form?) has a bit on selecting the most suitable postfixes during data entry.)

In this thread (Help_talk:Citation_Style_1/Archive_67#Possible_improved_treatment_of_title_parameters_and_language_attributes), I proposed how the scheme of language prefixes of the |script-= parameters could be expanded from only supporting a number of non-Latin scripts to all language codes without introducing any backward-compatibility problems. We could then use these language prefixes to control, (like that hypothetical |name-mode= parameter above, but) on a name-by-name basis, the various settings needed to display the name correctly (display order and possibly necessary text decoration), to generate the correct meta-data for it, and to derive the name parts for an anchor in Harvard style from it.

The current assignment of first=given=forename and last=family=surname would continue to hold true by default (also for backward compatibility with names provided without |script-=). However, if a name would be entered with f.e. the language prefix zh indicating a Chinese name, the internal assignments would become last=given and first=family, so that |script-author-given=zh:Given and |script-author-surname=zh:Surname would work just as well as |script-author-last=zh:Given and |script-author-first=zh:Surname and be rendered as "Surname Given" (no comma) (whereas the conventional |author-given=Given and |author-surname=Surname or |author-last=Surname and |author-first=Given would be rendered as "Surname, Given").

These settings could be implemented as properties in a table of language codes. Also, now, that the non-hyphenated name parameter forms will soon be gone, the code could take advantage of the symmetries in the parameter naming scheme to fold the name parameters into one "[prefix-][name[#]][-postfix[#]]" form (where name would be author/editor/contributor/translator/subject/interviewer). This would reduce redundancies in the code and avoid an endlessly long parameter whitelist.

I think, this extensible scheme would allow us to enter any kind of name in a semantically and technically correct way and process the data according to the rules necessary to be obeyed for each individual name for proper output on all ends.

--Matthiaspaul (talk) 19:31, 24 September 2020 (UTC)

This might look complicated, however, this is only because the example is for a Chinese name in Chinese script where the usage of the |script-= parameter variants would be mandantory. For Latin-based scripts, including translated Chinese names, things would be much simpler. As having to use the |script-= variants just to give language codes appears to be too cumbersome in these easier cases, what about supporting the language prefixes also for the non-script parameter variants? This would reduce something like

|script-author-given=hu:Given and |script-author-surname=hu:Surname

down to

|author-given=hu:Given and |author-surname=hu:Surname

or even to

|given=hu:Given and |surname=hu:Surname

Likewise

|script-author-last=hu:Given and |script-author-first=hu:Surname

to

|author-last=hu:Given and |author-first=hu:Surname

or even

|last=hu:Given and |first=hu:Surname

Assuming that Hungarian names (as indicated by hu:) would be internally configured to be rendered in "Eastern order", this would be rendered as "Surname Given" (without comma) (NB. This is only an example, the actual configuration for Hungarian names could be different, in fact, according to some style guides it is), whereas English names per

|given=en:Given and |surname=en:Surname

or

|last=en:Surname and |first=en:Given

or

|given=Given and |surname=Surname

or

|last=Surname and |first=Given

would be indexed/rendered as "Surname, Given" (with comma).

--Matthiaspaul (talk) 21:20, 16 November 2020 (UTC)

PMID limit

At Special:Permalink/982911547#PMID error, Nixinova was concerned that PMID 33022132 was outside the range specified at Help:CS1 errors#bad_pmid. This turns out not to be the case, as the limit specificed there is 33100000. However, it's awfully close, which led me to investigate it.

• #1426 @ 2020-10-10: last id 33038074
• #1423 @ 2020-10-07: last id 33026741
  • 33038074 - 33026741 = 11333 ids / 3 days = 3778 ids/day
• #1334 @ 2020-09-11: last id 32915410
  • 33038074 - 32915410 = 122664 ids / 29 days = 4230 ids/day
• #1100 @ 2020-03-01: last id 32113198
  • 33038074 - 32113198 = 924876 ids / 223 days = 4147 ids/day

The PMIDs appear to be assigned sequentially and are documented to "not be re-used". Based on the highest numbers found in several daily files here, the rate is roughly 4000 per day. The latest PMID as of the 2020-10-10 file is 33038074, which means it will hit 33100000 in less than 16 days. Was there a reason for the (strangely specific) 33100000 limit, should it be increased (soon), and to what? —[AlanM1 (talk)]— 15:25, 11 October 2020 (UTC)

I see Trappist the monk has been maintaining Module:Citation/CS1/Configuration. —[AlanM1 (talk)]— 15:30, 11 October 2020 (UTC)

I picked 33100000 just to clear the error. The limit exists to catch simple typos: too many digits, most significant digits out of bounds. Alas, we can't catch too-few-digits or typos that produce in-bounds results... cs1|2 can't do much more to protect editors from these kinds of mistakes. The limit should be sufficiently tight that we catch typos but not so tight that we overrun the limit every few days.

We might set the limit at 33500000 which, at 4k/day, will last us 100+ days. Elsewhere on this talk page it is suggested that we automatically increment the limits for the various identifiers. I don't particularly like that as a solution because there is no way to automatically close the loop to reduce or increase the limit-deltas as conditions warrant.

—Trappist the monk (talk) 16:24, 11 October 2020 (UTC)

Not without some arbitrary number like we have today, of course. --Izno (talk) 18:04, 11 October 2020 (UTC)

If someone has a general purpose bot, perhaps a job could be added to it, to be run monthly. It could retrieve the latest XML file from the FTP link above, find the highest PMID value, add 120,000 (30 days' use), round up to the next 100,000, and update the id_handlers['PMID'].id_limit value in the config file. Or someone could do it manually. While I do have a couple of things I do monthly manually, I don't have a foolproof system in place to ensure things get done and it would seem like this is too important for my casual approach. Are there other values here that can/should be updated, too? —[AlanM1 (talk)]— 06:05, 12 October 2020 (UTC)

We could also define a bot task to scan for the highest identifier value used in an article while performing other tasks (or have a bot continously loop over all articles), check this value against a value recorded in a new "/Limits" sub-page of the citation template, and update that value if the found value is higher. This sub-page would have to be unprotected to be easily accessible by bots and editors. The citation template could read this value and compare it against the value specified in its "/Configuration" module (which is protected), take the higher value, add some safety margin to it, and treat the result as the allowed upper limit in citations (with or without some extrapolation facility). Many variants of this are possible.

Using this approach would make it possible to more frequently update the limits while still ensuring that at least all values below the value specified in "/Configuration" are treated as valid. The limits in "/Configuration" would be updated whenever the template gets updated. By specifying a much too high value in "/Limits" vandals could temporarily disable the upper limit check but they could not cause the template to use much too low values in an attempt to invalidate (older) values in citations.

--Matthiaspaul (talk) 21:58, 12 October 2020 (UTC)

At least in theory Wikidata could also be used to retrieve some useful information instead or in addition to something like "/Limits": PMID (P698) has a property "number of records" P4876.

• 30060294 @ 2019-08-01
• 30178674 @ 2019-11-19

However, the info there is outdated.

The "number of records" is also defined for DOIs (P356) and JSTORs (P888); similarly outdated.

--Matthiaspaul (talk) 19:24, 14 October 2020 (UTC) (updated 13:25, 15 November 2020 (UTC))

Just to illustrate this a bit more, the unprotected "/Limits" subpage to be regularly kept up to date by bots or editors could be in a simple CSV format like:

pmc-limit=8000000,pmid-limit=33200000,ssrn-limit=4000000,s2cid-limit=230000000,oclc-limit=9999999999,osti-limit=23000000,rfc-limit=9000

The template would attempt to read this file and if present, check the identifier against either the internally defined limit or the limit defined in this file, depending on which one is larger.

Whenever the template would be scheduled to be updated, the internally defined limits would be updated to those from the "/Limits" file plus some margin.

Depending on the amount of overhead allowed the format of the "/Limit" could also be Lua source code instead of CSV.

--Matthiaspaul (talk) 23:54, 5 November 2020 (UTC) (updated 10:54, 10 November 2020 (UTC), 23:39, 13 November 2020 (UTC))

That was here: Help_talk:Citation_Style_1#Bump_PMC_to_8000000.

This "auto-increment" would still require monitoring/updates/adjustments of the limits and factors, but less frequently.

--Matthiaspaul (talk) 21:58, 12 October 2020 (UTC)

Sounds more complicated and error-prone than using the latest XML change file at PubMed for the max value and adding enough headroom to get past the next anticipated run. I don't think it should try to be exact, since new IDs are constantly being assigned and the latest articles may not be cited for some time. The new increment could even be re-calculated on each run based on the current and previous months' max values and file dates, plus a fudge factor based on some stats I can get from the variance in the current history file set. —[AlanM1 (talk)]— 00:16, 13 October 2020 (UTC)

Yes, for as long as such an XML file exists as an external resource, but this does not seem to be the case for all identifiers which need to be bumped up frequently. --Matthiaspaul (talk) 00:58, 13 October 2020 (UTC)

Another approach would be to allow users to temporarily enter "too high" values using the accept-this-as-written markup, this would put them into special maintenance categories similar to invalid ISBNs, etc. (This could be implemented with minimal overhead.)

If bots would run into this markup in the |pmc=, |pmid=, |ssrn= or |s2cid= parameters, they would retrieve the currently configured limit for an identifier through

{{#invoke:Cs1 documentation support|id_limits_get|<identifier>}}

like

• Current PMC limit: 11500000
• Current PMID limit: 39400000
• Current SSRN limit: 4900000
• Current S2CID limit: 270000000
• Current OCLC limit: 10310000000 (will show after the next template update)
• Current OSTI limit: 23010000 (will show after the next template update)
• Current RFC limit: 9300 (will show after the next template update)

and compare it against the number specified in the citation. If the limit is larger, they would remove the markup, otherwise leave it as it is. This would have the advantage that the "fix" is trivially easy for editors, and that the templates would not have to read a "/Limits" file. However, bots would have to edit the citations.

Still, the bots should record the highest found numbers in some prominent place (for example in a "/Limits" file), so that the internally defined limits can be easily updated accordingly when a template update is scheduled. Otherwise, someone would have to manually go through the maintenance category to determine the new limits.

--Matthiaspaul (talk) 23:54, 5 November 2020 (UTC) (updated 10:54, 10 November 2020 (UTC), 23:39, 13 November 2020 (UTC))

Edition and pages extra text as errors

Per a discussion elsewhere, in the sandbox I have separated Category:CS1 maint: extra text into two separate categories, as well as promoted the two categories to errors from maintenance. The two categories are per parameter: one for |edition= and one for |p/pp/page/pages=.

This change is demonstrated at test_extra_text test on Module talk:Citation/CS1/testcases/errors. I did not implement sensitivity to the exact parameter name in the pages test since that's still a bit beyond me. I have no strong opinion on someone else doing so.

Secondly, I see "volume" text in |work= in the wild often (and equivalents, esp. in the titles of encyclopedias and books). An example might be |title=Title, Volume X: Volume Name, which I would envision as better being |title=Title|volume=X: Volume Name. I would like to entertain an "extra text" test for that pattern and an associated maintenance category, and invite discussion accordingly. --Izno (talk) 03:39, 2 November 2020 (UTC)

As there are so many possible variants, I don't see a more narrow pattern as to just search for the string "Volume" or "Vol." in a title. In most cases it will be preceded by a separator and located near the end of a title, but I can also think of cases where that would not hold true. We'd have to live with the false positives.

Similar to the volume thing, I sometimes see variously formatted "Part" info in the title as well. If the |volume= parameter isn't used, this could be abused to move the part info into there, but what we'd actually need for this is a separate parameter |part= (see also Module_talk:Citation/CS1/Feature_requests#Part/Help_talk:Citation_Style_1/Archive_58#Books_with_volumes_and_parts, there even is a COinS tag for this, &rft.part=, although, as odd as it is, this appears to be defined only for periodicals, not books).

Applying to both volumes and parts, an Arabic or Roman number at the end of a title might also give a clue (but could also be a version number and valid part of the title).

--Matthiaspaul (talk) 14:59, 3 November 2020 (UTC)

Per Help_talk:Citation_Style_1/Archive_49#Edit_request_for_Template:Cite_book the template now also detects the British abbreviation "edn" in |edition= as extra text:

Extended content

Cite book comparison Wikitext {{cite book|author=Author|date=2020|edition=1st|title=Title}} Live Author (2020). Title (1st ed.). {{cite book}}: |author= has generic name (help) Sandbox Author (2020). Title (1st ed.). {{cite book}}: |author= has generic name (help) Cite book comparison Wikitext {{cite book|author=Author|date=2020|edition=1st ed.|title=Title}} Live Author (2020). Title (1st ed. ed.). {{cite book}}: |author= has generic name (help); |edition= has extra text (help) Sandbox Author (2020). Title (1st ed. ed.). {{cite book}}: |author= has generic name (help); |edition= has extra text (help) Cite book comparison Wikitext {{cite book|author=Author|date=2020|edition=1st edn|title=Title}} Live Author (2020). Title (1st edn ed.). {{cite book}}: |author= has generic name (help); |edition= has extra text (help) Sandbox Author (2020). Title (1st edn ed.). {{cite book}}: |author= has generic name (help); |edition= has extra text (help)

--Matthiaspaul (talk) 20:25, 7 November 2020 (UTC)

The extra text test for |page=/|pages= and |quote-page=/|quote-pages= now also checks for pattern "pg(s)(.)" etc. in addition to ""p(p)(.)" etc.:

Extended content

Cite book comparison Wikitext {{cite book|page=p. 35|title=Title}} Live Title. p. p. 35. {{cite book}}: |page= has extra text (help) Sandbox Title. p. p. 35. {{cite book}}: |page= has extra text (help) Cite book comparison Wikitext {{cite book|page=pp. 35|title=Title}} Live Title. p. pp. 35. {{cite book}}: |page= has extra text (help) Sandbox Title. p. pp. 35. {{cite book}}: |page= has extra text (help) Cite book comparison Wikitext {{cite book|page=pgs 35|title=Title}} Live Title. p. pgs 35. {{cite book}}: |page= has extra text (help) Sandbox Title. p. pgs 35. {{cite book}}: |page= has extra text (help) Cite book comparison Wikitext {{cite book|page=pgs. 35|title=Title}} Live Title. p. pgs. 35. {{cite book}}: |page= has extra text (help) Sandbox Title. p. pgs. 35. {{cite book}}: |page= has extra text (help) Cite book comparison Wikitext {{cite book|page=p123|title=Title}} Live Title. p. p123. {{cite book}}: |page= has extra text (help) Sandbox Title. p. p123. {{cite book}}: |page= has extra text (help) Cite book comparison Wikitext {{cite book|page=P123|title=Title}} Live Title. p. P123. Sandbox Title. p. P123.

--Matthiaspaul (talk) 01:17, 17 November 2020 (UTC)

Only remotely related to this "extra text detection" topic but I don't want to open a new thread for this minor bit: I changed the "et al." extra text detection code to also detect "et alii" and "et aliae" in addition to "et alia" and the abbreviated variants.

Extended content

Cite book comparison Wikitext {{cite book|author=Author, et alia|date=2020|title=Title}} Live Author; et al. (2020). Title. {{cite book}}: |author= has generic name (help); Explicit use of et al. in: |author= (help) Sandbox Author; et al. (2020). Title. {{cite book}}: |author= has generic name (help); Explicit use of et al. in: |author= (help) Cite book comparison Wikitext {{cite book|author=Author, et alii|date=2020|title=Title}} Live Author; et al. (2020). Title. {{cite book}}: |author= has generic name (help); Explicit use of et al. in: |author= (help) Sandbox Author; et al. (2020). Title. {{cite book}}: |author= has generic name (help); Explicit use of et al. in: |author= (help) Cite book comparison Wikitext {{cite book|author=Author, et aliae|date=2020|title=Title}} Live Author; et al. (2020). Title. {{cite book}}: |author= has generic name (help); Explicit use of et al. in: |author= (help) Sandbox Author; et al. (2020). Title. {{cite book}}: |author= has generic name (help); Explicit use of et al. in: |author= (help) Cite book comparison Wikitext {{cite book|author1=Author|author2=et alia|date=2020|title=Title}} Live Author; et al. (2020). Title. {{cite book}}: |author1= has generic name (help); Explicit use of et al. in: |author2= (help) Sandbox Author; et al. (2020). Title. {{cite book}}: |author1= has generic name (help); Explicit use of et al. in: |author2= (help) Cite book comparison Wikitext {{cite book|author1=Author|author2=et alii|date=2020|title=Title}} Live Author; et al. (2020). Title. {{cite book}}: |author1= has generic name (help); Explicit use of et al. in: |author2= (help) Sandbox Author; et al. (2020). Title. {{cite book}}: |author1= has generic name (help); Explicit use of et al. in: |author2= (help) Cite book comparison Wikitext {{cite book|author1=Author|author2=et aliae|date=2020|title=Title}} Live Author; et al. (2020). Title. {{cite book}}: |author1= has generic name (help); Explicit use of et al. in: |author2= (help) Sandbox Author; et al. (2020). Title. {{cite book}}: |author1= has generic name (help); Explicit use of et al. in: |author2= (help)

--Matthiaspaul (talk) 03:26, 17 November 2020 (UTC)

The sandboxed version now no longer leaves bracket-artifacts when it removes a double-bracketed pattern of et al.:

Cite book comparison

Wikitext	{{cite book|author1=Author1|author2=((et al.))|date=2020|title=Title}}
Live	Author1; et al. (2020). Title. {{cite book}}: |author1= has generic name (help); Explicit use of et al. in: |author2= (help)CS1 maint: numeric names: authors list (link)
Sandbox	Author1; et al. (2020). Title. {{cite book}}: |author1= has generic name (help); Explicit use of et al. in: |author2= (help)CS1 maint: numeric names: authors list (link)

--Matthiaspaul (talk) 14:12, 21 November 2020 (UTC)

CS1 maint: others

We presently capture citations that have no authorship information, besides |others=, in Category:CS1 maint: others (with some 20k pages). Due to prominence in the documentation of the templates {{cite AV media}} and {{cite AV media notes}}, these templates often have |others= exclusively, which makes it hard for other cases where this is an issue.

I am considering separating these out into a separate category (something like Category:CS1 maint: others in cite AV media (notes)) so that someone interested in working through slightly-less painful categories can do so.

Has anyone seen another of the core CS1 template set cause such inclusion in this maintenance category? Does anyone have an issue with that path? --Izno (talk) 05:05, 2 November 2020 (UTC)

Alternatively, is there something we can do about those templates? Provide still-more named parameters?... --Izno (talk) 05:08, 2 November 2020 (UTC)

This search can be helpful. We might restore |artist= as a template-specific parameter for {{cite av media notes}}. Instead of keeping it separate, the content of |artist= might be concatenated as a prefix to |title= so this:

{{cite av media notes |title=Dark Side of the Moon |artist=Pink Floyd}}

might render:

Pink Floyd: Dark Side of the Moon (Media notes).

with the metadata as:

&rft.btitle=Pink+Floyd%3A+Dark+Side+of+the+Moon

There are probably better rendering / metadata choices.

The {{cite av media}}, {{cite av media notes}}, {{cite episode}}, {{cite serial}} templates all deserve reworking. These are the templates that are the primary users of |people=, an alias of |authors= so none of the names listed in that parameter make it into the citation's metadata. All kinds of extraneous text is added to that parameter, mostly roles (director, producer, actor, voice-over, narrator, etc) none of which belongs in the metadata. Now that cs1|2 supports template-specific parameters, we could introduce specific role parameters for these templates so that the names are annotated in the rendering, and the names without annotation are included in the metadata. In the meantime, |people=, can be constrained to these templates only, and once the template specific parameters are available, deprecated and withdrawn.

To avoid the torches and pitchforks militias from those wikiprojects that use these templates, whichever those projects are should be consulted before we act on this.

—Trappist the monk (talk) 15:37, 2 November 2020 (UTC)

Sounds good to me in general. --Matthiaspaul (talk) 12:40, 3 November 2020 (UTC)

It is a good idea to reinstate |artist=. However, this may better be a free-form parameter since artist names maybe idiosyncratic, and of course we have cases of compilation works, collaborations etc.

I would think the role parameters should follow industry practice, i.e. render as they do in "credits" sections of artistic works. I suppose distinct roles should be limited to the main creators/contributors. Minor credits could be bundled in |others=. 98.0.246.242 (talk) 22:09, 3 November 2020 (UTC)

Others

Moved from Template talk:Citation#Others. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 11:12, 10 November 2020 (UTC)

Has anyone analysed what are the commonest types of role added as |others=? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 10:53, 8 November 2020 (UTC)

Not that I know of. Such analysis will be difficult because tools like ve have misused (and may still be misusing) |others= for author names and for editor names (without role being specified). That is the problem with free-form parameters; editors and tools can put just about anything there. There are approximately 52k-ish uses of |others= [search results]

—Trappist the monk (talk) 11:47, 8 November 2020 (UTC)

So should we add more non-free-from parameters, like |illustrator=? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 13:58, 8 November 2020 (UTC)

Probably better asked at WT:CS1 which is a bit more-watched.

—Trappist the monk (talk) 14:19, 8 November 2020 (UTC)

The question seems somewhat (tangentially?) relevant to discussion in #CS1 maint: others. --Izno (talk) 19:06, 10 November 2020 (UTC)

I suggest author of foreword (P2679) is another likely candidate. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 23:06, 12 November 2020 (UTC)

Perhaps not a good candidate for |others=. cs1|2 book citations support forewords, afterwords, and other contributions to an author's book:

{{cite book |author=Author |title=Title |contributor=Contributor |contribution=Foreword}}

Contributor. Foreword. Title. By Author. {{cite book}}: |author= has generic name (help)

—Trappist the monk (talk) 23:14, 12 November 2020 (UTC)

While there are use-cases for |contribution= with |contributorn= and it is good that the feature supports |contributor-first= and |contributor-last= as well as n-enumerated variants, I don't like the fact that only one |contribution= is allowed and that it is impossible to specify different types of contributions for different contributors (unless lumping them all together in |contribution=). What also looks odd most of the time is that the contributors are listed in front of the authors as this draws too much attention to them:

• {{cite book |title=Title |date=2020 |author-first1=AF1 |author-last1=AL1 |editor-first1=EF1 |editor-last1=EL1 |translator-first1=TF1 |translator-last1=TL1 |contributor-first1=CF1 |contributor-last1=CL1 |contributor-first2=CF2 |contributor-last2=CL2 |contributor-first3=CF3 |contributor-last3=CL3 |contributor-first4=CF4 |contributor-last4=CL4 |contribution=Illustration/Foreword/Afterword |others=Others}}

CL1, CF1; CL2, CF2; CL3, CF3; CL4, CF4 (2020). "Illustration/Foreword/Afterword". Title. By AL1, AF1. EL1, EF1 (ed.). Translated by TL1, TF1. Others.{{cite book}}: CS1 maint: numeric names: authors list (link)

This is okay if the goal is to cite something from a foreword or afterword and draw particular attention to this specifically, but not if the goal is to cite a source in general and list the various contributors for completeness or because, f.e., the writer of a foreword was specifically "advertised" on the book cover. Right now, we'd have to use |others= for this, but this does not support enumerated and -first/-last parameter variants, and the article editor has to invent his/her own notation to list multiple contributors and their roles as in the following three examples:

• {{cite book |title=Title |date=2020 |author-first1=AF1 |author-last1=AL1 |editor-first1=EF1 |editor-last1=EL1 |translator-first1=TF1 |translator-last1=TL1 |others=CL1, CF1 (Illustration). CL2, CF2; CL3, CF3 (Foreword). CL4, CF4 (Afterword). Others}}

AL1, AF1 (2020). EL1, EF1 (ed.). Title. Translated by TL1, TF1. CL1, CF1 (Illustration). CL2, CF2; CL3, CF3 (Foreword). CL4, CF4 (Afterword). Others.{{cite book}}: CS1 maint: numeric names: authors list (link)

• {{cite book |title=Title |date=2020 |author-first1=AF1 |author-last1=AL1 |editor-first1=EF1 |editor-last1=EL1 |translator-first1=TF1 |translator-last1=TL1 |others=Illustration: CL1, CF1. Foreword: CL2, CF2; CL3, CF3. Afterword: CL4, CF4. Others}}

AL1, AF1 (2020). EL1, EF1 (ed.). Title. Translated by TL1, TF1. Illustration: CL1, CF1. Foreword: CL2, CF2; CL3, CF3. Afterword: CL4, CF4. Others.{{cite book}}: CS1 maint: numeric names: authors list (link)

• {{cite book |title=Title |date=2020 |author-first1=AF1 |author-last1=AL1 |editor-first1=EF1 |editor-last1=EL1 |translator-first1=TF1 |translator-last1=TL1 |others=Illustrated by CL1, CF1. Foreword by CL2, CF2; CL3, CF3. Afterword by CL4, CF4. Others}}

AL1, AF1 (2020). EL1, EF1 (ed.). Title. Translated by TL1, TF1. Illustrated by CL1, CF1. Foreword by CL2, CF2; CL3, CF3. Afterword by CL4, CF4. Others.{{cite book}}: CS1 maint: numeric names: authors list (link)

Before we now introduce individual parameters for all possible roles, what I would like to see is a mix of both, |contributor= and |others=:

Multiple possible contributors with different contributions (with support for -first/-last and enumerated forms), but listed after the list of authors, editors and translators (and before |others=). This could be achieved by adding |contributor-role= (and enumerated forms). If the role would be specified, it would be listed alongside the corresponding contributor. In order to allow multiple contributors contributing to the same type of contribution, the role should occur either before all or after the last contributor of a specific group (as in the example renderings above). The markup for this could be like this:

• {{cite book |title=Title |date=2020 |author-first1=AF1 |author-last1=AL1 |editor-first1=EF1 |editor-last1=EL1 |translator-first1=TF1 |translator-last1=TL1 |contributor-first1=CF1 |contributor-last1=CL1 |contribution-role1=Illustration |contributor-first2=CF2 |contributor-last2=CL2 |contributor-role2=Foreword |contributor-first3=CF3 |contributor-last3=CL3 |contributor-role3=Foreword |contributor-first4=CF4 |contributor-last4=CL4 |contributor-role4=Afterword |others=Others}}

As a further refinement we could make subsequent |contributor-role= parameters optional if they would specify the same role as that of the preceding contributor (|contributor-role3= here):

• {{cite book |title=Title |date=2020 |author-first1=AF1 |author-last1=AL1 |editor-first1=EF1 |editor-last1=EL1 |translator-first1=TF1 |translator-last1=TL1 |contributor-first1=CF1 |contributor-last1=CL1 |contribution-role1=Illustration |contributor-first2=CF2 |contributor-last2=CL2 |contributor-role2=Foreword |contributor-first3=CF3 |contributor-last3=CL3 |contributor-first4=CF4 |contributor-last4=CL4 |contributor-role4=Afterword |others=Others}}

How to distinguish between the two forms? Either by the existence of |contribution=, by the existence of a |contributor-role= parameter, by introducing |others-first/-last/-role= instead of |contributor-first/-last/-role= or some mix of it.

--Matthiaspaul (talk) 20:11, 18 November 2020 (UTC)

I don't like the fact that only one |contribution= is allowed... From that, can I take it that you don't like the fact that a single cs1|2 template allows only one |chapter= or one |section= or one |entry= or one |article=?

The |contribution= and |contributor= pair are intended to cite the contributor's contribution to the work written by |author= as, for example, Anna Quindlen's introduction to Jane Austen's Pride and Prejudice, here where Quindlen is the writer who is being cited, not Austen, so it is correct that Quindlen is listed ahead of Austen in the citation. So, yes, [this] is okay if the goal is to cite something from a foreword or afterword and draw particular attention to this specifically because that is the defined purpose.

If an editor is not citing the writer of a foreword ... specifically "advertised" on the book cover, there is no need to clutter the citation with that extraneous detail; we don't need to distract or confuse the reader.

We should certainly not introduce individual parameters for all possible roles. If any such parameters are added they should only be added after careful consideration and when it can be shown that the new parameter is needed.

—Trappist the monk (talk) 13:50, 19 November 2020 (UTC)

I never proposed to introduce individual parameters for all possible roles, quite the opposite, I proposed to have a more general set of parameters that can be customized to suit all possible roles and use cases, so that we don't have to discuss this subject again and again. After all, whenever we added another set of parameters for a specific role, someone came around the corner asking for the next one. There is obviously a need to list some contributors, but the current system does not address all use cases (except for through a free-text parameter |others=, which, however, is unsatisfactory for most of the same reasons for why we are fading out |editors= and |authors= in the long term).

While there have been several requests in the past to add this and I too have come into sitations where it would have been great to handle more than one chapter in a single citation without having to lump them together in one parameter, I don't propose this. However, contributions are a completely different case, because there are often multiple contributions and of different types.

The Pride and Prejudice example you gave is a perfect example for the current use of |contribution= and |contributor=. I described this use case as well in my reply above. But it does not cover the more common use case where the afterword, foreword, illustrations, etc., are not by itself the subject to be cited, but they are nevertheless part of the contributions to a work and thus may be listed in a citation. (This is also why this ([1]) won't have the desired effect.) In this case, the contributions would be clutter when displayed before the main contributors. They should rather be listed following the main contributors like authors, editors and translators - basically they should be at the position where we show |others=. I could have worded my proposal to introduce |other-firstn=/|other-lastn=/|other-linkn=/|other-maskn= plus |other-rolen= (and fade out |others= in the long term). However, if we can combine this with the parameters for contributors we could just use the existing |contributor-firstn=/|contributor-lastn=/|contributor-linkn=/|contributor-maskn= for this as well and just add |contributor-rolen=.

--Matthiaspaul (talk) 20:17, 21 November 2020 (UTC)

Before we now introduce individual parameters for all possible roles, what I would like to see is a mix of both, |contributor= and |others=: ... reads, to me, like this mix of both is merely a prelude to the [introduction of] individual parameters for all possible roles which is something that we should not do.

I am not convinced that we need anything more than a carefully curated, select few, role-type parameters. We do not need something that will allow editors to name every last person who was even remotely connected to the cited work. We do not need to be film-credit-like and include the craft-services' third journeyman soup stirrer; leave that to the publisher.

I can imagine certain additional roles being added to replace |people= and |credits= which are predominantly used in {{cite AV media}}, {{cite episode}}, and {{cite serial}}. These new role parameters would be constrained to these templates.

But it does not cover the more common use case where the afterword, foreword, illustrations, etc., are not by itself the subject to be cited, but they are nevertheless part of the contributions to a work and thus may be listed in a citation. You're right, it doesn't and it shouldn't. When an afterword, foreword, introduction, preface, etc is not the subject to be cited, such contributions, noteworthy though they may be, are superfluous to the purpose of the citation which is to identify for the reader the subject to be cited. Including mention of afterwords, forewords, introductions, prefaces when they are not the subject to be cited merely obfuscates the subject to be cited within the citation and so does not benefit the reader. cs1|2 is not a repository for all possible bibliographic data associated with a source. If you want that, go write a template series to do that. It may be that in bibliographic lists of an author's works, for example, such a bibliographic information template might be desirable. Citations need only the bibliographic detail that is sufficient to identify the portion of the source that is the subject to be cited.

—Trappist the monk (talk) 18:49, 22 November 2020 (UTC)

My experience with "others" is that it is usually used incorrectly, for instance for authors after the first one. —David Eppstein (talk) 23:23, 12 November 2020 (UTC)

Even though the documentation has problems, in this case it correctly leads the horse to the water. 71.247.146.98 (talk) 12:56, 13 November 2020 (UTC)

Redirection

Tangent Why is that talk page un-redirected? --Izno (talk) 13:19, 10 November 2020 (UTC)

Don't know. Probably should be don't you think?

—Trappist the monk (talk) 15:05, 10 November 2020 (UTC)

As far as I understood, {{Citation}} is for CS2, not CS1. If so, redirecting here ("Help talk:Citation Style 1") would probably be wrong. I'm all for merging CS1 and CS2, but for as long as this hasn't happened, CS2 followers probably need a place to hold out as well. However, crosslinking would be appropriate, so that discussions won't be missed (as it apparently happens often).

--Matthiaspaul (talk) 16:29, 10 November 2020 (UTC)

The CS1 module handles CS2 and questions regarding it are 99% applicable to both. Help talk:CS2 also redirects here. --Izno (talk) 18:44, 10 November 2020 (UTC)

Almost, Help talk:Citation Style 2. Perhaps, we should redirect Template talk:Citation there?

--Matthiaspaul (talk) 22:08, 10 November 2020 (UTC)

No. Here is best. Help talk:Citation Style 2 has 29 watchers. Template talk:Citation has 201 watchers. This page has 384 watchers. No doubt, many of those watchers are the same.

—Trappist the monk (talk) 22:16, 10 November 2020 (UTC)

Merge the pages, rename & redirect. Only after the appropriate discussion. What the module does is irrelevant to how humans discuss and categorize things. If editors want to have seoarate pages for discussion because it makes sense to them, then that is how it should be. 208.251.187.170 (talk) 12:55, 11 November 2020 (UTC)

Fixed evaluation of accept-this-as-is syntax in parameters supporting item lists

Template parameters supporting item lists such as |pages=, |pp=, |issue=, |number= (and now also |quote-pages=) supported the accept-this-as-is syntax to suppress the conversion of hyphens to dashes globally as well as for individual list items. However, a bug prevented the code from properly evaluating item lists, where the first and the last list items were using this syntax. Such combinations were erroneously interpreted as if the global accept-this-as-is markup was used, resulting in invalid list items (fifth and last example). This has been fixed now:

Extended content

Cite journal comparison Wikitext {{cite journal|author=Author|journal=Journal|pages=1-3,5-7|title=Title}} Live Author. "Title". Journal: 1–3, 5–7. {{cite journal}}: |author= has generic name (help) Sandbox Author. "Title". Journal: 1–3, 5–7. {{cite journal}}: |author= has generic name (help) Cite journal comparison Wikitext {{cite journal|author=Author|journal=Journal|pages=1,201-1,234|title=Title}} Live Author. "Title". Journal: 1, 201–1, 234. {{cite journal}}: |author= has generic name (help) Sandbox Author. "Title". Journal: 1, 201–1, 234. {{cite journal}}: |author= has generic name (help) Cite journal comparison Wikitext {{cite journal|author=Author|journal=Journal|pages=((1,201–1,234))|title=Title}} Live Author. "Title". Journal: 1,201–1,234. {{cite journal}}: |author= has generic name (help) Sandbox Author. "Title". Journal: 1,201–1,234. {{cite journal}}: |author= has generic name (help) Cite journal comparison Wikitext {{cite journal|author=Author|journal=Journal|pages=((1-3,5-7))|title=Title}} Live Author. "Title". Journal: 1-3,5-7. {{cite journal}}: |author= has generic name (help) Sandbox Author. "Title". Journal: 1-3,5-7. {{cite journal}}: |author= has generic name (help) Cite journal comparison Wikitext {{cite journal|author=Author|journal=Journal|pages=((1-3)),((5-7))|title=Title}} Live Author. "Title". Journal: 1-3, 5-7. {{cite journal}}: |author= has generic name (help) Sandbox Author. "Title". Journal: 1-3, 5-7. {{cite journal}}: |author= has generic name (help) Cite journal comparison Wikitext {{cite journal|author=Author|journal=Journal|pages=((1-3)),5-7|title=Title}} Live Author. "Title". Journal: 1-3, 5–7. {{cite journal}}: |author= has generic name (help) Sandbox Author. "Title". Journal: 1-3, 5–7. {{cite journal}}: |author= has generic name (help) Cite journal comparison Wikitext {{cite journal|author=Author|journal=Journal|pages=((((1-3)),((5-7))))|title=Title}} Live Author. "Title". Journal: ((1-3)),((5-7)). {{cite journal}}: |author= has generic name (help) Sandbox Author. "Title". Journal: ((1-3)),((5-7)). {{cite journal}}: |author= has generic name (help) Cite journal comparison Wikitext {{cite journal|author=Author|journal=Journal|pages=((1-3)),((5-7)),9-10|title=Title}} Live Author. "Title". Journal: 1-3, 5-7, 9–10. {{cite journal}}: |author= has generic name (help) Sandbox Author. "Title". Journal: 1-3, 5-7, 9–10. {{cite journal}}: |author= has generic name (help) Cite journal comparison Wikitext {{cite journal|author=Author|journal=Journal|pages=((1-3)),5-7,((9-10))|title=Title}} Live Author. "Title". Journal: 1-3, 5–7, 9-10. {{cite journal}}: |author= has generic name (help) Sandbox Author. "Title". Journal: 1-3, 5–7, 9-10. {{cite journal}}: |author= has generic name (help)

--Matthiaspaul (talk) 02:19, 4 November 2020 (UTC)

The parameter evaluation for |volume= internally uses parts of the same code for list item evaluation, hyphen-to-dash conversion, and accept-this-as-is markup recognition as used for |issue=, |pages=, etc. above. However, a bug in the somewhat-heuristic code deciding if a volume value should be presented in boldface or not prevented this from being executed if the given argument was longer than 4 characters. This has now been fixed as well.

As before, the volume is shown in boldface only if it is a single number consisting of either Arabic or Roman digits only or if is not longer than 4 characters in total, that is, ranges are displayed in boldface only if they are very short, and list items framed with the accept-this-as-is markup are never shown in boldface. However, given the many requests in the past asking to not display volumes in boldface at all, this can be seen as a feature as well to optionally suppress boldface also for short volume values: ((1)), ((X)), ((1-2)), ((1–2)).

Extended content

Cite journal comparison Wikitext {{cite journal|author=Author|journal=Journal|title=Title|volume=2}} Live Author. "Title". Journal. 2. {{cite journal}}: |author= has generic name (help) Sandbox Author. "Title". Journal. 2. {{cite journal}}: |author= has generic name (help) Cite journal comparison Wikitext {{cite journal|author=Author|journal=Journal|title=Title|volume=((2))}} Live Author. "Title". Journal. 2. {{cite journal}}: |author= has generic name (help) Sandbox Author. "Title". Journal. 2. {{cite journal}}: |author= has generic name (help) Cite journal comparison Wikitext {{cite journal|author=Author|journal=Journal|title=Title|volume=X}} Live Author. "Title". Journal. X. {{cite journal}}: |author= has generic name (help) Sandbox Author. "Title". Journal. X. {{cite journal}}: |author= has generic name (help) Cite journal comparison Wikitext {{cite journal|author=Author|journal=Journal|title=Title|volume=((X))}} Live Author. "Title". Journal. X. {{cite journal}}: |author= has generic name (help) Sandbox Author. "Title". Journal. X. {{cite journal}}: |author= has generic name (help) Cite journal comparison Wikitext {{cite journal|author=Author|journal=Journal|title=Title|volume=1-2}} Live Author. "Title". Journal. 1–2. {{cite journal}}: |author= has generic name (help) Sandbox Author. "Title". Journal. 1–2. {{cite journal}}: |author= has generic name (help) Cite journal comparison Wikitext {{cite journal|author=Author|journal=Journal|title=Title|volume=((1-2))}} Live Author. "Title". Journal. 1-2. {{cite journal}}: |author= has generic name (help) Sandbox Author. "Title". Journal. 1-2. {{cite journal}}: |author= has generic name (help) Cite journal comparison Wikitext {{cite journal|author=Author|journal=Journal|title=Title|volume=1-2}} Live Author. "Title". Journal. 1–2. {{cite journal}}: |author= has generic name (help) Sandbox Author. "Title". Journal. 1–2. {{cite journal}}: |author= has generic name (help) Cite journal comparison Wikitext {{cite journal|author=Author|journal=Journal|title=Title|volume=((1–2))}} Live Author. "Title". Journal. 1–2. {{cite journal}}: |author= has generic name (help) Sandbox Author. "Title". Journal. 1–2. {{cite journal}}: |author= has generic name (help)

--Matthiaspaul (talk) 20:40, 4 November 2020 (UTC)

If this is a way to circumvent/subvert the module styling, please find another solution or revert yourself. --Izno (talk) 21:01, 4 November 2020 (UTC)

This would be pointless as the volume evaluation code has always been based on heuristics trying to cover the most common cases in the most desirable way for most users, but it never ruled out potentially invalid entries. The fixed code is an improvement on this, but it still does not rule out all corner-cases, also to keep the changes minimal and the code small.

If the above mentioned behaviour (which was not some deliberately coded feature) would be actually undesired it might be possible to add extra code to explicitly test for this condition and disallow it, but I think it is easier to just not enter them this way (as before). And to rule out these combinations, that code would have to be added to the original code as well, so nothing would be gained by reverting.

However, I mentioned this possibility because we have had many requests in the past to streamline the display of volumes (that is, to not bold them at all), so some users might even find this useful (if documented accordingly). The existing heuristics were the result of trying to find a compromise so that some short and special types of volumes would be displayed in boldface whereas others would not. This works exactly like before.

--Matthiaspaul (talk) 22:40, 4 November 2020 (UTC)

An aside: I doubt that the "existing heuristics" was the result of any compromise. If I remember correctly, some years back, somebody suggested that long volume labels be unbolded because of reasons (probably purely esthetic). The initial "discussion" was barely 3 comments long, IIRC. And that was it, |volume= was reclassified into the bipolar bin. As you state, many people have asked for a resolution either way (all bold font or all regular). It must be somebody's pet cause, because nothing has transpired. Other than that, if your edits cause no harm and correct a bug (personally I was not aware of it) then I don't see why they shouldn't stand. 98.0.246.242 (talk) 03:43, 5 November 2020 (UTC)

FWIW, here are some links to former discussions regarding the bolding/non-bolding of the volume label:

• Module_talk:Citation/CS1/Archive_2#series/volume/publisher_order
• Module_talk:Citation/CS1/Archive_6#Volume_bolding
• Help_talk:Citation_Style_1/Archive_4#Bold/non-bold_volume_parameter_doc_issue,_or_bug
• Help_talk:Citation_Style_1/Archive_8#Add_a_.27volume-b.3D.27_parameter_that_skips_the_four-chr_test_for_bolding.3F
• Help_talk:Citation_Style_1/Archive_21#Separator_added_before_short_volume_names/numbers
• Help_talk:Citation_Style_1/Archive_38#5-Digit_volume_numbers_not_rendered_in_boldface_by_((cite_book))
• Help_talk:Citation_Style_1/Archive_50#When_|volume=_is_a_Roman_Numeral
• Help_talk:Citation_Style_1/Archive_51#Volume_numbers_are_unbolded
• Help_talk:Citation_Style_1/Archive_60#Inconsistent_book_volume_bolding
• Help_talk:Citation_Style_1/Archive_62#Bolding_of_the_volume_number

--Matthiaspaul (talk) 21:07, 16 November 2020 (UTC)

Improving COinS metadata output

Investigating the COinS metadata output I have spotted some areas for possible improvement on various levels. Since most of them are small and/or affect corner-cases only they aren't worth individual threads polluting the TOC, so I will combine them into this thread.

There will be more, but so far there have been only two changes, both related to the metadata generated for identifiers which have no predefined &rft.<id-name> or &rft_id=info.<id-name> tags associated with them within COinS. For such identifiers, the template uses the &rft_id=<id-link> tag to provide URLs to the external resource. The code assembling such URLs uses prefix and suffix definitions from a table defining the various properties for the identifiers. While the suffix was added to the visible URLs, there was a bug omitting to add the suffix to the identifier URLs for COinS as well. This has been fixed. However, this is an internal change only and has no impact on the actually generated metadata because none of the identifiers defined so far actually used a suffix.

On the receiver side, users of the identifier data passed through via URLs may want to retranslate it back into a human-readable form "<id-name> <id-number>". While it is sometimes possible to derive the identifier type from the URL, this is not always the case. For example, DOI and bioRxiv as well as JFM and Zbl identifiers both resolve to the same URLs, respectively:

• DOI <id-number> → "&rft_id=//doi.org/<id-number>" → ?
• bioRxiv <id-number> → "&rft_id=//doi.org/<id-number>" → ?
• JFM <id-number> → "&rft_id=//zbmath.org/?format=complete&q=an:<id-number>" → ?
• Zbl <id-number> → "&rft_id=//zbmath.org/?format=complete&q=an:<id-number>" → ?

This is not a problem in the DOI case, because a predefined info:doi tag exists and thus is used by the metadata generator instead of creating an URL for it.

• DOI <id-number> → "&rft_id=info:doi/<id-number>" → DOI <id-number>

However, to make the URLs more useable on the receiver side, the generator now appends an URI #fragment to the URLs indicating the name of the identifier. This is transparent for browsers (would this metadata be copied and pasted into the address line of a browser), but is readable for humans and scripts which can thereby pick up the original name and translate the URL back into the "<id-name> <id-number>" form for storage in their database. Examples:

• bioRxiv <id-number> → "&rft_id=//doi.org/<id-number>#id-name=bioRxiv" → bioRxiv <id-number>
• JFM <id-number> → "&rft_id=//zbmath.org/?format=complete&q=an:<id-number>#id-name=JFM" → JFM <id-number>
• Zbl <id-number> → "&rft_id=//zbmath.org/?format=complete&q=an:<id-number>#id-name=Zbl" → Zbl <id-number>

There are some interesting concepts how to further encode information in URI fragments to describe a resource or make it automatically actionable on the client's side. If we'd find a low-footprint scheme formally describing the URL as a link to information related to a specific entity of a named identifier, this could be further refined.

--Matthiaspaul (talk) 17:36, 10 November 2020 (UTC) (updated 22:45, 10 November 2020 (UTC), updated 14:26, 16 November 2020 (UTC))

I believe one or another of your changes has caused the error in test_Zbl in Module talk:Citation/CS1/errors. --Izno (talk) 19:53, 10 November 2020 (UTC)

Thanks, according to Module_talk:Citation/CS1/testcases/errors this should be fixed now (but fixing this I spotted another issue in the existing code still to be fixed). --Matthiaspaul (talk) 23:57, 10 November 2020 (UTC)

URL in identifier

Bunce, Mrs. Oliver Bell (1 September 1897). "The Turkish Compassionate Fund". The Decorator and Furnisher. doi:10.2307/25585322. JSTOR https://www.jstor.org/stable/25585322. {{cite web}}: Check |jstor= value (help); External link in |JSTOR= (help)

|JSTOR= should emit an error. --Izno (talk) 18:49, 10 November 2020 (UTC)

|jstor= is one of three external identifiers that don't get some sort of check (the others are |osti= and |rfc=). |jstor= can hold a variety of identifiers:

• JSTOR 141294
• JSTOR 10.2979/textcult.6.1.114
• JSTOR i242639
• JSTOR j.ctv136bvg0
• JSTOR resrep05670.4

And then there is stuff like this that doesn't work:

• JSTOR bullecosociamer.87.2.10
• JSTOR publication date: Dec., 1991 Full publication date: Dec., 1991
• JSTOR www.jstor.org/stable/2941426

Because there is such a diversity of |jstor= identifiers, we may not be able to validate them.

I think that |osti= and |rfc= are simple numeric identifiers. Likely we have not bothered to check these because there are relatively few uses of these identifiers. |rfc= seems to be max number between 8000 and 9000. |osti= seems to be max number between 22000000 and 23000000. So these two could be given simple limit checks like we do for |pmc=.

—Trappist the monk (talk) 23:53, 10 November 2020 (UTC)

Sounds about right for RFC. Not familiar with OSTI.

As for JSTOR, here's some ideas: looks like it has a URL, or has spaces, as errors. We should already have URL detection from title checking, which would have caught at least two pages. (Not sure about schemeless URLs?) --Izno (talk) 01:48, 11 November 2020 (UTC)

Cite book comparison

Wikitext	{{cite book|rfc=1|title=Title}}
Live	Title. RFC 1.
Sandbox	Title. RFC 1.

Cite book comparison

Wikitext	{{cite book|rfc=10000|title=Title}}
Live	Title. RFC 10000. {{cite book}}: Check |rfc= value (help)
Sandbox	Title. RFC 10000. {{cite book}}: Check |rfc= value (help)

Cite book comparison

Wikitext	{{cite book|osti-access=free|osti=1|title=Title}}
Live	Title. OSTI 1. {{cite book}}: Check |osti= value (help)
Sandbox	Title. OSTI 1. {{cite book}}: Check |osti= value (help)

Cite book comparison

Wikitext	{{cite book|osti=23000001|title=Title}}
Live	Title. OSTI 23000001.
Sandbox	Title. OSTI 23000001.

—Trappist the monk (talk) 00:14, 15 November 2020 (UTC)

Has anyone seen OSTIs lower than 1018? Otherwise we could raise the lower limit from 1 to 1018.

--Matthiaspaul (talk) 23:08, 15 November 2020 (UTC)

As so far I could not find lower OSTI numbers to be supported by the OSTI site and only found considerably higher numbers in WP, I now changed the lower bound to 1018 to catch at least some "stray digit" errors:

Extended content

Cite book comparison Wikitext {{cite book|osti=0|title=Title}} Live Title. OSTI 0. {{cite book}}: Check |osti= value (help) Sandbox Title. OSTI 0. {{cite book}}: Check |osti= value (help) Cite book comparison Wikitext {{cite book|osti=1017|title=Title}} Live Title. OSTI 1017. {{cite book}}: Check |osti= value (help) Sandbox Title. OSTI 1017. {{cite book}}: Check |osti= value (help) Cite book comparison Wikitext {{cite book|osti=1018|title=Title}} Live Title. OSTI 1018. Sandbox Title. OSTI 1018. Cite book comparison Wikitext {{cite book|rfc=0|title=Title}} Live Title. RFC 0. {{cite book}}: Check |rfc= value (help) Sandbox Title. RFC 0. {{cite book}}: Check |rfc= value (help)

Please report if you find a lower number somewhere.

--Matthiaspaul (talk) 23:59, 16 November 2020 (UTC)

Both, URL scheme and space detection could be useful, although I couldn't find any JSTORs starting with "http:", etc. (probably fixed by you already?). I found about 20 citations with invalid JSTORs starting with "www.jstor.org", though. So, an identifier value starting with the domain name from the URL prefix from /Configuration could be a good pattern as well in general, but, given that the other identifiers have more sophisticated validation checks already, it would only make sense to add to JSTOR - but still wouldn't catch someone just entering garbage...

--Matthiaspaul (talk) 16:10, 16 November 2020 (UTC)

Yeah, but at best it's a maintenance category or a properties category while we review to see what looks like trash. If we were to do something like that, we'd want to exclude obvious ones like DOI-like identifiers, as a first case. --Izno (talk) 16:31, 16 November 2020 (UTC)

A test for stray spaces and "http(s)://" at the start of the identifier string has been added to the JSTOR code.

Extended content

Cite book comparison Wikitext {{cite book|jstor=141294|title=Title}} Live Title. JSTOR 141294. Sandbox Title. JSTOR 141294. Cite book comparison Wikitext {{cite book|jstor=141 294|title=Title}} Live Title. JSTOR 294 141 294. {{cite book}}: Check |jstor= value (help) Sandbox Title. JSTOR 294 141 294. {{cite book}}: Check |jstor= value (help) Cite book comparison Wikitext {{cite book|jstor=141dfdfdf29 4|title=Title}} Live Title. JSTOR 4 141dfdfdf29 4. {{cite book}}: Check |jstor= value (help) Sandbox Title. JSTOR 4 141dfdfdf29 4. {{cite book}}: Check |jstor= value (help) Cite book comparison Wikitext {{cite book|jstor=http://141294|title=Title}} Live Title. JSTOR http://141294. {{cite book}}: Check |jstor= value (help) Sandbox Title. JSTOR http://141294. {{cite book}}: Check |jstor= value (help) Cite book comparison Wikitext {{cite book|jstor=https://141294|title=Title}} Live Title. JSTOR https://141294. {{cite book}}: Check |jstor= value (help) Sandbox Title. JSTOR https://141294. {{cite book}}: Check |jstor= value (help)

However, there is still an older bug invalidating strings with spaces (also present in the live code).

--Matthiaspaul (talk) 16:50, 19 November 2020 (UTC)

Should be fixed now by encoding the id as well.

--Matthiaspaul (talk) 20:22, 19 November 2020 (UTC)

Add an iaident parameter

CS1 templates are very complex and ever changing, and writing a bot to enhance certain references, such as book references, to make them more easily accessible to readers can have unintended side-effects, consequences that may actually make things worse. I propose adding two new parameters to the CS1 templates. The first one is iaident. When this is populated, the module can figure out where to put the link to archive.org. If a URL is lacking, it go where any URL would normally go, if it isn't, it can perhaps append it to the citation in some way like "View at archive.org" or something like that. The URL would be https://archive.org/details/<iaident>. The second parameter would be iaoffset. In certain cases where pages don't link properly, iaoffset would be used to direct the server to the correct page/location of the media being viewed. This is the raw location. When used the URL simply becomes https://archive.org/details/<iaident>/page/n<iaoffset>.

These two additions will have no impact on existing citations and will allow a more harmonious addition of readable page previews to citations without stepping on anyone's toes, or accidentally breaking something in an existing reference.—CYBERPOWER (Chat) 13:28, 16 November 2020 (UTC)

We already have provision for archive links - why do we need special provision for the Internet Archive? They don't need any further advertising here.Nigel Ish (talk) 14:07, 16 November 2020 (UTC)

Nigel Ish, what I proposed is not an archive link, it's a link to a book scan at Internet Archive for readers to preview in an attempt to improve verifiability. The addition of these links is already approved, so the claim they are advertising is false. Internet Archive has nothing to gain from "advertising" their service. They are not making any revenue off of it. For example, you have a Cite Book reference with no link to be able to view the book. That's what this will serve. It only serves to make it easier for readers and editors to verify a claim on Wikipedia. I don't see how this does anything but help Wikipedia's core principles. —CYBERPOWER (Chat) 14:43, 16 November 2020 (UTC)

I am not sure I understand. As noted above, there's an archive url parameter already, for works that can be found in an archive. And |via= can inform the reader that the version of the work they are reading is published in an archive. If the work is only found in an online archive, then what is cited is the archive, likely via {{cite web}}. The particulars of the citation will make this obvious. I don't know what this has to do with bots "enhancing references" or how complexity can be reduced by adding even more specialized parameters. 65.204.10.231 (talk) 14:13, 16 November 2020 (UTC)

To explain more clearly, archive URL is for archives of website. What I'm proposing is not an archive of a web page. It's a media URL of a book, magazine, whatever, that stored at Internet Archive. As it currently stands, these URLs are placed in the url section, but doing that may have other consequences such as clashing with title-link, or something else I, or another botop may be unaware of. The proposal is to just put this info in it's own parameter so the template can deal with it appropriately. —CYBERPOWER (Chat) 14:47, 16 November 2020 (UTC)

Archive URLs point to any item archived online, be it webpage, book, video etc. As mentioned previously, when one cites s scanned item at Internet Archive, one is actually citing the archive. The source (in this case a website) is the Internet Archive. The scanned item (they are all digitized by scanning or other means) is an entry (webpage location) in that website. There is no need for an identifier, and I still don't understand how bots enter into this. If you feel something like that is needed, you can always make a wrapper for {{cite web}} as a single-source/special purpose template for Internet Archive. There are several examples. 50.74.165.202 (talk) 16:44, 16 November 2020 (UTC)

There are over 600,000 citations that link scanned books. Examples. It does seem kind of silly we don't use the ID system for this, it is one of the most frequently linked things on enwiki. There are 3.7 million {{cite book}} templates and if all these were in cite books (most are) that is 16%. -- GreenC

Most identifier parameters do not contain "id" or "identifier" in their name, so if this is introduced please just call it "ia" or "internetarchive". Note that we already have OpenLibrary identifiers that can be used to link a large part of IA books (but not other content).

I have no opinion on whether using an identifier is preferable to using the URL, but I support the stated goal (to facilitate linking books). Maybe it can simply be achieved by some Lua transformations on the URL? Nemo 16:24, 16 November 2020 (UTC)

Which reminds me that we should put |ol= into the metadata to make it easier for third-parties to correlate the data. (The technical reason for why we don't include it already is because different OL identifiers require different prefixes and this doesn't fit very well into the current implementation.)

--Matthiaspaul (talk) 16:47, 16 November 2020 (UTC)

Nemo bis, No objections to the naming conventions. —CYBERPOWER (Chat) 17:01, 16 November 2020 (UTC)

(edit-conflict) So, what you both are asking for is basically an identifier for archive.org, so that it does not occupy the title link? I like this idea, and if this identifier would be included in the list of auto-linking targets, it would be as convenient to use as if it would occupy |url= by itself but only be considered by the template when |url= is not specified as well. This would free |url= for other uses. If this is what you propose, I would support it. Ideally, though, this parameter would not take a complete URL such as "https://archive.org/details/sixmonthsatwhit02carpgoog" as a value, but just an id (like "Identifier=sixmonthsatwhit02carpgoog"). How does this correspond with the "Identifier-ark=ark:/13960/t40s07c8h"? Is it possible to derive the former from the latter (ark)?

Is my assumption correct that these scanned documents do not need to be archived any more because they can be considered to be archived already, that is, these links will be permanent? This would be another argument for having a specific identifier parameter for them and leave |url= with its |archive-url= companion for links which actually need |archive-url= to prevent link-rot.

--Matthiaspaul (talk) 16:38, 16 November 2020 (UTC)

We are not in the business of developing identifiers, nor extracting homebrewed ones from URL fragments. Neither is this a novel idea, similar have been discussed before. It hasn't happened for the reasons already spelled out here. This is more or less superfluous. Adds complexity. Brings nothing extra to discovery. Hasn't anyone noticed that editors can insert custom ids? In |id= an editor can insert the source's own identifying scheme, if any. 50.74.165.202 (talk) 17:01, 16 November 2020 (UTC)

Matthiaspaul, everything at Internet Archive is intended to be there permanently. There are some very rare exceptions to that rule, but what is saved to the Internet Archive will generally stay there forever. —CYBERPOWER (Chat) 17:14, 16 November 2020 (UTC)

I'm actually not aware of Identifier-ark. What does it do? —CYBERPOWER (Chat) 17:16, 16 November 2020 (UTC)

On the page (https://archive.org/details/sixmonthsatwhit02carpgoog) I linked above (nothing special, just the first example I found writing this), the entry "Identifier" contains the value "sixmonthsatwhit02carpgoog", and the entry "Identifier-ark" the value "ark:/13960/t40s07c8h", respectively. I have seen those "ark" identifiers in other IA pages related to scanned books, that's why I am interested in how they are related. --Matthiaspaul (talk) 18:01, 16 November 2020 (UTC)

Matthiaspaul, okay, I just wanted to be sure, but they are completely unrelated. It is not possible to derive either value from the other. —CYBERPOWER (Chat) 13:05, 17 November 2020 (UTC)

I support the addition of a |ia= with the caveat that it should be documented to take the Internet Archive identifier (and, yes, these are unique identifiers assigned by IA; they just don't have a resolver that abstracts the identifier from the physical address (URL)) of the scan where the information it supports was found, rather than any old scan of some book that may or may not be the same work in the same edition in a copy sufficiently identical to the original to support WP:V. People will still use it sloppily of course, but if the definition is strict we at least pull the trend in the right direction over time. This also means we treat it as an identifier and not a convenience link (those can go in |url=). This means the derived URL should not be auto-promoted to the |url=. It also means the parameter should not be bot-populated unless other information in the template uniquely identifies the scan to which it refers. IA book scans are a great resource and we should take advantage of it to the fullest extent practical, but not uncritically and sloppily.

I don't see the case for the proposed |iaoffset= parameter, and at first blush it would seem to be conceptually in conflict with everything else in CS1. --Xover (talk) 18:57, 16 November 2020 (UTC)

Xover, iaoffset is needed in the event the page number itself is not providing a working link to the target page of the book. iaoffset will change the link to the raw location of the book you want to view, which will always work. It's hopefully not going to be needed often. Use cases are roman numerals or numberless pages being referenced. —CYBERPOWER (Chat) 13:07, 17 November 2020 (UTC)

I have seen digitized blobs of many journals/magazines/collections in one file. Would this |ia-offset= (provisional name) be useful to point to the start of the relevant work as well?

However, I'm not too fond of adding two parameters for this. Perhaps, in those cases where it is needed, it should be allowed to just append /page/n<iaoffset> to the identifier... '/' is obviously a character which can never occur in the identifier. Are there other "reserved" characters? What is the format of these identifiers (as RegEx or similar)?

--Matthiaspaul (talk) 13:44, 17 November 2020 (UTC)

Matthiaspaul, n<iaoffset> is a pointer to the raw page scan location of the work. For example, n5 would take you to the 5th image scan of the media, which would probably be the cover page, or book information and copyright. n10 may take you to a page in the book with the page number iii. Conversely, dropping the n will take you the book's page 10. In most cases the n prefix doesn't need to be used, but there are cases where they are required so the link goes straight to the desired page that has the information needed to verify the reference. —CYBERPOWER (Chat) 13:54, 17 November 2020 (UTC)

Is there a document describing the inner format (if there is any) of these identifiers for validation checks, or are they just strings of random length containing random characters without checksum or date information? Who composes these identifiers and according to which rules?

--Matthiaspaul (talk) 15:01, 17 November 2020 (UTC)

Matthiaspaul, nope. There is no hidden information in these strings. They're effectively almost random. —CYBERPOWER (Chat) 21:01, 17 November 2020 (UTC)

@Cyberpower678: I understand its intended functionality, but I still don't see the case for adding it. No other identifier supported in CS1 links directly to a specific page (caveat: there are some field-specific ones in there that I'm not that familiar with), but to the work as such or a specific copy of it, and that's quite good enough. Linking directly to a specific point in a source is at best a convenience, and in some contexts can even be a (very very minor) inconvenience. Matthiaspaul's example above (linking to a specific article within a magazine or a specific issue within a whole volume collection of a periodical) is the best use case for this, but even in those instances it falls into "convenience" territory and fails to justify the addition of a dedicated parameter IMO (and the same goes for the additional complexity of trying to encode it into the identifier; identifiers should generally be opaque). --Xover (talk) 14:34, 17 November 2020 (UTC)

It seems that we have heard this type of request before, particularly for a google books 'id'. If I remember correctly, those requests were rejected because the 'id' isn't a persistent id and in fact, isn't an id at all, but merely a token in the url query string. I also recall Semantic Scholar's wish for an identifier. They originally wanted us to use the forty character path element from their url:

https://www.semanticscholar.org/paper/041a49f7fdc8eef74ac2e52a768011ed0c29d0ce

Before we would let them have a cs1|2 identifier, we required them to create a simpler form, their corpus ID which they then map to whatever url they want:

https://api.semanticscholar.org/CorpusID:219352572

|s2cid=219352572

The |ia-identifier=sixmonthsatwhit02carpgoog seems a lot the same to me.

HathiTrust, uses the handle system to link to books and to specific places in that book. For example, their copy of Six Months at the White House with Abraham Lincoln is here:

https://hdl.handle.net/2027/uc1.$b301895

and to link to page 15 they give this as the handle:

https://hdl.handle.net/2027/uc1.$b301895?urlappend=%3Bseq=23

I could imagine an IA corpus ID (something with a check-digit would be good) so: |iacid=<corpus ID> for the book and if a particular scan is desired then perhaps something like |iacid=<corpus ID>.n<scan ID>. cs1|2 would then build a handle system url that internet archive can redirect to the appropriate location

Why isn't Internet Archive listed at Special:BookSources?

—Trappist the monk (talk) 12:41, 18 November 2020 (UTC)

All this is well and good, but also a moot point since any such id is not necessary. It adds nothing that cannot easily be done now, without it. Instead of wasting time in trinkets, I would direct everybody's energies into fixing the many design and logical flaws in the cs1/cs2 system. 65.204.10.231 (talk) 13:42, 18 November 2020 (UTC)

(edit-conflict) I have run into cases in a citation where I wanted to include a "genuine" URL to some document/site but also had a link to a digitized copy of the work at Google Books or Internet Archive, so I had to append some of those links after the citation as convenience links. I have also seen editors or bots/scripts "fighting" over those entries by replacing the URL in |url= by one of the Google- or IA-type ones. It would have been much better, if those extra resources could be listed among the identifiers, so that they don't occupy the place of |url= any more and the bots would have a dedicated place where to put them without disturbing anyone. If parameters like |ia= or |gbooks= (provisional names) would be included in the list of auto-linking identifiers, they could still show up as title links if none of the other links take precedence.

However, as Trappist correctly pointed out, it only makes sense for "identifiers" which are established and stable long-term and don't need an archived link to prevent link-rot (because they are already sort-of-links-to-archived-copies). Also, it would be great if they would be shorter and follow some logical system (or we'd have to devise some way to link to them without showing the value)...

As Cyberpower and GreenC both have good connections to IA, they likely know who to ask at IA to make this happen.

--Matthiaspaul (talk) 16:28, 18 November 2020 (UTC)

Matthiaspaul, identifiers don't change. Once assigned, they are permanent. —CYBERPOWER (Chat) 21:44, 18 November 2020 (UTC)

BTW. They already have property assignments in Wikidata:

• ia: P724
• gbooks: P675

So, if we'd have corresponding parameters for them they could be used by {{cite Q}} as well.

--Matthiaspaul (talk) 17:34, 18 November 2020 (UTC)

Trappist the monk, IA identifiers however are persistent and do map to a specific scan. I'm not sure what exactly you are asking here. They are not tokens. The addition of /page/<page> further points to a specific location of said scan. This will never change. Further more the use of page, p, pp, pages, can be used by the module to assist in said pointing unless overriden by the offset parameter, or by the specification of /page/<page> in the identifier param. —CYBERPOWER (Around) 16:02, 18 November 2020 (UTC)

This will never change. Maybe; maybe not. Whatever mechanism IA uses is proprietary to IA. It seems better to me to avoid proprietary systems and use a system supported by many users so the handle system seems to fit; cs1|2 already supports |hdl= so we don't have to craft something special for IA.

I'm not sure that I see the need for a separate identifier. The primary use of cs1|2 templates is (supposed to be) to identify the source that the en.wiki editor consulted to support our article. I have never really felt comfortable with bots adding, and especially replacing, urls that the bot surmises may link to the source the editor consulted. Unless these bots have learned how to mindread, the bot does not and cannot know with any certainty what source the editor consulted. If editors want to blue-link titles to sources available at IA, they can use |url= to link to the source that they consulted.

The only question I asked, and that you did not answer, was: Why isn't Internet Archive listed at Special:BookSources?

—Trappist the monk (talk) 20:20, 18 November 2020 (UTC)

Trappist the monk, I can't answer that question. I'm not familiar with the functions of Special:BookSources. I don't understand your argument of proprietary. The strings are arbitrary, and unique to the book scan it's linked to. A bot does not need to mind read to ISBN match a book to something stored at Internet Archive. ISBNs are also unique, so there's no mindreading going on here. A unique identifier to a book, added by a human, is being matched to a unique identifier at IA. —CYBERPOWER (Chat) 21:41, 18 November 2020 (UTC)

In concept ISBNs are unique. In practice, they are not always unique. In past discussion on this page, Editors noted that ISBNs are not always unique because different editions may have different pagination, different covers, etc. But ISBNs are why I asked about Special:BookSources. If it is possible to search IA with an ISBN then IA should be listed at Special:BookSources; if google and amazon, why not IA? Get IA listed at Special:BookSources and there will be no need for a special identifier in cs1|2. A listing at Special:BookSources does not prevent editors from adding direct links with |url= to the facsimile at IA, and may increase the use of IA urls for books; better to link to IA than to google or amazon, isn't it? Google and amazon are right there at the top of the list at Special:BookSources; is it any wonder that editors looking for courtesy links use them?

Does citoid know about books at IA? If not, why not? I know that citoid knows about worldcat which has abominably poor metadata. If you can demonstrate that the metadata at IA are as good or better than the metadata at world cat, I would think it a no brainer for citoid to use IA, especially because IA has copies of the books it indexes whereas worldcat does not.

The strings are arbitrary... Arbitrary. That's certainly part of it for me. The strings are arbitrary and, for the example in this discussion, sixmonthsatwhit02carpgoog, seem to suggest that google is where I will land if I click on that 'identifier'. Arbitrary does not look systematic, it does not look professional. Editors at discussions here and elsewhere have complained that readers won't click on identifiers because they don't understand the meaning of the initialisms and so are intimidated. I think that our readers smarter than that; especially readers who have gotten to the point of following an article far enough that the references matter.

I don't think that a proprietary system that uses arbitrary strings benefits en.wiki. I have a hard time believing it whenever anyone says [this] will never change. This is the internet; nothing on the internet is static. A non-proprietary system, supporting multiple users is, I think, a better long-term choice for en.wiki because the stable identifier abstracts to the actual url of the source. That url can change as source providers upgrade their technology and internal data handling without it impacting us.

—Trappist the monk (talk) 00:23, 19 November 2020 (UTC)

A couple of points here…

I agree, and have previously suggested to both Cyberpower and Markjgraham, that they should first pursue options for making IA links easy for humans to add, specifically through Special:BookSources and Citoid. I am worried by their failure to pursue these options and read it as indication that they are only really interested in approaches that let them bulk-add links to IA via bot (cf. WP:VPP § Stop InternetArchiveBot from linking books and WP:BOTN § VPPOL discussion closed: linking by InternetArchiveBot). Bots are not a good match for this problem, and wishing screws were nails does not make the hammer any more suited.

That being said, the identifiers for works at IA have several of the important properties of identifiers (vs. addresses). They are unique, have a controlled syntax, are stable over time; and these properties are backed by guarantee from a generally well respected organisation of sufficient demonstrated longevity for our purposes. The properties it lacks are abstraction (it maps directly to an address in a static way) and a facility for resolving the identifier to an address other than the resource's current canonical address. It is also a proprietary identifier, and one backed by only a single organisation. However, this is no worse than |jstor=, and in some ways better because unlike JSTOR's "Stable URL", IA does actually treat this as an identifier. It is picked by the uploader, often according to a suggested schema, but it it assigned and managed by IA; and, crucially, it shows up in various APIs on their side where e.g. JSTOR would have used the URL (i.e. they actually treat it as an identifier in practice). It would be better if IA registered a HDL or DOI for each scan, but I don't see this as a bright line. I don't think an identifier's visual appearance, or the presence of certain substrings, are fair objections. Identifiers should be opaque except any defined hierarchy (DOI prefixes and such), and if they are too long their display can be truncated (or people will choose not to add them).

Specific params for such identifiers also makes it easier for users to discover (and thus actually make use of) than generic ones, and makes it easier to add multiple links where that is relevant. Having spent far far too many hours manually cleaning up article references I very much appreciate every additional identifier available, because even nominally stable identifiers like DOIs die in the timescales we care about. I don't know any services mirroring IA specifically (unlike JSTOR and Project MUSE that often both have copies of a given journal issue), but just as an illustration we have a lot of IA works uploaded at Commons. Being able to point both at the original at archive.org and the alternate copy at Commons will save somebody's behind a decade down the line when IA decides to annoy the publishers enough to get sued out of existence (or whatever).

Finally, there is not a 1:1 relationship between an ISBN and a specific scan of a specific copy of a specific edition of a specific work. Starting from an ISBN you can get to a search that lists lots of these, but you can't point at only one. That's (part of) why bot adding these links is a bad idea and Special:BookSources is the most appropriate avenue for making IA accessible at volume. But starting in the other end, you certainly can add the identifier of the specific scan you consulted when adding the reference. And sometimes the ability to specify a copy of a book (there are multiple advanced academic degrees made based on the copy-to-copy differences in the First Folio), and even the scan used of that copy (the same copy scanned by both Google and IA may have material differences in quality (hint: Google's scanner operators exhibit not a single fig given about quality)), is important.

Bottom line, for me, is that while this is not a no brainer, I ultimately fall down on the side of wanting this parameter. I also wish IA would actually participate here, and discuss issues surrounding linking, discoverability, metadata (their's is almost as bad as Worldcat's, just in different ways), but absent that I'll settle for ways we can more effectively make use of IA as a resource. --Xover (talk) 09:35, 19 November 2020 (UTC)

And then there is this 'identifier': northangerabbeyb00aust_1. Apparently, accuracy in creating these 'identifiers' is not a criteria for their creation. Some sort of numerical corpus ID (just take the next available number) would be much better than seeing an identifier naming Northanger Abbey in a citation for Pride and Predjudice: https://archive.org/details/northangerabbeyb00aust_1. That url was added by bot. It does illustrate the offset issue. The cited page is vii so the page link that the bot added did not work (since removed) but, had the bot written [https://archive.org/details/northangerabbeyb00aust_1/page/n9 vii] it would have worked: vii.

—Trappist the monk (talk) 14:16, 19 November 2020 (UTC)

Correct. Pages can be referred to by the physical leaf number, or the printed page number. For example anything without a printed page number, such as anything before printed "Page 1", it uses the "/page/n10" syntax eg. the 10th page leaf from the start. If the printed page number can't be asserted due to scanning errors, etc.. it uses the "n" leaf system. Determining (asserting) the printed page number from a OCR scan is not always possible, indeed technically challenging, so this is the default method to get to a page when page assertions are unavailable. -- GreenC 15:43, 19 November 2020 (UTC)

I wonder why this subject invites such elaborate discussion. All IA items are online. There is already a standardized, constantly utilized, familiar locator (the URL) to easily reach the referenced archive, as well as in-source locations such as specific pages (in the case of archived print media). Is there any reason for IA to have preferential treatment over other archives? Archives, just like any other source, are not automatically reliable. Afaik, IA's archiving protocols are opaque, and the resulting archives not vetted. Granted that the last time time I looked at IA governance was several years ago, but I was surprised to find out that there were no official "Archivist" positions at the organization. That is like having libraries without trained librarians. Not that university archiving operations are much better. I have seen horrible scans of well known works in such institutions. In some cases, really bad version control, with a different archive of the same original showing up seemingly randomly, no doubt thanks to some mysterious algorithm. But do go ahead and try to make sense of all this if that is your thing. 98.0.246.251 (talk) 01:59, 20 November 2020 (UTC)

Discussion is good, for as long as it remains constructive and aims at seeking the best solution to address a problem as this one.

I too am somewhat sceptical of unmanned bot actions for tasks where editorial judgement might be necessary.

I nevertheless support the addition of this identifier because it is also useful for editors manually improving citations. There is often more than one link that could be added to |url= and it would be good to have a separate place for at least the most common and established providers of content to free the |url= parameter and its companion |archive-url= for better purposes in order to improve the quality and usefulness of citations and to fight link-rot. Both, GB and IA identifiers have proven to be stable for many years (with minor exceptions), more stable than many URLs to other sites, but in the hyphothetical case that they would suddenly change their link formats, change their identifiers or change their services in unacceptable way, it would be trivially easy for us to centrally adjust or mute the corresponding template output, that is, it gives us more control.

Still, it would be great if IA could introduce some abstraction layer on top of their identifiers first, so that they become shorter and do not contain potentially misleading human-readable text fragments.

--Matthiaspaul (talk) 20:42, 21 November 2020 (UTC)

Well, my comment was centered on the opinion that there is no pressing problem to add anything. The idea that identifiers can be used as failovers for URLs, may not really hold water. For the simple reason that practically all ids are basically wrappers for, or reformatted abstractions of, URLs. One could argue that some ids may be using a different repository, or other (supposedly) authoritative service, or just simply a mirror that may stay up. But all of these can break too, and I do not know that we have a way to judge the future stability of the underlying infrastructure. I assume some, such as ISBNs (that resolve at web servers run by trade-affiliated entities) are more robust than others, simply because they are by now necessary for commerce. But even ISBN resolvers are known to have gone down. 98.0.246.242 (talk) 01:56, 22 November 2020 (UTC)

Obviously, we cannot predict the future. However, I don't know when they have been introduced originally, but both IA and GB identifiers have proven to be static for more than a decade already, and from the descriptions on their web sites they both see them as permanent long-term identifiers for use in public interfaces, not as short-time or only internal handles only accidently leaked to the outside world which could change/be renumbered the next time they set up their databases.

https://archive.org/services/docs/api/metadata-schema/index.html

http://blog.archive.org/2011/03/31/how-archive-org-items-are-structured/

https://developers.google.com/books/docs/v1/using#ids

So, it doesn't look as if they would intend to change them (to the better or worse) in the foreseeable future.

--Matthiaspaul (talk) 22:32, 23 November 2020 (UTC)

To reiterate, nobody will stop you if you wish to insert any "official" or semi-official identifier in |id=, regardless of whether such is well maintained or not. But there has to be a more compelling reason to formalize these into yet more parameters. Not every secondary identifier must be coded, documented and explained. This particular citation system is already overly complex and there is a good chance that the needs of the non-expert reader are not met. The litmus test: the most complex citation possible should be understood by the least knowledgeable reader possible. 107.14.54.1 (talk) 01:21, 24 November 2020 (UTC)

Matthiaspaul, It's that argument there why them shortening the idents is not likely to be changed. The static nature of the identifiers, once they are created they never change. —CYBERPOWER (Happy Thanksgiving) 13:56, 26 November 2020 (UTC)

Okay, I see that point, continuity is important, but given that the format is (almost) free-text at present, they could change it to become something more systematic and shorter for all future IDs and keep the existing ones as legacy. They could also assign a second ID following the new naming scheme to all of the older entries, keep the old IDs working forever but list the new IDs first. One ID for two targets would be a problem, but two IDs pointing at the same target is not.

This would allow external parties to slowly move to the new scheme, but would not break any old reference links from printed sources (if they exist) or from external parties which are not actively maintained and will keep pointing to the old ID forever as well.

--Matthiaspaul (talk) 14:12, 26 November 2020 (UTC)

Matthiaspaul, I doubt that would happen. The only time I would imagine a scheme change is if there were no other way to implement a function at a technical level. I could certainly ask, but bear in mind IA's infrastructure is immense. It may not be technically possible to implement this without diverting considerable resources into its implementation. —CYBERPOWER (Around) 23:59, 30 November 2020 (UTC)

Please ask them specifically mentioning our potential use-case in citations. I think it should be in IA's own interest to learn about options how to improve their services. Right now, their decision makers might not even be aware of that the current form of free-text identifiers is seen as problematic for use in citations and that a revised naming scheme would significantly improve their acceptance.

The new scheme could be either completely opaque or, if the goal is to also encode some information about the target object, the encoding should follow some well-defined rule set (not the ad-hoc style used today which can create misleading-to-humans identifiers such as in the "northangerabbeyb00aust_1" example mentioned above). If possible, the resulting identifiers should be shorter than the current ones so they look nicer and occupy less space in citations. They can contain digits and letters, either all-upper- or all-lowercase and from the 7-bit ASCII alphabet, no spaces, underscores, dashes, slashes or other special characters (except for hyphens). Longer groups could be separated by hyphens for easier reading and improved wrapping behaviour. For plausibility checks, the identifier should ideally include a checksum and a truncated datestamp of creation (f.e. binary encoded yyww). If old and new form were to share the same API, the new form should provide some means (a prefix?) to allow machines to distinguish between both of them, so that different checks can be applied.

--Matthiaspaul (talk) 15:10, 1 December 2020 (UTC)

ISBN line breaks

Moved from Template talk:Citation § ISBN line breaks

 – {{u|Sdkb}} ^talk 20:05, 16 November 2020 (UTC)

Screenshot; look at ref 114

During the ongoing FA review for Biblical criticism, I noticed that some ISBNs in the citations with dashes (e.g. Bauckham, currently ref 114) break onto multiple lines. This makes them marginally harder to read, so I think it would be preferable if they were non-breaking. Would it be possible to place a {{no wrap}} around the input for |ISBN= and other parameters that might have the same issue? {{u|Sdkb}} ^talk 18:09, 16 November 2020 (UTC)

In my browser, ISBNs and the "ISBN" text are always nowrapped, no matter how I modify the window width. Perhaps you could create a demonstration page in your sandbox, or upload a screen shot. – Jonesey95 (talk) 18:22, 16 November 2020 (UTC)

@Jonesey95: Screenshot added. {{u|Sdkb}} ^talk 18:34, 16 November 2020 (UTC)

reference info for Biblical criticism

unnamed refs	69
named refs	132
self closed	229
Refn templates	8
cs1 refs	208
cs1 templates	215
rp templates	296
webarchive templates	9
use xxx dates	dmy
cs1|2 dmy dates	11
cs1|2 ymd dates	3
cs1|2 last/first	196
cs1|2 author	4
List of cs1 templates cite book (169) Cite book (2) cite encyclopedia (2) cite journal (14) Cite journal (2) cite news (1) Cite web (11) cite web (14)
explanations

As far as I know, there has only been one previous discussion about preventing the rendered isbn from wrapping (there was an earlier discussion where it was mentioned). The discussion did not gain sufficient support.

Why now, all of a sudden? There are a lot of FAs that use cs1|2 and that have |isbn= with hyphenated isbns; the category has 6,556 articles of which 4,774 have hyphenated isbns; see this search.

A better venue is Help talk:Citation Style 1 because Biblical criticism does not use {{citation}}.

—Trappist the monk (talk) 18:59, 16 November 2020 (UTC)

Trappist the monk, I wasn't aware of that previous discussion; thanks for the link. The "why now" is just that I happened to notice it now while doing that review. And I'll move this to that venue.

While there's not uniformity in the prior discussion, it does look like there's enough support that consensus might develop with further discussion. What I notice is that there is a non-breaking space between the ISBN label and the number itself. Surely that would be a better breaking spot than any of the hyphens within the number? We should either change that to a breaking space, make the number non-breaking, or both, but definitely not neither. {{u|Sdkb}} ^talk 20:02, 16 November 2020 (UTC)

We also recently touched this in Help_talk:Citation_Style_1#Nbsp_in_|author,_|last,_and_equivalents_for_other_contributors

We currently frame ISBNs in <bdi>.

I would support to make the numbers for ISBN, SBN, ISSN, EISSN and ISMN identifiers as well as all dates (except for in the |orig-date= parameter) in suitable date formats non-wrapping. If this wouldn't grow the length of the non-wrapping string too long, this would ideally include the identifier names as well, but at the minimum we should keep the numbers from wrapping.

--Matthiaspaul (talk) 20:49, 16 November 2020 (UTC)

Following the example of many other messages containing short symbols/abbreviations (for example with volumes), to avoid odd-looking line breaks the sandboxed template now utilizes   in the message fragments used to display " et al.", " ed." (for edition) and "§ " and "§§ " (sections).

--Matthiaspaul (talk) 13:59, 17 November 2020 (UTC)

Matthiaspaul, I'm somewhat at a loss of how to push this forward. Should we start a survey to make consensus clearer, or is there some technical hurdle, or do we just need to make an edit request? {{u|Sdkb}} ^talk 21:17, 24 November 2020 (UTC)

Nowrapping things is a crutch. The web interface will never be perfectly typeset, and in almost all cases you will cause someone's (usually on mobile) experience to suffer from nowrapping various content. I generally oppose it, and don't see particular reason here to do so, especially given the length of identifier strings (which anyway have a separate introducer that is of sufficient length to get the point, unlike with page(s)). --Izno (talk) 21:32, 24 November 2020 (UTC)

That's part of the reason why I suggested to apply the no-wrapping only to a selected set of identifiers such as ISBN, ISSN, etc., not to identifiers with non-hyphenated values, not to those with longer values such as DOIs. And also to apply it only to their values, not the combination of name plus value as a whole. These value strings appear to be short enough to make it unlikely that they would force the browser into some horizontal scrolling mode. They are also still short enough to be often transscribed manually (for which it is particularly important for the eyes that the value gets displayed on a single line). So, these are the identifiers for which I see the largest user benefit of applying no-wrapping.

Either way, I would think that, on mobile or embedded devices with very narrow viewports and possibly even without scrolling capabilities, a dedicated browser would simply ignore <span class="nowrap">...</span> before it starts to scroll or truncate. For non-dedicated browsers, couldn't this be solved on Timeless skin-level (CSS)?

--Matthiaspaul (talk) 16:27, 26 November 2020 (UTC)

Cite OEIS generates invalid HTML

While updating Happy number, I tried to add "Cited in (an OEIS citation)", but noticed that every citation generates an id "CITEREFSloane" by default, which is incorrect HTML with more than one citation. When I tried to specify an explicit |ref= I got a cite error "Unrecognised parameter". I could not immediately see why that was, so I created the link by a bodge. This of course continued to annoy me, so I had another look this evening.

Apart from the constant id, there were two problems which are fixed in this (current) revision (testcases). The link after the final refs testcase jumps to the test citation for the live template and there are now no errors for the ref parameter displayed.

We also need to correct the default ref id. I propose a default id of

CITEREF<editor-last>_"<sequenceno>"

for which the user would add something like

{{sfn|Sloane "A12345"}} or {{harvtxt|Sloane "A12345"}}

to link to this, which seems both reasonably simple and clear. The quotes around the sequence number correspond to the quotes around the full entry title in the citation. You can see this in the (current) sandbox. In the testcases, the link after the next-to-last testcase for dates jumps to the test citation, but the live citation still has the incorrect id. Of course, I will update the documentation accordingly.

There may be other cite wrappers with the same problem now that cite * generate ids by default. Parameter check lists also need themselves to be checked.

Just as I finished preparing this, I notice that the testcases no longer display the missing error messages for the |foo= and |date= parameters. I can't see any reason for this at present. They appear in preview mode.

Comments welcome, especially "yes, please do it" of course. --Mirokado (talk) 22:54, 20 November 2020 (UTC)

{{Cite OEIS}} is not a cs1|2 template. Problems with that template are best addressed at its talk page. If there is something wrong with the underlying {{cite web}}, then we want to know about it.

—Trappist the monk (talk) 23:09, 20 November 2020 (UTC)

OK, copied most of this to Template talk:Cite OEIS#Generates invalid HTML for further comments.
"Other cite wrappers causing the same problem now that cite * generate ids by default" is certainly something relevant to this page, even if there is no really easy central solution. If someone is bored on a wet Saturday afternoon, here is something for them to look at. --Mirokado (talk) 00:24, 21 November 2020 (UTC)

Those other wrapper templates, like {{Cite OEIS}}, must adapt if they haven't already done so. This is really no different from wrapper templates needing to adapt when old forms of parameter names that the wrappers use are deprecated and support for them withdrawn. The issue that you are complaining about, automatic CITEREF anchor creation, changed nothing because |ref=harv was specified with this edit to {{Cite OEIS}}. That setting became superfluous when cs1|2 began creating automatic CITEREF anchors. With this edit, {{Cite OEIS}} lost the superfluous |ref=harv setting and gained the ability to set the citation's CITEREF anchor externally.

—Trappist the monk (talk) 00:59, 21 November 2020 (UTC)

Undated sources

At present a source without a stated date uses the format date=n.d., and displays as
The newspaper. n.d. Retrieved 6 December 2015.
This is rather obscure to the reader. I would suggest either that date=n.d. be retained in the cite parameters, but displayed to the reader as "Undated", or that date=undated be allowed and displayed. (A display of "No date" for parameter n.d. would be OK.)

A parameter that tells editors that a reference is undated also saves an attempt to find and add a date, in the same way as the recommended author=<!--not stated--> does.

Example with date=n.d.:
"Pooley Bridge, Cumbria". Britain Express. n.d. Retrieved 6 December 2015.

Example with unsupported date=Undated:
"Pooley Bridge, Cumbria". Britain Express. Undated. Retrieved 6 December 2015. {{cite web}}: Check date values in: |date= (help)

Best wishes, Pol098 (talk) 13:35, 23 November 2020 (UTC)

This is rather obscure to the reader. Really? Why do you believe that readers are incapable of understanding this rather common initialism? It is perfectly acceptable to omit |date= when the source is not dated. Similarly, it is perfectly acceptable to write |date=<!--no date--> for the benefit of editors if you think it appropriate.

Beyond incompetent readers, is there any substantive reason for cs1|2 to deviate from what is, apparently, accepted practice among the various external style guides?

—Trappist the monk (talk) 13:53, 23 November 2020 (UTC)

"Beyond incompetent readers ..." Requiring readers to be "competent" (and not necessarily English speakers; English Wikipedia is used worldwide) is not a good idea. Dropping "n.d." into the middle of a reference isn't necessarily clear ("Date=n.d." would be clearer, though "Undated" is better). To answer the question as asked: there is no substantive reason beyond "incompetent readers"; but that is enough for what is a trivial change without consequences (unless I have missed something) which will help readability. Let's see what others say. Best wishes, Pol098 (talk) 14:58, 23 November 2020 (UTC)

Just adding "undated" to the set of allowed input values would in fact be trivial. However, thereby we could not only not achieve consistency in the output, but even decrease it, as the template would display whatever was given as parameter input.

What I envision is a bit more: To catch the allowed keywords as parameter input but display the same predefined text for all of them. I'm open in regard to if we would keep the "n.d." text and just add some tooltip to it (which has my preference at present) or to change it to "undated" or "no date" or whatever has consensus.

What would also be possible is to catch the various keywords on input, but only accept one of them as the new valid input (for this I would suggest |date=none for consistency with other parameters already using the none keyword) and issue "extra text" warnings for the other inputs (like "n.d.", "nd", etc.) so that existing citations could be updated accordingly. Still, the output would be the predefined text "n.d." plus tooltip, "no date" or whatever we decide.

This could also be implemented gradually so that there is enough time to adapt.

--Matthiaspaul (talk) 17:38, 26 November 2020 (UTC)

(edit-conflict) Our target audience includes "incompetent readers". Our goal as an encyclopedia for everyone is to improve their education and competence. (Personally, I would not call someone "incompetent" just for not knowing what "n.d." or "3 (12): 7–8" means.)

While "n.d." is one accepted practise to indicate a "no date given" condition, it is only one of them. There are different styles how to denote this, from variations on the abbreviation (with or without space, in different cases and with varying interpunctation) to spelling it out as "no date" or "undated" (in different cases and possibly bracketed). While most people who are not aware of the abbreviation should be able to guess that "n.d." means "no date" if given instead of a date, others might not ("not documented", "not displayed", "new data", "next date", "named date", "no dummy"?). Our general philosophy is to avoid abbreviations which might not be understood by everyone.

As I have stated in the past already, I'm all in favour of tokenizing such special cases (we already do this in some cases, f.e. with "et al." - although this one is special also in other ways). This has several other advantages as well:

• Improved machine-readability
• Consistency within articles and across the project in regard to how to indicate this condition
• Control over the display output and metadata format should the recommended output format change over time (think of the discussions regarding how to display volumes, issues and pages) or if we would want to support other metadata standards in the future (beyond COinS) where this condition might be codified somehow. Even if we would not change the output format from "n.d.", it might be already helpful for readers if we'd display a tooltip with its expanded meaning. And in the metadata, it could be changed to "[n.d.]" to indicate a descriptive date rather than an actual date.
• Easier localisation into other languages (for the same reason why we prefer |language=fr over |language=French). For example, in a German citation one would typically write "o. D." ("ohne Datum") rather than "n.d.", but "k. D." ("kein Datum") is seen as well. Likewise, there are abbreviations like "o. J." (without year), "o. O." (without location), "o. A." (without author) and "Anon." (for anonymous author(s)).

Regarding HTML comments, you wrote that author=<!--not stated--> would be the recommended form. It is possible that this has changed, but the last time I looked the recommended form was author=<!-- staff writer, no byline -->. Either way, this shows that HTML comments, as useful as they often are, are not a good method to indicate common states like this because they are more complicated to use for editors and therefore are not used consistently, thereby making it difficult to machine-read them. Special tokens such as |date=none, |author=none, |author=staff, |author=anon are much preferable to them.

--Matthiaspaul (talk) 17:14, 23 November 2020 (UTC)

Yeah, incompetent might be a bit strong, but en.wiki is one of two English language Wikipedias. For those who do not understand commonplace citation initialisms, abbreviations, and symbols used throughout the English language publishing world (and consequently in cs1|2), perhaps the other English language Wikipedia is a better choice. But, were it an issue, I would have thought that editors at simple.wiki would have tweaked (or asked us for assistance in tweaking) simple:Module:Citation/CS1/Configuration to accommodate their readers.

I have said in the past, and will likely say in the future, that cs1|2 is not APA, CMOS, Bluebook, or any other citation style. I am comfortable with cs1|2 not being any of those, but, I do not think that cs1|2 should be made to be so different from other citation styles that we abandon the commonly-used citation initialisms, abbreviations, and symbols that English-language readers have come to expect.

If it is to be believed that n.d. is rather obscure to the reader and must be fixed, it must follow that all of the other citation initialisms, abbreviations, and symbols used by cs1|2 are also rather obscure to the reader, mustn't it? If we believe that to be true, then we must discontinue use of all standard English-language citation initialisms, abbreviations, and symbols. We must replace: 'ed.' → editor, 'eds.' → editors, 'ed.' → edition, '§' → section, '§§' → sections, 'Vol.' → volume, 'no.' and 'No.' → issue or number, 'p.' → page, and 'pp.' → pages. And lest we forget it, 'et al.' → and others.

—Trappist the monk (talk) 18:41, 23 November 2020 (UTC)

I agree with a lot of what you wrote above but not with the recommendation for the Wikipedia in Simple English - not knowing what "n.d." means does not necessarily mean that a user is a child, ancient, or illiterate, it does not even mean s/he is uneducated - as Pol mention above it could be as simple as that the user graduated from a university outside of the US or UK (possibly in pre-internet times), where other citation standards (were or) are more prevailing - they are similar, but different enough in the details that even a highly educated person might not be familiar with "n.d." at first. I would not want to point them to the Simple English WP, because they won't find what they are looking for over there, they even might feel offended. Of course, they will be able and willing to learn what "n.d." means.

I think the truth seldomly lies with the extremes. The fact that users repeatedly "complained" about "n.d." does not necessarily mean that we have to abandon all abbreviations. Still, it should let us think about options how to possibly improve the situation for them.

Perhaps all that would be needed is to add some tooltip to "n.d." explaining its meaning? We could try and see if this is already enough to address the problem. (However, given that this would require a predefined output instead of just passing through the input it would already require to tokenize the "no date" case, but, I think, it would be worth it also for the other advantages.)

--Matthiaspaul (talk) 17:38, 26 November 2020 (UTC)

The last time this topic was raised appears to be Help talk:Citation Style 1/Archive 55 § The n.d. keyword for undated sources (includes links to two other discussions).

—Trappist the monk (talk) 15:31, 23 November 2020 (UTC)

(edit-conflict) Given that we already use the keyword "none" in various other places, I would suggest to, at the minimum, support something like |date=none. However, if there are more similar conditions (as in the none/staff/anon example for authors above), more keywords could be introduced for them as well.

The keyword "none", indicating that this information is not given in the source, should be distinguished from the condition, that the information should not be displayed but would still be used in reference anchor generation and be provided in the metadata (for which I suggested the keyword "off" recently introduced for |title=), and the condition, that the information is simply unknown to the editor at present (but might be given in the source), which should not be indicated by a special token, but is often indicated to other editors by providing an empty |date= parameter (which, however, is sometimes removed by other editors "cleaning up").

I'm open in regard to the best output format, be it "n.d.", "no date", or something else. However, the good thing is that once we would have introduce a tokenized input for this condition, we are free to centrally change the output any time later on would this become necessary.

--Matthiaspaul (talk) 17:14, 23 November 2020 (UTC)

This is much better done in an HTML comment: |date=<!-- No date specified. -->, same as we (also optionally) handle works without specifically named authors. "N.d." is meaningless to most people, or worse may imply something else entirely like "North Dakota" asserted to be the publication location. (The fact that it's often completely lower-case as "n.d." is irrelevant, since we all know a lot of editors have terrible capitalization habits, and various people doing this abbreviation for "no date" are going to render it "ND" or something else, anyway.) We should just advise, with an example, to do it in an HTML comment, the way we advise noting no named author.  — SMcCandlish ☏ ¢ 😼  21:08, 4 December 2020 (UTC)

HTML comments aren't a good solution for this, as different people will phrase the comments differently thereby making it very difficult/next to impossible to reliably machine-read them. To a lesser degree, however, this also applies to the current state of affairs where we allow various forms of "nd", "n.d.", etc., which, in all its allowed forms, will be displayed and end up in metadata, producing inconsistent output.

We also need to distinguish between a value simply not known, a value not given in the source, and a value that should just not be displayed in a citation (but would still show up in metadata).

That's why I propose to tokenize such special values, not only in the "no date" case, but also in the "no author" and all similar cases. This streamlines the user interface and the output, and at the same time ensures machine-readability and full metadata.

--Matthiaspaul (talk) 23:49, 4 December 2020 (UTC)

Addition to generic title

Hello, I was wondering if articles with "Subscribe to read" in the reference title could be added to Category:CS1 errors: generic title. There are currently over 1,000 usages of these in titles. Thanks. Keith D (talk) 14:35, 23 November 2020 (UTC)

Appears to be associated with Financial Times:

Cite web comparison

Wikitext	{{cite web|title=Subscribe to read|url=https://www.ft.com/content/2d2a9afe-6829-11e5-97d0-1456a776a4f5|website=Financial Times}}
Live	"Subscribe to read". Financial Times. {{cite web}}: Cite uses generic title (help)
Sandbox	"Subscribe to read". Financial Times. {{cite web}}: Cite uses generic title (help)

—Trappist the monk (talk) 15:46, 23 November 2020 (UTC)

Thanks for the change. Keith D (talk) 00:41, 25 November 2020 (UTC)

DOI errors

This

• Colbert; Edwin, Harris (1946). "Hypsognathus, a Triassic reptile from New Jersey". Bulletin of the American Museum of Natural History. doi:10.http://hdl.handle.net/2246/390. {{cite journal}}: Check |doi= value (help); External link in |doi= (help)

should emit an error. The DOI format is 10.[4 or 5 digits]/foobar. Headbomb {t · c · p · b} 15:32, 24 November 2020 (UTC)

Cite journal comparison

Wikitext	{{cite journal|date=1946|doi=10.http://hdl.handle.net/2246/390|first2=Harris|journal=Bulletin of the American Museum of Natural History|last1=Colbert|last2=Edwin|title=Hypsognathus, a Triassic reptile from New Jersey}}
Live	Colbert; Edwin, Harris (1946). "Hypsognathus, a Triassic reptile from New Jersey". Bulletin of the American Museum of Natural History. doi:10.http://hdl.handle.net/2246/390. {{cite journal}}: Check |doi= value (help); External link in |doi= (help)
Sandbox	Colbert; Edwin, Harris (1946). "Hypsognathus, a Triassic reptile from New Jersey". Bulletin of the American Museum of Natural History. doi:10.http://hdl.handle.net/2246/390. {{cite journal}}: Check |doi= value (help); External link in |doi= (help)

—Trappist the monk (talk) 15:47, 24 November 2020 (UTC)

Podcasts published by newspaper

For {{Cite podcast}}, I'm trying to cite a podcast published by a newspaper. The documentation says to use |website= for the name of the podcast and |publisher= for the name of the publisher, but |publisher= won't let me italicize, and the name of a newspaper should always be italicized, even when it's acting as a publisher. What do I do here? {{u|Sdkb}} ^talk 20:34, 24 November 2020 (UTC)

Use the newspaper's publishing company instead. Alternatively, |via= is available, though I think I would prefer the former and not the latter solution. --Izno (talk) 20:42, 24 November 2020 (UTC)

It's a student newspaper, so it doesn't really have a publishing company. The {{Cite podcast}} template seems pretty underdeveloped, so I'd imagine there's probably a change we'll want to make at the template itself. {{u|Sdkb}} ^talk 21:07, 24 November 2020 (UTC)

I find it very hard to believe that anything made public (such as a student newspaper) does not have a publisher. Who or what makes it appear? It doesn't suddenly materialize. 69.94.58.75 (talk) 12:37, 25 November 2020 (UTC)

I mean, the newspaper itself has a staff who publish the podcast on the major podcast platforms. There's a printing company who prints it, and a student government that partially funds it, but putting either those in the |publisher= field and leaving out the name of the newspaper would be really weird. {{u|Sdkb}} ^talk 22:24, 27 November 2020 (UTC)

The trouble here may be the statement name of a newspaper should always be italicized. That is correct in prose. But in most citation systems (including this present one), italics are not used on specific variables (in your example a newspaper) but on the parameter field. Therefore, |publisher= is never italicized. |website= always is, as the work or source. I would fill in accordingly and let the software decide where to apply emphasis. The newspaper may be published by the Student Union.But the podcast is published by the Newspaper. 98.0.246.242 (talk) 19:04, 28 November 2020 (UTC)

I crossed out the last part above because it is not clear to me whether this is a freestanding podcast, or part of the newspaper. If it is a feature accessible through the newspaper website, then I would use

• {{cite web|title=Podcast Title|department=Podcast|url=http://www.podcastwebpage.com|website=Newspaper|publisher=Publisher}} which renders
• "Podcast Title". Podcast. Newspaper. Publisher.

Note that the podcast webpage is used in |url= instead of the including website. I would use the podcast date for |date=, and the podcaster, if any as the author. 98.0.246.242 (talk) 22:04, 28 November 2020 (UTC)

Some of the argument here is off base, e.g. "It's a student newspaper, so it doesn't really have a publishing company." The university is the publisher, obviously; "publisher" doesn't resolve solely to "for-profit entity". (If you really want to be more specific, you can do something like |publisher=Name of Student Organization, Name of Institution, just like you can do |publisher=Name of Department, Name of Institution for more official-channel materials, or |publisher=Name of Subdivision, Name of Overall Organization in any circumstance (we often do this with obscure UN, EU, etc. entities, though it's overkill for something globally recognized like UNESCO, which already has "UN" in it's name and a big article about it and its role in the UN, so we don't need to append ", United Nations".)

Podcasts (and blogs, and vlogs, and etc.) usually have a specific minor-work title (headline). If that's present, then that's what goes in |title=; it's no different from an article in a newspaper or journal, a named episode of a TV series, etc. If the podcast or blog is side product of the same publisher as a news site (or newspaper), but with separate editorial control and a completely separate domain name (or, on paper, is issued separately from the newspaper), then it's a separate work that shares a publisher, and is not part of the news site/newspaper. (e.g., The Observer is a separate work from The Guardian). If it's an integral feature of a news site (or whatever), then the podcast's (or other thing's) overall title is a |department=, just like a columnist's column is (and which will generally also have a per-piece |title=). We seem to put department names manually in double quotes, same as the |title= does automatically; that's what the |cite news= doc is suggesting. This basically the same markup approach as |series= in {{cite book}}, e.g. |series="Studies in American Cat Farming" series; the quotes make it clear its a title of some kind, not an entity.) I don't think anyone's brain will melt if you do |department=Book Reviews or |department=Ask Marjorie column or |series=Studies in American Cat Farming series, though; it's just a little less clear without quotes around the titles.

A weakness of our citation template system is that it cannot at present gracefully handle a serial work that doesn't have individual titles for each issuance (podcast episode, blog post, etc.), which basically forces us to put the podcast name in |title= even if it's logically more of a |department=. (The template will thrown an error without at |title=, no matter how rich the rest of the template data is.) So it goes. The important thing is that it can be narrowly enough identified that the source can be found and used for verification. The more consistent it is the better, but we need not torture ourselves over it. E.g., many newspapers include an insert supplement (on arts, or local news, or whatever), which in turn is further subdivided into departments, and then into specific articles. At bare minimum we need to the article title and the overall publication title (because the supplement/insert probably cannot be identified by most people without the overall work title). But if you're just really in a mood to obsess over it, you could also do something like |title=14 Arrested in Ferret Smuggling Operation|department="Local News" insert, "Police Beat" column. The same kind of approach can be used for drilling down through online stuff to get at a podcast that is part of a subsite/department of a news site, or whatever.

PS: Don't obsess over subdomains. Some news publisher like to do things like sports.whatever-news.com and international.whatever-news.com, but this is just an information architecture decision in most cases, and might be changed at any time. We know this for an annoying fact from changes (often audience-unhelpful ones) to how various major sites like BBC News have been reorganized over the years. Plus, quite often there are actually multiple paths to the exact same content, some using third-level domain names and some not. As long as the URL works, and is archived to prevent linkrot, don't pull your hair out about it.
 — SMcCandlish ☏ ¢ 😼  20:48, 4 December 2020 (UTC)

Italics 2

I know that sources like PBS, NPR, CNN, ABC, NBC, BBC, etc. should not be italicized. We save that for newspapers and magazines. Where is the MoS guideline for when NOT to italicize those listed news sources? An editor seems to think it makes no difference, and they are changing the citations all over the place so that those agencies are italicized. When I'm in doubt, I just look at the article for the source and see how it's done there, because I know that other editors have followed the MoS. -- Valjean (talk) 01:20, 25 November 2020 (UTC)

Can you provide specific examples. 98.0.246.242 (talk) 02:28, 25 November 2020 (UTC)

This is just one example which changes the correct format to italicized format. That editor does this a lot. I have tried to discuss this with them to no avail, hence my need for better information. Where is the MOS guideline for this? -- Valjean (talk) 02:36, 25 November 2020 (UTC)

It seems that the italics appear as a result of swapping |publisher= for |work=. The "work" is what is generally considered as the source, and this (unlike "publisher") is emphasized, in most cases with italic type. I would recommend a compromise: use the website (e.g. www.npr.org) as the "work", and NPR as the "publisher" of such work. And let the software format them accordingly. 69.94.58.75 (talk) 12:30, 25 November 2020 (UTC)

This is related to: User talk:Citation bot § Unhelpful changes? You did not like the answers that you got there so are asking elsewhere? Your posting here seems to be the same, more-or-less, as this: Wikipedia talk:Manual of Style § Italics...help. I'm pretty sure that you should not ask the same question in multiple venues because doing that is considered to be disruptive.

How do you know that sources like PBS, NPR, CNN, ABC, NBC, BBC, etc. should not be italicized? In cs1|2, the name of the source (the publisher's work) is italicized. If the source is a website, the name of the website is italicized; if the source is a magazine, journal, newspaper, or other periodical, the name of the magazine, journal, newspaper, or other periodical, is italicized; if the source is a book, the name of the book is italicized; if the source is a corporate entity initialism or broadcaster call-sign, the initialism or call-sign is italicized. This applies to both physical an online sources. It does not matter if the initialism of a cited source is the same as the initialism of the business that produced it.

I disagree to some extent with what the IP editor wrote. At Help:Citation Style 1 § Work and publisher is this:

Do not append ".com" or the like if the site's actual title does not include it ... and omit "www."

and this:

The "publisher" parameter should not be included for widely-known mainstream news sources, for major academic journals, or where it would be the same or mostly the same as the work.

—Trappist the monk (talk) 14:54, 25 November 2020 (UTC)

Yes this is a pretty confusing guidance (re: website name). It should be made clear that what is expected is the dba (doing business as) name, not the website title (the index or main page html title tag) or the domain/subdomain FQDN. However I don't know if dbas are indexed. Page titles and domains do, and therefore should be easier/faster to find. 50.75.204.50 (talk) 19:48, 25 November 2020 (UTC)

Hmmmm.... So why not go to these articles (PBS, NPR, CNN, ABC, NBC, BBC) and try to italicize them? See what happens. Then take the resulting edit wars to ArbCom or some appropriate drama board. I'd like to see a final decision, because I keep getting conflicting answers. I'd really like to know, but I'm not sure where is the best place to ask. Some places don't answer. -- Valjean (talk) 16:45, 25 November 2020 (UTC)

So why not go to these articles (PBS, NPR, CNN, ABC, NBC, BBC) and try to italicize them? Why would I want to do that? The articles are about those entities as businesses; we do not cite the business, we cite the business' work (its programming, its articles, etc), and the work, in cs1|2, is italicized.

—Trappist the monk (talk) 16:58, 25 November 2020 (UTC)

What's cs1|2? -- Valjean (talk) 17:19, 25 November 2020 (UTC)

Shorthand for "Citation Style 1 and 2". This help page is about them ie. the suite of templates such as cite web, cite news, etc..-- GreenC 17:23, 25 November 2020 (UTC)

Now I feel dumb. I have never used this page before. Thanks. -- Valjean (talk) 18:18, 25 November 2020 (UTC)

This has come up before – because the template only "allows" us to set websites in italics, and/or how every publishing organisation has been redefined, by cite template editors and partly through creepage at the MOS, as a "work". Plenty of examples were mentioned here in past discussion(s). The one that comes to mind is the music database AllMusic: as a result of the title being rendered italic in citations, some editors then italicise AllMusic in prose "for consistency". Which is ridiculous; and italicised BBC, NPR, PBS, etc, could well result from that also. It's not as if readers are left confused and dizzy by a roman (so-called) "work" in a citation, but that sort of rationale has been put forward here as a reason that each and every website must be italicised. Seems to me it's more a case of obsessiveness by editors who just think of cite templates in isolation (similar problem, eg, when editors focus solely on infoboxes from article to article, and not on how the infobox works with the article in question).

There was some discussion elsewhere, from memory, about coming up with a sort of "cite organisation" which would allow for non-italicised web sources. I think that would be a great idea. Until then, you default to writing out the relevant citations manually, avoiding the templates altogether. JG66 (talk) 17:32, 25 November 2020 (UTC)

JG66, this is an area where I confess to ignorance. I have been editing here since 2003, but have never gotten this fully explained. I don't fully understand the parameters in templates, but I know that publisher= and website= produce italics, and work= does not, website= and work= produce italics, and publisher= does not, so I use the one which will produce the "right" result, but that may not be the right approach.

I have gotten my cues (for how I should italicize in references) by looking at our articles. If the article uses italics, I use them in references and text, and if not, I don't. That's why I don't italicize sources like these (PBS, NPR, CNN, ABC, NBC, BBC), and do italicize The New York Times, The Guardian, etc. Am I wrong and/or totally naive? Is it really more complicated than that? I really appreciate the help, advice, and AGF. -- Valjean (talk) 18:30, 25 November 2020 (UTC)

I know that publisher= and website= produce italics, and work= does not. Umm, not true... |publisher= is not rendered in italics but both |website= and |work= are (along with their aliases |newspaper=, |magazine=, |periodical=, and |journal=).

—Trappist the monk (talk) 18:36, 25 November 2020 (UTC)

Oops! I remembered wrong. That should be "website= and work= produce italics, and publisher= does not." Fixed above. Here are some examples:

1. website= Mayer, Jane (November 25, 2019). "The Inside Story of Christopher Steele's Trump Dossier". The New Yorker. Retrieved November 27, 2019.
2. website= Borger, Julian (October 7, 2017). "The Trump–Russia dossier: why its findings grow more significant by the day". The Guardian. Retrieved December 28, 2017.
3. work= Elfrink, Tim; Flynn, Meagan (February 27, 2019). "Michael Cohen to testify that Trump knew of WikiLeaks plot". The Washington Post. Retrieved February 27, 2019.
4. publisher= (plus manual italicizing for Fresh Air) Gross, Terry; Simpson, Glenn; Fritsch, Peter (November 26, 2019). "Fusion GPS Founders On Russian Efforts To Sow Discord: 'They Have Succeeded'". NPR. Fresh Air

So what's the best way to do this? -- Valjean (talk) 18:54, 25 November 2020 (UTC)

The New Yorker is a magazine so {{cite magazine}} and |magazine=. Both The Guardian and The Washington Post are newspapers so {{cite news}} and |newspaper=. Fresh Air isn't a news program nor is it a journal or a magazine or a newspaper, so {{cite web}} (because you included a url) or because it's aired periodically (daily where I live) you might use {{cite periodical}} (a redirect to {{cite magazine}}) and |work=[[Fresh Air]]. You can include or omit |publisher=[[NPR]] as you choose. Hanging the program name after the cs1|2 template as you did means that the name is not included in the citation's metadata (for those who consume our citations using various machine tools).

—Trappist the monk (talk) 19:14, 25 November 2020 (UTC)

Valjean, that is the situation as I see it also – "If the article uses italics, I use them in references and text ..." It's logical (unless one's a template obsessive, it seems) and, as I've said, it ensures editors don't go and work the other way by deciding to italicise AllMusic, NPR, etc, because the word's italicised in references.

There was a discussion here early in the year which might be relevant: Help talk:Citation Style 1/Archive 63#This passage in the documentation. I believe it was Tenebrae (there or elsewhere) who outlined the "cite organisation" option, and laid out other reasons why italicising each and every website was either wrong or potentially confusing. JG66 (talk) 13:29, 28 November 2020 (UTC)

Yes, in spite of all the well-meaning advice above, I'm still confused. It can't be right that all sources in references should be italicized, but that's what some editors are doing. We need clearer guidelines, with very specific, site by site, instructions, a literal list, just like we have a specific list at WP:RS/P. There shouldn't be any rubbery wiggle room in those instructions.

Either The New York Times is always italicized or it's never italicized. What is it?

The list should also specify the ideal template to use. -- Valjean (talk) 16:30, 28 November 2020 (UTC)

The list should also specify the ideal template to use – my answer would be always use {{Citation}} for all citations. If you like full stops/periods all over the place, then add |mode=cs1. I'm sure that many editors would strongly disagree, which is why the list should not specify the ideal template to use. Peter coxhead (talk) 17:15, 28 November 2020 (UTC)

Sources in citations are not italicized, they are emphasized using italics. This is a not simply a typographical convention, it has semantic meaning, so a reader can immediately recognize what source it is they should be looking for. Formatted citations are terse, utilitarian statements employing a certain quasi-shorthand. Their style follows their syntax conventions. In that syntax, the source or work is paramount. But anyone is free to use a different citation format, or none (freehand). The objective is to give the reader a quick & easy way to verify what is claimed in text. The best-looking and best-articulated article means nothing if it cannot be verified. This does not require templates, formatted citations, or specific styles. As for the narrow case of template selection, I think one can only make recommendations. Different templates have slightly different format/syntax options or output, and there is a continuing effort to match them to the relevant sources. 98.0.246.242 (talk) 17:44, 28 November 2020 (UTC)

That's completely incorrect. They're italicized because because they're titles of major works. When we cite them as sources, we are by definition citing them as works, not as companies or as anything else – Wikipedia has a formal policy that we only cite published works. It has nothing at all to do with emphasis. If the convention in English had evolved differently, e.g. to put titles of minor works (chapters in a book, articles in a journal, etc.) in double quotes, as we do, and put titles of major works in single quotes, instead of italics, then this is exactly what our citations and the templates that construct them would also do, despite the smaller single quotes being less visually emphasizing than the larger double quotes.  — SMcCandlish ☏ ¢ 😼  19:38, 4 December 2020 (UTC)

We've been over this so many times. The title of the work is mandatory. The publisher name is optional, when it is redundant with the title. There is no way around this, no gaming plan to employ. Most of the "confusion" about this is patently manufactured by people trying to impose a different style on electronic sources. We just recently had an RfC clearly rejecting that idea. So, it's time to stop. If you need to cite something from news.bbc.com, for example, it is |title=Title of Article Here|work=[[BBC News]], and do not include |publisher=[[BBC]] which would be redundant and would treat our readers like they have severe brain damage. If you're citing a news source that has no clear title beyond its domain name, then do |work=Whatever.com. If you're citing a work that has the exact same name as the publisher (aside maybe from an appended "Inc." or "Ltd" in the latter case), put the name in |work=, even if the wikilink in it (if any) goes to a company article (the publication is a subtopic thereof), and omit |publisher=. E.g., the title of npr.org really is NPR, which is also the common name of the organization (in longer form National Public Radio), ergo: |work=[[NPR]]. If this just makes your head asplode, no one is likely to care if you do |work=[[NPR|NPR.org]] to distinguish a bit between company and output. But someone is apt to remove the .org later, because it is not actually a part of the title of the work. You cannot omit the work title and just use the publisher in an attempt to avoid italics because you have some weird notion in your head that online sources shouldn't receive the same style as dead trees ones. If you do that, you are writing broken citations and someone will correct them. If you revert-war against these corrections you are being disruptive and need to give up your lost cause. [PS: I'm using a generic "you" in this; it's not directed at a specific party in this thread, but at a diffuse cloud of editors who keep trying to abuse template parameters to de-italicize things and to pretend that we're citing a corporation rather than a published work produced by a corporation.] — SMcCandlish ☏ ¢ 😼  19:54, 4 December 2020 (UTC)

• Titles are italicized. But ABC News is not a title (publisher=ABC News). Sometimes it's entirely appropriate to use publisher=, not website= or work=. SarahSV ^(talk) 23:18, 6 December 2020 (UTC)

PMID numbers

Hello, at the Arecibo Observatory article there's a valid PMID of 33214727 despite the red ink saying 'Check |pmid= value'. I presume that the range of valid PMID numbers needs extending- please can someone fix this? TIA, Yadsalohcin (talk) 08:20, 25 November 2020 (UTC)

Thanks for reporting. The current limit is set to 33200000 per Help_talk:Citation_Style_1#PMID_limit.

I have increased it to 33500000 in the sandbox.

--Matthiaspaul (talk) 13:23, 25 November 2020 (UTC)

I'm guessing that 33500000 (>33214727!) should do it- does it propagate on automatically from the sandbox? Despite refreshing, there's still red ink at Arecibo Observatory Yadsalohcin (talk) 15:01, 25 November 2020 (UTC)

The live template gets updated from the sandbox every couple of months. The next update will probably happen in January.

As there have been quite a number of changes already, I would also support an earlier update, but it can be carried out by admins only. Also, as we are in the middle of a process to fade out many old parameter variants (not the functionality) we have to make sure that some old parameters have been updated in mainspace before we can roll out the next update.

Alternatively, we could just update the limits in the live template.

In the linked thread we are discussing possible means how to make it easier to update the limits so that keeping them tight does not cause inconvenience for editors. If you have ideas, your input is welcome there.

--Matthiaspaul (talk) 20:30, 25 November 2020 (UTC)

This is getting annoying to editors. I just saw 33273063. Please just set a {{template edit request}} for the specific template and value you want and let's get this limited problem fixed. DMacks (talk) 17:15, 6 December 2020 (UTC)

Thanks Trappist the monk for[2]. DMacks (talk) 15:55, 9 December 2020 (UTC)

Meta proposal to globalize the CS1 templates

Someone has made a proposal to allow a more Wikimedia-wide usage of these CS templates. Putting a notice here in case folks are interested. Jo-Jo Eumerus (talk) 08:36, 25 November 2020 (UTC)

Cite_OED template needs an update

The {{Cite_OED}} template is in need of an update, and it would be great if someone could take a look. I've asked several times on the talk page at Template_talk:Cite_OED#Template_needs_updating, but that page probably doesn't get much exposure. Asking here following a recommendation at WP:VP/T. MichaelMaggs (talk) 10:18, 25 November 2020 (UTC)

Thanks User:Trappist the monk, that's much better. I wonder, though, whether it would be better not to have a default date. "September 2005" doesn't seem to appear on the site at all, and may give an incorrect impression that that's the date of the word entry. It isn't usual to tag a continually-updated web resource with the date that the resource first became available online. MichaelMaggs (talk) 14:15, 25 November 2020 (UTC)

Thanks again. MichaelMaggs (talk) 14:36, 25 November 2020 (UTC)

Should further reading sections have "retrieved by" dates?

 You are invited to join the discussion at Wikipedia talk:Further reading § Should further reading sections have "retrieved by" dates?. {{u|Sdkb}} ^talk 20:39, 25 November 2020 (UTC)Template:Z48

Nomination for deletion of Module:Citation/CS1/Arguments

Module:Citation/CS1/Arguments has been nominated for deletion. You are invited to comment on the discussion at the entry on the Templates for discussion page. * Pppery * _{it has begun...} 00:26, 26 November 2020 (UTC)

deprecation and removal of nonhyphenated multiword parameter names

User:Monkbot/task 18 is a cosmetic bot task. Among the various things that it does is replace nonhyphenated parameter names with their canonical hyphenated names. One of those replacements is |accessdate= to |access-date=.

I have started this discussion because an editor at my talk page has objected to the bot's replacement of |accessdate=: accessdate is not currently deprecated, there is currently no discussion about deprecating it, and your only basis for replacing it by bot is the concern that were we to get consensus to deprecate it at some unknown future point, error messages would annoy people? For the time being, I have disabled the |accessdate= to |access-date= replacement.

I believe that it is our intent to deprecate and remove all of the all-run-together multiword parameter names in favor of their hyphenated forms. Am I wrong? At the bottom of the §Deprecated section of every cs1|2 template (except Template:Cite citeseerx/doc) is this:

In addition to the above list(s) of deprecated and removed parameters, all non-hyphenated aliases of parameters with hyphens are discouraged to be used in citation templates and are kept only for legacy support. They are subject to becoming deprecated and unsupported in the future as well. To streamline the appearance and improve consistency across the project, these variants should no longer be used when adding parameters to citation templates. Instead, select the hyphenated parameter variants and also consider switching other non-hyphenated parameters, which may be present in a citation already, to their hyphenated equivalents at the same time. – emphasis in original

A variant of that text is present at Help:CS1 errors#Cite uses deprecated parameter |<param>=:

Plan for the future: All non-hyphenated, multiword parameter names are aliases of hyphenated multiword parameter names. The non-hyphenated aliases exist only for legacy support. Editors should expect that support for non-hyphenated parameter names will be withdrawn. Choose the hyphenated form when adding parameters to a citation template. Consider replacing non-hyphenated parameters with the hyphenated equivalents at the same time.

Do those declarations accurately reflect our intent with regard to nonhyphenated parameter names? I believe that the answer is yes because:

• we have arranged the cs1|2 documentation to list hyphenated multiword forms first; these are the canonical forms
• we have arranged the aliases{} table in Module:Citation/CS1/Configuration so that the hyphenated multiword forms are listed first
• cs1|2 parameters need only one name except where semantics dictate a need for alternate parameter names (|chapter=, |contribution=, |entry=, |article=, |section=); nonhyphenated variants of a hyphenated parameter name do not meet this criterium
• there is no need to retain relics from the mergers of the various independent cs1 templates
• we have created new multiword parameters without simultaneously creating new nonhyphenated aliases (|chapter-url-access=, |name-list-style=, |script-title=, |url-status=, etc)
• at the 2020-10-10 Module:Citation/CS1-suite update, we deprecated several nonhyphenated parameter names and removed support for quite a few others; see the lists at Cite uses deprecated parameter |<param>=
• at the next module-suite update, we will be deprecating these: |conferenceurl=, |contributionurl=, |laydate=, |laysource=, |layurl=, |sectionurl=, |seriesno=, |timecaption=, and |titlelink=; discussion

It is probably true that we have never actually declared an intent to deprecate and remove, but reading between the lines of our past and current actions, it seems highly likely to me that our intent is to deprecate and remove these parameter names.

Is it?

—Trappist the monk (talk) 12:41, 30 November 2020 (UTC)

• There is a very significant difference between saying hyphenated is preferred and saying non-hyphenated cannot be used. Given the scale of the change proposed, this requires strong consensus, including from those who are not regulars here. Nikkimaria (talk) 12:46, 30 November 2020 (UTC)
  • Pinging some other editors who have raised objections at your talk page: ɱ, Jason Quinn, oknazevad. Nikkimaria (talk) 12:49, 30 November 2020 (UTC)
• Agree to deprecate and remove. For the sake of clarity, made-up compound terms should be separated. Even more so where specialist language may be employed.

  I also agree that this should have consensus but I don't see the scale of change as an important factor. We are talking about a formatting change that is transparent, with zero effect on semantics, in a very specialized area of Wikipedia. Imo, the change makes semantic meaning more obvious, a good thing. 68.173.79.202 (talk) 13:42, 30 November 2020 (UTC)

  We are talking about a formatting change that impacts a very widely used parameter in a very widely used set of templates. Whether you think the change is positive or not, it can be anticipated to have a impact on a large number of editors. As such, it would be appropriate to solicit input from a wider range of contributors than just those who happen to frequent this page. Nikkimaria (talk) 22:39, 30 November 2020 (UTC)

  Well, we are in almost complete agreement. Almost, because if someone is going to throw a fit over the appearance of perfectly harmless punctuation, and solely in the edit window, then we may be getting into the realm of therapy. Not that this is uncommon in Wikipedia. Among certain groups of editors, it is often prevalent behavior. In any case, that is why the presumed gravity of this change was questioned - everything else you state is agreed. As for the server load, well, not our concern really. And I assume that this would happen at the next module-group update anyway? Perhaps the commit might add a few more tics on the server clocks. I think Wikipedia will survive it. 98.0.246.242 (talk) 01:53, 1 December 2020 (UTC)

• Support deprecation & preemptive and/or prescriptive updating of all relevant non-hyphenated parameters.   ~ Tom.Reding (talk ⋅dgaf)  14:48, 30 November 2020 (UTC)
• If there isn't consensus already, I say we should deprecate the remaining unhyphenated parameter aliases. One of the objections raised was that the hyphens create line breaks. Funnily enough, that's exactly why I prefer the hyphenated forms; in addition to being more canonical in general, the line breaks mean that the lines will have more consistent lengths. This is perhaps the most useful in connection to |archiveurl=, which often has a very long link without any breaks. Using |archive-url= helps alleviate this. It also helps to distinguish "Archived from the original on..." as plain text, |archivedate=, and |archive-date= in plain-text searches. -BRAINULATOR9 (TALK) 15:07, 30 November 2020 (UTC)
• The system evolved over time and occasionally needs a refactor to keep it from spiraling into an unmanageable beast. "Caution: work in progress". Given the scale getting it done as quickly as possible is best, otherwise it will be irritating watchlists for 6 months ( at 10 edits/minute). AWB is not the right tool. The fastest way is via parallel processes on Toolforge (up to 15 slots though more slots might be requested). Toolforge is in the same data center so LAN speed. It should be possible to get it done in a few weeks with forward warning to temporarily enable "Hide: [ ]Bots" for anyone concerned about watchlist overload. -- `GreenC 15:09, 30 November 2020 (UTC)
• I believe all the regression testcases (Template:Cite book/testcases/regression tests) use authorlink and accessdate. Should deprecate mean changing those to author-link, or should legacy support mean duplicating them all? Or are these regression tests really not useful? David Brooks (talk) 18:20, 30 November 2020 (UTC) ETA: also true of Template:Cite book/testcases, I realize. David Brooks (talk) 18:22, 30 November 2020 (UTC)

  Those are updated when necessary. (Their utility is also somewhat suspect as they aren't exactly systematic.) --Izno (talk) 19:45, 30 November 2020 (UTC)

• I prefer non-hyphenated authorlink and accessdate because it is easier to type. I don't see why it should be deprecated. —David Eppstein (talk) 19:21, 30 November 2020 (UTC)

  By one character? Seriously? :-) They're harder to read; our entire template system has for years been moving away from mashedtogetherwordmess in template parameters and names, as it has been a major part of the daunting WP learning curve for new editors. There's no reason to disable them, but we should stop "advertising" those variants, and should ask citation tool makers to switch to the more sensible versions. Similarly, {{cn}} still redirects to {{citation needed}}, but we even have bots and AWB/JWB scripts that canonicalize such shortcuts to the real, non-jibberish templates names, and various tools use the real names of the templates in the first place now. Also, various cite template parameters (mostly newer ones) with hyphens don't even have non-hyphenated aliases, and the sky did not fall; there is no editorial outcry about it, so obviously there's not a real editorial demand for them theruntogetherversions as necessary or desirable.  — SMcCandlish ☏ ¢ 😼  21:23, 30 November 2020 (UTC)

  It's not just that it's one character; it's one character for which I have to move my whole hand away from the letter keys. It's significantly slower for me than just another letter. —David Eppstein (talk) 18:19, 1 December 2020 (UTC)

  Well, then don't use the hyphen version. Some bot or AWB script can deal with it later. I don't see anyone arguing for disabling the hyphen-free versions. They don't don't need to be advocated in the documentation since their use makes human parsing of the wikicode more difficult.  — SMcCandlish ☏ ¢ 😼  20:58, 4 December 2020 (UTC)

  SMcCandlish, deprecating the hyphen-free version is in fact exactly what this discussion is advocating. Nikkimaria (talk) 21:47, 4 December 2020 (UTC)

  "Deprecation" need not equate to disabling the functionality of. @Trappist the monk:, can we get some clarity on the intent here? I don't think it's a good idea to totally nuke the ability of old and heavily used parameter aliases to even work at all, versus just no longer "advertising" the old versions in the documentation (and having a bot replace them as part of routine cleanup). This is one of those WP:NOT#BUREACRACY things. The templates and their code exist to serve us, not the other way around.  — SMcCandlish ☏ ¢ 😼  21:59, 4 December 2020 (UTC)

  "Deprecation", by the definition used in the context of CS1/CS2, means that if the parameter is used, a red maintenance message will be shown and it will appear in a tracking category. It is a phase before removal of support for a parameter (in which case only an "unsupported parameter" message and optionally a hint on the new parameter will be shown). It is possible to stay in this state for extended periods of time, but the idea is that eventually the functionality will go (at least under this particular parameter name). While some of the non-hyphenated parameters are already deprecated, parameters like |accessdate= or |authorlink= are still too frequently used in mainspace to deprecate them now, they are only "discouraged". Being "discouraged" means that the functionality is still supported and no error message shown, but that preparations are in the works to deprecate the parameter at some later point in time, so it is wise to reduce the parameter's use whereever possible so that less work needs to be done when it gets deprecated eventually. --Matthiaspaul (talk) 23:16, 4 December 2020 (UTC)

  The first word in the this discussion's heading is 'deprecation'. Deprecation will not disable the functionality of |accessdate=. The functionality of any deprecated parameter is retained through the deprecation period. At the end of the deprecation period, support for the parameter name will be withdrawn and the parameter name will no longer work. For |accessdate=, an extended deprecation period may be desirable.

  —Trappist the monk (talk) 12:32, 5 December 2020 (UTC)

  So what you're saying is that yes, this discussion will lead to the disabling of the functionality of |accessdate=. Nikkimaria (talk) 13:12, 5 December 2020 (UTC)

  Are you not reading what I have previously written in this discussion? Earlier I wrote: The purpose of this discussion is to determine if we, the maintainers of the cs1|2 templates, intended to deprecate and remove all nonhyphenated parameters, and if we do, to declare that intent. In that sentence, all nonhyphenated parameters includes |accessdate= because that parameter name is a concatenation of two words and is not hyphenated.

  —Trappist the monk (talk) 15:43, 5 December 2020 (UTC)

  Well, for my part then, I don't think this should be deprecated in this particular way. Long-used parameter aliases should still remain functional, even if we do not mention them any longer in the documentation.  — SMcCandlish ☏ ¢ 😼  17:55, 6 December 2020 (UTC)

  At least in the common two-hand keyboard layouts for touch-typing (including US and UK QWERTY layouts), there is no need to move the whole hand away from the letter keys to reach the hyphen. All it requires is a slight move of the right hand's little finger. --Matthiaspaul (talk) 23:16, 4 December 2020 (UTC)

  For |accessdate= on a qwerty keyboard, the introductory pipe is both hands, 'accessdate' left hand only, and the assignement operator is right hand and the key is directly adjacent to the hyphen character.

  —Trappist the monk (talk) 12:32, 5 December 2020 (UTC)

• Support of the deprecation of all non-hyphenated multiword parameter names to achieve consistency across the project, improve readability in general and help users to memorize multiword parameter names. The fact that long parameter names wrap around also helps to keep citations readable even in narrow edit windows. In the long run, deprecation will help to simplify the citation template source code somewhat, giving us more room for more useful enhancements than just supporting syntactical equivalent parameter variants. I think, there has been a trend towards this for several years.
• While I think we should be careful not to actually remove support for frequently used parameter variants until all uses in mainspace (and possibly also in other spaces) and all tools have been updated to use hyphenated parameter variants, I think, we should not skip a chance to transform citations automatically in order to make the transition as smooth as possible for everyone.

  --Matthiaspaul (talk) 22:34, 30 November 2020 (UTC)

  Just one observation about the automation proposal. There are hundreds (literally) of templates that wrap {{cite book}}, and many more that wrap {{cite encyclopedia}}, etc. Some of these templates recognize and pass through |authorlink= etc. That raises two concerns - identify all those leaf templates that recognize these parameters and pass them on, and make sure they also recognize the hyphenated version before touching their customer articles. (There are other templates that transclude {{cite book}} and can be fixed painlessly). Second, somewhat orthogonally, in order to make the change thoroughly it should be necessary to list all templates that through a call chain end up in cs1|2, and fix the articles that use them. None of this is urgent as long as the smashedtogether variants are supported, of course. David Brooks (talk) 04:19, 1 December 2020 (UTC)

  Reconsideration overnight: First, I used the term transclude too loosely above. I meant templates that are simply shorthand for a specific book and have a hardwired |authorlink=, as opposed to those that call {{cite book}} with parameters passed through. More significantly, I guess {{cite book}} was not a great example, because it is not likely that users will override the specific author. More likely cases: templates that wrap {{cite encyclopedia}} or {{cite journal}}. An example of the former is {{New Cambridge History of Islam}}, which needs to recognize |author-link= before fixing its callers. I only did a shallow dive to show this pattern is non-zero. David Brooks (talk) 14:38, 1 December 2020 (UTC)

  Yes, both are good points but are already on the radar, I think, although perhaps more in a manner of an ad-hoc approach rather than systematically planned. As far as I have seen it, what we have done in the past is mostly to fix up the call down to CS1/CS2 (thereby ensuring that the templates continue to work after a switch) and leave it to the maintainers of these non-CS1/CS2-wrappers to adjust the article-facing side of parameters as they see fit. To achieve maximum consistency across the project it probably makes sense to help them by running bots tasks to fix up their parameter uses as well, but we have plenty of time for that.

  --Matthiaspaul (talk) 15:38, 1 December 2020 (UTC)

  I did some experimentation yesterday with a variant of Monkbot task 18 (namespace restriction limit lifted and the empty positional parameters subtask disabled). The experiments that I did yesterday suggest that task 18 in its limited form can successfully edit many of these kinds of templates. This search finds about 3300 templates that use {{cite book}}. Similar numbers for {{cite news}}, {{cite journal}}, and {{citation}} but not for {{cite encyclopedia}} (142).

  —Trappist the monk (talk) 15:37, 2 December 2020 (UTC)

  Thanks for the suggested search terms. Using that as a basis, I found that {{Cite encyclopedia}} has just 6 customers with {{{authorlink but no mention of author-link. So the potential fixups are getting more tractable. David Brooks (talk) 16:28, 2 December 2020 (UTC)

  There appear to be about 13,000 templates that contain "accessdate=", typically in a CS1 template inside the template. At some point in this long process, preferably before we start categorizing pages with unhyphenated parameters, Monkbot or someone else with an approved BRFA will probably need to run through those templates. – Jonesey95 (talk) 15:58, 3 December 2020 (UTC)

  I didn't look at accessdate, but it's the case that authorlink is often hard-coded in a template's code to refer to a particular book, rather than being passed down to CS1. For example, that's true of the first one that came up in that search, {{Taxonomy/Lepidoptera}}. No reason not to fix them, but as they aren't visible to regular editors they may be less urgent - if they could be distinguished easily. David Brooks (talk) 16:43, 3 December 2020 (UTC)

  |authorlink=? Did you mean |accessdate=? It is those kinds of cs1|2 templates-within-templates that task 18 can fix. It will not be able to fix cases where the wrapper template accepts/requires |accessdate= as an input:

  |accessdate={{{accessdate|}}}

  might be able to fix the lvalue and maybe, with some tweaking (don't hold your breath) might fix simple rvalues like my example.

  —Trappist the monk (talk) 17:16, 3 December 2020 (UTC)

  Yes, I meant |authorlink=, which I had looked at in a little detail, and just inferred that |accessdate= could have similar characteristics. Thanks for the clarification. David Brooks (talk) 17:44, 3 December 2020 (UTC)

• Something I thought about: when the time comes (say, the next update), should we create a category like Category:CS1 maint: uses non-hyphenated parameter names to track remaining uses of the parameters in question, regardless of whether they are currently deprecated? Since it's a maintenance category, this would only be visible to users who have opted in to seeing these messages anyway. -BRAINULATOR9 (TALK) 02:49, 2 December 2020 (UTC)

  Were we to do that today, we would create an enormous category of some 2.7 million articles. This search finds that many for |accessdate=. I'm not at all sure how useful that will be.

  —Trappist the monk (talk) 15:37, 2 December 2020 (UTC)

I think that the sense of the above discussion is that we are going to deprecate all nonhyphenated parameter names. As of the time I write this, Monkbot task 18 has made more than 125,000 edits. About half of those edits included the |accessdate= → |access-date= fix. Those 125k edits were made to a broad variety of articles so likely are included on thousands of watchlists. There have been 22 reverts (0.0176%). Given all of this, I intend to restore the |accessdate= → |access-date= fix to minimize the number of articles that Monkbot must revisit.

—Trappist the monk (talk) 14:53, 3 December 2020 (UTC)

Is it possible that this bot activity changed the parameter name in "old" templates that don't recognize access-date? David Brooks (talk) 16:43, 3 December 2020 (UTC)

I don't know what you mean by "old" templates. The task's activities are constrained to edits inside the canonical 27 cs1|2 templates and some of their most commonly used redirects. All of the canonical cs1|2 templates invoke Module:Citation/CS1 so all of them accept both |accessdate= and |access-date=. Redirects, being redirects, simply take the round-about way to get to Module:Citation/CS1. Did I answer the question?

—Trappist the monk (talk) 17:08, 3 December 2020 (UTC)

Yes, you did, thanks. "old" meant those written in innocence of the newer hyphen-preference. David Brooks (talk) 17:44, 3 December 2020 (UTC)

And here's a fun one. {{Schaff-Herzog}} (hundreds of uses, but I didn't check how many specify access date or author link) recognizes only |accessdate= but presents it as access-date when calling {{Schaff-Herzog cite}}. That redirects to {{Cite Schaff-Herzog}}, which (stop me if you've heard this before) recognizes only |accessdate= but presents it as access-date before passing to {{Cite encyclopedia}}, which invokes CS1. So there's no way of successfully representing the parameter, and the same blocked path attends |authorlink=. Sorry, just pointing out that while the 27 canonical templates are well-behaved, the rest of the ecosystem is a mess; there's no simple global fix. But I think everyone knew that. David Brooks (talk) 22:39, 3 December 2020 (UTC)

I have fixed a lot of those kinds template pairs. It is a good use of Module:Template wrapper so I'll fix those templates.

—Trappist the monk (talk) 23:19, 3 December 2020 (UTC)

And fixed, I think,

—Trappist the monk (talk) 00:44, 4 December 2020 (UTC)

@Trappist the monk: The above discussion is definitely not a strong enough consensus to deprecate such a widely-used parameter; it's only been four days and participation is quite low. Suggest making this an RfC with appropriate publicity. Nikkimaria (talk) 02:52, 4 December 2020 (UTC)

The purpose of this discussion is to determine if we, the maintainers of the cs1|2 templates, intended to deprecate and remove all nonhyphenated parameters, and if we do, to declare that intnet. We seem to have made the determination that yes, we intend to deprecate nonhyphenated parameters. But, I will wait a few more days until this discussion has been open a week to see if there is a change in our opinion.

—Trappist the monk (talk) 12:50, 4 December 2020 (UTC)

And I'm saying that, given the scale of this change, it shouldn't be left up to the small number of regulars on this page but should receive input from the wider community. What is your objection to that? Nikkimaria (talk) 13:47, 4 December 2020 (UTC)

Monkbot task 18 is closing in on 150,000 page edits. Each page that is edited is a poll of the editors who watch that page and so a poll of the wider community. Sure, it's likely that a portion of those pages are not being watched. The remainder are being watched. Every watcher in the wider community has the opportunity to revert the bot's edits. A very few (15 at the time I write this) have chosen to revert. The wider community's silence speaks quite loudly.

—Trappist the monk (talk) 15:05, 4 December 2020 (UTC)

See WP:FAIT. Let's have a properly advertised and well attended discussion to establish real consensus for what you're proposing, rather than having your bot make this change without an established consensus and then pointing to revert-count as a substitute. Nikkimaria (talk) 21:47, 4 December 2020 (UTC)

Not WP:FAIT but, as alluded to in the last sentence of my previous post, WP:SILENT.

—Trappist the monk (talk) 12:32, 5 December 2020 (UTC)

Making a mass edit without prior established consensus and then pointing to its persistence as evidence of consensus? Textbook FAIT. Have an actual RfC to get consensus for your proposed change, or don't make your proposed change at all. Nikkimaria (talk) 13:12, 5 December 2020 (UTC)

An edit is made, it is neither reverted nor changed. Text book WP:SILENT. So you then say something about WP:FAIT. Which prompts me to ... ad nauseum. Sigh.

—Trappist the monk (talk) 15:43, 5 December 2020 (UTC)

Not "an" edit. By your own count, 150,000 edits made without consensus. With objections from multiple editors. Nikkimaria (talk) 15:59, 5 December 2020 (UTC)

Trappist the monk, again: please start a well-advertised properly-run RfC. Editors have raised objections here and at your talk page, and even those supporting preferring hyphenated parameters have expressed concerns about aggressive bot-runs and removing functionality. A change impacting over a third of the articles on the site should have a stronger consensus behind it than what is seen here. Nikkimaria (talk) 22:06, 8 December 2020 (UTC)

Support most bot-assisted "aggressive" deprecation, but anything >25,000 uses (e.g. |accessdate= should be kept supported. When they fall <25,000 through "passive" conversations (e.g. AWB genfixes), then we can have bots aggressively convert them. Headbomb {t · c · p · b} 17:28, 3 December 2020 (UTC)

That's an idea, though for |access-date= the scale is millions of articles, it could take years - even bot speed could take months. Years might not be a problem through patience and dogged determination, but in the mean time users are still adding new templates (est 5-10 thousand a week) creating churn - users adding, bots removing, spinning wheels. So the idea if I understand is to deprecate with a red warning message, but that can't be rightly done until most of the existing stock is removed since in the past when millions of red warning messages suddenly appear the community revolts and demands the problem be fixed before red errors flood articles. -- GreenC 18:12, 3 December 2020 (UTC)

I tried the "passive" [conversions] route by including |accessdate= → |access-date= in AWB genfixes but there was pushback; understandable because there are so many instances of |accessdate= that the genfix obfuscates the fixes that awb operators intend. I have since suspended that genfix.

—Trappist the monk (talk) 18:51, 3 December 2020 (UTC)

I support deprecation of unhyphenated multi-word parameters. I do not think we should show red error messages or put pages in any sort of tracking category until Monkbot has processed 95% or more of the estimated 2.7 million articles with such parameters. – Jonesey95 (talk) 18:30, 3 December 2020 (UTC)

Comment and neutral. I wonder why bot task 18 was approved in the first place. Consider task 18's function #5: hyphenates cs1|2 parameters when they are written using the to-be-deprecated all-run-together form. It is admitted above that "we have never actually declared an intent to deprecate and remove" those parameters so this description could be considered misleading. Second, "to-be-deprecated" means they are still valid so the choice of wording here is suspiciously imprecise for a multi-million article bot and was a hint that many this hasn't been scrutinized enough. I also question the wisdom of not recognizing that the widespread use of |authorlink= and |accessate= makes global changes to them important enough to warrant special treatment. I think sometimes it makes sense to unbundle big very specific changes from less specific umbrella tasks that have mostly a bunch of rare and non-controversial changes. I'd like to see the bots approval group lean towards more specific, smaller tasks in the future as the discussion above shows how valuable focused discussion just on just |accessdate= is. That said, I recognize the power of WP:BE BOLD and don't want to discount the efforts of those who have the know-how and put in the work to keep Wikipedia evolving. For reasons related to both typing and reading source code, I have a preference for |accessdate= over |access-date= but since those editors actually working in this area are clearly against the un-hyphenated ones, I am fine with being neutral in regards to their deprecation or this bot making these changes. Jason Quinn (talk) 06:09, 4 December 2020 (UTC)

You should not be surprised that we have never actually declared an intent to deprecate and remove. We know our intent from the actions that we take, the code and the documentation that we write, etc. This discussion is about declaring our intent.

Yes, "to-be-deprecated" means they are still valid. These parameters are valid now and will be valid during the deprecation period until support for them is withdrawn. Given that support will be withdrawn, it is necessary to convert those nonhyphenated names to their hyphenated equivalents before deprecation so that we minimize the quantity of and similar error messages. Too many of those cause torches and pitchforks uprisings. It is precisely the recognition of the widespread use of some of these parameters that makes Monkbot task 18 important because when it comes time to deprecate these parameters, there will be far fewer error messages to distress editors.

If you have issues with WP:BAG and the WP:BRFA processes then you should take them up in the appropriate venues. This venue is not for those topics.

—Trappist the monk (talk) 12:50, 4 December 2020 (UTC)

Is it clear that parameters are not removed/deprecated? What is changing are parameter labels (names) aliases, marginally. All the software routines and module functions will be the same, and will result in exactly the same intended result. For prospective template editors, this is purely a minor nomenclature change to conform with the rest of the system, and one which I believe enhances clarity. It seems that most objections to this are along the lines of "we've always done it this way". 98.0.246.242 (talk) 00:01, 5 December 2020 (UTC)

• @Trappist the monk: task18's revert rate (as of a week ago) of 0.0176% is very, and indeed WP:SILENTly, low. Would you be able to determine a previous large task's revert rate, as another point for reference?   ~ Tom.Reding (talk ⋅dgaf)  15:44, 9 December 2020 (UTC)

  Alas, no. Because task 18 is a cosmetic task and because there was concern at the WP:BRFA that the community might rise against it, from the start I have been keeping track of the number of edits and logging each revert so that I could get a sense of what the community thinks. I have never felt the need to keep such statistics in the past. I have a sense that task 14 incurred more enmity than task 18 and involved 'only' 50k–75k' articles.

  Ah! this just in: For task 14 I kept a filter file that I could use to make awb remove articles from the lists that it created from cirrus searches. That list has 55 article titles. If, to be ultra conservative, we assume that task 14 operated on 100k articles, that gives a revert rate of 0.055% – 'hostile' reverts only, I did not keep track of reverts where the bot had edited vandalized articles or the I-don't-know-what-this-is-so-I'll-revert kinds of reverts or the inevitable drive-by reverts.

  As of this writing the revert rate for task 18 is 0.0145% (35 reverts in 241k edits). That includes all reverts, including those where the bot edited a vandalized page, etc.

  —Trappist the monk (talk) 17:06, 9 December 2020 (UTC)

Where are we on this? Everyone seems to have moved on and I'm not clear that all the outstanding questions are resolved.

The only RFC I'm aware of is the June 2014 resolution that only "All parameter names in Citation Style 1 templates" should accept hyphenated parameters; in addition, I think there is a consensus that documentation—narrative, examples, and TemplateData—should privilege the hyphenated versions. I believe both have been accomplished for the 26 or 23 (depending which list you consult, and I may have the wrong formal terms) canonical or "General use CS1 templates", but question 1: Is it still valid to use the nonhyphen versions in an example, if there are any such?

Remaining are the hundreds that wrap one of those templates, in particular those that recognize the parameters and pass them on (there are others that simply use a CS1 template internally to identify a single specific source). Are they included in the phrase "Citation Style 1 templates" in the RFC? If so, question 3: should there be a formal effort to identify those that don't recognize hyphens, and fix them? Some have been fixed recently but I think only because they were found using an incomplete search. Independently, question 4: should we make an effort to fix all the documentation, or will "fix them when you see them and have time" be OK for now, given that there is no agreement to formally deprecate the nonhyphen parameters? David Brooks (talk) 16:50, 14 December 2020 (UTC)

As I said above, there are many thousands of templates that contain |accessdate=. Not all of them are CS1 wrapper templates. It will probably be easiest to deal with them as follows: (1) Let Monkbot complete its run through affected articles, (2) put unhyphenated parameters in a maintenance category, which will allow us to catch templates, pages in other namespaces, and edge cases that the bot was unable to process, (3) process the pages in the maintenance category using a combination of bots and manual gnome work, (4) formally deprecate unhyphenated parameters in the module code, using the deprecated parameter category, and finally (5) remove support for the deprecated parameters. This process will probably take a year or more. – Jonesey95 (talk) 17:36, 14 December 2020 (UTC)

Sure, except (1) needs care, because there is no guarantee that every template, whether or not they end up in CS1, that accepts |accessdate= (etc) recognizes |access-date=. I guess the hunt through those that use CS1 could be automated pretty easily. David Brooks (talk) 22:40, 14 December 2020 (UTC)

• I oppose User:Monkbot/task 18 at least temporarily until it's been discussed - this seems to be a large-impact task that didn't get much attention when it was approved, and is now causing consternation...

1. I thought AWB wasn't supposed to be used for purely cosmetic edits? Isn't DavidBrooks right that if it is done it should be with Toolforge instead of spamming everyone over millions of articles?
2. I don't see a need to get rid of especially |accessdate= which is so commonly used. A lot of editors prefer it, perhaps even most? What was the ratio of with and without the hyphen before Monkbot started "fixing" it?

··gracefool 💬 09:38, 15 December 2020 (UTC)

• Comment. There should be no circumstance in which |accessdate= without the hyphen is ever deprecated. It should remain a valid alias. Plenty of users still create articles with citations that use the unhyphenated form, and if the goal is to inflict big ugly red error messages or just not display the date at all upon use of the unhyphenated form, I can't see how that's going to go down well or how it's even an appropriate remedy. There are claims this is for clarity, but who has ever said they were confused about what the unhyphenated form of |accessdate= means? Cosmetic, spam-like bot edits is all this is currently amounting to. I don't see the point of these edits. There will never be complete conformity on any issue like this on Wikipedia, and we should stop trying to force people to adapt when the old form has endured for years without any hassle. Ss112 13:42, 15 December 2020 (UTC)
• Comment. Per Ss112, and out of incredulity at the leeway cite template editors appear to be afforded, this ongoing wave of so-called cosmetic edits is spam-like; totally disruptive. I try to keep my watch list to a minimum, but even then, they're well-visited articles, and the mass (bot) activity can mask a whole range of unwelcome IP edits. What I can't figure out is why accessdate=, archiveurl=, p= (etc), was ever permitted if it's now deemed a major problem across the whole encyclopedia. Or the other way 'round: why it's suddenly a problem, after someone wayback-when allowed the unhyphenated/abbreviated forms, and editors acted accordingly and continue to do so. It's constantly upside down with this CS1/2 bollocks: it should be the cite templates serving article content, but it ends up that editors have to come here and ask a precious few what they're doing. Ask their permission, even. Which would be WP:OWN in every other circumstance. JG66 (talk) 14:51, 15 December 2020 (UTC)
• Response. This is the page where the templated application of cs1/cs2, one of the non-compulsory citation formats (styles) is discussed. That is why people have to come here, if they want to join the discussion. And like any other restricted property in Wikipedia, suggestions must be submitted and edit requests must be made to those who are currently administering the particular areas. This is the norm; given the complexity of the cs1cs2 project, a necessity.

In Wikipedia, citations in general do not serve articles. They explicitly serve the Wikipedia verification policy, which may apply to individual articles, but impacts Wikipedia's standing in toto. Wikipedia, after all, is a project where pseudonymous persons? bots? pieces of scrapcode? calling themselves "JG66" or some easily faked machine network address, can find a platform for elaborate discussions on non-issues such as the temporary appearance of an error message regarding the rendering of an important, but non-vital parameter in an application of style that is a matter of choice.

Without easily verifiable citations (in any style) anything in main space is garbage, worthy of any inane handle it is edited under. To repeat: citations do not serve articles. They are not around to make your article look good, or complete. They are there to take your work out of the trash pile, and establish it as fact. Otherwise, there are many platforms one can publish fiction at.

In any case, I believe that good arguments have been made for this particular change, including the argument that separating madeup compound terms enhances clarity and it is not simply cosmetic. 66.65.114.61 (talk) 20:10, 15 December 2020 (UTC)

More helpful error messages

Things like this:

in a big article can sometimes literally take an hour or longer to track down. If the code is smart enough to catch the error, it seems like it should be able to tell us what citation it appears in. It would probably actually make more sense to have these be red error messages in the citation, like most cite errors, instead of being page-top notes.

PS: There's also a bug, in that it won't detect |first= and |first1= in the same template as duplicates, even though one is an alias of the other. This may affect various other aliased params; I haven't tested it in depth.
 — SMcCandlish ☏ ¢ 😼  21:03, 30 November 2020 (UTC)

When a cs1|2 template has two parameters with the same name, MediaWiki gives Module:Citation/CS1 the last one it found. cs1|2 does not get or see the first one. This is an issue that must be addressed at MediaWiki.

—Trappist the monk (talk) 21:31, 30 November 2020 (UTC)

cs1|2 does detect |first= and |first1= in the same template as duplicates:

{{cite book |title=Title |last=Last |first=First |first1=First1}}

Last, First. Title. {{cite book}}: More than one of |first1= and |first= specified (help)

—Trappist the monk (talk) 21:33, 30 November 2020 (UTC)

This is not a CS1 message; it is a MediaWiki message that applies to all templates. If you follow the Help link and scroll down to "Locating the error", you will see helpful tips, including a script (User:Frietjes/findargdups) that moderately technical folks can install and use to identify the specific template that is generating the error. The script works well; I have used it for many years, since shortly after the introduction of this error-checking feature to MediaWiki. If all else fails, ask for help here, or post a "help me" request on the article's talk page, or post a help request at Category talk:Pages using duplicate arguments in template calls. Don't waste an hour of your life trying to fix it unless that is something you consider fun (as some of us gnomes do). – Jonesey95 (talk) 22:01, 30 November 2020 (UTC)

I agree that it would be great if MediaWiki would give more information in regard to this error. Perhaps that's something for (deadline later today):

https://meta.wikimedia.org/wiki/Community_Wishlist_Survey_2021

--Matthiaspaul (talk) 22:04, 30 November 2020 (UTC)

Part of what I'm getting at here (aside from the above "big-boxed" error examples not telling you which cite out of 200 of them is the issue) is that we have two completely separate error-reporting processes happening here, which isn't very helpful, especially since what they can detect and report is not consistent between the two.  — SMcCandlish ☏ ¢ 😼  20:54, 4 December 2020 (UTC)

Detect misuses of author parameter

Given the thread just above this, there is clearly some non-trivial code that can do various kinds of error detection. A useful one would would output something like "Warning: {{pagename}}} is calling Template:Cite whatever with what may be a misuse of the "author" or "last" parameter. (Help)" It could look for patterns like a long string followed by a letter and a dot followed by another long string ("Youill X. Zounds"), a letter-dot followed by a letter-dot followed by long string ("Y. X. Zounds" or "Y.X. Zounds"), a long string followed by a comma followed by another long string or by one or more letter-dots ("Zounds, Youill", "Zounds, Y.", "Zounds, Y. X."), and maybe a few other things. This wouldn't be utterly foolproof (couldn't distinguish "U.N. Foobar Investigative Commission", but that should be rewritten to use "UN" anyway), but it would help a lot.  — SMcCandlish ☏ ¢ 😼  21:14, 30 November 2020 (UTC)

We already have Category:CS1 maint: extra text: authors list and Category:CS1 maint: multiple names: authors list. What other specific checks do you envision? – Jonesey95 (talk) 22:10, 30 November 2020 (UTC)

I'm thinking more of an explicit visual indication, at least in preview mode if not in final display. I.e., so the editor at hand can resolve it now rather than gnomes being expected to "some day" get around to it, which frankly is not likely to actually happen, given the number of errors of this sort I encounter, some of them many years old.  — SMcCandlish ☏ ¢ 😼  20:51, 4 December 2020 (UTC)

The reason that there are so many of them (somewhere between 37K and 60K pages, depending on overlap between the categories) is that the CS1 modules only started checking for them in 2016 and 2017, and they have never displayed error messages except to the few dozen of us who show maint messages. I believe that the reason for maint instead of error messages (which would be displayed to all readers and editors) is that there are many false positives. – Jonesey95 (talk) 01:03, 5 December 2020 (UTC)

Maybe it could detect cases where someone writes |author=Doe, John rather than |last=Doe|first=John? I don't have the time (nor really the patience) to find examples of this, but I've seen a few. Glades12 (talk) 07:00, 5 December 2020 (UTC)

Never mind, I was skim-reading and didn't notice that SMcCandlish had already mentioned this. Glades12 (talk) 07:06, 5 December 2020 (UTC)

We do not have acceptable method of indicating instutional authors with commas in them. We have a hack of "accept this as written" markup, increasingly pushed into other parameters. Otherwise, I would decidedly recommend looking for any and all commas in author fields. --Izno (talk) 14:21, 5 December 2020 (UTC)

I appear to have misread SMcCandlish's original post. Is SMcCandlish suggesting that |author=Youill X. Zounds be deprecated or somehow flagged as an error? If so, I think there will be significant opposition. Our current documentation suggests (and has suggested for a heck of a long time) that this formulation is perfectly fine: author: this parameter is used to hold the complete name of a single author (first and last) or to hold the name of a corporate author. Maybe I misunderstand. If there is a specific value of |author= that should be put in the maint category and is not currently put in the maint category, please make that explicit here. – Jonesey95 (talk) 00:25, 6 December 2020 (UTC)

That instruction dates to before |author= and |last= (a.k.a. |last1=) became the same parameter. |author=Youill X. Zounds is an error because it identifies the entire string as a surname or institutional author. We have |last[1]= and |first[1]= for a reason.  — SMcCandlish ☏ ¢ 😼  17:52, 6 December 2020 (UTC)

Umm, no. I added that clause to the documentation with this edit. Here is the edit that converted {{cite book}} from an independent template to use {{citation/core}}. A little inspection will show that before and after that edit, |author= and |last= (a.k.a. |last1=) became the same parameter at some earlier time. The other major cs1|2 templates were similarly converted at about the same time give or take a year or two.

—Trappist the monk (talk) 18:14, 6 December 2020 (UTC)

PMID update

Hello,

could you please update the limit for PMIDs? The current value appears to be outdated.

Thank you! — Preceding unsigned comment added by Medconsult1 (talk • contribs) 22:25, 4 December 2020 (UTC)

See Help_talk:Citation_Style_1#PMID_numbers

--Matthiaspaul (talk) 22:40, 4 December 2020 (UTC)

Use in Works section

Can the {{cite book}} template be used in the Works section of writer? If not, is there another template to be used? I'm looking for a uniform way of adding information such as editions, page count, where to read online, etc. Thanks. — Orgyn (talk) 12:42, 6 December 2020 (UTC)

Yes. It is commonly used for that. When used that way, as in references, the template should be complete. If it is desirable to omit the author's name from the rendering, use |author-mask= or |display-authors=0.

—Trappist the monk (talk) 12:46, 6 December 2020 (UTC)

Great, thanks for the quick answer! — Orgyn (talk) 12:51, 6 December 2020 (UTC)

Author/Editor link in other language

Is there a possibility to provide an authorlink (or link to a magazine or whatever) in another language when there is no article in :en? Or am I getting crufty? Best,  Mr.choppers | ✎  20:27, 7 December 2020 (UTC)

Here is one way:

{{cite book|title=Title|author=Johann Smith|author-link=:de:Johann Smith}}

There may be a better way. – Jonesey95 (talk) 21:01, 7 December 2020 (UTC)

That is the 'supported' way, yes. I personally prefer not to link if the page is not on en.wp, or to provide a redlink for likely notable names, but that is personal preference. --Izno (talk) 21:03, 7 December 2020 (UTC)

Yes, it does fail the MOS:EGG test, since there is no indication that the reader is being sent to somewhere other than an English-language article. It would be nice if the link behaved like {{ill}} does. – Jonesey95 (talk) 22:08, 7 December 2020 (UTC)

{{ill}} is hardly intuitive. You and I may understand what the little-linked-language code means, but we cannot expect readers to understand what those sometimes very cryptic language codes mean. We might convert interwiki style links into external links so that your example might render:

Johann Smith. Title. {{cite book}}: External link in |author= (help)

Not very elegant but at least readers know that the link target isn't local to this wiki. Alternately, we might wrap the link in a <span>...</span> tag with a title= attribute:

[[:de:Johann_Smith|<span title="Johann Smith at the German Wikipedia">Johann Smith</span>]]

Johann Smith [in German]. Title.

That isn't very elegant either because it requires an action on the part of the reader to discover the link target... And yes, we could combine both:

Johann Smith. Title. {{cite book}}: External link in |author= (help)

—Trappist the monk (talk) 22:50, 7 December 2020 (UTC)

The big advantage of ill links is that they automagically turn into non-ill links once an article here is created for the same topic. I don't think we should add authorlinks to other languages unless we can do so with the same automatic transformation. —David Eppstein (talk) 22:55, 7 December 2020 (UTC)

Emulating {{ill}}, we'd need some way to specify two links if the title is not the same in the foreign and local Wikipedia. However, we could take advantage of Wikidata for this:

Let's assume that in lack of a local article |author-link= points to a WP article in another language. The template could then check if the foreign article is connected to Wikidata. If it is, it could further check if the Wikidata entry (meanwhile) also has an entry for a local article. If this would be the case, the |author-link= link would be automatically overridden by a link to the local article and the article put into a maintenance category so that the |author-link= link can be updated to point to the local article directly. (In the rare event, that we really want to point to the foreign article, we could use our accept-as-written markup |author-link=((:prefix:title)) to disable the smart override and enforce the link.)

--Matthiaspaul (talk) 20:10, 8 December 2020 (UTC)

Why we'd need some way to specify two links? What you describe seems like it should work, needing only |author-link=:de:Uta Lindgren (or whoever else). The {{ill}} template needs a way to take two names, both the local-language text to be linked and the other-language article title to be linked, but we only need to supply the other-language article title, because the local-language text of the link is already supplied by the |first= and |last= parameters. In fact there are probably existing citations using this syntax that this handling could improve. —David Eppstein (talk) 02:10, 9 December 2020 (UTC)

Yes, what I meant by "two links used by {{ill}}" is the (quite common) case, where the still non-existing red but suggested local title and the existing foreign-language title are not the same. This would be undesirable for our purposes, because we would have to introduce yet another parameter class for this (or some means to give two link targets in one parameter).

However, by the proposed scheme to just point to the foreign language article (as we currently do anyway) and let the template automatically work from there through Wikidata means (if available), we can avoid a second link, while keep the existing parameters and syntax at the same time. There are two potential backdraws:

• The proposed scheme implies that both link targets are actually connected to the same WD node, if present, not two independent ones.
• Issuing a number of WD queries might be expensive (TBC).

Still, I think, that the "same WD node" limitation is acceptable for our purposes, because the cases where this is not true are rare and we we would be erring on the safe side, anyway.

Expenses might be acceptable as well given that these queries would only happen on demand and the number of cross-site links are low compared to local ones.

So, this actually might be an elegant solution.

--Matthiaspaul (talk) 20:43, 10 December 2020 (UTC)

Re-inventing the logic of {{ill}} in citation templates seems counterintuitive. Why can't |author-link= accept {{ill}}: {{cite book|last=Lindren|first=Uta|author-link={{ill|Uta Lindgren|de}}|title=Title|ref=none}} -> Lindren, Uta. Title. {{cite book}}: Check |author-link= value (help). Can't the CS1 code make an allowance for this? -- Michael Bednarek (talk) 10:42, 15 December 2020 (UTC)

're-invention', if it could be called that, would still be required. The primary purpose of |author-link= is to provide an article title when the cs1|2 template uses |last= and |first=:

|last=Lindgren |first=Uta |author-link=:de:Uta Lindgren → [[:de:Uta Lindgren|Lindgren, Uta]] → Lindgren, Uta

Simply dropping {{ill}} into |author-link= does not work because what you get is:

|last=Lindgren |first=Uta |author-link={{ill|Uta Lindgren|de}} →

[[[[Uta Lindgren]][[Category:Interlanguage link template existing link]]|Lindgren, Uta]]

Further, when the article is available on en.wiki, {{ill}} adds a category link to its rendering. So, cs1|2 would need to parse apart whatever it gets from {{ill}} before it could create the equivalent.

—Trappist the monk (talk) 13:17, 15 December 2020 (UTC)

URL checking

Should this citation throw a url error? It doesn't trigger a link. kennethaw88 • talk 03:29, 9 December 2020 (UTC)

Liberatore, Paul (28 January 2011). [hhttps://www.marinij.com/2011/01/28/radio-personality-carter-b-smith-of-tiburon-dies-at-74/ "Radio Personality Carter B. Smith of Tiburon dies at 74"]. Marin Independent Journal. Retrieved 8 December 2020.

Well, yes and no. URI schemes are tested against the definition of a scheme specified in std 66 §3.1 so, according to that, hhttps: is a valid scheme.

—Trappist the monk (talk) 11:38, 9 December 2020 (UTC)

Would it be possible to check instead against the list enshrined in WP:ENCODE, to help fat-fingered typists? David Brooks (talk) 15:23, 9 December 2020 (UTC)

I wonder if we couldn't use the URI library in some way; I see a validate function there which might be able to help us validate the scheme. (Actually, I wonder if it could be used to do more of our URI validation in general.) --Izno (talk) 16:34, 9 December 2020 (UTC)

I remember experimenting with that when I was writing our current validation. I don't remember why I didn't use it.

—Trappist the monk (talk) 19:09, 9 December 2020 (UTC)

However, the scheme hhttps is not in the registry specified by RFC 7595 Shmuel (Seymour J.) Metz Username:Chatul (talk) 12:59, 13 December 2020 (UTC)

References

Publishers without work parameter

I could have sworn there was a maintenance category for this as the practice has become discouraged. Am I wrong or just missing something? –MJL ‐Talk‐^☖ 06:34, 9 December 2020 (UTC)

I'm talking about when someone uses {{Cite web}} or {{cite news}} but leaves the |work= parameter blank and fills the publisher parameter with something like this: |publisher=CNN. –MJL ‐Talk‐^☖ 06:36, 9 December 2020 (UTC)

There isn't a problem there to be fixed. Publisher without work is perfectly normal and often the best choice for a citation, when the text you want to put in that part of the citation is more a description of the organization making the web page or news story available and less a description of what site or channel they made it available through. CNN is an ambiguous one because it could refer either to the organization or to its channel or web site, so could reasonably go in either position, but in other cases it is more clear cut. In many of those cases, publisher without work is the correct choice. The actual problem that we face here is not that. It is that despite a clear consensus that the work a citation comes from should be italicized and that the organization that publishes it should not, some editors disagree with those choices and deliberately misclassify values that should be work into publisher or vice versa in order to get the formatting they prefer. You are not going to fix that with a blind policy to put everything into work and to create a maintenance category for exceptions. —David Eppstein (talk) 06:48, 9 December 2020 (UTC)

Yes, this is one of our few hidden errors after last year's hullabaloo. You're looking for Category:CS1 errors: missing periodical. --Izno (talk) 08:34, 9 December 2020 (UTC)

That should be for a template like cite journal or cite magazine that does not say the name of the journal or magazine. That is indeed an error. —David Eppstein (talk) 18:26, 9 December 2020 (UTC)

Appreciate the responses! :D –MJL ‐Talk‐^☖ 18:33, 12 December 2020 (UTC)

Cite Q updated

{{Cite Q}} had another bunch of updates today, including tracking categories for replaced or retracted papers. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 23:45, 12 December 2020 (UTC)

Citing section of journal article?

IBM System/360 cites a section within a journal article with this <ref>{{cite journal | author = A. Padegs | title = System/370 Extended Architecture: design considerations | journal = IBM Journal of Research & Development | volume = 27 | issue = 3 | pages = 198–205 | date = May 1983 | publisher = IBM | doi = 10.1147/rd.273.0198 }} – a subsection titled "31-bit addressing" begins on page 201.</ref> markup. The {{cite journal}} template does not support |section= or |section-url=, nor does it support nested page ranges.

What is the proper markup for doing this? Shmuel (Seymour J.) Metz Username:Chatul (talk) 13:24, 13 December 2020 (UTC)

References

Template:Cite journal § In-source locations: "page: The number of a single page in the source that supports the content" and "pages: A range of pages in the source that supports the content." Others, of course, disagree with that and are happy to squabble about it. Alternately, "at: For sources where a page number is inappropriate or insufficient." Perhaps, |at=§31-bit addressing p. 201

—Trappist the monk (talk) 14:41, 13 December 2020 (UTC)

Example of citing YouTube videos in the documentation of Cite AV media

This 2016 discussion requested an example of how to cite YouTube videos with Template:Cite AV media. As of 13 December 2020, Template:Cite AV media/doc does not have an example of a YouTube citation. Therefore, I propose this example, taken from Taylor Swift:

{{Cite AV media|title=73 Questions With Troye Sivan|work=Vogue|date=June 20, 2019|url=https://www.youtube.com/watch?v=9FhyKC6wQso|via=YouTube|access-date=January 16, 2020}}

which produces:

73 Questions With Troye Sivan. Vogue. June 20, 2019. Retrieved January 16, 2020 – via YouTube.

What do you think? Is there anything that you would do differently? Hanif Al Husaini (talk) 14:02, 13 December 2020 (UTC)

Perhaps not the best example; that might do just as well (or better) in {{cite interview}}.

—Trappist the monk (talk) 14:45, 13 December 2020 (UTC)

If that's not the best example, let's use the video from the original post:

{{Cite AV media|title=Make It Pop {{!}} BTS of the Make It Pop Summer Episode {{!}} Nick|publisher=[[Nickelodeon]]|date=July 23, 2016|url=https://www.youtube.com/watch?v=jCMz5W94nxY|via=[[YouTube]]|access-date=December 14, 2020}}

which produces:

Make It Pop | BTS of the Make It Pop Summer Episode | Nick. Nickelodeon. July 23, 2016. Retrieved December 14, 2020 – via YouTube.

The original post also uses movie trailers as another example. Here is one:

{{Cite AV media|title=Wonder Woman 1984 - Official Main Trailer|publisher=[[Warner Bros. Pictures]]|date=November 19, 2020|url=https://www.youtube.com/watch?v=psFf4KXJZoQ|via=[[YouTube]]|access-date=December 14, 2020}}

which produces:

Wonder Woman 1984 - Official Main Trailer. Warner Bros. Pictures. November 19, 2020. Retrieved December 14, 2020 – via YouTube.

--Hanif Al Husaini (talk) 02:09, 14 December 2020 (UTC)