Help talk:Citation Style 1

From Wikipedia, the free encyclopedia
  (Redirected from Template talk:Cite encyclopedia)
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.


Template:Cite thesis[edit]

Could a parameter be added for a thesis' BLDSC number? See e.g. [1] (linked to at Timothy Gowers). It Is Me Here t / c 14:29, 4 June 2014 (UTC)

Are these particularly common? If not, is there any reason that |id= could not be utilised? BTW the abbreviation e.g. is not italicised, see MOS:TEXT#Foreign terms. --Redrose64 (talk) 15:55, 4 June 2014 (UTC)
I've seen a number of places that archive thesi and such, using their own indexing system. Having a separate parameter for each such system would be quite a boggle. Much better if we have single generic parameter that can be adapted for various cases. But this suggests a pair of values: one to indicate which kind of number (e.g., "BLDSC"), another for the actual item number. Even a third value, for a link. Maybe |index-name=, |index-number=, |index-link=? ~ J. Johnson (JJ) (talk) 21:45, 7 June 2014 (UTC)
This sounds good. It Is Me Here t / c 18:52, 8 June 2014 (UTC)
If there was some unified identification method, that would be one issue. However, I see nothing here that justifies adding additional parameters. It appears that the desired function is appropriately covered by the generic |id= parameter. This parameter can have text describing the id, the ID number and a link to the appropriate location. Is there a reason this is not sufficient? — Makyen (talk) 06:31, 9 June 2014 (UTC)
You're saying we can free-form all that into this one parameter. I think that might suffice, but we should run up a few examples to demonstrate. ~ J. Johnson (JJ) (talk) 23:01, 10 June 2014 (UTC)
I'm not sure what you desire for an example. The one mentioned could be:
Gowers, Timothy (1990). Symmetric structures in Banach spaces (PhD thesis). University of Cambridge. BibID 8880. BLDSC D61037. 
While it would be trivial to also link the BLDSC number, there did not appear to be an appropriate clearing house site for such inquiries (i.e. all the links I found quickly were single locations). — Makyen (talk) 01:50, 11 June 2014 (UTC)
Yes, that seems sufficient. Additional parameter(s) not needed. ~ J. Johnson (JJ) (talk) 22:09, 11 June 2014 (UTC)

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)

Cite interview[edit]

In addition to the edit requested above, I propose the following:

  • Make |interviewer= a numbered parameter, |interviewer#=
|cointerviewers= has been deprecated; there are still programs that use more than one interviewer. |subject#= is an alias of |author#=; so utilizing |author#= would put the interviewer in the wrong place.
  • Add |interviewer-link= and |interviewer#-link=
Often interviewers have articles on Wikipedia; currently, the editor has to remember to wikilink the name; additionally, a pipe is usually needed, so the editor has to remember to use {{!}}: |interviewer=[[Ted Koppel{{!}}Koppel, Ted]]

Does this need an RFC? Or will discussion/support/oppose here suffice? Thanks!—D'Ranged 1 VTalk 23:32, 4 June 2014 (UTC)

  • Changing parameter names is usually very messy and a bad idea in general. Why do you think it would be beneficial to change the parameter names and force all of the users of the template to relearn the syntax that will have changed? I'm also not understanding what you want done on the {{!}} aspect of it, could you please clarify what the goal is? Thanks. — {{U|Technical 13}} (etc) 23:43, 4 June 2014 (UTC)
The {{!}} template is not required in this instance. The MediaWiki parser and the module properly parse parameters which contain wiki-links and templates. Example using normal syntax:
Author. Title. Interview with Koppel, Ted. 
Using {{!}}:
Author. Title. Interview with Koppel, Ted. 
The {{!}} template is only required if the "|" is a direct, unquoted part of a parameter value. In some instances, alternate encodings are more appropriate. The two most common places for this character to be used is in titles and URLs. In |title=, "|" should be replaced with | as is described at Help:Citation Style 1#Titles and chapters. In |url=, "|" should be replaced with %7C as is described at Help:Citation Style 1#Special characters.
The {{cite interview}} documentation clearly states that this parameter can be wiki-liked as desired.
The |interviewer= documentation describes that multiple interviewers should be listed in the single parameter with the names separated by a semicolon. It is unclear to me if it is desirable to handle this as a situation where the names should be split into multiple parameters. As I understand it, one of the main reasons why authors and editors are split in that manner is to facilitate creating the COinS data. I don't believe the interviewer is included in that data.
As I understand it, generation of COinS data is also the reason for separating author and editor wiki-links into |author-link= and |editor-link=. — Makyen (talk) 04:45, 5 June 2014 (UTC)
COinS is secondary, a more significant reason concerns the creation of links for Shortened footnotes and related techniques. If the authors are split into last/first pairs, all you need to do to set up a valid link is add |ref=harv --Redrose64 (talk) 10:46, 5 June 2014 (UTC)
Both {{cite interview}} and Chicago Manual of Style put the name of the person being interviewed in the beginning of the rendered citation, that is, the position of the author. When using the {{sfn}} template, the surname of the author, that is, the interviewee, is used, not the name of the interviewer. So I don't see that the structure of the interviewer parameter(s) is relevant to creating structured shortened footnotes. As for COinS, does it even have a parameter to export the name of the interviewer(s)? Jc3s5h (talk) 11:37, 5 June 2014 (UTC), fix word 13:20 UT
No; only authors are supported. See Module talk:Citation/CS1/COinS. --  Gadget850 talk 12:57, 5 June 2014 (UTC)

──────────────────────────────────────────────────────────────────────────────────────────────────── Technical 13, I am not asking to change any parameter names; rather to expand the |interviewer= parameter to an incrementable parameter that would function the same way |author= and |editor= do. I also am proposing adding a new parameter, |interviewer#-link=, to easily insert a link to the interviewer(s)' article(s) on Wikipedia into the citation. No one would need to learn different syntax unless they chose to use the incremental form of the parameter (by adding a number to the parameter); they could easily continue to use the present method of listing multiple interviewers in |interviewer= and manually wikilinking the interviewer name(s). I'm proposing an enhancement, not a replacement. As for the use of {{!}}, I mistakenly believed that use of it was necessary when wikilinking names within a citation template.

Makyen, thank you for the clarification regarding the use of {{!}}; I was sure I had seen one of the reference tools automatically replace the pipe in a wikilink with {{!}}; I was mistaken. I went back and reviewed the citation, {{!}} was used to insert a pipe in the |work= parameter; your information on a better way to do that is duly noted.

Makyen, Redrose64, Jc3s5h, and Gadget850—my proposal isn't prompted by considerations of COinS data or shortened footnotes. As has been pointed out, the |interviewer= parameter isn't included in COinS metadata and this change would have no impact on shortened footnotes.

The primary purpose of the proposal is to help make editing methods across these templates more consistent. To my knowledge, there are currently four parameters (and their aliases) in the CS1 templates to capture names of people: |author=, |editor=, |interviewer=, and |others=. Both |author= and |editor= are incrementable via attaching a number to the parameter. Like |interviewer=, an editor still has the option of listing all the authors in |author= and all the editors in |editor=, separated by semicolons and wikilinked if desired. However, in my opinion, it is much easier, especially with tools such as RefToolbar, to enter names in separate parameters and let the tool take care of the punctuation. My goal, about which Technical 13 inquired, is to cut down on the exceptions that an editor has to remember when using the CS1 templates. Just as an editor shouldn't have to remember that this parameter name takes a hyphen, but that one needs an underscore, and that other one mushes the words together, an editor shouldn't have to remember to structure his citation differently when dealing with similar data.

(As a side note: I am much less concerned that this methodology be applied to |others=; its use seems infrequent and I would imagine that its inclusion is rarely required in order to provide an accurate, identifiable reference to a specific source. If we wanted to be completely consistent, |others= would be incrementable and there would be parallel, incrementable |role=) and |others-link= to make data entry easier and, again, let the template add the proper punctuation and formatting. I don't see a real need to do any of that.)

I'm also not proposing that the parameter be further divided with |first= and |last= names; those exist for the reasons stated above; their use is not required (nor desirable) here. So it still wouldn't be a perfectly consistent method, but it would be more so than it is now. I hope this clarifies things; thank you for your patience. (My Talk page posts are probably in need of a good copyeditor for length.)—D'Ranged 1 VTalk 02:30, 6 June 2014 (UTC)

  • Well... That just seems like unnecessary template bloat to me... I don't suppose you could work up your idea in the sandbox with plenty of exhaustive testcases so I can see how much of an increase in template size this will be, can you? Template size on something like this is a concern because it can very quickly put pages in the Pages where template-inclusion size is exceeded category with even small increases in templates size (since they are often called multiple times on a page).. Thanks! — {{U|Technical 13}} (etc) 02:39, 6 June 2014 (UTC)
The changes that this proposal would require would be made to Module:Citation/CS1/sandbox and associated files.
I think that I'm opposed this sort of incremental change to Module:Citation/CS1. Special case code is ugly, hard to understand and hard to maintain. There is already too much of that in the CS1 code; we should avoid adding more. We should be putting our efforts first into creating a style guide type document that can be used to direct such enhancements. Once a proposed enhancement has been made to the guide, then and only then should we make changes to the CS1 code.
With less than 2000 transclusions of {{cite interview}}, it would seem that the effort required to implement this proposal would far outweigh the benefit.
Trappist the monk (talk) 03:11, 6 June 2014 (UTC)
I must respectfully disagree. Waiting for a style guide that may never happen doesn't fix the present inconsistency. We have the ability to make the templates more consistent; regardless of how much or how little they're used, they should be as consistent as possible. There are too many ways presently that the templates cause confusion; let's reduce the number of causes if we can.—D'Ranged 1 VTalk 00:08, 7 June 2014 (UTC)
Additionally, no I can't work up my "idea in the sandbox with plenty of exhaustive testcases". Should my inability to edit templates prevent their modification or improvement? If my proposal is approved (which doesn't seem likely) and development and testing show that it causes too much of a burden, the issue could be re-visited at that time. Invoking an argument about consequences that have yet to be measured isn't helpful.—D'Ranged 1 VTalk 00:17, 7 June 2014 (UTC)
  • I would support this change. As far as I understand it, one of the reasons behind having {{cite journal}} etc. use Module:Citation/CS1 in the first place was to make |lastn= and the like arbitrarily scaleable (instead of having to explicitly make a bespoke |last19=, |last20=, and so forth). It would therefore be in keeping with this thinking to have |interviewern=, |interviewern-last=, |interviewern-link=, |subjectn-link=, ..., work in the same way. It Is Me Here t / c 11:47, 18 June 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)

Error: accessdate= requires url= in cite journal[edit]

I ran across this and wondered if there's a way to avoid it:
{{Cite journal |author=Rabie, Mohamed |date=Summer 1992 |title=The U.S.–PLO Dialogue: The Swedish Connection |journal=[[Journal of Palestine Studies]] |publisher=[[University of California Press]] |volume=21 |issue=4 |pages=54–66 |accessdate=1 July 2007 |doi=10.1525/jps.1992.21.4.00p0140g |ref=harv |jstor=2537663}}

Rabie, Mohamed (Summer 1992). "The U.S.–PLO Dialogue: The Swedish Connection". Journal of Palestine Studies (University of California Press) 21 (4): 54–66. doi:10.1525/jps.1992.21.4.00p0140g. JSTOR 2537663. 

I fixed it by putting the retrieval date outside the template but still within the <ref> tags:
<ref>{{Cite journal |author=Rabie, Mohamed |date=Summer 1992 |title=The U.S.–PLO Dialogue: The Swedish Connection |journal=[[Journal of Palestine Studies]] |publisher=[[University of California Press]] |volume=21 |issue=4 |pages=54–66 |doi=10.1525/jps.1992.21.4.00p0140g |ref=harv |jstor=2537663}} Retrieved 1 July 2007.</ref>

Rabie, Mohamed (Summer 1992). "The U.S.–PLO Dialogue: The Swedish Connection". Journal of Palestine Studies (University of California Press) 21 (4): 54–66. doi:10.1525/jps.1992.21.4.00p0140g. JSTOR 2537663.  Retrieved 1 July 2007.

Both the doi and jstor parameters link to the same website (the doi link redirects to the jstor link); could the template be modified to ignore the error if one or both is present?—D'Ranged 1 VTalk 03:55, 9 June 2014 (UTC)

This error message has been discussed a number of times on this page (and similar pages) in the past year and a half. The short version of the different viewpoints, as I recall them, are:
  1. Access dates should not be cited for web pages that do not change. Journal articles with DOI or other identifiers do not change, so they should not have access dates in their citations.
  2. Access dates are useless. They should be removed entirely.
  3. Access dates are useful. The error message should be removed from the citation module.
  4. Access dates are sometimes useful, so they should not be deleted. Hiding them in an HTML comment may be acceptable, since they are not displayed in situations that are considered errors by the module.
  5. Hiding or deleting access dates (or moving them outside of the cite template) does not fix the problem. It only gets rid of the error message.
  6. In rare occasions, the access date error occurs in conjunction with other citation errors. When those other errors are fixed (e.g. an unnamed parameter error where url:http://www.example.com appears between two pipes), the access date error goes away.
You may note that some or all of these viewpoints are in conflict with one another. That is where we stand today. My assessment is that we do not have consensus that these error messages should be displayed in all cases. That is one reason why the |accessdate= error messages are hidden by default.
I have worked on almost all of the citation error categories over the past year or so, but I haven't touched the accessdate category. I have assumed that if we ever come to a consensus about this error message, the errors will either be eliminated permanently (i.e. this will no longer be considered an error) or fixed by a bot, so human editing at this point is not useful. That's my view, anyway. I welcome other opinions or summaries or additions to the numbered viewpoints above. If someone wants to make a concrete proposal to address this error message, I suggest starting a new section. – Jonesey95 (talk) 04:25, 9 June 2014 (UTC)
I doubt we will ever achieve internal consensus on this issue. You can also hide or style access dates per Help:Citation Style 1/accessdate. {{Retrieved}} can be used for standalone access dates. --  Gadget850 talk 10:59, 9 June 2014 (UTC)
Although no consensus has been reached about whether every accessdate must be accompanied by a URL, I don't think the original poster's example needs an accessdate because journal articles don't change. Jc3s5h (talk) 12:56, 9 June 2014 (UTC)

Error in documentation for display subtemplate[edit]

In the documentation under Display options, the following statement is incorrect:

  • postscript: Controls the closing punctuation for a citation; defaults to a period (.); for no terminating punctuation, specify |postscript=none – leaving |postscript= empty has the same effect but is ambiguous. Ignored if quote is defined.

In testing, I find that if you leave the parameter empty, it defaults to a period. In order to suppress the closing punctuation, the value must be set to |postscript=none:

  • {{cite web|first1=First|last1=Last|title=Sample Title|date=June 9, 2014|accessdate=June 9, 2014|url=http://www.example.com|postscript=}}
Last, First (June 9, 2014). "Sample Title". Retrieved June 9, 2014. 
  • {{cite web|first1=First|last1=Last|title=Sample Title|date=June 9, 2014|accessdate=June 9, 2014|url=http://www.example.com|postscript=none}}
Last, First (June 9, 2014). "Sample Title". Retrieved June 9, 2014 

The statement about the parameter being ignored if |quote= is defined is correct:

  • {{cite web|first1=First|last1=Last|title=Sample Title|date=June 9, 2014|accessdate=June 9, 2014|url=http://www.example.com|quote=Pithy statement.|postscript=none}}
Last, First (June 9, 2014). "Sample Title". Retrieved June 9, 2014. "Pithy statement." 

I haven't been able to figure out how to test this on non-lua templates; I don't know if the language there needs to be updated as well. The subtemplate {{Citation Style documentation/display}} uses #if statements to control what's displayed if the template is lua-based; I'm not comfortable in editing the documentation. Could someone more savvy do so? I think just deleting – leaving |postscript= empty has the same effect but is ambiguous would be sufficient. Thanks!—D'Ranged 1 VTalk 04:38, 9 June 2014 (UTC)

I changed it to "leaving |postscript= empty is the same as omitting it, but is ambiguous." Does that work? That text will display only in Lua citations (e.g. cite journal, cite book), the ones that use the CS1 module. – Jonesey95 (talk) 05:02, 9 June 2014 (UTC)
That's better; thanks so much!—D'Ranged 1 VTalk 05:09, 9 June 2014 (UTC)

distributor parameter[edit]

This parameter is mentioned in the documentation for {{cite encyclopedia}}, but is not recognized (leaves an error message) when used there or in {{citation}}. The documentation is suggestive that it is intended to be an alternate (synonym) for publisher, but when publisher is absent and distributor is present, the error says distributor is unknown (and suggests publisher instead). When both are present, another error also says both cannot be specified. What's the story? Documentation bug, or template bug, or old deprecated (nonfunctional) parameter? Evensteven (talk) 22:50, 9 June 2014 (UTC)

Perhaps a little bit of each. |distributor= is not listed at Module:Citation/CS1/Whitelist but is defined as an alias of |publisher= in Module:Citation/CS1/Configuration. The {{citation/core}} version of {{cite encyclopedia}} did not use |distributor=; the mention of |distributor= is in a section of the common documentation referring to parameters that produce the COinS metadata.
I think that the only template that used |distributor= is {{cite sign}} (currently transcluded into 161 pages). Because |distributor= isn't included in Module:Citation/CS1/Whitelist but is listed in Module:Citation/CS1/Suggestions, it would appear that the intent was to deprecate and remove |distributor= in favor of |publisher=.
If the intent was to deprecate and remove |distributor=, then to complete the task we need to edit Template:cite sign/doc to remove mention of |distributor= as an alias of |publisher=; edit Template:Citation_Style_documentation/coins to remove mention of |distributor=; edit Module:Citation/CS1/Configuration to remove |distributor= as an alias of |publisher=.
Trappist the monk (talk) 00:02, 10 June 2014 (UTC)
(edit conflict) Some details to help diagnose this apparent problem:
  • |distributor= does not appear in the Whitelist of valid parameters. It was added to the Whitelist on 31 August 2013, but it was not added to Whitelist/Sandbox at the same time. The next time the Sandbox was synced to the main Whitelist file, distributor was removed, probably inadvertently.
  • |distributor= appears in the Module Configuration code as an alias for |publisher=.
  • It also appears in the Suggestions list, which is where we put unsupported parameters for which we want to suggest the corrected parameters. It turns out that I added |distributor= to the Suggestions list on 13 December 2013, probably after noticing that it was marked as unsupported in a citation.
  • It appears in the documentation for {{cite encyclopedia}} and {{citation}}, as noted above, as well as {{Cite sign}} and probably others.
There is a conflict here. Based on the above, it looks like |distributor= was inadvertently removed from the Whitelist, and that re-adding it to the Whitelist and removing it from Suggestions will fix the problem. Trappist the monk has been making most of the changes to the CS1 module lately, but is on a wikibreak. I'm willing to make this small change and will document it accordingly. Any objections?
Another option would be to deprecate |distributor= and remove it from all documentation and module code. – Jonesey95 (talk) 00:49, 10 June 2014 (UTC)
Well, I have one more thought. When I first saw this parameter, it did not necessarily strike me as being synonymous with publisher. All that knowledge came from reading documentation and playing with template behavior. But what I was looking at was citation for an A/V source, figuring that the A/V production was one thing (say, the company that produced the video originally, like MGM), and that the distributor might be another thing, like a company who bought the rights and re-released it. Consider old movies, or TV shows, or the like, which perhaps had no videotape or disc-based media release when newer, but was acquired by a content provider who put it onto DVD for sale and distribution. That's what I thought "distributor" might be. So, if you guys want to patch up your original concept, or deprecate it, I don't much mind either way, as I probably won't use it that way. But what does one do to cite a "distributor" in my sense? And does it make any sense to change the sense of what distributor means? Evensteven (talk) 01:35, 10 June 2014 (UTC)
I think it would make more sense to use |others= for niche cases such as this. – Jonesey95 (talk) 04:36, 10 June 2014 (UTC)
"Others" puts its text before the cited title, not where one would want a distributor to go. Evensteven (talk) 07:23, 10 June 2014 (UTC)

Non-existing parameter documented?[edit]

The table in this documentation contains a parameter called "websitework", but that doesn't actually seem to exist? Derboo (talk) 08:16, 13 June 2014 (UTC)

Which template are you referring to? It isn't on the Help page. "work" and "website" are aliases of one another. The words probably got run together somehow; I'll fix it if you'll tell me which template includes the error. Thanks!—D'Ranged 1 VTalk 08:39, 13 June 2014 (UTC)
if you're referring to the documentation for {{cite web}}, maybe your browser isn't displaying correctly. The parameter "work" is displayed in grey under the parameter "website" to indicate that it is an alias of the parameter. They shouldn't be showing as one word; they're on two separate lines. —D'Ranged 1 VTalk 08:44, 13 June 2014 (UTC)

Derboo, can you please provide a link to the page that displays this erroneous text? Thanks. It looks like you may be seeing the same thing that an editor saw at this discussion. The resolution is not given there, but it looks like the specific web browser version was the cause. What web browser are you using? – Jonesey95 (talk) 12:35, 13 June 2014 (UTC)

Alright, it turns out that the table requires scripts to be activated for some reason, or otherwise all the grey stuff is displayed jumbled together with the first line. That is some weird bit of coding... Derboo (talk) 17:59, 13 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.[2] 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)