Help talk:Citation Style 1

From Wikipedia, the free encyclopedia
  (Redirected from Template talk:Cite episode)
Jump to: navigation, search
the Wikipedia Help Project (Rated B-class, High-importance)
WikiProject icon This page is within the scope of the Wikipedia Help Project, a collaborative effort to improve Wikipedia's help documentation for readers and contributors. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks. To browse help related resources see the help menu or help directory. Or ask for help on your talk page and a volunteer will visit you there.
B-Class article B  This page does not require a rating on the project's quality scale.
 High  This page has been rated as High-importance on the project's importance scale.
 

vcite templates[edit]

As noted above, "the {{vcite journal}} template [has] fallen into disuse". It has only 285 transclusions. It seems that it and the related templates ({{vcite book}} (208 transclusions), {{vcite news}} (100), {{vcite web}} (168)) were forked from their more commons equivalents due to performance issues, which have since been solved. They also lack COinS metadata. Is there any need to keep them? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 21:04, 14 May 2014 (UTC)

I personally would say they should be updated and used for Vancouver style so that Vancouver style parameters can be removed from the CS1 templates. Then the choice will be simple, if you want to use CS1 in an article, use cite * templates, and if you want to use Vancouver style, you use vcite * templates. Imzadi 1979  21:14, 14 May 2014 (UTC)
My thoughts exactly. Using CS1 templates with display options and other styling is always going to painful to maintain. --  Gadget850 talk 21:30, 14 May 2014 (UTC)
The vcite templates could be updated [or a new set of m(edical)cite templates created] to use the CS1 module and the parent template could parse the contents of the author parameter to create internal "first1, last1, first2, last2, ..." and if necessary "authorlinkn" parameters that would be passed onto the CS1 module producing clean author metadata (see {{vcite2 journal}} for a prototype that does not as yet contain the author parameter parser). Boghog (talk) 03:01, 15 May 2014 (UTC)
Could possibly be done. Parsing names in the parent template would, I think, have the same sort of limitations that we have with the {{citation/core}} templates: you can't pass something to a template unless the template is preconfigured to receive it.
Given Vancouver's strict naming conventions (apparently there are two), it should be possible to reliably extract names for COinS (though as I wrote elsewhere, I would prefer to not have to do that). Detecting improperly formatted names should also be possible so that error messages could alert editors to malformed names. Date validation would need to be modified to validate Vancouver-style dates in the {{vcite}} templates. I'm sure that there are other peculiarities I haven't discovered.
{{vcite journal}} does have quite a few unique parameters that aren't supported by CS1, for example the dot versions of several parameter names, the |xxxphrase= parameters, etc. Are these necessary? Are they used in current {{vcite}} templates? What is the list of all things where the {{vcite}} templates differ from CS1 templates? Are all of these differences required?
Trappist the monk (talk) 12:57, 15 May 2014 (UTC)
The dot parameters are used to suppress double periods, a feature already incorporated into the CS1 module. If updated, these should be converted to non dot parameters. I don't understand the 'xxxphrase' parameters. --  Gadget850 talk 13:36, 15 May 2014 (UTC)
In my opinion, all of the dot and xxxphrase parameters could be dispensed with. I also don't think we need special date handling. The only difference between the standard cite and the proposed mcite templates is the way the author parameter is processed and a change in the default settings for a few of the other parameters (e.g., authorformat, author-separator, and author-name-separator). All other parameters would be identical. Please note that the rendered citation would be a hybrid between Vancouver system authors and the CS1 style for everything else. Boghog (talk) 14:11, 15 May 2014 (UTC)

The vcite templates do not have strict naming conventions because institutional authors are allowed. seem my post to the #Authors and COinS thread at 15:35, 15 May 2014 (UTC). Jc3s5h (talk) 15:46, 15 May 2014 (UTC)

See Template:Vcite journal#Authors where there is this (excerpt):
... Spell out organizational authors, and separate them from other authors with semicolons. ... Some examples:
  • ...
  • Smith RC Jr, Jones B III, Barney MR Jr; American College of Academics
This form doesn't seem to be supported by the Vancouver System; fifth bullet point which see.
Trappist the monk (talk) 16:30, 15 May 2014 (UTC)
That would be part of the problem: the editors are being directed to separate authors with semicolons, where this is what the template should be doing as part of the display formatting. Different citation templates vary in how they display a citation, and perhaps in other functionality, but there should not be variance in how the bibliographic details are coded. ~ J. Johnson (JJ) (talk) 21:54, 15 May 2014 (UTC)
@J. Johnson:, that is a brand new proposal. I am not aware of any statement in any Wikipedia policy or guideline that citation templates should not vary in how bibliographic details are coded. Not only is there no such statement, there isn't even clear where such a statement could be made. (Just to clarify, by "citation template" I mean each citation template in Category:Citation templates including subcategories, and all the citation templates that will be added to that category in the future. Jc3s5h (talk) 22:11, 15 May 2014 (UTC)
Proposal? I wasn't aware of making any. That there should not be any variance in coding (entering) bibliographic details follows from two points. 1) The details don't change (aside from abbreviation or capitalization) in respect of either data ("Smith") or character ("last1") in different "styles" or templates. 2) Identical parameters used across similar templates should be used consistently because that avoids confusion and error. E.g., we don't requires titles to be enclosed in quotation marks in one template, but spaces replaced with underscores in another template. ~ J. Johnson (JJ) (talk) 22:34, 15 May 2014 (UTC)
No need to support Vancouver citation style; it conflicts with MOS too much and is hard to parse for anyone not steeped in it (meanwhile, no one has any trouble parsing "Garcia, Xavier B.; Jones, A. M." just because they're also familiar with "Garcia XB, Jones AM").  — SMcCandlish ¢ ≽ʌⱷ҅ʌ≼  22:54, 16 May 2014 (UTC)
It is not at all clear that the MOS applies to citations. However, if it does, per:

Only use initials in a personal name if the name is commonly written that way.
— MOS:ABBR

which in turn refers to:

Generally, use the most common format of a name used in reliable sources: if that is with a middle name or initials, make the Wikipedia article title conform to that format.
— Wikipedia:Naming_conventions_(people)#Middle_names_and_initials

Reliable sources (e.g., biomedical journals) as well as databases such as PubMed more often than not use author and journal abbreviations. In addition, many of these journals follow the Vancouver system. Hence the MOS would not only permit the use of abbreviations in citations, but would seem to encourage it.
Also "Garcia XB, Jones AM" is cleaner and easier to read than "Garcia, Xavier B.; Jones, A. M.". As long as citations within an article are consistently formatted (as encouraged by WP:CITEVAR), no one will have any problem parsing these authors, even if they are abbreviated. Boghog (talk) 08:51, 17 May 2014 (UTC)
In these contexts, WP:SSF is sometimes used as a counter argument. However I think it is important to point out that SSF is an essay and not a guideline. I agree that many of points in this essay are reasonable common sense suggestions when applied to the prose of an article, however as with MOS, it is not clear that SSF would apply to citations and even if it did, it is not clear that it would specifically advise against the Vancouver system. The Vancouver system author format is easy to parse, even for a nonspecialist. Boghog (talk) 09:44, 17 May 2014 (UTC)

Imzadi: What do you mean by "if you want to use Vancouver style, you use vcite * templates"?

It seems to me the only reason people use vcite is because they are in love with the "initials condensed together" of the Vancouver system. But this can be done with the other templates, so why are vcite templates necessary? ~ J. Johnson (JJ) (talk) 21:28, 18 May 2014 (UTC)

@Imzadi1979: or anyone else: what do the {{vcite}} templates do that can't be done with any other citation template?

They produce the author format used in the Vancouver system without going against the documentation present at Help:Citation Style 1. Jc3s5h (talk) 21:51, 20 May 2014 (UTC)
By "author format" do you mean the condensed abbreviations (e.g. "Jones, AM")? How is this in any way precluded in CS1? ~ J. Johnson (JJ) (talk) 23:11, 20 May 2014 (UTC)
Help:Citation style 1#Authors indicates authors should be separated with semicolons, while vcite separates them with commas. The parameters needed to make CS1 templates act like vcite templates are described in Help:Citation style 1#Display options, with the description "These features are not often used, but can customize the display for use with other styles." Jc3s5h (talk) 23:32, 20 May 2014 (UTC)
According to Help:Citation_style_1#Style, for a template to be "CS1 compliant", it must [display] a semicolon as a punctuation mark to separate authors and editors. Setting | authorformat = vanc | author-separator=, | author-name-separator =   will cause the template to display the authors in Vancouver style. This is neither prohibited nor goes against the documentation (or why would these documented parameters exist in the first place?). Boghog (talk) 05:56, 21 May 2014 (UTC)
The citation templates evolved; they were not designed as a coherent set. It is only in the last two years or so they have been viewed as making up a style. There are parameters that are left over from the days when they were viewed as a toolkit rather than as a style. I believe authorformat, author-separator, and author-name-separator are left-over parameters that are retained so that existing instances of those parameters can still be displayed. Jc3s5h (talk) 12:15, 21 May 2014 (UTC)
These parameters are actively maintained and their continued use is consistent with WP:CITESTYLE. Boghog (talk) 18:45, 21 May 2014 (UTC)
Help:Citation style 1#Authors says nothing about semi-colons, or how authors' names are separated, neither is nor ought. As Boghog shows, Help:Citation style 1#Style says that a template must use semicolons in order to be compliant with CS1. But the question here is whether other templates can, or cannot, be used in a manner compliant with Vancouver system. And it seems clear that they can: vcite templates are not needed in order to use Vancouver style. To answer Andy's question: it appears there is no need to keep the vcite templates. ~ J. Johnson (JJ) (talk) 22:28, 21 May 2014 (UTC)

Should the question of whether there is any need for the vcite templates be raised in an RfC? ~ J. Johnson (JJ) (talk) 21:57, 1 June 2014 (UTC)

RFC: Citation Style 1 parameter naming convention[edit]

Closing per a WP:ANRFC request.
There is a clear consensus for this proposal. @Trappist the monk: feel free to implement it. Armbrust The Homunculus 08:35, 7 July 2014 (UTC)

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

All parameter names in Citation Style 1 templates shall include at least an alias which is in lowercase that has separations with hyphens between English words, between (not within) acronyms, or between English words and acronyms. The documentation is to show this lowercase, hyphenated version as the one for "normal use". This is to establish a parameter name format that is uniformly available for all CS1 templates. Establishing this uniform parameter name convention does not preclude the existence of any other alias for a parameter, merely that a lowercase, hyphenated version will exist for each parameter.—D'Ranged 1 VTalk 22:10, 24 May 2014 (UTC); Reworded to make it more clear that this proposal is not to eliminate any current version of a parameter. — Makyen (talk) 22:50, 24 May 2014 (UTC)

I added this RFC to Wikipedia:Requests for comment/Wikipedia technical issues and templates, Wikipedia:Village pump (technical), and Wikipedia:Village pump (proposals) in an effort to gain more input.—D'Ranged 1 VTalk 20:12, 3 June 2014 (UTC)

Survey[edit]

(Please only indicate Support or Oppose here, with discussion in the section below.)

  • Support to add consistency to this area of Wikipedia.—D'Ranged 1 VTalk 22:10, 24 May 2014 (UTC)
  • Support This will significantly reduce editor confusion. They don't have to think about: "Is this the parameter where the words are mushed together, or is it one where they are separated by an '_' ?" Hopefully this will make the templates easier to use. — Makyen (talk) 23:10, 24 May 2014 (UTC)
  • Support—for the reasons concerning editor confusion above. (I will note that a formal RfC feels a bit like overkill in this situation.) Imzadi 1979  00:05, 25 May 2014 (UTC)
I agree that it feels like overkill. I think that it appeared there are multiple discussions about parameters and parameter names which are ongoing, or have occurred recently here, Module talk:Citation/CS1‎, and/or at Template talk:Citation. While the discussions have not specifically been about this issue, the other discussions regarding parameter names have ended with little resolution, or appeared settled only to be brought up again weeks or months later. This issue, feels to me like one which should be not that controversial, has significant benefit to editors at large, and is something which we can have as an agreed upon basic property of CS1 templates which might make them feel a bit more like a whole rather than pieces – becoming more of a whole has been the general trend in direction for some time now. Given the contentious nature of other parameter and parameter name issues, I think it is good to move forward with this. — Makyen (talk) 05:30, 25 May 2014 (UTC)
  • Support This is a good step to making the CS1 templates more consistent with one another. I will help in changing the documentation if this is approved and implemented. – Jonesey95 (talk) 15:53, 27 May 2014 (UTC)
  • Support Consistency is the way forward. Clear communication and documentation is important too. -- 79.67.241.215 (talk) 16:44, 27 May 2014 (UTC)
  • Support for the reasons already stated. --Mirokado (talk) 20:35, 3 June 2014 (UTC)
  • Support. This is a good idea. The naming convention is currently rather arbitrary, and this will help to dispel the resulting confusion. NinjaRobotPirate (talk) 00:15, 5 June 2014 (UTC)

Discussion[edit]

Citation Style 1 parameter names are now a mix of CamelCase, mergedwords, and words separated by spaces, hyphens, or underscores. Remembering which style applies to what parameter name is frustrating; all parameter names should follow the same style so that an editor intuitively knows how to enter the parameter name. Most names are lower-case, hyphenated names, or have an alias that is, but not all. Adopting a naming convention will ensure that all current and future parameter names create less confusion and easier editing for editors.—D'Ranged 1 VTalk 22:10, 24 May 2014 (UTC)

(edit conflict) I have made changes to this RfC to make it more clear that it is only intended to establish that the lowercase, hyphenated version exist for all parameters and not exclude the existence of other versions. I was in the process of writing such as an original RfC when I found there was an edit conflict. — Makyen (talk) 22:50, 24 May 2014 (UTC)
The list of parameter names currently used in Citation Style 1 templates may be found at Module:Citation/CS1/Whitelist.—D'Ranged 1 VTalk 23:17, 24 May 2014 (UTC)

I don't object to this concept, but I think it should be reworded to forbid bots from changing from the hyphenated version of a parameter name to an earlier version of the name, and the RFC be advertised at appropriate bot-related talk pages. Otherwise we will have warring bots. Jc3s5h (talk) 16:04, 25 May 2014 (UTC)

I feel that is a question for another time. There is nothing in this RfC which implies that there will be bots changing parameter names in citations already in articles.
Very specifically, the only thing this RfC covers is that templates, to be compliant with Citation Style 1, will have at least an alias for every parameter which is entirely in lowercase with any words/acronyms separated by hyphens, and that the documentation for the template will use those versions of the parameters as "primary". If the person writing the template also wants to have a |TrANs__tITle= for |trans-title= that is not excluded by this RfC. I hope that it is not done, but it is not excluded. The goal of the RfC is to have at least one consistent style of parameter names across all of CS1 so that editors of enwiki do not have to guess at what parameter name style happens to be used in a particular template, or for a specific parameter within a template.
This RfC is very much not intended to be the end-all be-all of deciding what parameters or aliases will exist for CS1 templates. It is intended to require the existence a set of parameters which are harmonized with respect to parameter name format across CS1.
There are, obviously, other issues with respect to parameters and parameter names. That is clear from the fact that there have been running conversations about such for a long time. There is no single solution to all the issues. What the solution is for every individual issues is not something that should be covered in an RfC at this time.
BTW: Given that you have raised this concern, are there bots that you are aware of which are going through and changing parameters from one valid parameter alias to another? I know that |coauthors=, etc. are being changed due to those parameters being deprecated, but I don't recall any bot going through and specifically changing other parameters. — Makyen (talk) 01:37, 26 May 2014 (UTC)
@Makyen:I have seen a bot change a parameter of the form "date = 2010" to "year = 2010", but I did not make a note of which bot it was or which article(s) were edited. Jc3s5h (talk) 15:11, 26 May 2014 (UTC)
Mr Stephen used AWB to change |date= to |year= here on May 17. I seem to recall that this was discussed and that AWB users were to stop doing it, but I don't remember when that took effect.—D'Ranged 1 VTalk 15:39, 26 May 2014 (UTC)
An AWB script was also swapping |trans-title= over to |trans_title= for a long time. That process was recently halted. -- 79.67.241.215 (talk) 14:52, 27 May 2014 (UTC)
@Jc3s5h, D'Ranged 1: If this suggestion is enabled, Wikipedia:AutoWikiBrowser/Rename template parameters#Citation templates will need to be updated so bots do not make unnecessary replacements. Also, the AWB functionality to change "date = 2010" to "year = 2010" was removed last month (see Wikipedia talk:AutoWikiBrowser/Archive 27#Cite book date - Year) and a new version was pushed out to all AWB users around May 18. GoingBatty (talk) 15:45, 26 May 2014 (UTC)
GoingBatty Thank you. It would appear that the change occurred just prior to the push-out. I had already thought of how this would affect AWB users; I'll make sure the proper steps are taken to avoid conflict/confusion in the event the RFC succeeds. Thanks again!—D'Ranged 1 VTalk 15:50, 26 May 2014 (UTC)
@D'Ranged 1: Thanks for thinking about the AWBers. When this RfC is concluded, it would be very helpful to have a complete list of valid parameters for each of the citation templates. Thanks! GoingBatty (talk) 15:59, 26 May 2014 (UTC)
There's a complete list of parameter names at: Module:Citation/CS1/Whitelist and this page (Module:Citation/CS1/Suggestions) might also be useful. Additionally Citation Bot has its own list of parameters here (User:Citation_bot/parameters) -- 79.67.241.215 (talk) 07:19, 27 May 2014 (UTC)
When mentioning any kind of module code to people who are not actively engaged in writing code for the module, it is necessary to give sufficient context so it can be understood. If these modules are to be mentioned to non-programmers on a regular basis, such context should be provided in comments in the code. In this case, it is unclear if the parameters represent parameters that may be present in an instance of cite xxx, parameters that are passed from the cite xxx template to the Lua module, or parameters used witin the Lua module. Jc3s5h (talk) 14:15, 27 May 2014 (UTC)
Having been mentioned by name, perhaps someone could point me at the discussion in question. For the avoidance of doubt, I am not a bot. Mr Stephen (talk) 18:35, 26 May 2014 (UTC)
@Mr Stepehen: As I stated above, the discussion was at Wikipedia talk:AutoWikiBrowser/Archive 27#Cite book date - Year. GoingBatty (talk) 19:26, 26 May 2014 (UTC)
@Mr Stephen: The edit you made here changed a citation made with {{cite book}} so that a parameter that read "date = 2011" (which is perfectly valid) to "year = 2011". It seems likely this was made with AWB and you didn't notice it, or didn't realize the change was inadvisable. AWB has since been fixed. Jc3s5h (talk) 19:32, 26 May 2014 (UTC)
If date = 2011 is perfectly valid, then consensus has changed. I will read the discussion. Mr Stephen (talk) 19:40, 26 May 2014 (UTC)
It appears that it has indeed changed. Not my idea of an improvement, but it's done. I will fix my code, but I have multiple scripts that I pull up according to the task in hand; should anyone see me living in the past, give me a nudge. Mr Stephen (talk) 19:48, 26 May 2014 (UTC)
About a month ago, I suggested starting an "Advisories" page (discussed here: Help_talk:Citation_Style 1/Archive 4#CS1 Advisories) to cover exactly this type of situation. -- 79.67.241.215 (talk) 14:48, 27 May 2014 (UTC)

Conclusion / Action needed[edit]

There seems to be consensus to implement this. In order to do so, the following parameter names need to be added to the Whitelist and recognized as valid aliases by the templates:

  • ['access-date']
  • ['air-date']
  • ['book-title']
  • ['call-sign']
  • ['chapter-link']
  • ['dead-url']
  • ['doi-broken']
  • ['doi-broken-date']
  • ['doi-inactive-date']
  • ['editor-given']
  • ['editor-surname']
  • ['episode-link']
  • ['event-url']
  • ['last-author-amp']
  • ['lay-date']
  • ['lay-source']
  • ['lay-summary']
  • ['lay-url']
  • ['no-cat']
  • ['no-pp']
  • ['orig-year']
  • ['p-prefix']
  • ['pp-prefix']
  • ['section-url']
  • ['series-link']
  • ['series-no']
  • ['series-number']
  • ['subject-link']
  • ['template-doc-demo']
  • ['time-caption']
  • ['title-link']

And numbered_arguments:

  • ['subject-link#']
  • ['subject#link']
  • ['subject#-link']

Once this is done, I will notify the AWB users of the additions so that valid parameter names aren't mistakenly "corrected". I will then undertake updating the documentation on the templates.

Would someone with the ability to make the necessary changes please do so? Thanks!—D'Ranged 1 VTalk 22:07, 30 June 2014 (UTC)

You can add these to Module:Citation/CS1/Whitelist/sandbox.Yes check.svg Done You can also make the appropriate changes to Module:Citation/CS1/Configuration/sandboxYes check.svg Done if you feel comfortable doing that. Be sure that you test each addition so that we know that you haven't broken anything and to prove that the new parameters work. I am planning to be more available within the next week or so and want to update the live version of the module with all of the changes that have lain dormant for the past month and more.
Trappist the monk (talk) 23:17, 30 June 2014 (UTC)
Update Trappist the monk FYI, I will work on test cases next; I'm not shirking that task; it's just very involved and will take some time. Thanks!—D'Ranged 1 VTalk 22:56, 1 July 2014 (UTC)
Take what time you need. I'm in no hurry.
Trappist the monk (talk) 23:25, 1 July 2014 (UTC)
[removed earlier post] I'm told there's an infinite loop occurring within the module; my earlier post is irrelevant.—D'Ranged 1 VTalk 18:13, 3 July 2014 (UTC)

The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.


RefToolbar adding duplicate " ed."[edit]

This subject was brought up previously, but was abandoned. Now it's been archived. The problem occurs when using RefToolbar's auto-fill ISBN feature on {{cite book}}:

  • {{cite book |first1=Ian H. |last1=Witten |first2=David |last2=Bainbridge |first3=David M. |last3=Nichols |title=How to build a digital library |date=2010 |isbn=978-0-12-374857-7 |publisher=Morgan Kaufmann Publishers |location=Amsterdam |edition=2nd ed.}}:
Witten, Ian H.; Bainbridge, David; Nichols, David M. (2010). How to build a digital library (2nd ed. ed.). Amsterdam: Morgan Kaufmann Publishers. ISBN 978-0-12-374857-7. 

RefToolbar extracts the data, which includes the " ed." text, and inserts it into the template. When parsed, the template adds another " ed." to the end of |edition=. What is the best way to proceed to fix the problem? Should we ask Mr.Z-man to alter the RefToolbar gadget? Is there a way to programmatically have the template replace an instance of " ed. ed." with " ed."? Or should we just rely on editors to remove the " ed." from the gadget before inserting it into the article? Since many will miss it, this should be on the replacement list for many bots, I would think; it may already be. Any ideas for next steps to fix this?—D'Ranged 1 VTalk 21:24, 4 June 2014 (UTC)

Second request. Could someone please address this issue? I fear it's headed for the archives again with no action taken. Thanks!—D'Ranged 1 VTalk 01:11, 1 July 2014 (UTC)

Template: cite interview incorrect formatting[edit]

I originally thought this was a simple fix; upon further investigation and testing, it's more complicated than what was in my protected edit request above.

Wikipedia:Manual of Style#Titles states:

Use italics for the titles of ... television series .... The titles of ... television episodes ... are not italicized; they are enclosed in double quotation marks.

Here is how the current {{cite interview}} template formats a citation including both |program= and |title= data:

  • {{cite interview |first1=John |last1=Kerry |subjectlink1=John Kerry |title=The Secretary of State |date=September 29, 2013 |interviewer=[[Scott Pelley|Pelley, Scott]] |program=60 Minutes |accessdate=June 6, 2014 |url=http://www.cbs.com/shows/60_minutes/video/O4kO1ksZbGQoGMPNL_8BQ_PoNNrL5EQD/the-secretary-of-state-imminent-danger-killing-jesus/ |publisher=CBS}}
Kerry, John (September 29, 2013). The Secretary of State. Interview with Pelley, Scott. CBS. 60 Minutes. Retrieved June 6, 2014. 

Here is the additional formatting needed within the current template to make it display properly:

  • {{cite interview |first1=John |last1=Kerry |subjectlink1=John Kerry |title=''"The Secretary of State"'' |date=September 29, 2013 |interviewer=[[Scott Pelley|Pelley, Scott]] |program=''60 Minutes'' |accessdate=June 6, 2014 |url=http://www.cbs.com/shows/60_minutes/video/O4kO1ksZbGQoGMPNL_8BQ_PoNNrL5EQD/the-secretary-of-state-imminent-danger-killing-jesus/ |publisher=CBS}}
Kerry, John (September 29, 2013). "The Secretary of State". Interview with Pelley, Scott. CBS. 60 Minutes. Retrieved June 6, 2014. 

Here is how the current {{cite interview}} template formats a citation which only has |program= data:

  • {{cite interview |first1=John |last1=Kerry |subjectlink1=John Kerry |date=September 29, 2013 |interviewer=[[Scott Pelley |Pelley, Scott]] |program=60 Minutes |accessdate=June 6, 2014 |url=http://www.cbs.com/shows/60_minutes/video/O4kO1ksZbGQoGMPNL_8BQ_PoNNrL5EQD/the-secretary-of-state-imminent-danger-killing-jesus/ |publisher=CBS}}
Kerry, John (September 29, 2013). Interview with Pelley, Scott. CBS. 60 Minutes http://www.cbs.com/shows/60_minutes/video/O4kO1ksZbGQoGMPNL_8BQ_PoNNrL5EQD/the-secretary-of-state-imminent-danger-killing-jesus/. Retrieved June 6, 2014.  Missing or empty |title= (help)

Note that in addition to the error message, data in |url= is rendered as a raw URL. I have updated the template documentation to indicate that |title= is required; however, ideally, this is how the template would function:

  1. Start by requiring either |title= or |program=; eliminate the error message when |program= is populated but |title= is not.
  2. If both |program= and |title= are populated, italicize |program= and wrap |title= in quotation marks; if |url= is populated, map it to |title=.
  3. If only |title= is populated, assume it is the name of the show/series, not the episode, and italicize it; if |url= is populated, map it to |title=.
  4. If only |program= is populated, italicize it; if |url= is populated, map it to |program=.

Can this be done?—D'Ranged 1 VTalk 04:00, 6 June 2014 (UTC)

(I have numbered the items above for easy reference.) I agree with items 2 and 4 above.
As for item 1, I agree with eliminating the error message, since some programs do not name their episodes. I don't know that requiring either |title= or |program= is necessary unless |url= is present. In that case, one or the other should be required.
I think item 3 is not needed and would lead to confusion. This would essentially treat |title= as an alias of |program= in some cases; we have other cite templates like this (encyclopedia comes to mind), and they are very confusing. I'd rather see |title= in quotation marks always and just let editors change |title= to |program= if it makes sense to do so. – Jonesey95 (talk) 05:15, 6 June 2014 (UTC)
I read the documentation for the template, and it says it is "used to create citations for published or broadcast interviews." So we are really in the same quagmire as {{Citation}}, trying to figure out from the parameters supplied whether the medium of the publication is a book, magazine article, broadcast, or whatever. I think it would be better to deprecate "cite interview" and add interviewers template to other templates. Jc3s5h (talk) 12:36, 6 June 2014 (UTC)
I agree with Jonesey95, and would further suggest that if both |title= and |program= are empty but |url= is supplied, that it map to "Interview with", which the template automatically generates unless |type= is supplied; in that case, the URL could map to the value in |type=. This would avoid another error message.
  • {{cite interview |first1=John |last1=Kerry |subjectlink1=John Kerry |first2=Hillary |last2=Clinton |subjectlink1=Hillary Clinton |type=Round-table discussion |date=September 29, 2013 |interviewer=[[Scott Pelley|Pelley, Scott]]; [[Morley Safer|Safer, Morley]] |accessdate=June 6, 2014 |url=http://www.cbs.com/shows/60_minutes/video/O4kO1ksZbGQoGMPNL_8BQ_PoNNrL5EQD/the-secretary-of-state-imminent-danger-killing-jesus/ |publisher=CBS}} could display as:
Kerry, John; Clinton, Hillary (September 29, 2013). Round-table discussion with Pelley, Scott; Safer, Morley. CBS. Retrieved June 6, 2014.
I disagree with Jc3s5h; surely it would be less confusing to editors to add an identifying parameter to {{cite interview}} (perhaps |source=?) than to fold additional parameters into {{cite book}}, {{cite news}}, and {{cite web}}?—D'Ranged 1 VTalk 00:01, 7 June 2014

──────────────────────────────────────────────────────────────────────────────────────────────────── To summarize, here's what seems to need consensus:

  1. Eliminate the error message when |program= is populated but |title= is not.
  2. If both |program= and |title= are populated, italicize |program= and wrap |title= in quotation marks; if |url= is populated, map it to |title=.
  3. If only one of |program= or |title= are populated and |url= is populated, map it to the populated parameter.
  4. Either:
    1. require either |program= or |title= only if |url= is populated (error message generated)
          or
    2. if neither |program= nor |title= is populated and |url= is populated, map |url= to the default text "Interview with" or the value of |type= (no error message).

Further comments? This seems to have stalled; I'd like to get it resolved and implement whatever conclusion is reached. Thanks!—D'Ranged 1 VTalk 23:05, 30 June 2014 (UTC)

Transcript parameter for cite podcast[edit]

Can a parameter for linking to a transcript be added to Template:Cite podcast?-- Brainy J ~~ (talk) 16:01, 13 June 2014 (UTC)

We already have |transcript-url= in the CS1 module, but it appears that it is not currently used in any citations that use the CS1 module for rendering (I could be wrong). It is used in {{cite serial}} and {{cite episode}}, but those still use the old citation/core code. Adding it to cite podcast should be straightforward but would take some new code. Let's see if it works already:
Cite podcast compare
{{ cite podcast | host=Jack Handey | title=Deep Thoughts with Jack Handey, episode 123 | transcript=Episode 123 transcript | transcript-url=http://www.deepthoughts.org/podcast/123/transcript | url=http://www.deepthoughts.org/podcast/123 }}
Old Jack Handey. "Deep Thoughts with Jack Handey, episode 123" (Podcast). http://www.deepthoughts.org/podcast/123.
Live Jack Handey. "Deep Thoughts with Jack Handey, episode 123" (Podcast). 
Sandbox Jack Handey. "Deep Thoughts with Jack Handey, episode 123" (Podcast). 
No, it looks like it doesn't work yet. – Jonesey95 (talk) 19:41, 13 June 2014 (UTC)
  1. What is the purpose of local TranscriptAssemble?
  2. Shouldn't we first find out why terminal punctuation isn't present before hard coding the terminal period in the way that you have done it here?
  3. Do you have test cases that show that your changes do no harm when |transcript-url= is missing or empty?
Trappist the monk (talk) 23:24, 1 July 2014 (UTC)

────────────────────────────────────────────────────────────────────────────────────────────────────I've tried again; I've corrected the needed modifications and included testcases below. The test citation template is {{cite podcast/sandbox2}}, which invokes the modified Module:Citation/CS1/sandbox4, which calls the modified Module:Citation/CS1/Configuration/sandbox3. The only change in the configuration module not documented below is that Module:Citation/CS1/sandbox4 calls Module:Citation/CS1/Configuration/sandbox3 under function z.citation(frame) rather than Module:Citation/CS1/Configuration/sandbox. (I was loathe to edit existing sandboxes for fear of disrupting other testcases; I don't know what standard practice is with regard to the sandboxes.)

Two parts of Module:Citation/CS1 need to be modified:

Line numbers 1817–1821

Currently:

   if is_set(Transcript) then
       if is_set(TranscriptURL) then Transcript = externallink( TranscriptURL, Transcript ); end 
   elseif is_set(TranscriptURL) then 
       Transcript = externallink( TranscriptURL, nil, TranscriptURLorigin ); 
   end

Proposed modification: (I added some additional line breaks to make the code more readable.)

   if is_set(Transcript) then 
       if is_set(TranscriptURL) then 
           Transcript = sepc .. " " .. externallink( TranscriptURL, Transcript ); 
       else 
           Transcript = sepc .. " " .. seterror('transcript_missing_url'); 
       end 
   elseif is_set(TranscriptURL) then
       Transcript = sepc .. " " .. seterror('transcripturl_missing_transcript'); 
   else 
       Transcript = ""; 
   end
Line number 1906

Currently:

   local idcommon = safejoin( { ID_list, URL, Archived, AccessDate, Via, SubscriptionRequired, Lay, Quote }, sepc ); 

Proposed modification:

   local idcommon = safejoin( { ID_list, URL, Archived, AccessDate, Via, Lay, Transcript, Quote, SubscriptionRequired }, sepc ); 

Additionally, Module:Citation/CS1/Configuration will need two new error messages in the citation_config.error_conditions section. I don't know what determines whether an error message is hidden or not; I would think these should always show, but I could be mistaken. Note that the category called by the errors doesn't currently exist; if it shouldn't be created, please comment out the category name. (I personally see no harm in having a new error category; it is not likely to ever have very many pages in it, but would be useful in tracking this particular error.) Please let me know if I need to create the category.

Proposed insertion after line 364
   transcript_missing_url = { 
        message = '<code>&#124;transcript=</code> requires <code>&#124;transcript-url=</code>', 
anchor = 'transcript_missing_url',
category = 'Pages with transcripturl citation errors',
hidden = false },
   transcripturl_missing_transcript = { 
        message = '<code>&#124;transcript-url=</code> requires <code>&#124;transcript=</code>', 
anchor = 'transcripturl_missing_transcript',
category = 'Pages with transcripturl citation errors',
hidden = false },

To answer the questions above:

  1. I don't know the purpose of local TranscriptAssemble; it was present in the sandbox I edited; it is no longer part of the proposed modifications.
  2. The terminal punctuation was a flaw in the sandbox I was using. "Clean" sandboxes, with the changes above, eliminate this error.
  3. Here are the testcases:
    1. Includes both |transcript-url= and |transcript= with data in both:
      {{cite podcast/sandbox2 |title=Deep Thoughts with Jack Handey, episode 123 |host=Jack Handey |url=http://www.deepthoughts.org/podcast/123 |transcript-url=http://www.deepthoughts.org/podcast/123/transcript |transcript=Episode 123 transcript}}
      Jack Handey. "Deep Thoughts with Jack Handey, episode 123" (Podcast). Episode 123 transcript. 
    2. Omits both |transcript-url= and |transcript=:
      {{cite podcast/sandbox2 |title=Deep Thoughts with Jack Handey, episode 123 |host=Jack Handey |url=http://www.deepthoughts.org/podcast/123}}
      Jack Handey. "Deep Thoughts with Jack Handey, episode 123" (Podcast). 
    3. Both |transcript-url= and |transcript= are present but empty:
      {{cite podcast/sandbox2 |title=Deep Thoughts with Jack Handey, episode 123 |host=Jack Handey |url=http://www.deepthoughts.org/podcast/123 |transcript-url= |transcript=}}
      Jack Handey. "Deep Thoughts with Jack Handey, episode 123" (Podcast). 
    4. Only |transcript= is present, but empty:
      {{cite podcast/sandbox2 |title=Deep Thoughts with Jack Handey, episode 123 |host=Jack Handey |url=http://www.deepthoughts.org/podcast/123 |transcript=}}
      Jack Handey. "Deep Thoughts with Jack Handey, episode 123" (Podcast). 
    5. Only |transcript-url= is present, but empty:
      {{cite podcast/sandbox2 |title=Deep Thoughts with Jack Handey, episode 123 |host=Jack Handey |url=http://www.deepthoughts.org/podcast/123 |transcript-url=}}
      Jack Handey. "Deep Thoughts with Jack Handey, episode 123" (Podcast). 
    6. Both parameters are present; however, only |transcript= is populated; |transcript-url= is empty. This now emits an error message:
      {{cite podcast/sandbox2 |title=Deep Thoughts with Jack Handey, episode 123 |host=Jack Handey |url=http://www.deepthoughts.org/podcast/123 |transcript-url= |transcript=Episode 123 transcript}}
      Jack Handey. "Deep Thoughts with Jack Handey, episode 123" (Podcast). |transcript= requires |transcript-url= (help). 
    7. Only |transcript= is present and populated; |transcript-url= is not present. This now emits an error message:
      {{cite podcast/sandbox2 |title=Deep Thoughts with Jack Handey, episode 123 |host=Jack Handey |url=http://www.deepthoughts.org/podcast/123 |transcript=Episode 123 transcript}}
      Jack Handey. "Deep Thoughts with Jack Handey, episode 123" (Podcast). |transcript= requires |transcript-url= (help). 
    8. Both parameters are present; however, only |transcript-url= is populated; |transcript= is empty. This now emits an error message:
      {{cite podcast/sandbox2 |title=Deep Thoughts with Jack Handey, episode 123 |host=Jack Handey |url=http://www.deepthoughts.org/podcast/123 |transcript-url=http://www.deepthoughts.org/podcast/123/transcript |transcript=}}
      Jack Handey. "Deep Thoughts with Jack Handey, episode 123" (Podcast). |transcript-url= requires |transcript= (help). 
    9. Only |transcript-url= is present and populated; |transcript= is not present. This now emits an error message:
      {{cite podcast/sandbox2 |title=Deep Thoughts with Jack Handey, episode 123 |host=Jack Handey |url=http://www.deepthoughts.org/podcast/123 |transcript-url=http://www.deepthoughts.org/podcast/123/transcript}}
      Jack Handey. "Deep Thoughts with Jack Handey, episode 123" (Podcast). |transcript-url= requires |transcript= (help). 

I'm not adept at coding in Lua; I had hoped that someone with more knowledge would springboard off what I had discovered and make any further changes needed to comply with the rest of the template coding. I was trying to help move the process along; I hope this is enough to get the changes made with any additional modifications known to be needed by someone who's adept at this! I'm learning as I go; hopefully, I'll keep getting better at it. (I have experience in other coding languages; Lua/Scribunto is not among them; I've bookmarked the relevant reference manual.) Thanks!—D'Ranged 1 VTalk 11:33, 2 July 2014 (UTC)

I've been wondering if idcommon is the correct location of the transcript text. It seems reasonable to assume that the podcast could be archived, could require a subscription (which might make the use of |quote= desirable) would then make this:
Jack Handey. "Deep Thoughts with Jack Handey, episode 123" (Podcast). Archived from the original on 2014-07-02. Episode 123 transcript. "Quoted text.". (subscription required (help)) 
{{cite episode}} places the transcript after |series= by using {{citation/core}} parameter |Other= (|others=). Perhaps something similar should be considered for {{cite podcast}}. Here I've used |others=[http://www.deepthoughts.org/podcast/123/transcript Episode 123 transcript] to mimic the positioning used by {{cite episode}}:
Jack Handey. "Deep Thoughts with Jack Handey, episode 123" (Podcast). Episode 123 transcript. Archived from the original on 2014-07-02. "Quoted text.". (subscription required (help)) 
As an aside, I'm thinking that the position of the subscription note should be moved so that it is the last thing rendered in the citation.
Trappist the monk (talk) 14:10, 2 July 2014 (UTC)
I agree with moving subscription to the end; I've done so and your example above parses better. Below is an example testing the use of |registration= rather than |subscription= to ensure that it also falls at the end of the citation:
Jack Handey. "Deep Thoughts with Jack Handey, episode 123" (Podcast). Episode 123 transcript. Archived from the original on 2014-07-02. "Quoted text.". (registration required (help)) 
As for the placement used by {{cite episode}}; I dislike that the archive information appears after the transcript; it's less clear what is archived, the podcast, or the transcript?
It occurs to me that the transcript might be archived or require a subscription as well; do we want to go there?—D'Ranged 1 VTalk 16:37, 2 July 2014 (UTC)

Adding a "section" parameter?[edit]

perhaps we should add a section parameter to template:cite book, not all books that will be referenced are separated by "chapters". I feel a little awkward constantly using the chapter parameter when its not really a chapter. Lucia Black (talk) 11:35, 22 June 2014 (UTC)

The rendered citation doesn't indicate that is a chapter, so I don't see a problem, unless you think a section should be formatted differently in the rendered citation than the way a chapter title is rendered. Jc3s5h (talk) 12:15, 22 June 2014 (UTC)
visually? no, but i can see how this affects people when they want to cite a book that doesn't have chapters and they dont know chapters is a viable option. But this could also work for AV media, such as DVD releases that have additional commentary, or other. Lucia Black (talk) 12:17, 22 June 2014 (UTC)
We have the |at= parameter, but bear in mind that it can't be used with |page=, so you could use |at=section 3.2.1, p. 123 --Redrose64 (talk) 12:33, 22 June 2014 (UTC)
I think making a section section is a better choice, or reworking the "at" parameter into a section parameter (that allows page numbers). and i'm looking at template:cite AV media and it doesn't have a section, which makes citing a DVD that much harder. Lucia Black (talk) 12:38, 22 June 2014 (UTC)
Didn't we discuss this recently? --  Gadget850 talk 00:37, 24 June 2014 (UTC)

First time i'm asking for one i believe, anyways, why shouldn't there be a section parameter? it'll make things much easier. Lucia Black (talk) 06:56, 24 June 2014 (UTC)

I believe that {{cite book}} permits use of either |chapter= or |section=, just not both at the same time. They are treated as synonyms, and produce the same textual output, so the difference is really just a matter of internal record. You won't see it unless you look at the wiki source code. Evensteven (talk) 07:22, 24 June 2014 (UTC)
if cite book offers section parameter that's fine, it just needs to recognize its existence in the documentation. But i'm still suggesting that {{cite AV media}} to use sections, which is important for DVD/Blu-ray releases several sections such as commentary and production notes. Lucia Black (talk) 07:34, 24 June 2014 (UTC)
It seems that {{cite AV media}} also permits |section= in place of |chapter=. Yes, the documentation is inadequate. Many of these "cite" templates permit the full range of parameter choices equally - anything that {{citation}} allows. You can pretty much select which of them you want to employ in any individual citation. Evensteven (talk) 10:51, 24 June 2014 (UTC)
there needs to be a cleanup/expansion on these. but thanks for letting me know. Lucia Black (talk) 10:53, 24 June 2014 (UTC)


Proposal: display DOIs as URLs rather than URNs[edit]

The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.
WITHDRAWN - as Gadget850 points out below, when printing, full URLs are output. I didn't know that. Okay then! — Scott talk 12:50, 30 June 2014 (UTC)

Given that in 2011 CrossRef began encouraging the display of DOIs as URLs, why is {{cite journal}} still rendering them as URNs, even if the namespace-specific strings are hyperlinked to the resolver? I believe that we should be following their guidance for best practice, and rendering the DOIs as URLs, which will facilitate research using printed copies of our articles.

Looking at this discussion from 2011, it may be due to the desire to present the string "doi" as an explanatory hyperlink, as with the rendering of PMCs, PMIDs, etc. There are good arguments made in that discussion for the current link-next-to-a-link behavior as being harmful (Kaldari wrote: I often click the wrong one by mistake.), but also the valid point is made that readers may not know what a DOI is. I believe the issue should be reconsidered in the light of CrossRef's guidance. — Scott talk 14:42, 29 June 2014 (UTC)

I agree that we should render the DOIs as URLs and drop the explanatory links (as they will no longer be necessary). URLs are the current standard and much more widely understood. Kaldari (talk) 17:24, 29 June 2014 (UTC)
Can you please give an example of a journal citation as it is rendered now and as you would like to see it? As far as I know, DOIs are rendered as URLs. The DOI in the following citation renders as doi:10.3389/gene.2013.00151 and links to http://dx.doi.org/10.3389%2Ffgene.2013.00151, a URL.
Are you suggesting that it should render as DOI 10.3389/gene.2013.00151? The brief, unconcluded discussion at Help talk:Citation Style 1/Archive 5 may be relevant. – Jonesey95 (talk) 17:52, 29 June 2014 (UTC)
We have always rendered DOI links as URLs. We simply show a doi identifier link before the DOI, just as we show ISBN and the like.  Gadget850 talk 18:06, 29 June 2014 (UTC)
Using the dictionary definition of 'render', the link would be displayed as
http://dx.doi.org/10.3389/gene.2013.00151 within the reference citation. -- 79.67.248.252 (talk) 19:31, 29 June 2014 (UTC)
Yes, as 79.67 says. The current formulation takes the form of a URN, which is the only reason that for the lower-case "doi", as the display rendering is a URN of which "doi" is the namespace. That's inconsistent with the display of other identifiers. To follow best practice guidance, satisfy the needs of print readers, allow better copying, and be consistent with our display of other identifiers, we should be producing "DOI http://dx.doi.org/10.3389/gene.2013.00151". — Scott talk 22:12, 29 June 2014 (UTC)
  • Oppose – I like the current shorter display, and since they link as urls, I don't see any need for change. It is also faster to cite, since ofttimes the source provides the doi without the "leader". (Aside: I still am having problems with JSTOR dois.) --Bejnar (talk) 20:17, 29 June 2014 (UTC)
  • Oppose – The proposal would make rendered citations that contain dois longer. In addition, the proposal would create bare urls which many consider ugly. Finally the argument that CrossRef gave for revising their guideline is “The old format was confusing for users, since it did not automatically become a link in web browsers”. That obviously does not apply to dois in {{cite journal}} templates where the link is created automatically. Boghog (talk) 20:28, 29 June 2014 (UTC)
    • The difference in length between "doi:10.3389/gene.2013.00151" and "http://dx.doi.org/10.3389/gene.2013.00151" is not significant. You selectively quote the least important part of the CrossRef statement, as opposed to This change will allow users to copy permanent CrossRef DOI links from HTML pages to emails, blogs, reference management software and other applications. It's applications other than web browsers where linkification may need to happen, or even simply places where humans enter URLs by hand, such as from print, an issue which I raised and you do not address in your comment. Also, "which many consider ugly" is weasel words and "I don't like it" in one. You'll also notice that virtually all of WP:BAREURLs is about the problem of link rot, which is irrelevant to the DOI resolver system for obvious reasons. — Scott talk 22:12, 29 June 2014 (UTC)
      • The DOI in the above citation is "10.3389/fgene.2013.00151". That's why why list it as the DOI, just as we list ISBNs and PMIDs with only the identifier. I could get behind consistency in display, showing "DOI 10.3389/fgene.2013.00151" instead of "doi:10.3389/fgene.2013.00151", but showing the full URL is redundant, and it is certainly not anything that a reasonable citation style would call for. – Jonesey95 (talk) 23:28, 29 June 2014 (UTC)
        • It's not redundant for print users, and "reasonable" is, once again, pure personal opinion. — Scott talk 09:54, 30 June 2014 (UTC)
  • Oppose – per Boghog. Uglier in articles with a lot of refs. URL encoded URLs for DOIs based on Publisher Item Identifier like doi:10.1016/S0140-6736(12)61728-0 (Lancet) are uglier again. RDBrown (talk) 04:55, 30 June 2014 (UTC)
    • How is http://dx.doi.org/10.1016/S0140-6736(12)61728-0 "uglier" than 10.1016/S0140-6736(12)61728-0? — Scott talk 09:54, 30 June 2014 (UTC)
http://dx.doi.org/10.1016%2FS0140-6736%2809%2960829-1 is an encoded form RDBrown (talk) 12:48, 30 June 2014 (UTC)

Comment – Looks to me like we are already in compliance with the CrossRef guideline. To wit, Option 6 which reads:

Option 6—Display the words "Full Text" or "Article" or something similar with the permanent DOI link behind the text.
Example
Ghosh, M.K., M.L. Harter. 2003. A viral mechanism for remodeling chromatin structure in G0 cells. Mol. Cell. 12:255–260, Article

That same citation using {{cite journal}} is:

Ghosh,, M.K.; Harter, M.L. (July 2003). "A viral mechanism for remodeling chromatin structure in G0 cells.". Molecular Cell 12 (1): 255–260. doi:10.1016/S1097-2765(03)00225-9. 

Here we are complying with the 'something similar [the identifier] with the permanent DOI link behind the text.' The permanent link is available with a right-click > Save link as ... or similar functionality in every browser I have to hand.

As I read the guidelines, there doesn't appear to be any requirement for print versions of articles to use the full URL. In fact, were that a requirement, then none of Options 4, 5, or 6 would make any sense.

Trappist the monk (talk) 23:40, 29 June 2014 (UTC)

Perhaps my original comment was ambiguous, I'll clarify - "I believe that we should be following their guidance for best practice, and rendering the DOIs as URLs, which. By doing so we will facilitate research using printed copies of our articles." I'm not implying a requirement made by CrossRef. However, I believe that display as a URL is option #1 on their list because they consider it to be best practice. — Scott talk 10:03, 30 June 2014 (UTC)
When printed, the full URL is displayed for all links. --  Gadget850 talk 10:48, 30 June 2014 (UTC)

The above discussion is preserved as an archive. Please do not modify it. Subsequent comments should be made in a new section.


Bug in DOI output[edit]

We should bring DOI display into consistency with other identifiers. I.e., going from

doi:10.3389/gene.2013.00151

to

DOI 10.3389/gene.2013.00151

The URN formulation is not particularly useful - in fact, it's not even valid. URN syntax requires them to begin with urn:, meaning that doi would be a namespace; the DOI Foundation has deliberately not registered a DOI namespace for URNs. See Uniform resource name#Absence of DOI namespace. — Scott talk 10:29, 30 June 2014 (UTC)

In May 2012 it was changed to DOI and in July it was changed to doi.[1] When we switched to the module, it was kept as doi. I have not been able to fond specific discussions. --  Gadget850 talk 11:08, 30 June 2014 (UTC)
Reading the July discussion, the motivation for changing to doi was because the output was a URI, and that URI schemes are required to be in lowercase. However, the output is not a proper URI, because doi is not a URI scheme (permanent or provisional). And as mentioned above, even if it were to be prefixed with urn:, there's no DOI namespace for URNs either - so the output in its current state is malformed, being neither a URN or URI. — Scott talk 12:38, 30 June 2014 (UTC)
The same issue is present in print output - an example given in the section above renders as
Ghosh,, M.K.; Harter, M.L. (July 2003). "A viral mechanism for remodeling chromatin structure in G0 cells.". Molecular Cell 12 (1): 255–260. doi:10.1016/S1097-2765(03)00225-9 (http://dx.doi.org/10.1016%2FS1097-2765%2803%2900225-9).
The doi: should be replaced with DOI. — Scott talk 12:50, 30 June 2014 (UTC)

────────────────────────────────────────────────────────────────────────────────────────────────────It is not a bug. It is displayed that way because the DOI specification explicitly calls for lowercase "doi:". (see 2.6.1 Screen and print presentation) — Makyen (talk) 13:37, 30 June 2014 (UTC)

Well then, that's me told. Ho hum. Thanks for the clarification. It would be of use having this information placed into the relevant documentation. — Scott talk 15:01, 30 June 2014 (UTC)
I agree that a link to the spec would be beneficial. I actually only knew that was what the specification called for because some time ago I also noticed that it was "doi:' instead of DOI, which is different from the other identifiers. I had intended to bring it up as an issue here, but I first went and read the specification so that I would recommend/request what the spec. actually called for. I, obviously, dropped it once I saw that we were displaying it in the manner in which the specification specifically stated. Thus, given that at least two of us noticed that it was different and thought that might be an error, it would be a good idea to have a link, or maybe a footnote that states that this is the specified display format.
Along these lines I have put this information into Digital object identifier and moved the mention of the stupid CrossRef recommendation into a footnote. The CrossRef recommendation is stupid because it is recommending using the full URL specifically in online versions merely because "doi:10.1000/182" is not automatically linked by most browsers. The correct recommendation would have been to recommend that the DOI is displayed as "doi:10.1000/182". Their recommendation is specifically contrary to the concepts that have driven the WWW since the beginning, which is that the content provider should link the things which are intended to point to other resources. They are recommending using a feature added to most browsers (auto-linking bare, unlnked URLs) because content creators are lazy and sloppy. Thus, they are specifically recommending that their content creators be lazy and sloppy. That is just wrong, particularly for professional content creators.
Sorry, that last part should really be in the previous section, not this one. — Makyen (talk) 18:54, 30 June 2014 (UTC)
Thank you for that. It was the note in the DOI article that first brought me here, as you may have guessed. I've made a correction to your modified footnote, as the "doi:xxxxx" format isn't a URN. I find it very odd that the DOI Foundation chose a display format that looks like it could be part of a URN or a URI but is in fact neither (despite the best assurances of part 2.6.2 of the handbook regarding the latter!), but I guess we're stuck with it. The CrossRef recommendation appears to have evolved out of the failure of DOIs to become adopted as resolvable on their own. The whole thing (especially if you read the note I added to the URN article about why DOIs aren't URNs) stinks of Not Invented Here syndrome and hints at fighting between the DOIF and W3C. Fun times. — Scott talk 09:39, 1 July 2014 (UTC)
doi:10.3389/gene.2013.00151 is not a URN. It is the linked text 'doi' followed by the doi identifier linked to the full URL. Simply because it has the visual appearance of a URN does not make it a URN. If it were a URN, then the link would not work, since 'doi' is not a valid URI. --  Gadget850 talk 14:02, 30 June 2014 (UTC)--  Gadget850 talk 14:02, 30 June 2014 (UTC)
Yes, you're reiterating my points. — Scott talk 15:01, 30 June 2014 (UTC)

Suggestion (for cite journal)[edit]

So there's a trans_title parameter... might there also be a need for a trans_work (or trans_journal, trans_newspaper, etc.) parameter? —/Mendaliv//Δ's/ 01:22, 3 July 2014 (UTC)

I don't think so... a translation of the title is useful for knowing what the cited article is about, but translating the name of the work doesn't really help in finding it. Die Welt and Le Monde both mean "The World" but you can't go into a library and ask for a copy of The World from 1 July 2013 and expect to get the right newspaper. --Redrose64 (talk) 08:14, 3 July 2014 (UTC)
Who said that the only purpose of a citation is to help you find the cited source? A translation of e.g. a journal title may provide useful context; a periodically title translating as The Heidelberg University Quarterly Political Review gives quite a different impression than does The Danziger Workers' Daily. EEng (talk) 20:39, 3 July 2014 (UTC)
Yes, exactly. While the adage says not to judge a book by its cover, when you aren't literate in the language of the source, fact checking at all becomes harder. For those who have to do so in a hurry (e.g., under a pressing deadline for something going on the main page), not having to dump the journal name into Google Translate and make guesses as to what it means can be helpful. It's also possible that the journal (or other work) has an English name by which it is known elsewhere (thus having the English title to the journal may be helpful to people looking for more information). And while, Redrose64, you may be right about Die Welt and Le Monde, the situation can be quite different for journals and newspapers whose names aren't rendered in the Latin alphabet. 人民日报 for instance. Should newspapers and journals like those always just be rendered as their accepted English names? I don't think that's really fitting with the way most citation styles work. —/Mendaliv//Δ's/ 18:33, 8 July 2014 (UTC)
Another issues is that |title= italicizes all titles— italics are not appropriate for Asian languages. The fix has been to use {{asiantitle}}, but this pollutes the metadata with markup. --  Gadget850 talk 19:18, 8 July 2014 (UTC)
The same problem occurs with Hebrew and Arabic: they should never be italicized (italicized Hebrew is characteristic of self-published books) and also should not display in (what corresponds to) a sans-serif font. I use ''{{hebrew|Title}}'' to get the desired result. Until this is fixed, metadata be hanged... הסרפד (call me Hasirpad) 23:28, 8 July 2014 (UTC)

Cite book editor2 template data[edit]

I just added templatedata for cite book for the editor2 parameters. Now opening a cite book template in VE brings up the new parameters but without the descriptive name I provided. Did I screw something up? I checked the VE archives and found mention of a null edit to the template being necessary after an edit to templatedata; is that the issue here? Mike Christie (talk - contribs - library) 13:23, 3 July 2014 (UTC)

I don't think that a full WP:NULLEDIT should be necessary. A WP:PURGE always updates the green doc box, so should also update the templatedata. At the top of the doc box are some links - [view] [edit] [history] [purge] - go for the last one of these. --Redrose64 (talk) 13:48, 3 July 2014 (UTC)
Doesn't seem to be solving the problem. I tried that, and also tried adding "&action=purge" to the page I was editing, to see if that would clean anything up. If you bring up a VE session and do Insert -> Template and add cite book, and then search for editor, do you get the editor2 parameters showing up? I'm not seeing them. I can type them in manually, so it does work, but I'd like to know if I screwed anything up in case I need to add more params in the future. Mike Christie (talk - contribs - library) 14:07, 3 July 2014 (UTC)
Don't know. I never use VE: I prefer to make my own messes. --Redrose64 (talk) 14:27, 3 July 2014 (UTC)
OK, no problem; I'll ask over at the VE page. Thanks. Mike Christie (talk - contribs - library) 14:39, 3 July 2014 (UTC)
I just checked. The MediaWiki API is definitely serving the updated TemplateData with editor2-last, editor2-first, and editor2-link. Thus, the problem is on the VE side (they may cache the TempateData somewhere). — Makyen (talk) 23:27, 3 July 2014 (UTC)
It appears a null edit was necessary; see this discussion. In fact another null edit is needed now, if anyone here who is an admin wouldn't mind doing one; I just added the editor3 through editor9 params, and a null edit is needed to make them show up. Mike Christie (talk - contribs - library) 11:11, 5 July 2014 (UTC)
Within 15 minutes of your post the API was providing a TemplateData JSON which included the additional editors.
Something other than just a purge is required, probably a null edit. I made changes to the TemplateData at Template:Cite book/doc to group the authors and editors (separately) so that all authors and all editors show up in the paramOrder object sequentially without intervening non-related parameters. After that edit, I tried multiple different things to see when the API started serving the new structure. After purging both Template:Cite book/doc and Template:Cite book (in order), the structure being served remained identical to what it was prior to my edit of Template:Cite book/doc, To verify that my edit had some effect, I retrieved the TemplateData structure from Template:Cite book/doc. That structure did reflect my changes. Thus, it is clear that purging the Template:Cite book page is insufficient to get the new structure to be served by the API.
As it is still not being served, an additional null edit would probably be helpful. When someone does so, please report here so I can 100% verify that a null edit is actually what causes the API to serve the API to serve the updated TemplateData. — Makyen (talk) 13:35, 5 July 2014 (UTC)

TemplateData for citation templates[edit]

The current state of TemplateData is:

Template Number of parameters
Citation 248
Cite AV media none
Cite AV media notes none
Cite DVD notes none
Cite arXiv none
Cite book 116
Cite conference none
Cite doi none
Cite encyclopedia 66
Cite episode none
Cite hdl none
Cite interview none
Cite journal 92
Cite mailing list none
Cite map none
Cite music release notes none
Cite news 93
Cite newsgroup none
Cite pmid none
Cite podcast none
Cite press release 25
Cite serial none
Cite sign 93
Cite speech none
Cite techreport none
Cite thesis none
Cite web 91

I have been considering harmonizing the TemplateData for CS1 templates for some time. Such has also been suggested over at Wikipedia:VisualEditor/Feedback#Templatedata for cite book. I would think that it would be a good idea to have TemplateData in all of the CS1 templates. We should probably organize it such that the text is in templates containing the commonly used parameters. — Makyen (talk) 13:52, 5 July 2014 (UTC)

Can we create this with templates for consistency? --  Gadget850 talk 16:06, 5 July 2014 (UTC)
Using templates would be the way I would expect us to do so. We do not want to be copying the text from page to page by hand. — Makyen (talk) 19:40, 5 July 2014 (UTC)
Somehow I missed the last statement in your proposal.  Gadget850 talk 20:23, 5 July 2014 (UTC)

Foreign language and translated title mismatch[edit]

Template:Cite_web#Examples includes the following (highlighting added):

Foreign language and translated title
  • {{cite web |url=http://www.example.org/ |title=Honi soit qui mal y pense |last=Joliet |first=François |date=30 April 2005 |accessdate=10 July 2014 |language=French |trans_title=Shame on those who think evil }}
Joliet, François (30 April 2005). "Honi soit qui mal y pense" [Shamed be he who thinks evil of it]  (in French). Retrieved 10 July 2014.


How does the template transform the translated title (trans_title=)

  • Shame on those who think evil

to

  • Shamed be he who thinks evil of it

??


There's obviously something going on behind the scenes in this example that goes way beyond the parameters. Whatever it is, it's distracting and needs to be explained, or the example replaced by something straightforward. I can't see the actual code because Template:Cite_web's "View source" tab says "You do not have permission to edit this page…" (I don't want to edit it, just view it) and shows the entire code as

<includeonly>{{#invoke:citation/CS1|citation
|CitationClass=web
}}</includeonly><noinclude>
{{documentation}}
</noinclude>

which is no help at all. {{ping}} me if you want to discuss it. --Thnidu (talk) 06:53, 11 July 2014 (UTC)

The different translations were because different translations were given in the nowiki'd example code and the actual citation - now fixed.Nigel Ish (talk) 08:33, 11 July 2014 (UTC)

Publisher in different language[edit]

Should the non-English, official publisher name be included, or only the English translation of it? Regards.--Tomcat (7) 11:16, 11 July 2014 (UTC)

Including the non-English publisher name is helpful if it helps the reader locate the original source. You can put the translation in brackets, like |publisher=Le Chat Rouge [The Red Cat]. – Jonesey95 (talk) 14:43, 11 July 2014 (UTC)

How to cite a newspaper that has republished an article from another newspaper[edit]

This obituary in the Pittsburgh Post-Gazette appears to have been originally published in the Dallas Morning News. Should I cite it like this...

DeShong, Rae D. (November 10, 2000). "Eyewitness to JFK assassination". Pittsburgh Post Gazette. p. C14. Retrieved July 20, 2014. 

...or is there some way to credit the original paper? Thanks! -Location (talk) 21:48, 20 July 2014 (UTC)

Interesting question. The essential problem is where an article's on-line availability is not at the original source, but only in a syndicated version, and likely abridged or even modified, often at some purely local paper few people have heard of. As we do not necessarily know how the article was modified, I would say the end publisher (here, the Post-Gazette) should be cited as the responsible "author". But if the article really originates elsewhere, then that should be noted. I tried using |agency=, but that just added the "agency" with out comment. Perhaps just add text after the template, something like "Syndicated from the Dallas Morning News". ~ J. Johnson (JJ) (talk) 22:50, 20 July 2014 (UTC)
Thanks for the reply. I was able to find the text of the Dallas Morning News obituary in an unreliable source (i.e. newsgroup post) and it seems to indicate that the Post-Gazette only truncated the last sentence - a list of the decedent's survivors.[2] That led me to what appears to be a reliable source confirming the title of that article.[3] I was also able to track down the page number of the original article in a questionable source.[4] Given that the truncated sentence is not the material I wished to cite, I think what you have suggested is the best bet. Thanks, again! Location (talk) 23:42, 20 July 2014 (UTC)
The guideline is to say where you found it. Cite only sources that you have read yourself. – Jonesey95 (talk) 04:08, 21 July 2014 (UTC)
If one source credits another, you can indicate that like this:
  • DeShong, Rae D. (November 10, 2000). "Eyewitness to JFK assassination". Pittsburgh Post Gazette. p. C14  , crediting Smith, John (November 9, 2000). "More on JFK assassination". Daily Bugle. p. 2. 
That way you're giving not only where you saw it, but also the obviously-appropriate additional information. Notice the "C14.," -- there's a special parameter (I think it's "postscript") to the cite template for getting rid of the period. Now, the example I gave simply bolts two cite templates together with no formal semantic relationship; possibly there is (or should be) a parameter in the cite template -- something like "citing" or "quoting" -- which itself could contain an entire cite such as the Bugle cite above. Hope this helps. EEng (talk) 16:08, 21 July 2014 (UTC)
|postscript=none
Trappist the monk (talk) 16:24, 21 July 2014 (UTC)

sfn and page internal links[edit]

This comes from Elmo Hope, best seen in an earlier version [5]... Using {{sfn}} if the author field is blank (e.g., citation 2), then it is the newspaper name that pops up when the numbered citation is hovered over, but clicking on that name has no effect (it should jump to and highlight the relevant work in Bibliography). There is a similar problem with citation 4, I assume because the publication date is "2002" in the sfn but "2012 [2002]" in the Bibliography. {{rp}} has been used as a way around this, but that has introduced a second referencing system and removed the functionality of {{sfn}}. Is there a solution to these two problems, using {{sfn}} or another system? EddieHugh (talk) 12:47, 22 July 2014 (UTC)

For citation 2, add |ref={{sfnref|New York Amsterdam News|1940}} to the citation under §Bibliography.
Trappist the monk (talk) 13:07, 22 July 2014 (UTC)
|year=2012 [2002] is not valid syntax in the complicated world of the citation templates. I changed it to |year=2012 |origyear=2002, which works fine. I also changed the year in the {{sfn}} references to 2012; since the bibliography lists only the 2012 version, that's what needs to be cited. – Jonesey95 (talk) 14:31, 22 July 2014 (UTC)
Wonderful! Thanks both. I'll wait for a reply from the editor who changed to {{rp}}, as it was as part of a DYK nomination, but I expect that that change will be made too, as it's a much better solution. EddieHugh (talk) 15:13, 22 July 2014 (UTC)
@EddieHugh: You should never need to use {{rp}} when {{sfn}} is used: that's one of the primary purposes of {{sfn}}. --Redrose64 (talk) 17:56, 22 July 2014 (UTC)
Thanks. I've now changed it back to sfn using the script above. I didn't want to use rp, but finding the solution(s) (without asking on a page such as this) proved difficult. EddieHugh (talk) 18:43, 22 July 2014 (UTC)