Module talk:Citation/CS1/Archive 5

This is an current talk page .

I set up Module talk:Citation/CS1/testcases to automatically compare {{cite encyclopedia}} and {{cite news}} values generated from both the live module and its sandbox. As people make improvements to the sandbox, please check the testcases page to make sure nothing is breaking. We should extend this as we go. Dragons flight (talk) 23:30, 20 March 2013 (UTC)

Omit the colon in "Bibcode:Bibcode" data: For option "bibcode=" there is a spurious colon added in the Lua version (during last year?). Other than that, I think the {cite_journal} users will be happy to have 6x faster cites in the medical/science articles. See: Pneumonia, Cancer, Cystic fibrosis:

• Run: {{#invoke:CiteConversionTest|test|Cancer}}

Most journal cites look almost identical in format with the Lua version. Like an echo. Like an echo. Everything else seems good to go. I think many scientists will not even notice the Lua version is formatting the {cite_journal} data. -Wikid77 (talk) 07:46, 21 March 2013 (UTC)

I'm not actually sure it is accidental. If you look at the separators following the Lua identifiers, we see that:

arXiv, Bibcode, and doi use colon (":")

ASIN, ISBN, ISSN, JFM, JSTOR, LCCN, MR, OCLC, OSTI, PMC, PMID, RFC, SSRN, and Zbl use space (" ")

I could easily believe that someone wanted to use space after all of the uppercase ones and ":" after all the mixed case ones, but somehow missed Zbl.

The only difference between Lua and the older templates right now is that Bibcode was moved from using a space to using a colon.

So, we have several possible options.

1. We could leave the configuration as is.
2. We could revert Bibcode to use space, matching the current templates, but leaving doi and arXiv as the odd ducks.
3. We could convert Zbl to use ":", so all mixed case IDs use colon and all uppercase IDs use space.
4. We could convert all of them to use ":" as a separator.
5. We could convert all of them to use space as a separator.

Personally, I think the choice of separators here is pretty unimportant, and none of these options would bother me, but if people have strong feelings one way or the other, it might be good to share. Dragons flight (talk) 19:04, 21 March 2013 (UTC)

I am also ambivalent. The stand-alone {{Bibcode}} uses a colon. --— Gadget850 (Ed) ^talk 23:15, 21 March 2013 (UTC)

For {{cite journal}} it appears the current convention is "author, editor, title, journal", i.e.:

While for book chapters in {{cite book}} we use "author, chapter, editor, title", i.e.:

The latter feels much more natural to me since it places the editor name in closer association with the composite work. Is this something we should consider changing? As an aside, though academic journals routinely have editors, it seems a little weird to include their names in the citation at all. Editors are not generally included in referencing academic works, as far as I know, though I have seen some examples of people apparently doing this with their citations. Dragons flight (talk) 18:16, 21 March 2013 (UTC)

I prefer this the book style. You do seem to be making the resumption that journal is only for academic journals. Per the documentation: "for articles in magazines and journals and for academic papers." --— Gadget850 (Ed) ^talk 18:45, 21 March 2013 (UTC)

Could you be slightly clearer about which "this" you prefer? Dragons flight (talk) 18:48, 21 March 2013 (UTC)

P.S. Also, I meant specifically that it seemed weird to have editor's names on citations to academic papers, which is where I recall seeing it. For example, I saw a citation to

Physical Review D with both author and editor fields and thought that very odd. Dragons flight (talk

) 19:13, 21 March 2013 (UTC)

I would like to see a legitimate use case of having both an author and an editor on a journal paper before forming an opinion on what style is preferable. It certainly should not be listing someone just for being the editor of the journal in question. —David Eppstein (talk) 20:24, 21 March 2013 (UTC)

Journal with editor examples

Here are some in the actual use examples where both author and editor was given to cite journal. Some of these citations are admittedly a little weird. Dragons flight (talk) 21:32, 21 March 2013 (UTC)

There's a reason I qualified my request for use cases by asking for "legitimate" use cases. The first four do not look legitimate to me.

• Mandel — the editor is just the regular journal editor and should not be listed (even though the publisher's bibtex data lists the editor).
• Torfs — is a technical report, not a journal article.
• Covina – Is a conference proceedings in a book series, not a journal article.
• Humphrey – really is a journal paper, but "The Royal Society" is its publisher, not its editor.
• Boxhall – probably legitimate. This is a paper in a special issue of the journal (with title and editors for the special issue). The parameter usage is a little funky (the paper title has been moved to "chapter" so that the special issue title can go in "title"), and as a result the formatting is not really right (the paper title is in italics rather than double quotes). There should be a better way than this to handle this case; maybe cite journal could allow a booktitle parameter?
• Chan – probably also legitimate but I didn't track down the official journal page to be sure. The Lua cite differs in not boldfacing the long volume name "Suppl. 23"; I think this is an improvement.
• Zhang – again an article in a titled special issue of a journal.

—David Eppstein (talk) 21:56, 21 March 2013 (UTC)

Just because it is often a strange (or even incorrect) usage doesn't necessary mean it is good to allow inconsistent styling. If I could send all the users to citation formatting reeducation camps, then we could fix a lot of problems. However, those intractable users are damn hard to fix, so since people sometimes deploy {{cite journal}} when they really mean {{cite book}} (or do other weird things), I don't think there is any harm in moving the editor fields to make them similar across the various usages. I've done this in the version shown above. Dragons flight (talk) 16:39, 22 March 2013 (UTC)

There are currently about 25 examples where we check multiple case representations of arguments, i.e. doi= and DOI=, Author= and author=.

Would there be any downside to making all the parameters case insensitive? It can be done easily at the point we locally copy the argument table, and I expect the net effect is pretty performance neutral (a few calls to string.lower offset by removing various checks for alternate capitalization), so basically I'm asking is there any reason it would be bad if editors had the option of using whatever parameter capitalization they wanted? I seems like allowing title=, Title=, and TITLE=, etc. to function the same is probably okay (and might help newbies) even if that's not how templates generally work. It would certainly help clean up some of the code by allowing us remove the various capitalization checks. Dragons flight (talk) 02:57, 22 March 2013 (UTC)

This seems reasonable to me. BibTeX is not case sensitive in its corresponding parameter names, and that doesn't seem to cause any problems. Some external software might need to be updated (e.g. I have code I use to convert back and forth between Wikipedia citations and BibTeX that is currently case-sensitive on the Wikipedia side) but the update would be very easy. —David Eppstein (talk) 04:14, 22 March 2013 (UTC)

• Avoid vast divergence from 23 {cite_*} forks and markup templates: We need to beware any changes which radically differ from the 23 older {cite_*} forks. For example, allowing capital-letter "Title=xx" in {cite_journal} would encourage use of a parameter spelling which would be insidiously ignored in the older fork templates, to cause confusion in new users unaware of the transition status of the various {cite_*} fork templates. Also, we would complicate the comparisons of parameters between the Lua versions and the old markup-based templates which would ignore many uppercase parameter names. Beyond those problems, there would be endless confusion with alternate citation templates, such as
  paralysis of analysis which causes a 9-day transition to Lua-based cites to drag into 6 weeks/months of numerous delays. -Wikid77 (talk
  ) 05:29, 22 March 2013 (UTC)

Changing the capitalisation rules would widely affect bots. We'd diverge further from other cite templates and those related to them. As Wikid77 says mid-transition is not a good point. I think overall it would lead to more problems. Rjwilmsi 09:08, 22 March 2013 (UTC)

The documentation explicitly states to use lower case, and the upper case aliases and the one misspelling alias have never been documented. The defacto site standard for parameters is lower case. --— Gadget850 (Ed) ^talk 12:47, 22 March 2013 (UTC)

Okay, we can table this, if people think it will be too much of a problem. For the record, I did add a check for URL=, which seems to be the most frequent variant in actual use among cases we haven't been checking (probably because it is an acronym and we allow most other acronyms to be all uppercase). Dragons flight (talk) 15:12, 22 March 2013 (UTC)

This page is in this category. Shouldnt it just be for main space? Christian75 (talk) 19:20, 22 March 2013 (UTC)

Right. {{Citation/identifier}} does a namespace check and uses the category only for articles. --— Gadget850 (Ed) ^talk 19:31, 22 March 2013 (UTC)

Okay, but why only main space? References can also appear occasionally on file descriptions, Wikipedia pages, and other places. It's not obvious why only using the category for main space is the right idea. If the only problem one is worried about is documentation pages and ones like this one where the error is being displayed intentionally, then those can be removed from the category by adding nocat=true to the citation that generates the error. Dragons flight (talk) 20:00, 22 March 2013 (UTC)

PS. I managed to block the track cats in enough places to disable that category for this page. Dragons flight (talk) 20:22, 22 March 2013 (UTC)

Point. {{Broken ref}} controls the cite error messages and categorizes only main (article), template, category, help and file pages. --— Gadget850 (Ed) ^talk 20:25, 22 March 2013 (UTC)

I've prepared a set of {{cite journal}} testcases at Module talk:Citation/CS1/test/journal. If there are no complaints, or other issues, I'd propose to migrate this later today. Dragons flight (talk) 19:30, 22 March 2013 (UTC)

Looks good to me. --— Gadget850 (Ed) ^talk 20:04, 22 March 2013 (UTC)

{{cite journal}} is now installed as Lua. Dragons flight (talk) 01:17, 23 March 2013 (UTC)

I've just set up automated archiving of this talk page, with a delay of seven days. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 20:09, 22 March 2013 (UTC)

Issues with lastauthoramp and author-separator:

--— Gadget850 (Ed) ^talk 18:22, 24 March 2013 (UTC)

I edited your examples, "lastauthoramp" has been added to the sandbox version of CS1. However, you should note that it is never used if "et al." is present. This the same behavior as the current templates. Dragons flight (talk) 18:54, 24 March 2013 (UTC)

I think the separator issue is also fixed. Dragons flight (talk) 19:03, 24 March 2013 (UTC)

Please check lastauthoramp in the cases where there are both authors and editors (e.g. a chapter in an edited book). If lastauthoramp=yes, "et al." appearing in the authors, for example, should not suppress the & in the editors, or vice versa. Peter coxhead (talk) 21:37, 24 March 2013 (UTC)

authormask alias not supported:

--— Gadget850 (Ed) ^talk 12:52, 25 March 2013 (UTC)

Fixed in sandbox. Dragons flight (talk) 15:00, 25 March 2013 (UTC)

 Fixed --  Gadget850 (Ed) ^talk 13:24, 2 April 2013 (UTC)

Apparently, it has been the case with the old templates that accessdate is stripped if no URL is specified. Specifically, the documentation says that accessdate is the date that the URL was accessed, and with that understanding it makes sense not to use the field if no URL is given. I can update this to match, but before I do, I wanted to ask whether it might be worth preserving. I could see that accessdate might occasionally help resolve ambiguities regarding version / edition / printing of various printed works even though they tend to update far less often than internet. On the other hand, if a full citation is given (including information such as edition) then there is really no utility to saying when a book was accessed. Do people think this is worthwhile to preserve or not? If not, then I would probably add error tracking for accessdates with no URL specified. Dragons flight (talk) 15:20, 25 March 2013 (UTC)

We have parameters version, origyear and edition. accessdate is only for web pages with content that changes. Thus, maintain the original suppression. --— Gadget850 (Ed) ^talk 15:37, 25 March 2013 (UTC)

Okay, this has been removed in the sandbox and the tracking category Category:Pages using citations with accessdate and no URL has been added. Dragons flight (talk) 17:21, 25 March 2013 (UTC)

 Fixed --  Gadget850 (Ed) ^talk 13:26, 2 April 2013 (UTC)

Per spec (e.g.

So, if no URL is specified, should we:

1. Remove the format= value, based on the spec?
2. Preserve the historical template behavior, on the understanding that format= has probably been abused in the wild?

Dragons flight (talk) 15:44, 25 March 2013 (UTC)

I will pick #2. --— Gadget850 (Ed) ^talk 16:09, 25 March 2013 (UTC)

That's my preference too. Dragons flight (talk) 16:26, 25 March 2013 (UTC)

Preserve historical template behavior but emit an error message: format= used without URL=. The de facto specification should be adhered to until it is changed through consensus.

—Trappist the monk (talk) 15:06, 27 March 2013 (UTC)

I've added a tracking cat, Category:Pages using citations with format and no URL, to help identify this issue. In general, I'm very reluctant to add a visible error message without having more information and a larger discussion. If there are many users using format for purposes other than that envisioned by the specification, then it may be more appropriate to change the specification rather than trying to force editors to conform. Dragons flight (talk) 17:21, 27 March 2013 (UTC)

I agree with DF here. Will expand below. --— Gadget850 (Ed) ^talk 17:58, 27 March 2013 (UTC)

Okay, in the sandbox I've made it so that format= attaches to the primary work if no URL is given, which is synonymous with how type= is used. If there is a URL then format= follows the URL link. Dragons flight (talk) 00:41, 26 March 2013 (UTC)

but see, when |series= is defined:

{{cite book|author=Author|title=Book|format=Format|type=Type|series=Series}}

also:

{{cite book|author=Author|work=Book|format=Format|type=Type|series=Series}}

70.19.122.39 (talk) 14:28, 27 March 2013 (UTC)

 Fixed --  Gadget850 (Ed) ^talk 13:27, 2 April 2013 (UTC)

The old v. Lua anchors are:

• "CITEREF.22Fowler.27s_Ghost.221962"
• "CITEREF"Fowler's Ghost"1962"

Granted, this particular example is odd in the use of quotes, but it shows that the anchor is not encoded. {{Citation/core}} uses anchorencode:.

Here we have a similar problem with a rational use:

The old v. Lua anchors are:

• "CITEREFSch.C3.B6nhaus2004"
• "CITEREFSchönhaus2004"

Templates such as {{

Does that look correct? Dragons flight (talk) 04:49, 27 March 2013 (UTC)

More better. Thanks. --— Gadget850 (Ed) ^talk 12:42, 27 March 2013 (UTC)

• Seems fixed so try encoded harv link on various browsers: The generated HTML looks correct, now, and here is a Lua-only {cite_book/lua} with ref=harv but internal year=1994b:    Schönhausauch, Andere; Nürnberger, Fritz (1 June 1994). The Forger Forged. Enwiki. {{cite book}}: Invalid |ref=harv (help)CS1 maint: date and year (link)
  After clicking a related {harvnb} author/year link, then any browser should scroll back to the Lua citation directly above. Now, the following is a related wikilink of those 2 authors and year "1994b" as {{harvnb|Schönhausauch|Nürnberger|1994b}}, to that citation, to click here: Schönhausauch & Nürnberger 1994b. Any browser should scroll back to the Schönhausauch/Nürnberger citation above. The umlaut letters 'ö' and 'ü' are encoded so that the anchor id matches to the wikilink. In various checks of numerous live articles, I have not found any other broken author/year links, so the problem has been rare. -Wikid77 (talk) 13:03, 27 March 2013 (UTC)

I use a script that shows harv anchors when there is no corresponding link, so this is pretty obvious. The anchors are now properly encoded. --— Gadget850 (Ed) ^talk 20:26, 27 March 2013 (UTC)

 Fixed --  Gadget850 (Ed) ^talk 13:45, 2 April 2013 (UTC)