Misplaced Pages

This is an old revision of this page, as edited by ClueBot III (talk | contribs) at 06:54, 27 May 2015 (Archiving 4 discussions to Module talk:Citation/CS1/Archive 11. (BOT)). The present address (URL) is a permanent link to this revision, which may differ significantly from the current revision.

Archives (index)

Index 1, 2, 3, 4, 5, 6, 7, 8, 9, 10 11, 12

This page has archives. Sections older than 30 days may be automatically archived by ClueBot III when more than 6 sections are present.

name-list-format=scap now producing error

The authorformat=scap/name-list-format=scap, producing smallcaps, is now producing an " Invalid |name-list-format=scap" error across a large number of articles. Anyone have any idea why? Simon Burchell (talk) 15:26, 15 February 2015 (UTC)

|authorformat= has been deprecated and the scap value has been removed altogether. See Help talk:Citation Style 1/Archive 7#Update to the live CS1 module weekend of 14–15 February 2015. Discussion at Help talk:Citation Style 1/Archive 7#Separator parameters which references MOS:ALLCAPS. --  Gadget850 15:35, 15 February 2015 (UTC)

Sigh. That's it, I'm done with CS1 citing. It was good while it lasted. Simon Burchell (talk) 15:37, 15 February 2015 (UTC)

@Simon Burchell: MOS:SMALLCAPS has long deprecated the use of small caps. Although I'm unhappy about some of the changes made to the citation templates, this one seems well justified. Peter coxhead (talk) 21:08, 15 February 2015 (UTC)

MOS smallcaps guidance seems more geared towards the body text of an article, and smallcaps in references helps author names stand out from the mass of text when looking up a reference. I find it ironic that supposedly there is no "house style" of referencing, yet widespread styles such as smallcaps are stamped out via citation templates. At any rate, I'm done with it. The citation template parameters are constantly changing, and I've reached my patience threshold with running to catch up. All the best, Simon Burchell (talk) 21:13, 15 February 2015 (UTC)

See also: All caps#Readability. --  Gadget850 21:22, 15 February 2015 (UTC)

That's all very well for reading sentences or paragraphs of text, but when one is merely scanning for an author name I find that having smallcaps help pick out the author names for rapid identification of a cited source (which I admit becomes irrelevant if {{sfn}} is used). Simon Burchell (talk) 21:27, 15 February 2015 (UTC)

We're not going to come to a consensus, so have a nice day. --  Gadget850 21:35, 15 February 2015 (UTC)

• I think it is absolutely ridiculous to prohibit the use of small caps in references. What exactly is the rationale? What problems does it cause? And yes I agree with Simon that if supposedly we are free to choose our own citation style then we should also be free to use small caps for author names. The all caps readability argument is irrelevant since this is not about running prose but about making it easier to pick out author names in reference lists - something which is often done with small caps in professional publications. I will also, like Simon, consider to stop using citation templates all together.User:Maunus ·ʍaunus·snunɐw· 18:52, 16 February 2015 (UTC)

The templates implement the MOS. Per MOS:ALLCAPS: "Avoid writing with all capitals, including small caps." Have an issue with that, then get it changed at Misplaced Pages talk:Manual of Style/Capital letters.

You can certainly stop using templates, but that means you are not going to be adding citations to articles already using templates unless you have consensus to change per WP:CITEVAR. --  Gadget850 19:13, 16 February 2015 (UTC)

That is about the text not about references. I will bloody well decide where and when I will add citations thank you very much.User:Maunus ·ʍaunus·snunɐw· 19:25, 16 February 2015 (UTC)

You are welcome. Unwatching page. --  Gadget850 19:26, 16 February 2015 (UTC)

Well isn't that great. Driving off one of the most knowledgeable and helpful contributors to this page. Way to go, Maunus. --Redrose64 (talk) 01:53, 17 February 2015 (UTC)

Wtf? How on earth is Gadget805s decision to unwatch this page my fault? As for being helpful that doesnt exactly seem like a fitting description of their interactions with Simon Burchell above or with myself.User:Maunus ·ʍaunus·snunɐw· 02:01, 17 February 2015 (UTC)

Maunus / Simon, I have no strong opinion about the scap option. However, it seems to me that if you object to the result of the previous discussion, the best course of action is to express that objection at a broader forum. I would suggest Village Pump (policy) since this does seem to touch on how broadly the MOSCAPS guideline should be applied. This is a wiki, and the change to CS1 can be reverted if that is the consensus. Dragons flight (talk) 19:45, 16 February 2015 (UTC)

It seems to me that such a broader discussion should have been started before implementing these changes though. Nonetheless I have now initiated a discussion at Wikipedia_talk:Manual_of_Style/Capital_letters#Exceptions_to_Small_Caps and I have made a bold edit to the MOS. User:Maunus ·ʍaunus·snunɐw· 19:53, 16 February 2015 (UTC)

• Here is the RfC about the issue: Wikipedia_talk:Manual_of_Style/Capital_letters#RfC:_Proposed_exceptions_to_general_deprecation_of_Allcaps You input will be valued. User:Maunus ·ʍaunus·snunɐw· 21:16, 16 February 2015 (UTC)

This RFC has been resolved in favor of leaving the citation module as it currently exists. Capitals and small caps are allowed only when the meaning of the words or letters is changed when caps are used. – Jonesey95 (talk) 16:50, 10 May 2015 (UTC)

Language parameter

user:Trappist_the_monk, and others :)

Hi! See this task. We are wondering if there's a way to tell Cite templates in VE that they don't need to add the language parameter if the source language is the same than the wiki one. Do you think this is feasible, and most importantly, that it makes sense to do so? (AWB removes that parameter anyway.) Thanks a lot for your input! --Elitre (WMF) (talk) 11:33, 30 April 2015 (UTC)

I don't use VE so I don't know anything about how it works. But is that really your question? The phabricator task doesn't mention VE.

If the question is should VE populate |language=English (or the ISO 639-1 code en) then I would say no, don't do it. Editors here complain about citation template clutter whether it's in the rendering (access dates or English language annotation) or in the wikitext. The exception – isn't there always an exception? – is when the source is in multiple languages: |language=fr, de, en, then you should include English in the |language= parameter.

Did I answer your question?

—Trappist the monk (talk) 12:22, 30 April 2015 (UTC)

I oversimplified :) mw:Citoid is a tool in VE which auto-generates references. It relies on Cite templates and TemplateData, so we're looking for a way to change the former or the latter to tell it to not populate that field, precisely for the reason you provided. Maybe now the Phabricator task makes more sense? Thank you! --Elitre (WMF) (talk) 12:32, 30 April 2015 (UTC)

I don't use Citoid or VE either, but those would be the places to focus. In one of them, you may be able to have some sort of explanatory note for editors that they should not populate |language= with the language of the WP that they are editing. – Jonesey95 (talk) 12:45, 30 April 2015 (UTC)

Thank you for weighing in. While it's certainly possible to improve such messaging in case of need, we aren't talking about editors adding that parameter manually. See a brief description of how Citoid works. Best, --Elitre (WMF) (talk) 12:50, 30 April 2015 (UTC)

Doesn't Citoid create the cite template? If so, how could the template, which hasn't yet been created, tell citoid how it is to be populated? Why am I so confused?

—Trappist the monk (talk) 13:27, 30 April 2015 (UTC)

@Trappist the monk and Jonesey95: Sorry for the confusion, possibly my fault for not explaining my suggestion clearly enough near the bottom of that phab task.

Briefly, the aim (of my suggestion) is to make our Module work the same way as the French Modules do - to not render the language if it's set to the local default (English) - for example, in this revision, the 1st and 2nd citations both include |langue = français, but that info isn't rendered in the reflist below. That fixes the issue of having a useless string of text shown to readers (I assume that's the main reason we automatically remove it, when someone includes it in a citation).

This would:

1. make the citation's language (meta-info) programatically available for researchers (rather than them having to just assume a missing language=..)
2. let Citoid freely add any detected language (without having to worry about exceptions)
3. Remove one task from the Checkwiki cleanup list at enwiki (thereby leading to fewer bot-edits like (half of the changes in) this diff)

   (Seems to be #21 at Misplaced Pages:WikiProject Check Misplaced Pages/List of errors)

See Zebulon84's explanation in this comment, for links to the French module (with line numbers) and a few details on the nuances.

I hope that's a bit clearer, and seems like a sensible course of action. Quiddity (WMF) (talk) 18:27, 30 April 2015 (UTC)

The more-or-less equivalent code in en:WP's Module:Citation/CS1/sandbox (sandbox because it is slightly different from the current live module and til now was the intended update) is at line 1762. There, we look to see how many languages are listed in |language=. If only one language is listed and if that language is English or en then we add the page to Category:CS1 maint: English language specified and then go on to render the (in English) annotation text. We could, instead of or in addition to categorizing, simply return an empty string when English is the only language in the parameter value. That more-or-less mimics fr:WP.

As far as past conversations about the language parameter, those, if they exist, would most likely be in this page's archive or in the archives of Help talk:Citation Style 1. Or not. When I wrote Monkbot task 6 I adopted the philosophy stated in the box at {{en icon}}. If I remember correctly, that's the only place that I found that addressed the issue of English language annotation in en:WP.

There has been little to no reaction from CS1|2 template users with regard to the changes I've made to |language= support. Still, if your proposal is to procede, it might be best to, at the least, notice Help talk:Citation Style 1 with its 160 watchers since only 60 watch this page (and who probably are also watching H:CS1).

—Trappist the monk (talk) 19:55, 30 April 2015 (UTC)

Pinging people there. Thank you. --Elitre (WMF) (talk) 08:28, 1 May 2015 (UTC)

I also apologize for the confusion: my point instead was a bit different. I'm taking for granted that not having the language parameter at in the template (not just not having a redundant language code in the reflist) is what the community here currently desires and the reason why it gets deleted by bots. I'm not challenging the reasoning behind this, I'm asking if there's a way to achieve this by changing the template behaviour, if possible and, as I stated in my first post, if it really makes sense for everybody. If it doesn't, and Quiddity's suggestion makes more sense, or if you have a different one, great! We'd just like to understand what's everybody's preference, here. HTH. --Elitre (WMF) (talk) 19:32, 30 April 2015 (UTC)

I'm not sure I understand what you mean by changing the template behaviour. An editor (or Citoid) creates a CS1|2 template and Module:Citation/CS1 renders it. Here, we can't do anything about what editors or Citoid create. We can, though, decide how we render the citation that the reader sees. The fr:WP solution is to not display language annotation when the specified language is an acceptable form of French. The |language=English parameter is still in the wikitext. Is this what you mean by changing behavior?

—Trappist the monk (talk) 19:55, 30 April 2015 (UTC)

What the French are doing is a partial solution - you wouldn't provide a redundant information, but you'd still need cleanup; if an empty string (when English is the only language in the parameter value) was returned, wouldn't editors here still instruct the bot to go and delete "language=en" from wikitext anyway? I think they would, unless they decided this is not an error which needs to be corrected anymore. Since bots at enwiki currently get rid of "language=en" entirely, I'm just wondering if there is a way to prevent that that parameter is added in the first place (if this is a desirable outcome, obviously, and only when the source language matches the wiki one). Again, we're just flagging this to understand whether something needs to be done, and by whom :) Best, --Elitre (WMF) (talk) 08:28, 1 May 2015 (UTC)

The only way to keep bots from deleting something is to deny them access to the wikitext. Automated tools that create CS1|2 templates place those templates into the wikitext. The template processing tool (here, Module:Citation/CS1) has no power to rewrite the template in wikitext; it can only read and act upon what it reads where that act is to translate the data contained in the template into a correctly rendered HTML citation for display in a reader's browser.

The only place to prevent |language= parameter insertion is at the inserter: Citoid or Visual Editor. The French solution handles the cases where the inserter is a human editor constructing CS1|2 citations and where the community have decided that language annotation for sources in the local WP language need not be displayed.

—Trappist the monk (talk) 10:06, 1 May 2015 (UTC)

Trappist the monk, thanks a lot for the explanation. Let me know if anything changes at some point as a result of this conversation. best, --Elitre (WMF) (talk) 06:01, 5 May 2015 (UTC)

Elitre (WMF): I have changed the en:WP Module:Citation/CS1/sandbox so that citations at en:WP with |language=en or |language=English will not display the language annotation:

—Trappist the monk (talk) 00:16, 7 May 2015 (UTC)

You know, thinking about how often WPMED folks (especially the translation task force) copy citations to other Wikipedias, it might be a good idea to keep the |language=en information. Maybe we should hide it, rather than removing it. WhatamIdoing (talk) 17:38, 5 May 2015 (UTC)

That is a good point. Paging Doc James, who does a lot of this copying, I believe. – Jonesey95 (talk) 18:25, 5 May 2015 (UTC)

I think it is good information to provide. Yes we are adding En references to nearly 100 other Wikipedias. Doc James (talk · contribs · email) 19:34, 5 May 2015 (UTC)

Author parsing

So after the latest blowup over template changes, I think adopting the "vauthors=" mechanism from Template:Vcite2 journal is worth serious consideration. The current approach is very unambiguous, but having the first and last name of every author as a separate parameter makes for very bloated markup, and it's definitely a burden on those of us who are still hand-typing citations. I support the goal of making our references into something semantically meaningful, because I think that many useful tools for article curation could be built if we had a reliable way of identifying which articles were supported by which references, which journals, books, authors, etc. But the content has to come first: if the semantic markup scheme is deterring authors from editing, there is a serious problem. In the big picture, it's much more important to have people identify sources in medical articles as being WP:MEDRS (or not) than it is for those references to emit correct metadata. (I think the medical articles tend to be a bigger friction point because they often have very large author lists that bloat enormously.)

So, is it possible to graft the parsing code for "vauthors=" onto the "authors=" parameter here? I assume "authors=" already dumps its entire string as a single author into the COinS metadata, so it's unlikely to make things worse. And is it possible to parse "et al." or "''et al.''" at the end of that string without needing explicit markup? I have enough experience of HTML parsing to know that this kind of "do what I mean" parsing is risky, but given the debacle of the Visual Editor rollout, we're going to have to cope with hand-writing these templates for quite a while. Explicitly marking up every author may be less prone to error, but this isn't the first time there has been pushback about this, and I think this solution might make the process of structuring references a lot less objectionable. Choess (talk) 02:18, 6 May 2015 (UTC)

I haven't given the question of how would |vauthors= parsing work within Module:Citation/CS1 a great deal of thought but I'm pretty sure that it could be done. And it would produce better metadata because a requirement of |vauthors= would be that author (and editor) name lists would be required to adhere to the Vancouver system. Because |authors= does not have that kind of requirement, a wide variety of formats can be found.

Module:Citation/CS1 already recognizes a variety of et al. forms. It is that recognition that causes the population of Category:CS1 maint: Explicit use of et al. That same recognition strips the et al. from the author and editor lists before they are sent to metadata and causes the module to render the author and editor lists with the standardized form of et al. appended. The cs1|2 templates' remit includes handling and placement of static text but it is necessary to have a proper and consistent mechanism to inform the template when it should render certain static text. This is why we have |display-authors=etal.

When editors feel free to add non-author-name text et al. to author-name parameters, I think that they then feel free to add other non-author-name text to author-name parameters in spite of instruction to the contrary in all cs1|2 documentation. Et al. is relatively easy to detect and compensate for; other text, not so easy; if it were, I'd have a category full of pages that have such cs1|2 template parameters.

—Trappist the monk (talk) 09:29, 6 May 2015 (UTC)

Et al 2

In English, abbreviations are set off with a comma, e.g. like this. This applies to "et al." equally, i.e. Smith, Jones, et al. When used with two or more names, the APA style expects it, viz. http://blog.apastyle.org/apastyle/2011/11/the-proper-use-of-et-al-in-apa-style.html. Similarly for Grammarist. As does ICMJE. Chicago says to use a comma unless there's only one name written in full. That's everybody except Trappist the monk, so I've restored my edit. Any third opinions? --RexxS (talk) 22:00, 13 May 2015 (UTC)

When I reverted your edit, in my edit summary I wrote: cs1|2 not bound by ICMJE; historically, cs1|2 has not used a comma before et al.

I've written this before: cs1|2 are not APA, are not Chicago, are not Bluebook, are not LSA, are not ICMJE, nor are they any other style. Certainly cs1|2 have been influenced by these styles but are not beholden to them.

Here is a simple {{cite book/old}} using {{citation/core}}. It has nine authors so it generates et al. in place of the ninth:

Author1; Author2; Author3; Author4; Author5; Author6; Author7; Author8 et al. Title. 

This form has been in place since this edit to {{citation/core}} on 7 October 2009. That style continues in use to the present day in Module:Citation/CS1.

In the edit summary of your revert of my revert you wrote: not bound by your preferences either - see talk. I have made no claim of personal preference with regards to a comma preceding et al.; if you can show where I have, please do so, otherwise, please do not put words into my mouth that I have not spoken.

—Trappist the monk (talk) 00:16, 14 May 2015 (UTC)

RexxS has made a bold edit, and that edit has been reverted. Now we discuss. That's how WP works. Let's not have an edit war in a sandbox.

One of the things that we typically do on this page, or on Help talk:Citation Style 1, which is watched by more editors and serves as a better place to discuss changes to the module, is suggest a change and show some examples of how the change would be implemented. Then the change, if it meets with approval (or at least tentative approval, or perhaps aggressive lack of interest, or outright ambivalence), can be implemented in the sandbox and examples of the before/after rendering can be shown.

A suggestion has been made to insert a comma before "et al." in author and editor lists. Shall we attempt to implement that change in the sandbox and then display some test cases here to see if it works as intended? – Jonesey95 (talk) 03:21, 14 May 2015 (UTC)

One of the problems that besets Misplaced Pages is that it is being fossilised by editors who insist that "we have done it this way in the past" is an argument against any change. It isn't any argument at all. @Trappist the monk: Your revert summary made two points, neither of which provided any objective reason why it would be better to have no separator before " et al." Your argument is clearly then nothing more than your personal preference, and I make no apologies for pointing that out to you. I have provided multiple objective reasons: the use of commas before abbreviations is standard English grammar; all other style guides that I know of require a comma. I know we're not obliged to follow other style guides, but a lack of obligation to do something is poor excuse for not doing it, and I'd ask why you would not want to adopt a style that was consistent with what readers see in almost every other serious publication? --RexxS (talk) 11:58, 14 May 2015 (UTC)

Do not presume to think that I am opposed to change; I am not. For evidence of that look at the history of this module; read Help talk:Citation Style 1 and its archives.

Lest you continue to put words into my mouth that I have not spoken, let me definitively state my position with regards to punctuation preceding et al.: I am neither in favor of nor opposed to punctuation preceding et al. in editor- and author-name-lists; in short, I do not care.

If the community are content to have et al. rendered without preceding punctuation, then I accept that. If the community determines though discussion that cs1|2 should render et al. with preceding punctuation, then I accept that.

—Trappist the monk (talk) 13:14, 14 May 2015 (UTC)

• Support – The only argument presented above for not including a serial comma before "et al." is that it hasn't been since 7 October 2009 which is not a strong argument. Furthermore the removal of the comma was apparently made with no discussion. As journal style guides overwhelming support including a comma, the argument in favor is much stronger. Boghog (talk) 03:26, 14 May 2015 (UTC)
• Partial support: I think that "Smith, Alan; Brown, Jane; et al." makes sense. In the standard CS1 style, I support changing to use a semicolon before "et al.", not a comma, because other authors are separated from one another by semicolons. If the separator of choice is a comma (i.e. |mode=cs2|name-list-format=vanc), then use a comma before "et al." – Jonesey95 (talk) 03:39, 14 May 2015 (UTC)

  |mode= does not change the style of separators used in the author and editor name lists:

  |mode=cs1:

  Last1, First1; Last2, First2; Last3, First3; Last4, First4. Title.{{cite book}}: CS1 maint: numeric names: authors list (link)

  |mode=cs2:

  Last1, First1; Last2, First2; Last3, First3; Last4, First4, Title{{cite book}}: CS1 maint: numeric names: authors list (link)

  but |name-list-format=vanc does:

  Last1, First1; Last2, First2; Last3, First3; Last4, First4. Title. {{cite book}}: Unknown parameter |name-list-format= ignored (|name-list-style= suggested) (help)CS1 maint: numeric names: authors list (link) – the error here because the example uses enumerated names

  —Trappist the monk (talk) 11:28, 14 May 2015 (UTC)

Good point. A semicolon should be used unless |name-list-format=vanc or |mode=cs2 in which case a comma should be used. Boghog (talk) 04:28, 14 May 2015 (UTC)

I corrected myself above. I'm not used to these new formatting parameters, but I knew there was some way to have commas separating names. – Jonesey95 (talk) 13:47, 14 May 2015 (UTC)

The new |vauthors= and |veditors= cause the module to rewrite their content as a last-first list and then render it in Vancouver system style without requiring |name-list-format=vanc.

—Trappist the monk (talk) 14:05, 14 May 2015 (UTC)

• Partial support per Joensey95 for consistency with the existing formatting and how this is done in other style guides. Imzadi 1979 → 04:07, 14 May 2015 (UTC)
• Support. Serial comma is the norm here, and so far no real objections have been raised. "Standard English grammar" is of course a red herring, as these are citations rather than sentences. My only concern would be to clarify usage when combining individuals with corporate authors. LeadSongDog come howl! 12:19, 15 May 2015 (UTC)

Redirect this page to Help talk:Citation Style 1?

Should we redirect this page to Help talk:Citation Style 1? That page is watched by 160 editors, while this one is watched by only 60, and they are essentially the same forum. I think we should have just one discussion location for issues relating to the CS1 templates. – Jonesey95 (talk) 03:21, 14 May 2015 (UTC)

I would support this.

—Trappist the monk (talk) 11:33, 14 May 2015 (UTC)

Given the above discussion occurred, absolutely. --Izno (talk) 19:49, 14 May 2015 (UTC)

Et al 3

Please see this thread at the Helpdesk. The author name Sheetal is being rendered as She et al. in {{citation}}. Something to do with the regex for et al., apparently. Thanks. - Sitush (talk) 18:32, 26 May 2015 (UTC)

(ec) For details, compare:

• {{citation |first=Sheetal |last=Ranjan |chapter=Crimes Against Women in India |editor-first=N. Prabha |editor-lasUnnithan |title=Crime and Justice in India |year=2013 |publisher=SAGE Publications |isbn=978-8-13210-977-8 |url=https://books.google.co.uk/books?id=k_6HAwAAQBAJ}}
• Ranjan, Sheetal (2013), "Crimes Against Women in India", in Unnithan, N. Prabha (ed.), Crime and Justice in India, SAGE Publications, ISBN 978-8-13210-977-8

This is evidently caused by the over-eager regexp in the following code line:

local pattern = ",? *'* **$"

which will recognize an "et al" mark even if it has neither a space between the two words nor a word boundary before it. Could we have a "\w" check or something of the sort built in to the beginning of that regexp to avoid this?

Fut.Perf. ☼ 18:34, 26 May 2015 (UTC)

Specifically, I'd recommend replacing ",? *" with "(, *| +)" (i.e. either a comma plus optional space, or at least one space to separate the "et al" string from the preceding text). Fut.Perf. ☼ 06:53, 27 May 2015 (UTC)