# Help talk:Citation Style 1

(Redirected from Template talk:Cite journal/doc)
Citation templates (conception)
Citation templates (reality)

## Working on Category:CS1 errors: invisible characters

I know that most of the editors who hang out here are gnomes that prefer to work quietly, but sometimes it's fun to take on a project as a team. This is an invitation to do just that. I'm planning to work on Category:CS1 errors: invisible characters, which has about 3,105 pages in it as of this writing.

I have found that most of the errors are straightforward line feeds and tab characters that should be replaced with spaces. Other characters should be replaced by a dash, apostrophe (single quote mark), space, ellipsis, quote mark, an accented character, or nothing. You can usually figure it out by context, or by checking the original source. I have some regexes that mostly work (each one needs to be checked manually) in the "invisible character" section of User:Jonesey95/AutoEd/unnamed.js, an AutoEd script. You are welcome to copy and refine those regexes, use manual searches, or adopt any other method you want.

I am planning to make a pass through the category to fix the easy errors, then see what's left. Feel free to join me, and post here with questions or comments. – Jonesey95 (talk) 05:56, 3 December 2017 (UTC)

Down to 2,800 at this writing. There is still a lot of low-hanging fruit in this category. – Jonesey95 (talk) 16:40, 24 December 2017 (UTC)
Now at 2773. I basically went after the first page in each alphabetical section (why not?). However, I stumbled across several pages with errors inside non-English text--mostly related to Sri Lanka--which I think will require some work by someone with language skills (example at Cadex 2009). I checked on one editor but he/she has not been here since 2011.-- 20:19, 24 December 2017 (UTC)
Thanks for contributing! I've been skipping those zero-width joiner characters so far, as well as right-to-left text, which does not behave well in my editor. – Jonesey95 (talk) 21:49, 24 December 2017 (UTC)
We recently fixed that issue for several Indic scripts. A bit of Googling seems to show that zwj is also required for Sinhalese so I've added detection for Sinh script to Module:Citation/CS1/Configuration/sandbox (and fixed a bug at the same time):
 {{ cite news | last=Warnakulasuriya | date=2009-10-11 | first=Keerthi | title=යුද රහස් හෙලි කල එන්. ජී. ඕ ක්‍රියාකාරිකයාගේ සුලමුල හෙලිවේ | language=Sinhala | work=Divaina | pages=18 | accessdate=2009-10-16 }} Live Warnakulasuriya, Keerthi (2009-10-11). "යුද රහස් හෙලි කල එන්. ජී. ඕ ක්‍රියාකාරිකයාගේ සුලමුල හෙලිවේ". Divaina (in Sinhala). p. 18. Sandbox Warnakulasuriya, Keerthi (2009-10-11). "යුද රහස් හෙලි කල එන්. ජී. ඕ ක්‍රියාකාරිකයාගේ සුලමුල හෙලිවේ". Divaina (in Sinhala). p. 18.
Trappist the monk (talk) 22:04, 24 December 2017 (UTC)

Is there a validation process before this is implemented?-- 03:52, 29 December 2017 (UTC)

### Horizontal tab

Is there any use, anywhere, in Wikipedia for the horizontal tab, U+0009 (HT)? I've been editing for seven years plus and can't think of one. If there isn't one, I don't see why we can't ask the folks who work on bots to do a search and replace and substitute a <space> for every <HT>. In some cases, we might get strings of spaces but that would still be an improvement. I'm a big fan of letting computers do my work for me. Or am I over simplifying this?-- 23:58, 30 December 2017 (UTC)

Tab can be seen on programming pages in and out of article space. You might also see it in <pre> and <poem> blocks, or even outside to provide the latter (since a space at the beginning of a line starts a block). --Izno (talk) 00:10, 31 December 2017 (UTC)
Oh, well.<sigh>-- 00:32, 31 December 2017 (UTC)

### Update one month in

A little over one month in, we are down to 2,149. I am working backwards through the alphabet and have hit pages starting with S-Z so far. Steady progress. – Jonesey95 (talk) 05:25, 10 January 2018 (UTC)

We need to get implementation on ignoring the zero-length characters in Indic(?). I think every page in the U's "suffers" from that condition.-- 15:17, 12 January 2018 (UTC)

It has been implemented in the sandbox. It will be useful to go through the rest of the category to see if there are any other bugs that need to be fixed. – Jonesey95 (talk) 15:41, 12 January 2018 (UTC)
1,294. 0–9, A–I. Meet at N? :)
I'm seeing a lot of tabs and newlines, mainly in |title=, but also in other params. These should be possible to automate: in all params (except |quote=, see below; and with a caveat, ditto), all runs of whitespace can be safely collapsed to a single space character. Another big class is apostrophes, long dashes, and smart quotation marks copied from unlabelled Windows code page 1252 (and a few other charsets) that can probably be automated with an acceptable error rate. Then there's a bunch of completely garbled text, titles mostly, that suffers from the same problem but which can't really be fixed automatically or semi-automatically. There's also a few similarly garbled author names, but not a lot of them. And, of course, a lot of ZWJ warnings in various asian scripts (possibly only in Sinhalese, but there may have been some Malayalam and Hindic etc. too) that, I believe, are just false positives.
And then there's a ton of newlines in |quote= that can't really be fixed, neither automated nor manually. Truncating the quote or simply removing the newlines is likely to annoy the natives (local editors), and I don't know of a workaround. This needs to be resolved somewhere, somehow: drop support for |quote= entirely; set a hard limit on what it can contain; or permit newlines inside this specific parameter.
And then there is {{cite tweet}}.
Which wraps {{cite web}}, but for its |title= parameter documents: "Entire content of the tweet, including hashtags (#), at signs (@), and links". This, to me, is bogus in so many ways; but in any case, this module's check for newlines is in direct conflict with that template's documented behaviour. In other words, this can't be cleaned up by gnomes. --Xover (talk) 17:54, 14 January 2018 (UTC)
Thanks for the comments. I wonder if silently converting all white space to spaces without emitting error messages would bother editors. We currently collapse white space and emit an error message; it might be more fruitful to do so without an error message. Here's an example of how we do it now:
 {{ cite web | title=Text followed by new line Second line Third lines | url=http://www.example.com | date=January 1, 2000 | author=Author }} Live Author (January 1, 2000). "Text followed by new line Second line Third lines". line feed character in |title= at position 26 (help) Sandbox Author (January 1, 2000). "Text followed by new line Second line Third lines". line feed character in |title= at position 26 (help)
Perhaps someone here could remind us why we emit error messages for harmless white space. I forget, and I am too busy doing other stuff (lazy?) to dig through this page's archives right now. Maybe later. – Jonesey95 (talk) 18:02, 14 January 2018 (UTC)
For |quote=, newlines can be replaced with <br /> tags:
{{cite book |title=Title |quote=Text followed by new line<br />Second line<br />Third line}}
Title. Text followed by new line
Second line
Third line
or, depending on context, <p>...</p> tags:
{{cite book |title=Title |quote=Paragraph followed by<p>Second paragraph</p><p>Third paragraph</p>}}
Title. Paragraph followed by

Second paragraph

Third paragraph

We find tabs, line feeds, carriage return characters because they generally don't belong in the metadata along with all of the other ascii characters with byte value less than 32 decimal (0x20 hex) – the space character.
Trappist the monk (talk) 18:59, 14 January 2018 (UTC)
Thanks. I don't know why I was convinced <br /> and <p>...</p> wouldn't work here. Possibly I'd been doing battle with errors related to strip markers and such. In any case, most |quote= parameters now look like they can be fixed this way (some cases require too much tag soup so I'm leaving them alone). In view of that, what I'm leaving behind (not touching) are mainly ZWJ cases and {{cite tweet}} (which would turn into tag soup if handled this way).
Incidentally, in going back over these articles I've found (in Fuk'anggan) that Manchu alphabet and Mongolian script (the former seems to be an extension/adaption of the latter) also require ZWJ. Otherwise the ZWJ cases so far are all Sinhalese. --Xover (talk) 11:51, 16 January 2018 (UTC)
(added) Oh, and I nearly forgot: based on Characters of Casualty, certain cases of Emoji also require ZWJs, which will be an increasing issue as we copy whole tweets into citations. See this link on emojipedia for details. Not sure what, if anything, can be done about this (detect and ignore them in Emoji sequences?). --Xover (talk) 11:58, 16 January 2018 (UTC)
Additional case of legitimate use / false positive: Burmese script does not use spaces for word boundaries, so a Zero width space character is often used at phrase boundaries to facilitate line breaking. See UNICODE technical note 11 for details. Example in Ayeyarwady Region Government. --Xover (talk) 09:32, 19 January 2018 (UTC)

I came across a "line feed in quote" in El Rancho Hotel and Casino last night that I could not find. I decided the error was from an included {{collapsible list}}, which I remmed out. It worked but left a very long reference which I'm not sure is necessary.-- 19:25, 14 January 2018 (UTC)

I haven't looked at the source, but a quote that long is likely to be a copyright violation. I have found a couple of those while cleaning out this category, and my fix is to remove all but a sentence or two, preserving the relevant text that supports the statement in the article's prose. – Jonesey95 (talk) 19:46, 14 January 2018 (UTC)
I went back and "aggressively trimmed" the quote.-- 16:30, 16 January 2018 (UTC)

### Pretty much done

At this writing, we have reduced this category from 3,000+ pages to 193 pages. One more pass through the letters P, R, and S could probably fix a couple dozen more pages. I haven't done an exact count, but I think at least half of the remaining pages are false positives – Sinhalese and other scripts that use allowable zero width joiner characters. The CS1 sandbox has been partially updated to account for these; once it is moved to production, we can null-edit the whole category to find (and, ideally, fix) the remaining errors. Great work, everyone! – Jonesey95 (talk) 05:19, 23 January 2018 (UTC)

144, after a manual pass through all the remaining pages. The vast majority are zero width joiners in Singhala script, with a single Manchu and a couple of Emoji cases in the mix. There's also a bunch of tweets quoted entire (some using cite web, some using cite tweet). And a few archives that I don't feel comfortable editing for various reasons (some shady "Trappist the monk" character demonstrating nested references on the technical village pump, for instance). And then there are these: NEC V60 and Bill, the Galactic Hero on the Planet of Bottled Brains...
In any case, when the script-related false positives are eliminated, the category will be essentially empty except for tweets and archives.
But working on this I've noticed new cases being added at an alarming rate (on the order of 5-10 per day). To keep this down we're going to need some way to prevent these from getting added in the first place. Perhaps it'd be worthwhile to explore some validation or other measure in Citoid (which is the backend for both reFill and Visual Editor)? The garbage data is mostly coming from the source website through indiscriminate cut&paste / import, and Citoid is in a position to prevent a significant portion of these from getting in. The remainder would probably need to be handled (if needed) by some more assertive warning from Module:Citation/CS1. --Xover (talk) 22:02, 24 January 2018 (UTC)
User:ReferenceBot used to post on editors' talk pages when they added a page to one of the "empty" CS1 categories. Its notices resulted in fixes from editors who could understand the error messages and how to fix them, which was maybe around half. That's considerably better than nothing. The bot has been inactive for nearly a year. Maybe a bot request would result in another editor taking on that bot task. – Jonesey95 (talk) 22:23, 24 January 2018 (UTC)
Maybe the category count should be something like PAGESINCATEGORY <= 10. Sometimes, a lot can happen at once.-- 23:07, 24 January 2018 (UTC)
ReferenceBot did not pay attention to any category's population count. It had a list of categories (provided by me, as it happens) that were deemed "empty" at some point, and notified editors when they added an article to one of those categories. The reason you need to empty the category first is to prevent a revert or a false positive or other constructive action from adding to the category. As we have seen with the invisible character category, we found some false positives while emptying it. – Jonesey95 (talk) 03:54, 25 January 2018 (UTC)

## Ellipses being truncated

{{cite web}} seems to be truncating ellipses in citation titles. Examples: 1 2. Opencooper (talk) 15:44, 18 December 2017 (UTC)

It seems that a final full stop/period is always trimmed from the end of the title when rendering the title, which is also a problem when the title ends with an abbreviation such as "U.S.A.". So it would be interesting to understand whether such scenarios were considered when adding the trim logic. Rjwilmsi 16:36, 18 December 2017 (UTC)
Fixed in the sandbox I think:
• {{cite book/new |title=no dots |publisher=Publisher}}no dots. Publisher.
• {{cite book/new |title=one dot. |publisher=Publisher}}one dot. Publisher.
• {{cite book/new |title=two dots.. |publisher=Publisher}}two dots. Publisher.
• {{cite book/new |title=three dots... |publisher=Publisher}}three dots... Publisher.
• {{cite book/new |title=four dots.... |publisher=Publisher}}four dots... Publisher.
and, for the Doubting Thomas's, this:
 {{ cite book | publisher=Publisher | title=Title ends with an abbreviation such as "U.S.A.". }} Live Title ends with an abbreviation such as "U.S.A.". Publisher. Sandbox Title ends with an abbreviation such as "U.S.A.". Publisher.
and take out the quote marks:
 {{ cite book | publisher=Publisher | title=Title ends with an abbreviation such as U.S.A. }} Live Title ends with an abbreviation such as U.S.A. Publisher. Sandbox Title ends with an abbreviation such as U.S.A. Publisher.

The module does the right thing I think; if it doesn't, no one has ever spoken up about it.

Trappist the monk (talk) 23:46, 18 December 2017 (UTC)
Doesn't seem to be working for cite journal, still getting final full stop truncation:
{{cite journal| author=Sheppard, P.A. |year= 1959| title= Title ending U.S.A. | journal= Quarterly Journal of the Royal Meteorological Society| volume=85 }}Sheppard, P.A. (1959). "Title ending U.S.A.". Quarterly Journal of the Royal Meteorological Society. 85.
{{cite journal/new| author=Sheppard, P.A. |year= 1959| title= Title ending U.S.A. | journal= Quarterly Journal of the Royal Meteorological Society| volume=85 }}Sheppard, P.A. (1959). "Title ending U.S.A.". Quarterly Journal of the Royal Meteorological Society. 85.
Which doesn't seem correct to me. Thanks Rjwilmsi 09:22, 11 January 2018 (UTC)
Difficult to know what to do. This insource search timed out after finding nearly 24,000 articles where the last character in |title= is a dot (those may not all be cs1|2 parameters). For some reason, editors like to put dots at the end of titles. More so, I think, than any other parameter value. Refining the search to look for \.[a-z]\. (case insensitive) timed out at about 2k articles. In many (most?) of these the trailing dot appears to be part of an initialism. And once again to look for \.[0-9]\. found about 50 where the trailing dot appears (to me) to be terminal punctuation rather than a key component of the last character group.
I suppose that we can look for \.[a-z]\. as a special case for retaining the trailing dot. I have tweaked the sandbox to do that. Is that a correct solution? Renering is slightly different with and without |url=:
{{cite journal/new| author=Sheppard, P.A. |year= 1959| title= Title ending U.S.A. | journal= Quarterly Journal of the Royal Meteorological Society| volume=85 }}
Sheppard, P.A. (1959). "Title ending U.S.A.". Quarterly Journal of the Royal Meteorological Society. 85.
{{cite journal/new| author=Sheppard, P.A. |url=http://www.example.com |year= 1959| title= Title ending U.S.A. | journal= Quarterly Journal of the Royal Meteorological Society| volume=85 }}
Sheppard, P.A. (1959). "Title ending U.S.A." Quarterly Journal of the Royal Meteorological Society. 85.
Trappist the monk (talk) 12:32, 11 January 2018 (UTC)
I have an sqlite database generated from data dump, with all en wp mainspace cite journal and citation with journal param, here are my numbers for title ending in dot, and what the penultimate character of title is, and how many of those have 3rd last char is dot too (e.g. ends in ".A." of "U.S.A.") grouped by character type (data from Nov 2016 but somewhat updated):
Class Count 3rd last is dot?
Lower alpha 80804 44
Num 5903 182
Other 6328 1332
Upper alpha 4386 1247
Does that help? I'm not sure what the right answer is, I think something needs to change to handle U.S.A. format better, but a simple rule to handle all scenarios is unlikely to be possible. Rjwilmsi 13:16, 11 January 2018 (UTC)
We might also have to look for "\. [a-z]\.", which would be proper spacing per MOS:INITIALS. – Jonesey95 (talk) 14:15, 11 January 2018 (UTC)
\. +[a-z]\. Sandbox tweaked.
{{cite journal/new| author=Sheppard, P.A. |year= 1959| title= Title ending U. S. A. | journal= Quarterly Journal of the Royal Meteorological Society| volume=85 }}
Sheppard, P.A. (1959). "Title ending U. S. A.". Quarterly Journal of the Royal Meteorological Society. 85.
Trappist the monk (talk) 14:38, 11 January 2018 (UTC)

## ASIN

I am seeing evidence that some people are filling in the ASIN reference when there is an ISBN or other identifier. Clearly we should not be using Amazon's proprietary ID unless there is no alternative. What's the best way to document this and perhaps call it out int he interface (ProveIt or whatever) so that people don't use ASIN unless it's required? Guy (Help!) 10:48, 21 December 2017 (UTC)

The documentation already says, Because this link favours one specific distributor, only include it if standard identifiers are not available. It might be reasonable for a maintenance or error message to display on the page when both ASIN and some other set of identifiers (probably ISBN at least) are present. --Izno (talk) 13:44, 21 December 2017 (UTC)
Or the ASIN could automatically be suppressed if ISBN are provided. Headbomb {t · c · p · b} 14:04, 21 December 2017 (UTC)
Because this link favours one specific distributor .. this could be more direct: Because this link favours one company Amazon.com. -- GreenC 14:33, 21 December 2017 (UTC)
No. What you propose is open to misinterpretation, and the documentation could be seen as biased against a specific company. Any company is not targeted; any company that happens to be the distributor in question is. The appearance of neutrality is as important as the thing itself, because people do tend to misread depending on their own biases. No specific company or person (legal or natural) should be mentioned anywhere, even if they are clearly the only example. 72.43.99.138 (talk) 14:53, 21 December 2017 (UTC)
The above needs to be qualified a bit. I suppose it would be ok if any one entity is mentioned in passing, as an example e.g. "such as Amazon". Imo, this would be less likely to be misinterpreted as targeting. 72.43.99.138 (talk) 15:12, 21 December 2017 (UTC)
This is an Amazon-specific link. There is no other entity it could possibly apply to. Headbomb {t · c · p · b} 15:59, 21 December 2017 (UTC)
Correct. Saying "one specific distributor" is an unnecessary obfuscation. Even the IP editor is confused. -- GreenC 19:43, 21 December 2017 (UTC)
I was referring to the documentation, not the identifier. The documentation should avoid the appearance of targeting, even when such interpretation seems far-fetched. There is no confusion on my part at all. The documentation should retain the generic condition ("a specific distributor") and optionally add specific examples ("such as Amazon" − emphasis on plural examples). Both these statements are true, and more neutral than the proposed documentation change. 72.43.99.138 (talk) 15:16, 23 December 2017 (UTC)
"a specific distributor" is the only thing we need to say. "Such as Amazon" is redundant nonsense since this is documentation for the ASIN identifier, and would imply that there are non-Amazon ASINs. Headbomb {t · c · p · b} 20:09, 24 December 2017 (UTC)
────────────────────────────────────────────────────────────────────────────────────────────────────Going back to Izno above how about: if ISBN is present then supress presentation of seemingly redundant identifiers such as ASIN and also throw an error/warning notification that redundant identifiers have been supressed? Wtmitchell (talk) (earlier Boracay Bill) 13:38, 11 January 2018 (UTC)

## 8 digit ZBL

I was fixing some citations when I stumbled upon a zbl with 8 digits in Lou van den Dries. It is indeed the valid zbl for the citation in question, but it causes an error because usually zbl appears in nnnn.nnnnn format. As User:Headbomb had pointed out, this is a temporary zbl for new abstracts/articles. He suggested making a maintenance category for these zbls. While I'm not the most experienced editor, since I stumbled upon this, I thought I should bring it to someone's attention. Hecseur (talk) 12:39, 23 December 2017 (UTC)

## How to make source-specific shim?

I just embarked on the creation of a source-specific citation template, on the naïve assumption that this would be easy. After all, we're just talking about providing defaults for a few params and passing the rest along to Module:Citation/CS1, right? Right?

Obviously I ran into the wall of my own ignorance pretty quick. So… Any docs on how to create source-specific citation templates based on Module:Citation/CS1? My use case (and, I imagine, most such) just needs to provide defaults for stuff like |publisher=, |editor-last=, |editor-first=. Maybe add some simple logic for creating an URL based on |title= (e.g. prefix |title= with https://en.wikipedia.org/wiki/ and stash it in |url=).

My first cut was using template code that called one of the existing CS1 modules ({{cite_book}} say), but that means I have to write the boilerplate for every single param (last1, last2, last3, etc.) and in MW template syntax. Then I tried just #invoke'ing Module:Citation/CS1, expecting to be able to just touch the params I want to hard code, but here I don't seem to have figured out how to pass stuff from the template to the Lua module (even though using the template seems to pass them just fine).

In other words, I'm completely lost! Help? Surely there's some doc explaining this somewhere? Or an explanation in a talk page archive somewhere (I didn't find anything in the archives here, but that may be my poor choice of terms)? For anyone curious, the project that prompted this plea for help is Template:cite_Grove, an attempt to replace Template:GroveOnline (and its companions) with something that supports all the nice stuff in Module:Citation/CS1 (|ref=harv for one thing!). If you look at its sandbox you can probably tell I'm reduced to voodoo-debugging and trying random variations to get anywhere. Any pointers would be appreciated! --Xover (talk) 14:56, 26 December 2017 (UTC)

Except for the single parameter, |CitationClass=, frame parameters (those parameters implemented in the {{#invoke:}}) are reserved for cs1 debugging.
I can see that {{GroveOnline}} has it's problems, particularly:
|encyclopedia=''In L. Root, Deane.'' [[The New Grove Dictionary of Music and Musicians|Grove Music Online. Oxford Music Online]]
editor's name and static text do not belong there so that line should be replaced with:
|editor-last=Root
|editor-first=Deane L.
|encyclopedia=[[The New Grove Dictionary of Music and Musicians|Grove Music Online. Oxford Music Online]]
The {{subscription required}} template seems to me to be redundant to |url-access=. Perhaps when |url= is not set, only then should {{subscription required}} be executed:
{{#if:{{{url|}}}||{{subscription required}}}}
To support |harv=, add:
|ref={{{ref|}}}
Otherwise, what else is needed?
Trappist the monk (talk) 16:20, 26 December 2017 (UTC)
Well, |last= etc., since each entry has a separate author (or multiple authors). |doi=, since each entry has a DOI (as does the overall work, I believe). |year=, since there are various publication dates for the entries. There's also a whole collection (7-ish) of Grove templates with duplicated code, variations in quirks and supported params, and so forth. Some call {{cite encyclopedia}} and some {{cite book}}. Some put the entry in |title=, and some in |chapter=.
But do I understand correctly that Module:Citation/CS1's approach is to deliberately force "wrappers" (i.e. source-specific citation templates) to go through existing "core" templates (like {{cite_book}}) rather than invoke the module directly? Are there any docs outlining this anywhere? Any alternate approaches that would let me handle stuff in Lua rather than that horrid mess of line noise that is MW template syntax? --Xover (talk) 17:38, 26 December 2017 (UTC)
|last=, |first=, |doi=, and |year= are all easy fixes that could be made to {{GroveOnline}}.
Before cs1|2 supported |vauthors=, there was (and still is) {{vcite2 journal}} which uses Module:ParseVauthors. {{vcite2 journal}} is a wrapper template that uses its module to convert Vancouver style names to |last=-|first= parameters. The module passes the new author name parameters and everything else that it got from the template-call to Module:Citation/CS1 by calling {{cite journal}} with
frame:expandTemplate{title = 'cite journal', args = citeArgs}

Another example of this trick is {{cite Q}} which uses Module:citeq.
You could do something similar by setting the appropriate default values into a table from the frame and then filling it with whatever is included in the parent frame; parent frame parameters, if set, would, of course, overwrite same-named defaults.
Trappist the monk (talk) 18:43, 26 December 2017 (UTC)
Perhaps this:
{{Cite Grove/sandbox}}Root, Deane L. (ed.). Grove Music Online. Oxford University Press. (Subscription required (help)).
{{Cite Grove/sandbox|last=Black |first=A |last2=Brown |first2=B}}Black, A; Brown, B. Root, Deane L., ed. Grove Music Online. Oxford University Press. (Subscription required (help)).
{{Cite Grove/sandbox|last=Black |first=A |last2=Brown |first2=B |translator=Green, C}}Black, A; Brown, B. Root, Deane L., ed. Grove Music Online. Translated by Green, C. Oxford University Press. (Subscription required (help)).
uses Module:Sandbox/trappist the monk/cs1 wrapper
If this is what you're looking for, we should move it out of my sandbox and put it somewhere useful.
Trappist the monk (talk) 22:00, 26 December 2017 (UTC)
Oooh, yes. Provided I'm following this correctly (always an open question ;D), this is exactly what I was looking for! If this is something you're willing to support it should definitely move out of the sandbox; and maybe even amass some "Here's how you make a source-specific citation template in the CS1 system" docs? I don't think most such templates exist as half-baked cut-n-paste code for any reason other than the lack of a better alternative. --Xover (talk) 08:55, 27 December 2017 (UTC)
One point I would make strongly is that, as for all source-specific templates, it's important that they include |mode= and any other parameters needed to enable them to be adapted to the existing style in an article, as per WP:CITEVAR. There have been issues in the past (and indeed ongoing) where source-specific templates only generated CS1 or generated only one format for access and archive dates.
More generally, it's surely a bad idea to call the module directly, rather than via a carefully documented template (such as {{Citation}} or the most appropriate of the "cite" templates). The more entry points there are into a Lua module, the harder it is to maintain and modify (as I know from experience with the automated taxobox system). Peter coxhead (talk) 09:35, 27 December 2017 (UTC)
The templates that use Module:Sandbox/trappist the monk/cs1 wrapper (or whatever its final name becomes) do not have to include |mode=. In {{cite Grove/sandbox}} |mode= does not exist, yet:
{{Cite Grove/sandbox|last=Black |first=A |last2=Brown |first2=B |translator=Green, C |mode=cs2}}
Black, A; Brown, B, Root, Deane L., ed., Grove Music Online, translated by Green, C, Oxford University Press, (Subscription required (help))
This works because the wrapper module passes everything that it gets from the wrapper template to the wrapped template (encyclopedia in this example) which hands them off to Module:Citation/CS1 which knows about |mode= and all other cs1|2 parameters.
Trappist the monk (talk) 10:04, 27 December 2017 (UTC)

──────────────────────────────────────────────────────────────────────────────────────────────────── The new {{cite Grove}} template that uses Module:Sandbox/trappist the monk/cs1 wrapper has been in actual use (in an FA in mainspace) for a week now with no obvious ill effects. Perhaps the cs1 wrapper could migrate into Module:Citation/CS1/Wrapper (or similar) and be marked supported (but possibly also "experimental" until it gets wider use and testing)? I'm uncomfortable taking it further so long as it lives inside a user sandbox. --Xover (talk) 07:18, 8 January 2018 (UTC)

That looks nice. Even |mode=cs2 works, a pleasant surprise. I can imagine rewriting a lot of source-specific citation templates this way; for instance, {{Introduction to Algorithms}} would become both simpler and more flexible by not having to copy the arguments it doesn't actually use itself and by allowing a broader class of arguments (e.g. |page= or |at= in place of |pages=). —David Eppstein (talk) 07:43, 8 January 2018 (UTC)
Ok, moved. I've also added code to ignore empty editor-supplied parameters and added a keyword unset that may be used to 'unset' a default parameter:
{{cite Grove|subscription=unset}}
Root, Deane L. (ed.). Grove Music Online. Oxford University Press.
And added vague documentation to the module.
Trappist the monk (talk) 13:09, 8 January 2018 (UTC)
Ah, perfect. Thank you! --Xover (talk) 15:25, 8 January 2018 (UTC)

## trans-journal

Please add "trans-journal" parameter to Template:cite journal in order to translate foreign journal names into English.--Zoupan 05:56, 28 December 2017 (UTC)

I think script-journal would be useful—perhaps even more useful—since journal titles don't often get translated, but it would be nice to give the actual title and transliteration for titles in non-Latin scripts. Umimmak (talk) 06:33, 28 December 2017 (UTC)
Agreed. Publication names are usually not translated, so Le Monde, a newspaper in Paris, would not be given as The World in any typical citation. Imzadi 1979  16:11, 28 December 2017 (UTC)
There is an old request on the feature requests subpage to provide for {{lang}}-like parameters for all of the parameters in Citation. However, I have previously documented a parenthetical bunching problem, and I suspect this particular suggestion would exacerbate that issue. --Izno (talk) 17:09, 28 December 2017 (UTC)
Indeed, especially since Die Welt also translates as The World. --Redrose64 🌹 (talk) 21:53, 28 December 2017 (UTC)
Are the articles referenced in said journals in English? Localized-language sources are preferred for Wikipedia localized editions. A non-local-language in-source article should only be used when 1) it is unique and 2) there are no available reliable translations for it. 72.43.99.146 (talk) 16:02, 28 December 2017 (UTC)
Yes. Also: I don't see any point in translating the name of a foreign journal. E.g.: Die Welt is the name of that publication for all languages. If someone is competent enough in German to search for material written in German (because it's not available in English?) then they are competent enough to understand what the name means in English. Not that that is necessary: where a publication incorporates some foreign word – or for that matter, any technical, obscure, or even invented word – we do not need a translation or explanation in order to reference that publication. ~ J. Johnson (JJ) (talk) 23:54, 28 December 2017 (UTC)
That's fine for Die Welt, but what about (for instance) 香港經濟日報? Even if we transliterate it to Xiānggǎng Jīngjì Rìbào, our readers can't reasonably be expected to have the slightest idea that this is the Hong Kong Economic Times (an impeccable RS) without a translation to guide them. Even if it's not always used, the facility needs to be there. ‑ Iridescent 00:03, 29 December 2017 (UTC)
However, the Hong Kong Economic Times uses (I assume Mandarin) Chinese, without any obvious English facility. To reiterate my point above, any reference in non-Chinese Wikipedias using that publication as a source would be a bit of a red herring, as far as verifiability is concerned. One could certainly flag it as difficult to verify. 72.43.99.146 (talk) 14:15, 29 December 2017 (UTC)
The English Wikipedia allows the use of non English sources. Emir of Wikipedia (talk) 15:10, 29 December 2017 (UTC)
Of course. But, WP:NOENG. 50.74.121.43 (talk) 21:10, 29 December 2017 (UTC)
With reference to Japanese only, many academic journals have their own official English names, so that could go into the journal field without the need for a trans-journal field. However, a script-journal field might be helpful. Not as important as the original article title, but it always helps to look something up if you know the original. It would also address the problem that Japanese looks terrible in italics (one of the reasons why script-title was introduced for books). – Margin1522 (talk) 16:38, 29 December 2017 (UTC)

## mediawiki and language names/code again

Previous discussion re: Bengali or Bangla. This time it's language code bh.

ISO 639-1 defines code bh as a synonym of ISO 639-2 code bih for 'Bihari languages'; see bih @ sil.org.

MediaWiki has remapped code bh for use as a subdomain name for the Bhojpuri language edition of Wikipedia https://bh.wikipedia.org (see List of Wikipedias).

cs1|2 attempts to fetch a language code from MediaWiki when |language= holds a name. With the remapping, when queried for language 'Bhojpuri', MediaWiki returns code bh. This code is used to categorize the article into one of the subcategories of Category:CS1 foreign language sources (639-1 two-character codes) or into Category:CS1 foreign language sources (ISO 639-2) (three-character codes). ISO 639-2 assigns bho to language name 'Bhojpuri' (bho @ sil.org); this is the code that MediaWiki should be returning.

We know that MediaWiki knows about bho because:

{{#language:bho|en}} → Bhojpuri

but:

{{#language:bh|en}} → Bhojpuri

or

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

This last result, bih, is expected because ISO 639-1 has a synonym bh so bih would be omitted from the list of codes (this is the common practice).

I have tweaked Module:Citation/CS1/sandbox (Bengali included here because special case code for that language has been rewritten):

 {{ cite book | title=Title | language=bh }} Live Title (in Bihari). Sandbox Title (in Bihari). should be Bihari
 {{ cite book | title=Title | language=bih }} Live Title (in bih). Sandbox Title (in bih). ISO 639-2 codes with 639-1 synonyms are not listed; module uses the code for language
 {{ cite book | title=Title | language=bho }} Live Title (in Bhojpuri). Sandbox Title (in Bhojpuri). should be Bhojpuri
 {{ cite book | title=Title | language=bn }} Live Title (in Bengali). Sandbox Title (in Bengali). should be Bengali

Trappist the monk (talk) 12:43, 30 December 2017 (UTC)

## BCE dates in the date parameter

Is there currently a supported method (i.e., one that doesn't generate an error message) for specifying a BCE date in the date parameter of a CS1-based citation template? I've just encountered citations that use BCE dates for the first time ([1][2]) and I'm not really sure how to address the error messages without un-templating these citations. Seppi333 (Insert ) 04:08, 5 January 2018 (UTC)

References

1. ^ Herodotus (2009) [440 BCE]. The Histories: Book II (Euterpe). Translated by George Rawlinson.
2. ^ Plato (2009) [360 BCE]. Timaeus. Translated by George Rawlinson.
See discussion here: https://en.wikipedia.org/wiki/Help_talk:Citation_Style_1/Archive_37#Years_and_Classical_publications_from_Antiquity . Remember |date= is for the date of publication of the actual work cited. Umimmak (talk) 06:56, 5 January 2018 (UTC)
Good point. Both of those links point to a text document which links to another page which don't include publication dates, but instead list "©1994-2009". I'm just going to assume 2009 is the republication date for both and use that in the date parameter instead. Seppi333 (Insert ) 08:22, 5 January 2018 (UTC)

## Raised eyebrow

So what is the problem with this edit? Paradoctor (talk) 16:15, 6 January 2018 (UTC)

Wrong place. WP:ACCESSDATE is a redirect that links to Help:Citation_Style_1#Access_date. Information at that location is more-or-less a word-for-word copy of the information that is found on all of the template documentation pages (which all get it by transcluding Template:Citation Style documentation/url).
The shortcut template goes at the target. Because you put {{shortcut}} inside the main documentation template that is transcluded into all of the cs1|2 template docs, you made it look like the shortcut linked to each of the individual template docs when in fact it did not. If this shortcut template is required, then it should go at the target, Help:Citation_Style_1#Access_date, not inside Template:Citation Style documentation/url. There can be only one target for a shortcut, right?
Trappist the monk (talk) 16:43, 6 January 2018 (UTC)
So what is problem with fixing the redirect instead of reverting? Paradoctor (talk) 17:29, 6 January 2018 (UTC)
Because
2. the edit summary told me what was done but not why it was done
3. I could not think of a use-case for that edit that made sense
Trappist the monk (talk) 20:05, 6 January 2018 (UTC)
"mindreading" / "told me what was done but not why it was done" Guess how I felt when I saw a revert that just ordered me to "discuss"?
"could not think of a use-case" For a shortcut box? You must have seen many more of them than I did. Well, whatever.
Now that that has been cleared, there will be no problem if I revert back and retarget the shortcut? Paradoctor (talk) 23:13, 6 January 2018 (UTC)
I could not, cannot, think of a use case where including {{shortcut}} in Template:Citation Style documentation/url which then transcludes into 25-ish cs1|2 template documentation pages thus creating 25-ish false targets. If there is a good reason to do that, please tell us.
Trappist the monk (talk) 00:01, 7 January 2018 (UTC)
I don't think that's going to be a productive use of my time, so I'll leave this conversation. Paradoctor (talk) 01:01, 7 January 2018 (UTC)
Also, it creates accessibility problems via horrifically mixed-up list markup. --Redrose64 🌹 (talk) 21:04, 6 January 2018 (UTC)
When the community decides to ditch wiki markup in favor of an object oriented document model, I'll be the first to open a cask of Amontillado. Until then, I'll dream of better times and stay the hell away from Lua. Paradoctor (talk) 23:13, 6 January 2018 (UTC)
Who said anything about Lua? You dropped definition lists into the middle of unordered lists. Put simply - this is valid:
*Item
**Item
*Item

so is this:
*Item
*:Item
*Item

but this is not:
*Item
:*Item
*Item

The easiest way is to make sure that your new entry starts with the same symbol(s) as the entry above it, optionally adding one more symbol - whether asterisk, colon or hash - after the existing ones, not before them. --Redrose64 🌹 (talk) 23:32, 6 January 2018 (UTC)
This is the first time I became aware that this is one of the Help:List#Common mistakes. I referred to Lua because I only edited the list because the {{shortcut}} template breaks the bulleting when using the standard **... wiki markup. Now that I know the proper workaround for that, I'll use it, of course. Thanks, and happy editing. Paradoctor (talk) 00:04, 7 January 2018 (UTC)

## Italic lint error

In some citations with italics in the title (if nowhere else), lint errors are being caused. (There is a similar issue reported by @IKhitron: regarding bolding at phab:T140358, and I've left some comments there.) One example is at Geodesic convexity, the Rapcsák reference, which I believe to be legitimate. Currently, the HTML served (so, module + parser + Tidy) is (abbreviated for relevance):

<cite class="citation book">Rapcsák, Tamás (1997). <i>Smooth nonlinear optimization in <b>R</b></i><sup>n</sup>.</cite>


-> Rapcsák, Tamás. Smooth nonlinear optimization in Rn.

Like a previous post of mine at Template talk:Lang, this is clearly wrong, as the italics should surround the entirety of the title.

However, in a world where Tidy is turned off, the same citation returns:

<cite class="citation book">Rapcsák, Tamás (1997). <i>Smooth nonlinear optimization in <b>R</b><sup></sup></i>n<i></i>.</cite>


Which causes the misplacement of the sup tag and a subsequent visual rendering difference (in that the "n" is no longer superpositioned). (Aside: This seems also to cause a number of the errors related to the cite tag and template:Reflist in the misnesting category.)

The correct fix would be for all of the italic tags to be included (by changing Module:Citation/CS1/Configuration to add HTML italics rather than wikitext italics) and for the inner italics to be de-italicized. The HTML of that is the following:

<cite class="citation book">Rapcsák, Tamás (1997). <i>Smooth nonlinear optimization in <b>R</b><sup><i>n</i></sup></i>.</cite>


To de-italicize the inner italics, we would need to make a change to the CSS files of interest (at least on en.wp). However, making this particular fix would not preserve the italicization of the source currently: I have tested what happens when we have italics wrapping italics at this perma-link--in short, nothing! We could probably hack around this issue in this specific case at MediaWiki:Common.css by adding CSS to the tune of i sup i {font-style: normal;}, but this is sadly a not-so-general solution (I'll leave the exercise of futility to the reader). LESS could fix this according to StackOverflow, but we can't use LESS on-wiki.

So, the optimal solution to the problem is the following:

1. Change Module:Citation/CS1/Configuration to italicize using HTML. This removes the lint errors (which is categorically good because of problems like that reference, IK's reference) but does not preserve the sense of the italics.
2. Use LESS to style the <i> tag generally on Wikipedia (where its parent text is unitalicized, italicize; where its parent text is italizied, unitalicized). This would require a MediaWiki change.

I'm looking for thoughts, interim steps, and such agreement as can be found on Wikipedia (ping SSastry (WMF) for good measure) to a) making sure all of the italics render correctly, and b) the template is future-proof to the removal of Tidy. --Izno (talk) 02:54, 19 January 2018 (UTC)

All of your suggested formats are wrong. Math formulas in titles should not be italicized, because mathematics uses different font styles to encode different meanings, so changing the font style changes the meaning. Unfortunately, the {{math}} templates don't do anything to avoid italicizing when they are used in an italic context, and it would be really really ugly to put in explicit un-italic coding in the title parameter. So the only option we're left with is $: {{cite book|last=Rapcsák|first=Tamás|title=Smooth nonlinear optimization in [itex]\mathbf{R}^n$}}
Rapcsák, Tamás. Smooth nonlinear optimization in ${\displaystyle \mathbf {R} ^{n}}$.
David Eppstein (talk) 04:03, 19 January 2018 (UTC)
That's not an unreasonable approach in the context of math, but my problem is clearly more general. :^) --Izno (talk) 04:13, 19 January 2018 (UTC)
PS if you look up a preview of the book itself, you'll find that it's printed on the front cover as "Smooth Nonlinear Optimization in ${\displaystyle R^{n}}$", with an italic (not bold) R. So it's a bad example of the issue for multiple reasons. —David Eppstein (talk) 04:41, 19 January 2018 (UTC)
I think quote parsing in MediaWiki is somewhat hacky because of unintended interactions between quotes in template args and quotes in the template source and this seems to be a common problem (I've seen this on many wikis including itwiki, svwiki, and others). But, I digress. In this case, what I have seen itwiki do is exactly what Izno proposes which is to change the template to use the HTML <i> tag instead of '' and <b> tag instead of '''. I recommended the same solution for svwiki. That said, given that some pages (like the Geodesic convexity example) "hack" their way to intended rendering by deliberately breaking quoting, with this fix by itself, rendering for those refs can change. I feel like using CSS to preserve it is another hack (which, we could add if it became necessary, but not sure what other unintended effects it could have). Ideally, the pages using this hack would be changed. One option is to use math as User:David Eppstein recommends. Another is to use a styled span tag around the text that needs de-italicising. But, that depends on how many pages are actually relying on this quote-hack. SSastry (WMF) (talk) 05:15, 19 January 2018 (UTC)
Thank you for noticing. Something weird. The problem I described in the task was fixed a couple of months ago. I totally forgot about filing the task, closed it now. It was my understanding of situation - the cause was <span /> in the code of the module. It was fixed in enwiki, and I fixed it in our wiki when I been told about this. I believed there could not be something you're describing. Can you please give a simple nowiki example that can create a problem in enwiki now? IKhitron (talk) 10:29, 19 January 2018 (UTC)
I'm on wiki break right now so my participation in this conversation will be sporadic. The $...$-markup-in-cs1|2-titles-solution is problematic. It used to be that the module could extract the raw content of markup for use in its metadata, but MediaWiki was broken some time ago and never fixed. See this and linked discussions.
Presently, cs1|2 render an error message in the metadata in lieu of a stripmarker:
<cite class="citation book">Rapcsák, Tamás. ''Smooth nonlinear optimization in '"UNIQ--math-000000A1-QINU"'''.</cite><span title="ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Abook&rft.genre=book&rft.btitle=Smooth+nonlinear+optimization+in+MATH+RENDER+ERROR&rft.aulast=Rapcs%C3%A1k&rft.aufirst=Tam%C3%A1s&rfr_id=info%3Asid%2Fen.wikipedia.org%3AHelp+talk%3ACitation+Style+1" class="Z3988"><span style="display:none;">&nbsp;</span></span>
Trappist the monk (talk) 12:02, 19 January 2018 (UTC)

## Lay source

I discovered during my work for the above that the current module processes LaySource by adding italics and then invoking safe_for_italics (and then closing the italics). Is there a reason we're not using wrap_style here (I think it's possible but I can be told I'm wrong :D)? --Izno (talk) 03:42, 19 January 2018 (UTC)

The more important question is: should cs1|2 support lay sourcing at all? If the lay source is important enough to cite, shouldn't it get its own cs1|2 template? Aren't cs1|2 templates intended to cite a single source per template? That is, after all the reason cs1|2 doesn't support multiple ISBNs; why should a layman's version of a source be any different?
Trappist the monk (talk) 12:07, 19 January 2018 (UTC)
What is a lay source? Also, "shouldn't it get its own cs1|2 template" is confusing. Of course we do not have separate cs1 or 2 templates for each source, such as the notional {{cite-tale-of-two-cities}}.So it isn't clear what this phrase means. Jc3s5h (talk) 16:39, 19 January 2018 (UTC)
I would guess a "lay source" (it's completely undocumented from what I can tell) is a source which explains a source only understandable by subject matter experts. There are only about 3k uses.— Preceding unsigned comment added by Izno (talkcontribs) 17:27, 19 January 2018 (UTC)
Template:Cite journal#Lay summary.
Trappist the monk (talk) 01:43, 20 January 2018 (UTC)

## Is language=Bengali an error?

I am seeing articles in Category:CS1 maint: Unrecognized language due to |language=Bengali (example: 1950 East Pakistan riots), but this apparently official link says that Bengali is the official language name. What am I missing? – Jonesey95 (talk) 16:35, 19 January 2018 (UTC)

Help talk:Citation Style 1#mediawiki and language names/code again. The sandbox accepts Bengali and bn even though MediaWiki thinks that bn = {{#language:bn|en}} → Bangla.
Trappist the monk (talk) 01:39, 20 January 2018 (UTC)

## Dispute over Template:Citation Style documentation/journal – handling of complex |issue= information

I updated the documentation of the |issue= parameter to account for cases like "#293, Vol. 24, No. 5" (i.e., two different kinds of issue numbering), by adding the instruction "When a total issue number and an issue within a volume are both given – e.g., "#293, Vol. 24, No. 5" – this can be coded as |volume=24|issue=5 [total issue #293]." [1]; the documentation has for years already accounted for issue naming, with "When the issue has a special title of its own, this may be given, in italics, along with the issue number, e.g. |issue=2, ''Modern Canadian Literature''." This was not only reverted, but the revert included removal of both of these instructions, with an edit summary that doesn't make much sense to me: "no; abusing |issue= is no substitute for abusing |page=; one piece of information per parameter" [2]. Using |issue= for issue information is not "abuse" of the parameter, it's what the parameter exists for. Nor is there any principle here of "one piece of information per parameter", or we'd have separate parameters for middle names of authors, separate parameters for countries of city locations, separate parameters for days and months in dates, separate parameters for subtitles, and so on.

The problem to solve is that people are randomly actually abusing completely unrelated parameters like |page= and |publisher= to try to shoe-horn complex issue information into the template, when it obviously belongs in |issue=. But not obviously enough, or people wouldn't be doing that and we wouldn't need to have clearer documentation.

The only other alternative it to introduce yet more parameters for such things, and I think that's a terrible idea. So, I think this version should be restored. 12:28, 5 February 2018 (UTC)

I concur with SMcCandlish. Jc3s5h (talk) 16:20, 5 February 2018 (UTC)
That was me. It is not correct for us to 'permit' the misuse of a parameter just because editors have abused another parameter. The correct approach to the cumulative-issue-number vs. volume-issue-number question is to permit either but not both and to proscribe |volume= when a cumulative issue number is supplied in |issue=. For the issue-number-issue-title question, we have two fundamentally different pieces of information: the number is the basic descriptive unit typical of almost all periodicals and issue titles are generally rare special cases where the title merely supplements the issue number. Choose one, do not include wiki markup because the value assigned to |issue= is made part of the metadata.
No we would not have separate parameters for author middle names because we we have no need for that granularity; same for country location; same for dates. The question of subtitles is vaguely similar to the issue-number-issue-title question. There have been occasional requests here for a subtitle parameter but the community (not necessarily me) have rejected that, ostensibly because subtitles are merely extensions of the title. One might stretch the subtitle-as-title-extension point to argue that we should permit extension of issue number with issue title. I do not think that we should; extending a title with more title text is not the same as extending a sequence number with wiki markup and title text.
I don't see much value in the inclusion of issue titles in a citation. If the primary purpose of a citation is to help reader locate source material taken from a periodical, volume, issue, and date are much more likely to be helpful than an issue title. Further, it is the duty and obligation of the cs1|2 templates to render the correct style for each parameter. The only parameters that should use wiki markup are |title= and |chapter= (and their aliases) because titles often mix upright and italic fonts for good reason (scientific names, for example).
Trappist the monk (talk) 12:09, 6 February 2018 (UTC)

## Quote formatting

Currently, the quotes parameter can make the reference section hard to read, especially if quotes are long, or numerous (see example in this article). What do people think of having the quoted text be formatted with either a smaller font, or a dark grey colour so as to better delineate what is the reference and what is the quoted text? T.Shafee(Evo&Evo)talk 12:32, 9 February 2018 (UTC)

The suggested styling can be mimicked by adding this line to your personal css:
cite q {color:gray; font-size:85%;}
Trappist the monk (talk) 12:55, 9 February 2018 (UTC)
Broadly would not support this, as the text inside of the references group is already small text. Per WP:ACCESS we should not make it (much) smaller. The same goes for the text color, which would decrease contrast. As TTM notes, there is an alternative for yourself. --Izno (talk) 13:02, 9 February 2018 (UTC)
Oppose for reasons stated by Inzo. Also, I oppose grey fonts in nearly all situations, and have unfriendly thoughts to all those stylists who have been making so much of the web text I encounter grey. There's a reason laser printer manufacturers give you a warning when your toner is running low. Jc3s5h (talk) 13:59, 9 February 2018 (UTC)
we should only be quoting the specific text necessary for verification purposes, and even then in many cases, we don't need a quotation at all. If a reference list is turning into a quotation farm, then perhaps the better solution is to audit the quotation usages to see if we really need all of that text. If it's really excessive, it could turn into a copyright-related issue as well. Imzadi 1979  14:19, 9 February 2018 (UTC)
Long quotes like these should typically be trimmed, placed in a Notes section, or incorporated into the article's body. – Jonesey95 (talk) 15:46, 9 February 2018 (UTC)

## Update to the live cs1|2 modules weekend of 17–18 February 2018

I intend to update the live sc1|2 modules over the weekend of 17–18 February 2018. These changes are included:

• test categorization for Julian/Gregorian date uncertainty; discussion
• fix title separator removal; discussion
• proper language name output for code bh; discussion
• date validation internationalization; discussion
• these parameters no longer supported: |doi_brokendate=, |doi_inactivedate=, |template doc demo=, |trans_chapter=, |trans_title=
• added script code mn;
• test categorization for Julian/Gregorian date uncertainty
• added Sinhala 0D80-0DFF characters to invisible character exclusion; discussion
• these parameters no longer supported: |doi_brokendate=, |doi_inactivedate=, |template doc demo=, |trans_chapter=, |trans_title=
• internationalization support for non-Western digits in access-date timestamps; discussion
• COinS season and proper-name date index fix;
• test categorization for Julian/Gregorian date uncertainty

Trappist the monk (talk) 12:53, 11 February 2018 (UTC)

Trappist: just dropping an extra mention here to make sure it didn't get lost in the noise: there are valid cases for ZWJ in Burmese and Emoji too (in addition to Sinhalese etc.). See the referenced thread above for details (such as they are). --Xover (talk) 14:06, 11 February 2018 (UTC)
I have added the unicode blocks for Burmese: Myanmar, Myanmar extended A, Myanmar extended B. Emoji I've left for some other time because, if one is to believe the table here, they are spread unevenly across multiple code blocks and are sometimes isolated codes which makes for a mess.
Trappist the monk (talk) 15:28, 11 February 2018 (UTC)
Ugh! You're right. I see no sane way to detect this that doesn't involve importing and using the Unicode Emoji test table as a lookup table. Independently tracking all the code blocks and ranges that contain Emoji looks impractical, to the point that the Unicode consortium itself seems to have given up. --Xover (talk) 15:50, 11 February 2018 (UTC)
Forgot about Manchu language, cf. Fuk'anggan. --Xover (talk) 17:57, 17 February 2018 (UTC)
I don't think that support for the Manchu alphabet is something that will be added soon, if ever. In your example, the Manchu text requires the use of {{MongolUnicode}} which emits a rather large amount of html & css to render that text. All of that html and css ends up in the metadata where it does not belong. Citing sources that have Manchu-alphabet titles is, I think, not something for which cs1|2 are the appropriate tools. Citing such sources should be hand-crafted or should use a custom citation template (if there is sufficient need).
Trappist the monk (talk) 20:19, 17 February 2018 (UTC)
Trapppist, I don't see any link above to any discussion about the removal of "trans-title" and "trans-chapter", which is surprising, as I think they are useful parms to have. Could you provide a link, please? --NSH001 (talk) 00:02, 12 February 2018 (UTC)
Help talk:Citation Style 1/Archive 38#yet more parameters to deprecate.
Trappist the monk (talk) 00:58, 12 February 2018 (UTC)
To be clear, |trans-chapter= and |trans-title= are remaining. All of our recommended multi-word parameters are separated by hyphens. – Jonesey95 (talk) 01:32, 12 February 2018 (UTC)
Ah, good, that's fine, thanks. (Must get my eyesight tested...) --NSH001 (talk) 07:11, 12 February 2018 (UTC)

## Date range over year boundary

I get date check errors for |date=December 2004–January 2005 (regardless of whether I space the en-dash or leave it unspaced) in Annalisa Crannell. This is the publication date of one of the references, as given to me by JSTOR. How am I supposed to write this date? As far as I can tell from MOS:DATERANGE this format (at least with the spaced dashes) is supposed to be valid. —David Eppstein (talk) 22:23, 15 February 2018 (UTC)

{{Cite book |title=Title |date=December 2004 – January 2005}}Title. December 2004 – January 2005.
This works correctly, right?
Trappist the monk (talk) 22:42, 15 February 2018 (UTC)
It does now. For some reason it wasn't before. I'm suspicious that my software (Chrome on OS X) is inserting invisible characters when I type an en-dash, as sometimes I see later edits that remove them. Maybe that's what it was? —David Eppstein (talk) 22:49, 15 February 2018 (UTC)
(edit conflict) I have tried December 2004{{snd}}January 2005 and December 2004 – January 2005 with the same error being produced. Emir of Wikipedia (talk) 22:51, 15 February 2018 (UTC)

## Correct usage of dead URL?

In the past I used the dead-url parameter (I think) to indicate that the URL for the citation no longer worked, and someone needed to look at it, i.e. find an archived version or a new version of the page. However, from reading the documentation and using it again now, it looks like this is no longer the intended usage of dead-url. It doesn't show up anywhere, there is no hidden category, etc. What is the correct usage of dead-url and what parameter can I use to indicate dead links? Or should it be in a separate {{dead link}} template? —Ynhockey (Talk) 12:33, 17 February 2018 (UTC)

I'm pretty sure that the use you describe was never the intended purpose of |dead-url= nor has that functionality ever been implemented. The parameter is ignored except when the cs1|2 template uses both |archive-url= and |archive-date=. There is no cs1|2-specific parameter to indicate that a url is dead so the {{dead link}} template should be used to do that (outside of the cs1|2 template).
Trappist the monk (talk) 12:55, 17 February 2018 (UTC)
At one time it was a simple yes/no binary parameter, but nowadays has at least two more recognised values, see Help:Citation Style 1#Web archives and Template:Cite web#csdoc_deadurl. --Redrose64 🌹 (talk) 12:59, 17 February 2018 (UTC)
Thank you for this topic. This thread fixed my misunderstanding of that parameter too. This is a terribly misleading parameter name. If |dead-url= is intended to be used in conjunction with archived urls, the name should have reflected that to avoid obvious confusion by users. Jason Quinn (talk) 13:58, 17 February 2018 (UTC)
I agree and I think that I have argued elsewhere in these pages that it is a bad name because all other |<name>-url= parameters take urls as their assigned values. I have never gotten sufficient traction to deprecate |dead-url= and replace it with with something more appropriate. This morning I was thinking that |use-archive= might work. Anyone have a better name?
Trappist the monk (talk) 14:10, 17 February 2018 (UTC)
I have privately supported your suggestion of url-state/url-status before. (Russian Wikipedia allows HTTP codes in the field as well, which might be an interesting addition here, especially for IABot.) --Izno (talk) 15:33, 17 February 2018 (UTC)
Suggest |archive-state= (or |archive-status= or |archive-display=) so that the three |archive-*= arguments are easier to remember and kept together as a set. It's also more clear referring to the state of the archive, and not the url, which is the main source of confusion. Should the archive come first or second in display is the underlying question. -- GreenC 19:46, 17 February 2018 (UTC)
Any of those would be preferable and it'd be splitting hairs to chose among them. I have a slight preference for |archive-display= among the three. In each case the association is much clearer. The problem with |dead-url= is that it looks self-explanatory (seeming to answer the question "does the url work?") but it is not. Jason Quinn (talk) 02:26, 18 February 2018 (UTC)
Also this kind of change will break a lot of third party tools that work on citations. In my experience how quickly and easily those tools get fixed (if at all) is an open question. I'm of the opinion keep it the same because it's not a huge problem if a stray |deadurl= gets added - my bot WaybackMedic removes strays, and Cyberpower678's IABot marks links dead regardless. -- GreenC 19:55, 17 February 2018 (UTC)