This is an archive of past discussions. Do not edit the contents of this page. If you wish to start a new discussion or revive an old one, please do so on the current talk page.

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: 11100000
• Current PMID limit: 38900000
• Current SSRN limit: 4700000
• Current S2CID limit: 270000000
• Current OCLC limit: 10170000000 (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))

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 e.g. 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)

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:

-- 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)).

-- 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)

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)

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)

— 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:

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.

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)

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)

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:

-- 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.:

-- 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.

-- 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.:

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

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, e.g., 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)

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:

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

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

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)

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

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)

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)

 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)

Moved from Template talk:Citation § ISBN line breaks

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

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)

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,479 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)

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)

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%. -- Green C

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. -- Green C 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 (e.g. 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)

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, e.g. 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 mentioned 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)

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)

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)

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)

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)

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}} 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)

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 ^[1] Shmuel (Seymour J.) Metz Username:Chatul ( talk) 12:59, 13 December 2020 (UTC)

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)

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)

I think solving this rather rare concern may cause more trouble than it's worth... For now I inserted Shigeharu Kumakura's name in Japanese in <!-- --> within the citation; if anyone really wants to find author's article that might help. For me the reason I wanted to include it is that it might be hard to find ja:熊倉重春 from their name written in Romaji, whereas getting to Uta Lindgren's German language entry would be fairly easy for a non-German speaker.  Mr.choppers |  ✎  15:25, 16 December 2020 (UTC)

Why did you do that? If you want to link the editor's name to the ja.wiki article, why did you not write: |editor-link=:ja:熊倉重春? This method was mentioned in the first reply to your initial post in this topic.

— Trappist the monk ( talk) 15:40, 16 December 2020 (UTC)

The obvious disadvantages of direct interlanguage links are 1) it's almost impossible to distinguish such links from internal ordinary Wikipedia links; 2) if an English article for Kumakura appears, the link will not change to that one. {{ill}}, which can be used in {{ wikicite}}, doesn't suffer from those. -- Michael Bednarek ( talk) 01:25, 17 December 2020 (UTC)

Ad 1) While I think this is deliberate so that links to all language entities of Wikipedia are treated as forming one unified "Wikipedia universe", it would be easy enough to change this so that prefixed links will have a special symbol attached to them. The symbol could be specific to the prefix (preferable) or just use the "external link" double-arrow symbol as well.

Ad 2) Above, I described a method how this could be solved, so that the citation template would automatically change a link to :ja:熊倉重春 to Shigeharu Kumakura as soon as it detects that an equivalent article has been added to the English WP.

-- Matthiaspaul ( talk) 14:47, 17 December 2020 (UTC)

Hello, there appears to be a problem with the lock symbols on urls, where the symbol overwrites the last letter of the title.

"Mirfield director of 96". 22 October 1943. p. 5 col.2.

Could be a browser/skin problem - using Firefox 83.0 (64-bit) with Monobook.

Keith D ( talk) 12:17, 17 December 2020 (UTC)

For me, using the current version of chrome with monobook, the lock above renders correctly.

— Trappist the monk ( talk) 12:30, 17 December 2020 (UTC)

I observed the same behaviour as Keith D reported. Disabling Enable responsive MonoBook design fixed this (and missing external links indicators, too); see phab:T270012 and WP:VPT#External links indicator. -- Michael Bednarek ( talk) 13:10, 17 December 2020 (UTC)

Thanks that fixes the problem. Keith D ( talk) 13:56, 17 December 2020 (UTC)

In the COinS guidance common to the documentation for {{ cite book}} and other CS1 templates, the following statement appears: Do not include Wiki markup '' (italic font) or ''' (bold font) because these markup characters will contaminate the metadata. Is this guidance out of date? There are plenty of situations in which italics are needed within a title – to mention a species name, for example. – Jonesey95 ( talk) 02:44, 22 December 2020 (UTC)

I don't see any COinS problems here. Am I missing something?

{{markup|{{code|lang=html|{{cite book |last=Last |first=First |title=This part of the Title is '''bold'''}}}}|{{cite book |last=Last |first=First |title=This part of the Title is '''bold'''}}}}

'"`UNIQ--templatestyles-00000194-QINU`"'<cite id="CITEREFLast" class="citation book cs1">Last, First. ''This part of the Title is '''bold'''<span></span>''.</cite><span title="ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Abook&rft.genre=book&rft.btitle=This+part+of+the+Title+is+bold&rft.aulast=Last&rft.aufirst=First&rfr_id=info%3Asid%2Fen.wikipedia.org%3AHelp+talk%3ACitation+Style+1%2FArchive+73" class="Z3988"></span>

98.0.246.242 ( talk) 22:54, 22 December 2020 (UTC)

Of course the documentation is out of date. When has it not been? Bold and italic markup are allowed in titles (|title=, |chapter=, etc); are not allowed in any other parameters that contribute to the metadata. Bold and italic markup in |publisher= and the |work= aliases cause cs1|2 templates to emit the Italic or bold markup not allowed in: |<param>n= error message.

— Trappist the monk ( talk) 14:44, 23 December 2020 (UTC)

Thanks. I just wanted to be sure before I removed it. – Jonesey95 ( talk) 15:47, 23 December 2020 (UTC)

What about bold and italic in, e.g., |section=? Shmuel (Seymour J.) Metz Username:Chatul ( talk) 22:36, 24 December 2020 (UTC)

|section= is a synonym for |chapter=. -- Izno ( talk) 22:56, 24 December 2020 (UTC)

Any ideas on what is causing these errors: Special:PermanentLink/996278824#Notes? I'm aware of the issue of using {{ sfn}} within <ref> but this doesn't appear to be that and, oddly enough, short footnotes are working in the first several list-defined notes but not the rest. Any ideas what's going wrong here, or is this a bug? czar 19:21, 25 December 2020 (UTC)

This is not a cs1|2 problem nor is it a {{ sfn}} problem. If I recall correctly, it is a MediaWiki parser problem because the parser gets confused (not surprisingly) when <ref>...</ref> tags are nested in <ref>...</ref> tags. I don't recall if the problem is related to named or unnamed <ref>...</ref> tags. It appears that the issue has been resolved in that article.

— Trappist the monk ( talk) 00:18, 26 December 2020 (UTC)

Looks like the fix was just reverting the list-defined notes back into the text. I didn't think it was a nested ref tag issue since some notes with multiple short footnotes were working fine in the original diff. Oh well. czar 00:53, 26 December 2020 (UTC)

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)

Okay, but we're still right back to this being an error, of assertion that "Youill X. Zounds" is a surname or an institution.  —  SMcCandlish ☏ ¢ 😼  22:57, 31 December 2020 (UTC)

Template:Cite conference documents |publication-date= and |publication-place= for {{ cite news}}, but not for {{ cite conference}}. What is the proper way to cite a conference paper when the time and place of the conference differ from the time and place of publication? Shmuel (Seymour J.) Metz Username:Chatul ( talk) 14:11, 27 December 2020 (UTC)

I would add that information in |conference=. It is not unusual for the full conference title to incude the location and date. On the other hand, it is not a bad idea to activate the relevant parameters in this template as well. 208.251.187.170 ( talk) 14:34, 27 December 2020 (UTC)

Typically the location of the conference is in the title of the proceedings, e.g. |title=Proceedings of the 43rd COSPAR Scientific Assembly, Held in Sydney, Australia on 28 January –- 4 February 2021. If the location doesn't appear in the title, then there's no need to include it. Headbomb { t · c · p · b} 15:13, 27 December 2020 (UTC)

If this information isn't in the title already, the official way to document it is to use |publication-place= to specify the place of publication and |location= to document the written-at-place. These parameters are not aliases and can both be given at the same time when relevant. {{ cite conference}} supports this as well.

-- Matthiaspaul ( talk) 14:06, 30 December 2020 (UTC)

That is incorrect. Written-at location is guesswork here and is irrelevant. Something may be presented in Liège, but written in New York, and published in Amsterdam. Only Amsterdam is relevant, bibliographically speaking. Headbomb { t · c · p · b} 02:46, 1 January 2021 (UTC)

Isn't the location of the conference more important than the location of the publisher? Shmuel (Seymour J.) Metz Username:Chatul ( talk) 04:40, 1 January 2021 (UTC)

Not bibliographically speaking. The publisher's location is stipulated to indicate where you need to deal with to contact the publisher. It's a mostly historical thing, when you needed to send letters by mail, or place costly phone calls, but it still used by modern style guides because it was used by old style guides. Headbomb { t · c · p · b} 04:48, 1 January 2021 (UTC)

Conference locations are often included in the titles of their proceedings, though. And some metadata aggregators (e.g. DBLP and MathSciNet) will add the conference location as part of the proceedings title even when it wasn't put there by the publisher. (On the other hand, I could do without MathSciNet's habit of putting the location of the publisher into the name of the publisher, rather than keeping it separate the way our templates prefer.) — David Eppstein ( talk) 06:49, 1 January 2021 (UTC)

Hmmm... Isn't |title= reserved for the specific conference presentation/paper? (an in-source location). The OP wants to specify the location(s) of the source, i.e. of the entire conference. Such information is normally specified in the source name/description i.e. in |conference=, something indicated at the relevant template. The cited paper is part of the conference, which takes place somewhere. 64.61.73.84 ( talk) 04:35, 2 January 2021 (UTC)

For {{ cite conference}}, I might often use |title= for the title of the proceedings (a book, usually) and |contribution= for the title of the individual paper. But it also works to use |title= for the paper and |book-title= for the title of the whole proceedings. Both are formatted the same. But that's a separate issue from where to put the location of the conference, which I think can reasonably go in the title of the proceedings (not the title of the paper). — David Eppstein ( talk) 05:36, 2 January 2021 (UTC)

Should we add a "libre" access level to the doi-access and url access levels? Adding such a label would help editors in need of images or other content: a majority of "libre" OA content is CC BY and Wikipedia-compatible, as opposed to an Elsevier User License which is unusable. -- Artoria 2e5 🌉 21:19, 19 December 2020 (UTC)

??? Such facility already exists, and in |url= is the presumed default. There is similar option for |doi-access=. Am I misundertanding your intent? 65.204.10.231 ( talk) 21:36, 19 December 2020 (UTC)

• No, again. We should probably have a note about this, since it comes up periodically. We support only indicators that describe the "to-read" access, not reuse permission access. Citations exist to support verification, so the ability to read the cited material is the only relevant criterion here. – Jonesey95 ( talk) 22:30, 19 December 2020 (UTC)
  • Follow-up: I have updated the text in the relevant section of this page. Does this help Artoria2e5 understand what the access levels are for? If so, please withdraw this RFC. Thanks. – Jonesey95 ( talk) 22:38, 19 December 2020 (UTC)
• No access icons reflect if something is free to read. Not the re-usability, which comes under dozens of various licenses, each with different terms of re-use. Licensing information is not something that is needed to verify information, which is the purpose of citations. Headbomb { t · c · p · b} 22:32, 19 December 2020 (UTC)
• No thank you. That is not what citations are for. See also Help talk:Citation Style 1/Archive 72#A parameter for open content licenses (CC BY) and automatic filling/parsing via reFill and Autofill and/or a bot, Help talk:Citation Style 1/Archive 63#Add license parameter, Help talk:Citation Style 1/Archive 61#Another plea for a licence parameter, Help talk:Citation Style 1/Archive 33#License information, and Help talk:Citation Style 1/Archive 31#Adding a license parameter right at the top when searching for previous discussion. -- Izno ( talk) 20:14, 20 December 2020 (UTC)
• No. The purpose of citations on Wikipedia is to help readers verify information, not to give editors information in case they want to copy around the contents of the source. Glades12 ( talk) 15:48, 23 December 2020 (UTC)
• Yes. The same few users repeat the ever-same point about "that is not what citations are for", basing their rationale for why it shouldn't be added upon tradition. The many other posts about this (coming up "periodically") shows that this is a feature many are looking for while those few users watching this page constantly block it.

There also were some more people supporting this in those threads including in the one which I recently created. This should probably be discussed at a place or way that allows more editors to be involved and one could consider these users as counting for Yes here too or at least ask them to comment if they're currently active around here.

They ignore the following argument against this:

even if citations did not display such information here or elsewhere ever before and the purpose of citations is agreed by consensus of the wider Wikimedia community to be finding the source / verification of the added material without any additional information (with the addition of such a parameter not contributing towards said purpose) it could still be added because Wikipedia is not WP:NOTPAPER and there is no formal policy that would prohibit it.

For why and how to add it: it conveys additional useful info about the reference which could be used for things like identifying sources that have content (e.g. images) eligible for Commons and could be added to the article or embedded/attached otherwise. For further info on why and how see also my recent post about it. In short: it could be set by a bot and/or automatic parsing by the citations/reFill tool similar to the existing |doi-access=free parameter for everything that's public domain or CC BY and look like this:

Kawaguchi, Yuko; et al. (26 August 2020). "DNA Damage and Survival Time Course of Deinococcal Cell Pellets During 3 Years of Exposure to Outer Space". Frontiers in Microbiology. 11. doi: 10.3389/fmicb.2020.02050. S2CID  221300151.{{ cite journal}}: CS1 maint: unflagged free DOI ( link)

-- Prototyperspective ( talk) 22:50, 2 January 2021 (UTC)

By the above logic, we could and should also add the number of pages in a cited book, or the color of its cover, or who its proofreader was, but we do not do this, because it is not what citations are for. There is a movement at Wikidata to create a database of citations (see the beta template {{ Cite Q}} for details); the OP may be able to persuade the folks at Wikidata to add this sort of indicator to reusable citations there. – Jonesey95 ( talk) 01:19, 3 January 2021 (UTC)

• No. Again, that is not what citations are for. This is useless cruft that makes citations noisier without making them more useful to Wikipedia readers. If people are looking for freely licensable content to re-use, the citations on Wikipedia articles are not really where they should be looking for that, either, so even those people are not sufficiently helped by this to make up for the extra effort of maintaining this information and the extra effort on readers of having to keep skipping past its colorful distractions. — David Eppstein ( talk) 23:12, 2 January 2021 (UTC)

Jonesey95, David Eppstein These are good points, however it's:

• not useless cruft - I addressed this in specific outlining some of the many uses
• adding/changing this parameter would not require people to come here to find freely licensable content, it would just add this feature for people already browsing Wikipedia (editors and readers) even though attracting more users would be a good thing
• it wouldn't be a "colorful distraction" but a small icon with a tooltip people don't get "distracted" by.

Thanks for linking the Wikidata database of citation project! I thought about Wikidata but didn't know there already was related ongoing work. I don't think this proposal is the optimal solution because the way references are handled in general isn't optimal so far imo but it would be a more longer-term project to improve that. This proposal is about near-term changes to how things are currently implemented which could be used by references on Wikidata. -- Prototyperspective ( talk) 11:46, 3 January 2021 (UTC)

What is the process for requesting more identifiers to be included in the standard list like ProQuest, INIST or NAID? Is there a threshold of number of transclusions or some other measure of popularity?  —  Chris Capoccia 💬 20:44, 1 January 2021 (UTC)

I think we typically ask editors to include those IDs in |id= in order to see how much demand there really is for them. Use a template if appropriate; see Template:Cite book#Identifiers. – Jonesey95 ( talk) 21:11, 1 January 2021 (UTC)

thanks… currently more than 6000 transclusions of the ProQuest template… not sure what the acceptance threshold is.  —  Chris Capoccia 💬 18:02, 2 January 2021 (UTC)

{{cite journal|title=Title|journal=Journal|issue=10|pp=100-110|quote-page=100|quote=A quote from this page.}}

renders as

"Title". Journal (10): 100–110. p. 100: A quote from this page.

Shouldn't the |quote-page= prefix be invisible for consistency? |no-pp=y works but... 98.0.246.242 ( talk) 05:55, 2 January 2021 (UTC)

I don't think suppressing the "p."/"pp." by default would be an actual improvement. While in your example of a quote immediately following the article page span it would remain reasonably clear what is meant, this would not be the case if the citation would provide other information between the page range and the quotation.

Regarding consistency, there have been requests to display "pp. 100–110" instead of "100–110" also for {{ cite journal}}, as it is done by the other templates. The suppression of the "pp." is only done because the notation

volume[s] (issue[s]): page[s]

is an established convention to cite scientific journals. Abandoning this would achieve consistency the other way around. (I would generally support this, but only if there would be a parameter like |periodical-mode=symbolic/scientific/abbreviated/full to override the default format when desired - something that could later be made part of a system of article-wide format parameters similar to what we have for global date formats at present - in fact, I have prototypical code ready to support such global settings through {{ reflist}} and/or {{ use dmy dates}}/{{ use mdy dates}} would this be desired.)

-- Matthiaspaul ( talk) 15:42, 3 January 2021 (UTC)