Template talk:Citation/core

Reinstating talk page

{{editprotected}} This page used to redirect to Template talk:Citation; now that other templates rely on it this isn't really appropriate so I've substantiated the talk page. To celebrate this I'll duplicate an edit request already advertised at Template talk:Cite book#Translator; please copy Template:citation/core/book to Template:citation/core.

Interested users may wish to add this page to their watchlist. Martin ' 04:51, 8 December 2008 (UTC)

I would argue that the talk pages of all these templates (citation, cite_book, cite_journal, cite_web) should also be unified; i.e. they should all redirect to Talk:Citation. I would also argue that the documentation should be unified as well. ---- CharlesGillingham (talk) 07:54, 8 December 2008 (UTC)

I agree that the former needs to happen at some point; maybe best to wait until outstanding issues from the update are resolved at {cite book}. Merging the documentation also seems to make sense. Martin ' 13:38, 8 December 2008 (UTC)

Parameter naming

Most of the parms in citation/core are named with InitialCaps, but there are a couple (format, language, amp, laysummary & its related ones) that are in all lowercase.

For consistency's sake, should we have all of citation/core's parms named/formatted the same way? For the 'wrapper' templates that are now calling this one like cite journal, cite book, all the parms are lowercase. I suppose that having citation/core's parms named with InitialCaps helps distinguish between what wld otherwise be identically named parms in the core, and in the wrapper templates.--cjllw 00:28, 11 December 2008 (UTC)

As editors never have to use Citation/core's parameters directly, I don't think it matters either way. Martin ' 13:33, 12 December 2008 (UTC)

Well, even if not an issue for {citation} or {cite XXX} template users, inconsistency may be a potential annoyance to folks who maintain this (increasingly complicated) code—not everyone doing this now and in the future may be familiar with the template's development. Particularly so since case matters in these parameter names, it's easy enough to misstype a parm as lowercase when it should be InitCaps, and vice versa, when say sandboxing some proposed modifications. Having more predictable parameter names/orthography ought to lessen the chances of such snafus, one would think.--cjllw 13:52, 18 December 2008 (UTC)

I would go for consistency. We did have a problem a while back with "DOI" vrs "doi" with both being used in the core template code. Adhering to an defined convention would have eliminated this. --Salix (talk): 16:20, 18 December 2008 (UTC)

Misc updates

{{editprotected}} Please copy the Sandbox to Template:Citation/core.

This incorporates miscellaneous changes:

• Fix language and format parameter as requested at Template talk:Cite book without damaging Cite Journal
• restoration of origyear functionality (requested at Cite Book)
• Un-hardcoding a separator that was missed originally
• Ensuring that the title displays with different URL specifications
• Allowing the format of the accessdate to be manually specified

I've tested it against all the testcase pages and can't see any problems.

Thanks, Martin ' 14:07, 12 December 2008 (UTC)

 Done It Is Me Here 19:14, 12 December 2008 (UTC)

Another minor tweak

{{editprotected}} There was a convoluted twist in the code that could result in unusual combinations of parameters displaying the language and format twice. Replacing Template:Citation/core with Citation/core/sandbox resolves this anomaly, making the code more intuitive and slightly smaller (= faster to load). I did not observe any deleterious effects at the test case pages. Martin ' 19:26, 13 December 2008 (UTC)

 Done It Is Me Here 21:02, 13 December 2008 (UTC)

Thank you Martin ' 23:29, 13 December 2008 (UTC)

More fields

Should Template:Citation/core support fields like artist, and inker, penciller (and/or derivatives of those)? These as something to default to if they exist but there's no author, along with the existing issue, periodical, title, and series fields, would make it possible to directly support manga and comic books. (They may not be cited much, but they're one of the few primary sources in articles actually having to do with those media.)

Also, some way to switch from the existing periodical formatting to more like "___ vol. 3" / "___ vol. 3, #100"? This is a much more common use for comics than something like "___ 3 (100)". Here's an example of what I mean:

Lee, Stan (w); Kirby, Jack (p); Ayers, Dick (i); Klein, George (i); Rule, Christopher (i). "The Fantastic Four!" The Fantastic Four vol. 1, #1 (10 November 1961). Lee, Stan ed. New York, NY: Marvel Comics. Cover. "Just wait and see, sister! The Fantastic Four have only begun to fight!"

The formatting doesn't have to be exactly that, of course, but it should get the gist across. Sukael \o/ 17:27, 20 December 2008 (UTC)

Support for these additional fields would have to be provided by, say, 'cite comic book', which would work out what to append to the authors and pass this information to 'citation/core'. Is such information really necessary in a citation? I should imagine that the source is no harder to find if you don't know whether Joe Bloggs was the inker or writer. Martin ' 18:54, 3 January 2009 (UTC)

Unlink laydate

{{editprotected}} Could we remove the brackets around laydate? It looks strange, and it seems the other dates are not linked. Make it {{{laydate}}} instead of [[{{{laydate}}}]]. --Apoc2400 (talk) 19:25, 28 December 2008 (UTC)

Before this edit is made, I think you need to muster consensus for the best solution – try advertising the proposed edit at Template talk:Citation, Template talk:Cite book and Template talk:Cite journal. Martin ' 18:57, 3 January 2009 (UTC)

Since all the other dates in this template are not linked I don't think it's controversial to unlink the laydate field as well. --Apoc2400 (talk) 13:53, 7 January 2009 (UTC)

What does "laydate" do? —Remember the dot ^(talk) 19:55, 10 January 2009 (UTC)

It appears to be a bad idea imported from {{cite science}}. The {{Cite journal}} talk archives have some damning things to say that were essentially unanswered, and it appears to have come here as a result of changes necessary to convert that template to use this one. RossPatterson (talk) 21:19, 10 January 2009 (UTC)

I don't know the history, but I have used it a few times. It's for when you cite a scientific article in a journal, but also an article in a newspaper or magazine that reports about the study in laymans terms. laydate is the access date for laysummary. Ross: How would you prefer to do it instead? Put the article and lay summary in separate refs? Put both {{cite journal}} and {{cite news}} in the same <ref></ref>? Or just cite one of them? --Apoc2400 (talk) 22:43, 10 January 2009 (UTC)

Yeah, I agree with fnielsen's suggestion of "<ref>{{cite journal|title=Really Dense Paper Einstein Couldn't Understand |...}}{{cite news|title=Oversimplified Article Written at a Moronic Level |...}}</ref>". It makes it patently obvious that the two sources are related and part of the same citation, without hiding all the details of the less-valuable-but-so-important-it-can't-be-omitted layperson's reference. RossPatterson (talk) 23:48, 10 January 2009 (UTC)

 Done Ruslik (talk) 14:42, 16 January 2009 (UTC)

Editor punctuation

{{editprotected}} An issue has been raised at template talk:Cite book regarding the double punctuation of the editor field. My comment and edit request is copied below.

As I understand it, we should see 'ed.' where the rest of the citation is separated by periods, and 'ed.,' where a comma separator is used. This can be resolved by changing Template:Citation/core by replacing the line

      }}, ed{{#if:{{{EditorSurname2|}}}|s}}.{{

with

      }}, ed{{#if:{{{EditorSurname2|}}}|s}}{{#ifeq|{{{Sep|,}}}|.||.}}{{

This will always display a period after 'ed', unless the citation separator is itself a period, where it will display 'ed.' instead of 'ed..'. Martin ' 18:57, 3 January 2009 (UTC)

PS while you're at it, could you please add the line <noinclude>{{documentation}}</noinclude> to the end of the template code, so that I can add documentation (I intend to provide a list of templates using this core, but as some editors are scared of the template it may be helpful if I provided a brief explanation of its functions.) Martin ' 19:17, 3 January 2009 (UTC)

Thanks. Martin (Smith609 – Talk) 21:39, 3 January 2009 (UTC)

The change you requested was implemented here, but - based on what I saw at John O'Donovan (scholar) and Constantine II of Scotland - it didn't work as designed. So I undid it. Angus McLellan (Talk) 18:03, 4 January 2009 (UTC)

There are two cases of "ed{{#if:{{{EditorSurname2|}}}|s}}." in he template, and I think the one that Martin suggested changing is to be the one that isn't used by the specific examples given. Martin: Check out lines 192 and 283 of the template - your change affected line 192 only. I suspect they both need to be changed. RossPatterson (talk) 17:29, 10 January 2009 (UTC)

Thanks, Ross. Admin - please replace

      }}, ed{{#if:{{{EditorSurname2|}}}|s}}.{{

and

        |{{{Sep|,}}} ed{{#if:{{{EditorSurname2|}}}|s}}.

with

      }}, ed{{#if:{{{EditorSurname2|}}}|s}}{{#ifeq:|{{{Sep|,}}}|.||.}}{{

and

      |, ed{{#if:{{{EditorSurname2|}}}|s}}{{#ifeq:|{{{Sep|,}}}|.||.}}

respectively. Martin (Smith609 – Talk) 00:24, 11 January 2009 (UTC)

 Done Ruslik (talk) 14:35, 16 January 2009 (UTC)

And I reverted it because it did not work on Jacobi polynomials. The Abramowitz reference was displayed as "Abramowitz, Milton; Stegun, Irene A., eds{{#ifeq|,|.||.}} (1965), …". -- Jitse Niesen (talk) 15:52, 16 January 2009 (UTC)

So many people engaged in this discussion, and still no solution is available! I probably need to try solving this enigmatic problem myself. Ruslik (talk) 16:36, 16 January 2009 (UTC)

{{editrequest}}

The correct fix is to replace

      }}, ed{{#if:{{{EditorSurname2|}}}|s}}.{{

and

        |{{{Sep|,}}} ed{{#if:{{{EditorSurname2|}}}|s}}.

with

      }}, ed{{#if:{{{EditorSurname2|}}}|s}}{{#ifeq:|{{{Sep|,}}}|.||.}}{{

and

      |, ed{{#if:{{{EditorSurname2|}}}|s}}{{#ifeq:|{{{Sep|,}}}|.||.}}

Thanks, Martin (Smith609 – Talk) 22:55, 19 January 2009 (UTC)

I has already made the change (there should be no | after #ifeq: or after #ifeq, as it was written initially. See mw:Help:Extension:ParserFunctions). Ruslik (talk) 19:53, 20 January 2009 (UTC)

Date formatting

I would like to suggest that this template reformat input like date=2009-01-10 into the format "10 January 2009". The DMY format is widely used for citations even in the United States (see [1] for example). Reformatting is already done on the AccessDate parameter, so it should be easy to apply the format to the Date parameter as well. —Remember the dot ^(talk) 20:01, 10 January 2009 (UTC)

Each template which calls the citation/core template has the option to specify a DateFormat= parameter to automatically format the date. Most templates have opted not to specify autoformatting. Martin (Smith609 – Talk) 00:17, 11 January 2009 (UTC)

Really? It looks like this template applies DateFormat to AccessDate but not to Date itself. —Remember the dot ^(talk) 00:26, 11 January 2009 (UTC)

Apologies; I misread you. Martin (Smith609 – Talk) 04:42, 11 January 2009 (UTC)

This version of the sandbox should format the date and publicationdate per the DateFormat parameter, which defaults to dmy. (It also includes the change in the section below). If this works, feel free to request the edit. Martin (Smith609 – Talk) 14:27, 28 January 2009 (UTC)

There's one error with the date formatting: if it tries to format a year, it produces 1901 instead of 1901. Martin (Smith609 – Talk) 13:55, 30 January 2009 (UTC)

Leading period with no author or title specified

The current version of this sandbox includes a fix so the punctuation before the 'journal' field is only displayed if an author, editor, title, or includedworktitle is specified. While I think this will work I haven't tested it; testing should be performed before anyone requests an edit. Martin (Smith609 – Talk) 14:22, 28 January 2009 (UTC)

Thanks for pointing the way. I found a couple of problems with that fix. First, it put the italicization of the journal title in the wrong place. Second, it included the period when either the author and title were specified, when what was wanted was to included it when just the title was specified. I did some further twiddling and got it to work; please see below. Eubulides (talk) 19:07, 30 January 2009 (UTC)

Test cases for stray dot problem

1. Neither author nor title: {{cite journal |journal= Arch Dis Child |year=2007 |volume=92 |issue=6 |pages=540–5 |doi=10.1136/adc.2005.086280 |pmid=17515625}}
   • With installed version: Arch Dis Child. 92 (6): 540–5. 2007. doi:10.1136/adc.2005.086280. PMID 17515625. {{cite journal}}: Missing or empty |title= (help)
   • With sandbox version:
2. Just author: {{cite journal |journal= Arch Dis Child |year=2007 |volume=92 |issue=6 |pages=540–5 |author= Dover CJ, Le Couteur A |doi=10.1136/adc.2005.086280 |pmid=17515625}}
   • With installed version: Dover CJ, Le Couteur A (2007). Arch Dis Child. 92 (6): 540–5. doi:10.1136/adc.2005.086280. PMID 17515625. {{cite journal}}: Missing or empty |title= (help)
   • With sandbox version:
3. Just title: {{cite journal |journal= Arch Dis Child |year=2007 |volume=92 |issue=6 |pages=540–5 |title= How to diagnose autism |doi=10.1136/adc.2005.086280 |pmid=17515625}}
   • With installed version: "How to diagnose autism". Arch Dis Child. 92 (6): 540–5. 2007. doi:10.1136/adc.2005.086280. PMID 17515625.
   • With sandbox version:
4. Both author and title: {{cite journal |journal= Arch Dis Child |year=2007 |volume=92 |issue=6 |pages=540–5 |title= How to diagnose autism |author= Dover CJ, Le Couteur A |doi=10.1136/adc.2005.086280 |pmid=17515625}}
   • With installed version: Dover CJ, Le Couteur A (2007). "How to diagnose autism". Arch Dis Child. 92 (6): 540–5. doi:10.1136/adc.2005.086280. PMID 17515625.
   • With sandbox version:

The first two cases currently fail. The last two currently work, and are included here as sanity checks to test that the fix doesn't break things. Eubulides (talk) 19:07, 30 January 2009 (UTC)

Please install this fix for the stray dot problem

{{editprotected}} Please install this edit, which fixes the problem for all the test cases listed above. The edit changes the following lines (lines 324 and 325 of the current version):

}}{{
  #if: {{{Periodical|}}}|{{{Sep|,}}} ''{{{Periodical}}}''{{

to these lines:

}}{{#if: {{{Periodical|}}}
    |{{#if: {{{IncludedWorkTitle|}}}{{{Title|}}}
       |{{{Sep|,}}} 
     }}''{{{Periodical}}}''{{

Please cut and paste from the sandbox edit, not from the source code of this talk page, as the talk-page source contains "&amp;#32;" when what we want is "&#32;" in the actual fix.

Eubulides (talk) 19:07, 30 January 2009 (UTC)

 Done Happy‑melon 20:26, 30 January 2009 (UTC)

Citations no longer ending in periods

Now that {{cite news}} has switched to cite/core, none of the news citations end in periods anymore. Can someone fix this? Kaldari (talk) 19:04, 30 January 2009 (UTC)

This was a Cite news problem and not a Citation/core problem. Pagrashtak 19:13, 30 January 2009 (UTC)

Invalid id attribute

{{editprotected}} Please replace the code with this revision of sandbox. It prevents invalid id attribute like "id=CITEREF". --fryed-peach (talk) 08:51, 6 February 2009 (UTC)

This change looks like it might have unintended consequences. The id= should be fixed, not removed, or harvard references using the template will be broken. And it's not immediately obvious what the other changes are for - could you explain these too? Thanks, Martin (Smith609 – Talk) 12:57, 6 February 2009 (UTC)

This change won't break proper harvard references which have |Surname1= or |EditorSurname1=. Others are cosmetic changes, which do you want me to explain? --fryed-peach (talk) 16:51, 6 February 2009 (UTC)

I didn't have time to take a careful look at the code before; it looked at first glance like you'd removed the id parameter altogether, although I now notice it's actually on the next line. The other changes I thought I saw were the removal of the date formatting, which isn't in the live template. This is waiting on an edit at Template talk:Date; would you be happy to wait for that to be implemented, then implement both your edit and the date formatting at once? I think it'll make things simpler if we avoid overlapping... Martin (Smith609 – Talk) 17:43, 6 February 2009 (UTC)

That's fine with me. --fryed-peach (talk) 18:22, 6 February 2009 (UTC)

Thanks. Template:Date has now been updated, so I've merged our two edits into the current sandbox. Perhaps you'd like to check that this is still working before we request an edit? Cheers, Martin (Smith609 – Talk) 22:52, 6 February 2009 (UTC)

My edit is merged correctly. --fryed-peach (talk) 14:33, 7 February 2009 (UTC)

Super. Would an admin mind merging this version of the sandbox into Template:Citation/core? Thanks, Martin (Smith609 – Talk) 16:13, 7 February 2009 (UTC)

Archival improvement

{{editprotected}} The current system for specifying archive details is imperfect; it is currently specified, quite clumsily, in the templates which call citation/core. This is a potential area of template drift; I have noticed discussion in several places about tweaking the system and it'd be much easier to implement these if the code was central. Therefore I've spent this morning bringing the Archive handling into Citation/core. This version of the sandbox contains an addition, which will continue to work alongside the existing code, and has been tested at Template:Citation/testcases/archive. It brings a number of immediate benefits, including better formatting and error-detection. It will not affect other templates until those templates are modified. In readiness for implementing other templates, please copy the current sandbox to Template:Citation/core. Note that this will also implement the change requested in the section above. Martin (Smith609 – Talk) 17:47, 7 February 2009 (UTC)

 Done. I'm particularly pleased to see the date formatting techniques employed consistently. Good job! Happy‑melon 23:13, 7 February 2009 (UTC)

It looks like this broke the year=2006b syntax in the case that you have two references with the same authors published in the same year, as noted on Template talk:Citation#Year bug. This syntax is suggested on Template:Harv and is in use. Should we revert? -- Jitse Niesen (talk) 18:06, 9 February 2009 (UTC)

The issue is at {{date}}, not here. Happy‑melon 20:53, 9 February 2009 (UTC)

The issue is not at {{date}}. Its {{citation/core}} that broke, not {{date}}. And {{date}} cannot possibly handle the range of date styles that are perfectly valid in a citation, but are not calendar dates. The only fields that can safely be passed on to {{date}} are those that will be assuredly calendar dates (i.e. access-date=), and even those should not be passed to {{date}} because it either clobbers the editor's preferred date format, or requires him/her to now use another parameter in order to not clobber the formatting. This is not backwards compatible, and its completely counter-intuitive.

Editors should define dates in whatever format is appropriate to that citation and in that article. The citation template should not ever second-guess the editor.

I have provided a fix for {{citation/core}} here. -- Fullstop (talk) 02:13, 10 February 2009 (UTC)

Removal of dateformat parameter

While I am inclined to agree with Fullstop, that all dateish parameters should be left alone by all cit(e)(ation) templates, the dateformat parameter should not have been removed, which removes what little control editors had over the matter. --Gerry Ashton (talk) 04:55, 10 February 2009 (UTC)

The change in question has been undone. --Gerry Ashton (talk) 05:26, 10 February 2009 (UTC)

If you follow what I wrote above, including the provided link to the fix (alt: {{citation/fixdate}}), you might also observe that the dateformat parameter is superfluous.

The "little control editors had over the matter" is not necessary when editors retain full control. JUST FOLLOW THE LINKS if you can't understand what I'm talking about. -- Fullstop (talk) 06:35, 10 February 2009 (UTC)

The Citation/fixdate approach seems like a good solution. I edited the documentation to indicate the valid range, which I determined through experiments at User:Gerry Ashton/sandbox3. --Gerry Ashton (talk) 17:13, 10 February 2009 (UTC)

Making it so YYYY-MM-DD converts to DD-MM-YYYY is such a stupid idea and is a major inconvenience, unless there is a bot that can go and fix articles that don't use that formatting. I don't recall a discussion, so why not go back to the better format? YYYY-MM-DD should display as YYYY-MM-DD. Or at least go back to letting editors pick the format, Template:Cite web had it right. Gerry, how has it been undone? I just tried using that parameter and it isn't working since articles are still displaying as DD-MM-YYYY in the ref section of Jeff Hardy (which I used the dateformat for in refs). TJ Spyke 03:08, 11 February 2009 (UTC)

Dates in the format YYYY-MM-DD are not accepted in any citation style because they are very unfamiliar to readers. You should not be using them. —Remember the dot ^(talk) 03:16, 11 February 2009 (UTC)

Had they not been the default in many cite templates, I wouldn't. This wasn't an issue either when we could just link the date (which would then display as either MM-DD-YYYY or DD-MM-YYYY depending on what the user has in their preferences), but then some users started complaining about how we shouldn't link dates in refs. TJ Spyke 03:24, 11 February 2009 (UTC)

Spyke, an example of how an access dates in the Jeff Hardy article displays is "8 October 2007". It is confusing to call this a DD-MM-YYYY format, because some might think you mean it dispays as "08-10-2007". Also, your statement "This wasn't an issue either when we could just link the date (which would then display as either MM-DD-YYYY or DD-MM-YYYY ..." is 99% false, because around 99% of our readers do not have accounts.

Finally, you asked how has it been undone? I didn't change anything (I am not an administrator). I surmise that the date processing function has been changed so it will convert dates in the YYYY-MM-DD format to the day-month-year format, and leave other formats alone. The dateformat parameter seems to be ignored. To fix the "Jeff Hardy" article, you could go in and convert all the dates like "2007-10-08" to "October 10, 2007". --Gerry Ashton (talk) 04:22, 11 February 2009 (UTC)

• This is a terrible change to the template. So if the dates need to be in MM-DD-YYYY, we now have to change them all by hand? Can someone at least give us a tool to do so? Something like Template:Citation/fixdate, but that putputs in American format, or a script that would permit international dates to be changed into American format in the thousands of pages that need that format? --2008Olympian^chitchat 04:52, 11 February 2009 (UTC)

I wrote a tool a while back that automatically converts ISO dates to either DMY or MDY format throughout the article: User:Remember the dot/ISO date format unifier.js. You might find that helpful. —Remember the dot ^(talk) 04:38, 11 February 2009 (UTC)

Personally, I'd rather use the "1 February 2000" format in all citations so that you don't have to worry about date formats at all when copying references between articles. —Remember the dot ^(talk) 04:43, 11 February 2009 (UTC)

Thanks! You wouldn't happen to know about one that changes from International to American or vice versa?--2008Olympian^chitchat 04:54, 11 February 2009 (UTC)

User:Lightmouse/monobook.js/script.js doesn't currently handle ISO dates in references or treat references differently from prose, but it can convert dates to and from US and international format. —Remember the dot ^(talk) 05:12, 11 February 2009 (UTC)

Lightmouse's script, unfortunately, does not reformat dates in references.--2008Olympian^chitchat 08:42, 11 February 2009 (UTC)

A tool that converts YYYY-MM-DD to a format with month names is fairly safe, because few quotations will have the YYYY-MM-DD format. A tool that changes American to International or vice versa is tricky; the operator will have to make sure it isn't allowed to change dates within quotations.

Date format described as YYYY-MM-DD is ISO based style.--Namazu-tron (talk) 05:22, 11 February 2009 (UTC)

Given that {{date}} is designed to be completely transparent when its dateformat is set to "none", surely the least disruptive way to stop the citation templates from reformatting dates undesirably is simply to default the |dateformat= parameter to "none" on all templates? This is already done on many of the templates, with complete success:

• {{cite web|url=http://example.com|title=Title|year=2007a|last=Smith}}
  • Smith (2007a). "Title".
• {{cite news|url=http://example.com|title=Title|year=2007a|last=Smith}}
  • Smith (2007a). "Title".
• {{cite journal|url=http://example.com|title=Title|year=2007a|last=Smith}}
• {{cite book|url=http://example.com|title=Title|year=2007a|last=Smith}}
  • Smith (2007a). Title.
• {{citation|url=http://example.com|title=Title|year=2007a|last=Smith}}
  • Smith (2007a), Title

Spot the difference. This 'fix' was, in my opinion, rather rushed. Happy‑melon 08:55, 11 February 2009 (UTC)

• "Spot the difference" between doing nothing and doing nothing? Citation does not have to call another template to do nothing. Citation is quite capable of doing nothing all by itself. Its rather bizarre to suggest that one template should call another template with an explicit command to do nothing.
• Since breakage to ./core was HappyMelon's responsibility (as committing admin), and it was HappyMelon's opinion that a revert need not be done, HappyMelon is not in an ideal position to determine what constitutes "rather rushed". It was his own actions that precipitated the need to find another solution that doesn't break citations. That {{date}} (or any other date-formatting routine) can't be called for anything but access-date= has been known for at least a year. No question of "rather rushed" there.
  Instead, it was the changes that caused the breakage that were "rather rushed"; it was the update to citation/core that was "rather rushed"; it was the supposition that {{date}} was at fault for the breakage that was "rather rushed"; and it was the carry-over of cite xyz legacy crapola into citation/core that is "rather rushed".
  All these things happened because someone did not think things through, and did not invite discussion which might have caused the error to be noted. A template used by tens of thousands of articles demands a conservative approach, and a shoot-first approach is inexcusable. Moreover, because mistakes happen even when the greatest of care is taken, the first sign of breakage should automatically provoke a revert. Immediately. Excuse-finding, dilly-dallying and oh-hum-the-breakage-is-elsewhere is completely unacceptable.
• Citation/fixdate does what {{date}} does not do, and was not designed to do. {{Date}} (or any other date-manipulation routine) cannot be called for data that is not assuredly a calendar date. That is why (previously) citation never called {{Date}} for anything but access-date=. This should be patently obvious to any template-coder who also actually writes citations on a regular basis (as distinguished from someone just abstractly thinking about them).
• TJ Spyke's and 2008Olympian's comments above indicate that they haven't understood what is going on. Relax. Nothing is broken anymore, which is not what can be said for the state of affairs before the so-called "rather rushed" fix, the documentation for which can be read at {{citation/fixdate}}. There was no such thing as a 'DD-MM-YYYY' date format, and it is not meaningful to suddenly begin writing dates that way. There is no need to change anything (which too cannot what can be said for the state of affairs before the so-called "rather rushed" fix).
  The obsolete notion that {{cite xyz}}'s date= fields need to be in yyyy-mm-dd (NOTE) format was to facilitate date linkage (by {{cite xyz}}). Regardless of how dumb it was to begin with, that practice is history now, and there is no need for that yyyy-mm-dd silliness anymore. Besides, it was only ever {{cite xyz}} (not {{citation}}) that did such gratuitous date linking, and if {{cite xyz}} has this legacy to live with, then {{cite xyz}} needs to wipe its own backside before calling citation. -- Fullstop (talk) 18:39, 11 February 2009 (UTC)

Fullstop, regardless of it being unnecessary for the YYYY-MM-DD format any longer, it is used in thousands of articles, so unless someone fires up a bot to correctly identify and correct the YYYY-MM-DD dates so they are formatted in the correct date format (US or International), there is going to be problems with articles having some citations displaying YYYY-MM-DD and others displaying DMY. Citation/fixdate also seems to be causing issues with calling #time too many times on articles with a large number of sources. As an example, Barack Obama has 215 sources at the moment and source 181 displays "Error: too many #time calls" instead of the publication date. I don't recall seeing this problem prior to citation/fixdate being implemented. --Bobblehead ^(rants) 23:07, 11 February 2009 (UTC)

Not only is fixdate slow, it displays dates incorrectly when editors want ISO format dates. Let's get rid of fixdate. Please see #Please don't mess with editor's date format below. Eubulides (talk) 23:11, 11 February 2009 (UTC)

@Bobblehead: citation/fixdate replaced citation's previous calling of {{date}} for everthing, so citation would in fact have previously caused the error at ref 181.

@Eubulides: There is no such thing as a "slow" template on Wikipedia. It is however wasteful to do the same 'X' multiple times in citation/core. Thats what citation is there for, i.e. to do 'X' once, and then pass the results to core.

@Eubulides: As I said elsewhere, citation should not ever be second-guessing editors. But I'm curious: when would an editor want ISO format dates in a citation?

-- Fullstop (talk) 09:20, 12 February 2009 (UTC)

YYYY-mm-dd dates are compact, most-significant figure first, internationally unambigious (translatable), numerically machine parsable (date extraction/date conversion), sortable and can be abbreviated just YYYY-mm or just YYYY. I do want to use YYYY-mm-dd dates in every non-prose location I can. —Sladen (talk) 12:07, 12 February 2009 (UTC)

I also prefer YYYY-mm-dd in citations, for compactness there. Citations are not English text and normally use short notations that wouldn't be acceptable in main text (e.g., "3" rather than "volume 3", "JAMA" rather than "Journal of the American Medical Association") and dates are no exception to this rule. Eubulides (talk) 21:30, 12 February 2009 (UTC)

Any consistent date format is machine-parsable; dates don't have to be numeric for that. Sortability is not an issue in citations either -- it's a citation, not a list. Translation is an issue, but not a very large one because English citations should be avoided in non-English projects as much as possible. And however much they abbreviate to save ink, no manual of style recommends using YYYY-mm-dd dates in citations. —Remember the dot ^(talk) 23:07, 12 February 2009 (UTC)

Umm, this is not really the place to get into date-format wars, but ISO 690 ("Information and documentation—Guidelines for bibliographic references and citations to information resources"), perhaps not surprisingly, does say it's OK to use YYYY-mm-dd dates in citations, and recommends it over all other numeric styles. If you take a look at this set of examples of the use of ISO 690 format for citations, it contains only one example that has year, month, and day, and that example uses YYYY-mm-dd format. Eubulides (talk) 02:50, 13 February 2009 (UTC)

Section break

@Fullstop: quite simply, no. There is no responsibility on me as the committing admin to ensure that the changes made are technically correct, that they do not contain bugs, or to resolve any such issues if they arise. Nothing in the protection policy even requires that the committing admin have any knowledge of template code; literally any admin can copy a sandbox to a live page. All that is required is that there be "consensus" for the edit, either explicit or implicit, and in the case of changes to templates, there is a precedent that 'technical updates' - that is, edits that change the internal structure of a template but are not intended to affect its input or output - are uncontroversial if they really do function as intended. Of course, since there is no explicit consensus for such an edit, it is not considered wheel-warring for another admin to revert it for any reason. This is what I agree should have happened here. You are almost correct when you say that "the first sign of breakage should automatically provoke a revert"; the only word I disagree with is "automatically": if the procedures for admin action were so clear-cut, they could be written into software routines and admins would be unnecessary. If I had been online at 6am on 10 Feb, I would probably have reverted it myself; any admin who was online would have been completely correct to do so. That is the responsibility that the committing admin has, to revert their changes if it is clear that the apparent consensus was not in fact present. However, once the 'fix' was implemented, the whole situation changes. What would you consider my position to be if I had also been the admin to commit your equally unsuccessful code? It is rather unkind to conclude that I would thereby be responsible both for breaking the template in the first place, and then in failing to fix it, when all I would have done is implement two changes suggested by other editors.

It is very widely accepted, indeed fundamental policy, that administrators are otherwise equal members of the community with all other editors; only when taking administrative actions do we wear our 'admin hats'. As such, you completely misinterpret this comment if you think I was in any way making an 'executive decision' that no reversion was necessary; as the edit summary suggests, I was making a comment in the capacity of an editor familiar with the structure of the templates involved. On the contrary, as more details of the scale of the problem surfaced, I would (had I still been online) have supported its reversion. In almost no situation is it the wrong approach to simply revert a page to the previous stable version, particularly with templates. Then we could have taken the time to construct a superior solution that avoids throwing the baby out with the bathwater (or at least allows us to decide properly whether we want to keep the baby before chucking it). That is what I mean when I say the 'fix' was rushed.

In general, of course, if you feel that my actions constitute a misuse or abuse of administrative tools, you're looking for WP:AN or WP:RFC.

Generally: It seems that there is a growing consensus that the citation templates should not attempt to be 'clever' enough to anticipate what output format is desired. This is an entirely separate question to whether the citation templates should be 'clever' enough to be able to reformat dates if asked to do so. By removing all date formatting entirely, we return to square one; why did we ever take that circular road if square one is where we want to be? This whole issue is about effort-minimisation: we seek to reduce the amount of time we require editors to put in to produce professional, consistent citations. Editors will enter dates in a myriad of different input formats - generally, whatever is most natural for them - and yet we want them to be consistently output. We have come to realise that attempting to guess which output format that should be is a Bad Idea, so we accept the need to make some form of edit to each citation to aid in standardisation. In this context, we lose nothing by continuing to provide the option to specify a |dateformat= parameter; IMO it is by far the easier way to standardise citations across a page; simply go to an article, decide which date format it should use, then add |dateformat=xxx to all the citation templates there, error-checking as necessary. The alternative is, as noted, to manually change all the input dates to the correct format. This method is, of course, always available, and is in no way in conflict with a |dateformat= method.

So you ask what the difference is between "doing nothing and doing nothing"? It's the fact that, if asked to do something by an editor who just wants to get on with writing an article, one of them will actually do it, while the other will simply say "no, do it yourself". Which is the more constructive approach? We seem to be in agreement that having the template do things without being asked is Bad. That is not the same as saying that the template should not be able to do them at all. Happy‑melon 16:25, 12 February 2009 (UTC)

I infer that Happy-melon thinks that it is inevitable that editors "enter dates in a myriad of different input formats - generally, whatever is most natural for them". I disagree. I think that editors who take the trouble to use a citation template understand the custom of making citations consistent within an article, and will comply with whatever the usage is in the artcie. However, we have made it very difficult for editors to do this, because

• Articles often have inconsistent date usage, so the editor can't decide which one to use
• Editors of existing articles have to deal with whatever templates are already in use, so must be able to use the gazillion different Citation/Cite xyz templates. These templates have conflicting instructions and behaviour with respect to dates
• There is no style manual that guides the development of these gazillion different templates, so neither article editors nor developers can decide which templates are right and which ones are wrong.

In short, editors enter a myriad if different date formats because the Citation/cite xyz editors have made it nearly impossible for them to do otherwise. --Gerry Ashton (talk) 16:41, 12 February 2009 (UTC)

I agree fully with that conclusion, with the exception of the first statement: I don't think it is inevitable, but I do think it is customary. I can count myself as a prime example here: I find it much easier to enter dates in yyy-mm-dd format into citation templates, and substantially quicker too. I am usually careful to follow the style of the article, but I find it "inconvenient" to do so by changing the input format: for me, the |dateformat= parameter is much easier, and I'm sure it is for many other editors too; equally there is a large group of people for whom that parameter makes no sense whatsoever, and they'd rather just change the input format. For every template, style and format, there is a large block of editors who are accustomed to using them, and they are the people we're trying to help here. As long as the options we provide are not conflicting, there is no harm in providing more than one; by providing a variety of 'options' (and I say that with a pinch of salt because the "change the input format" 'option' is not really something we can not support :D) we can make the process as easy as possible for the greatest number of editors. Happy‑melon 08:53, 13 February 2009 (UTC)

{{date}} (or any other kind of format conversion) is in fact "really something we can not support". It only works when a date is assuredly a calendar date, and A) "dates" in citations are not necessarily calendar dates, B) anything based on #time requires the input to be a calendar date. Moreover, as we have seen, there are editors who actually prefer seeing yyyy-mm-dd dates, so there isn't even a legacy-mode certainty. A "change the input format" option did not exist before, and the notion that "we can make the process as easy as possible for the greatest number of editors" is a fiction when it adds a new layer of complexity. The process is simple when things are kept simple. And if anyone "likes" to write "X", then "X" is exactly what they should see. Citation is a citation template, and not a date formatter. And date is a date template, not a citation formatter. One tool, one job. Citations don't benefit from a change of date/date-style, so enough already. -- Fullstop (talk) 14:01, 13 February 2009 (UTC)

ps:There are umpteen never/rarely used date-manipulation templates that could benefit from consolidation with {{date}}.

I don't consider a method of entering dates in citations to be supported until the following occurs:

1. Every Cite xxx and Citation template accepts the same syntax for that subset of dates that apply to it.
2. Any Cite xxx templates that are not used enough to bother supporting them are deleted, and a bot converts usages of the deleted template to a more popular template.

History suggests we are not able to provide this level of support. --Gerry Ashton (talk) 17:54, 13 February 2009 (UTC)

Fullstop, how can you suggest that "A 'change the input format' option did not exist before"? When has entering a date into a citation template in a different format (with the exception of accessdates in the datelinking era) not been a way to alter the output format?

The "layers of complexity" argument is a strawman when editors who are not familiar with the extra levels are not required to use them; as I said above, including support for a |dateformat= parameter in no way conflicts with editors' ability to 'fix' citation templates simply by changing the input format, nor should it. {{citation}} is a method for producing inline citations in a consistent and professional manner, part of which is to ensure that dates are appropriately and consistently rendered. The template is indeed not a date formatter, that's why it calls a separate template to handle that functionality. There is no logic in saying that because its primary purpose is not date formatting, it should not in any circumstance even delegate that task.

Gerry, once again I fully agree. The number of underused citation forks is obscene. Happy‑melon 20:34, 13 February 2009 (UTC)

Please don't mess with editor's date format

The recent changes to the citation templates have caused problems with the pages I help edit. For example, this pair of citations, taken from the featured article Daylight saving time:

• {{cite paper |author= Mark Gurevitz |url=http://opencrs.cdt.org/document/RS22284/ |accessdate=2007-06-01 |title= Daylight saving time |publisher= Congressional Research Service |version= Order Code RS22284 |date=2006-04-04}}
• {{cite news |author=Rick Kissell |title= Daylight-saving dock ratings |work=Variety |date=2007-03-20 |url=http://www.variety.com/article/VR1117961488.html |accessdate=2007-05-16}}

currently generates this:

• Mark Gurevitz (2006-04-04). "Daylight saving time". Order Code RS22284. Congressional Research Service. Retrieved 2007-06-01. {{cite journal}}: Cite journal requires |journal= (help)
• Rick Kissell (2007-03-20). "Daylight-saving dock ratings". Variety. Retrieved 2007-05-16.

The formatting is currently inconsistent. The first line has the behavior that I want, except that it wikilinks the date, a longstanding bogosity which I assume will be fixed eventually. The second line reformats the date to use a format like "20 March 2007", which is even worse: I want the date to appear the way that I wrote it. This behavior of the second line is new, and is a step backwards.

I notice above that several people have requested that the citation templates stop reformatting dates, and just use the dates that editors prefer. Currently this has been done, except when editors prefer ISO format dates. There should be no exception: if an editor prefers ISO format dates, it's not this template's job to override the editor's preference.

There's a simple fix for the problem: remove all occurrences of {{Citation/fixdate}} from {{Citation/core}}. I have tested this with an edit to the sandbox. This simple change will make the templates easier to use and to describe. There is a backward-compatibility concern with accessdate=, but that is a relatively minor issue compared to the continuing and longrunning hassles of messing with what editors write. I also realize that this fix will not fix the {{Cite paper}} problem with wikilinking dates until that template is adjusted to use {{Citation/core}}, but that's OK: we can make that change later. Eubulides (talk) 22:30, 11 February 2009 (UTC)

Notice to Eubulides: You are put on notice that the ISO 8601 standard requires the use of the Gregorian calendar. Henceforth, if you write a Julian calendar date in the format YYYY-MM-DD and describe it as an ISO date, you will have lied. --Gerry Ashton (talk) 22:37, 11 February 2009 (UTC)

That's fine, and it doesn't affect my request. Wikipedia article citations invariably use ISO format to specify Gregorian dates, so the point about Julian dates has no practical relevance to the main subject of this thread. Eubulides (talk) 22:45, 11 February 2009 (UTC)

No, books and monuments from before the conversion to Gregorian can be cited. Of course, if you only consider the access date of on-line resources, you would be right.

Yes, in theory date= could mention a Julian date using ISO format. However, in practice, articles on older subjects (for example, John Dee, Philitas of Cos) simply don't do that. So in practice the proposed change won't affect any formatting of Julian dates. Any problem in future use of this template can be handled simply by documenting the new behavior (something that should be done anyway, of course). Eubulides (talk) 23:24, 11 February 2009 (UTC)

So, are we in agreement that dates in citations should simply be displayed as entered? —Remember the dot ^(talk) 23:26, 11 February 2009 (UTC)

Considering {{citation/fixdate}} breaks cites in articles with a large number of sources, dear god, yes.;) --Bobblehead ^(rants) 23:28, 11 February 2009 (UTC)

Yes. The breakage to Barack Obama described above in #Removal of dateformat parameter sounds relatively urgent, so I just now added {{editprotected}} to this request. Eubulides (talk) 23:49, 11 February 2009 (UTC)

Okay, dates should now be displayed as entered: what you see is what you get. This is a lot simpler and more straightforward, but it also means that we will have to actively convert dates like "2009-02-11" to the format "11 February 2009". I created a tool, User:Remember the dot/ISO date format unifier.js, that can help do this automatically. —Remember the dot ^(talk) 01:45, 12 February 2009 (UTC)

Remember the dot, could you explain where to look to get Javascript functions to work in Wikipedia, and what to look for on the screen if your function has been successfully installed? --Gerry Ashton (talk) 03:15, 12 February 2009 (UTC)

Add the line

importScript("User:Remember the dot/ISO date format unifier.js")

to your monobook.js page and clear your browser cache to install my tool. "Format ISO dates in American style" and "Format ISO dates in international style" will appear in the toolbox on the left when editing pages. The procedure for Lightmouse's script is similar, only the code is

importScript("User:Lightmouse/monobook.js/script.js")

—Remember the dot ^(talk) 06:37, 12 February 2009 (UTC)

good going. Thanks for the care you've taken with everything. -- Fullstop (talk) 09:23, 12 February 2009 (UTC)

Thanks, I got it working. A word of caution: there are more Cite xyz templates than I can count, and there is no telling what some of them might do with a date not in the form YYYY-MM-DD. Editor's using the unifier script must examine the name of the template and determine whether the template can support the change. --Gerry Ashton (talk) 16:10, 12 February 2009 (UTC)

Scripts to update formats

If the community of stakeholders has decided on the format for dates in citations, that is good. It may be possible to amend User:Lightmouse/monobook.js/script.js to update the formats at the same time as its other tasks. Perhaps Lightbot can help too.

The format yyyy-mm-dd is a great benefit in many applications that are international and/or reference in nature. It is/was commonly used in citations on Wikipedia and that seemed to me to be a good thing. However, that is just my opinion.

It would be good to be able to refer to a document and/or a talk page if somebody queries a change in citation format. I certainly wouldn't be able to defend the decisions of the citation stakeholder community otherwise. Lightmouse (talk) 20:10, 13 February 2009 (UTC)

I don't see any consensus in the above discussion as to the format for dates in citations. Like you, I prefer the yyyy-mm-dd format, and at least one international style guide (ISO 690) allows it, but obviously there's no general agreement on this. As a practical matter I expect that articles about military history will tend to use military-style dates, articles about international standardization will tend to use ISO format dates, and so forth. There are advantages to using the same date format everywhere, but they seem to be less than the advantages of letting articles use date formats suitable for the topic in question. Eubulides (talk) 20:37, 13 February 2009 (UTC)

I'm not sure firing up a bot to make the change is necessary now that the dates are displaying as they are entered.. It doesn't exactly hurt anyone to have YYYY-MM-DD display in the citations. For those articles that want to convert ISO to DMY or MDY, then they can either use Remember the dot's script or the updated version of yours... or do it manually. --Bobblehead ^(rants) 20:45, 13 February 2009 (UTC)

OK. Thanks for the response. Lightmouse (talk) 11:07, 14 February 2009 (UTC)

There are "signal" templates that can be used to tell a bot what format a particular article uses. If I'm remembering things right, in articles that have that sort of signature, bots can routinely ensure that dates in an article have a consistent date format. IIRC, there are all sorts of tweakable things (like means to prevent some dates from being converted), but thats the gist of it.

I have no personal experience with this facility (I only read about it somewhere). Perhaps Lightmouse knows more? -- Fullstop (talk) 16:40, 14 February 2009 (UTC)

Here is what I know:

• There is a proposal at Template talk:Dmy
• There is a proposal to use invisible categories.
• Some templates have configurations (e.g. 'Birth date and age|1953|5|6|df=yes') but they are often wrong. So they can't be used to adjust the whole article.
• A script User:Lightmouse/monobook.js/script.js allows a human user to select dmy or mdy for an article with just one click. For example, if they have selected 'dmy', the script will force mdy dates into dmy.
• It is possible for bots to use the same code as the script with some limited success. Article titles can be used as a clue to the format that is 'correct' according to the current mosnum guidance.

Incidentally, although I have done a lot of work to help make date formats consistent, it isn't as important to me as it is to other people. Outside Wikipedia, I hardly notice if a format is dmy or mdy. It is less important to me than spelling variation. Lightmouse (talk) 11:46, 15 February 2009 (UTC)

Change "Retrieved on" to "Accessed"

{{editprotected}} We seem to have consensus here that "on" should be removed. It's located in the "<!--============ URL and AccessDate ============-->" area, near the bottom of the code. change:

| <span class="reference-accessdate">{{#ifeq:{{{Sep|,}}}|,|, r|. R}}etrieved on {{{AccessDate}}}</span> to:

| <span class="reference-accessdate">{{#ifeq:{{{Sep|,}}}|,|, r|. R}}etrieved {{{AccessDate}}}</span>

thanks!
— Ω (talk) 02:40, 14 August 2009 (UTC)

 Done —TheDJ (talk • contribs) 00:17, 16 August 2009 (UTC)

---

Currently, a citation like this:

• {{cite web |url=http://google.com |title= Google |accessdate= 13 February 2009}}

displays like this:

• Google. Retrieved on 13 February 2009.

Let's make this a bit shorter, and closer to the what the parameter name says, by replacing "Retrieved on" with "Accessed", so that it looks like this instead.

• Google. Accessed 13 February 2009.

Subtracting a word (and a syllable) will make our citations slightly easier to read. Also, many style guides seem to prefer "Accessed", at least if I judge by examples, e.g., the AMA style guide,[2] Turabian[3], and the ACS style guide.[4]

The implementation of this change is straightforward. In the template, replace this line:

| <span class="reference-accessdate">{{#ifeq:{{{Sep|,}}}|,|,&#32;r|.&#32;R}}etrieved on {{{AccessDate}}}</span>

with this line:

| <span class="reference-accessdate">{{#ifeq:{{{Sep|,}}}|,|,&#32;a|.&#32;A}}ccessed {{{AccessDate}}}</span>

Eubulides (talk) 21:28, 13 February 2009 (UTC)

Just for some background reading—according to Template talk:Cite web/Archive 1, the phrase "URL accessed on..." was changed to "Retrieved on..." in May 2006, although not everyone seemed happy about it. At Template talk:Cite web/Archive 3#Redundant word "on" before the date and Template talk:Cite web/Archive 4#AGAIN: Redundant word "on" before the date, Tony tried to push to get "on" removed, but it didn't seem to happen. Personally, I think we could remove "on", but we need to make sure that we do it simultaneously in the cite templates that aren't based on Citation/core. As for Retrieved/Accessed, I guess I'm indifferent. Pagrashtak 21:59, 13 February 2009 (UTC)

Thanks, I read through that old discussion. Among style guides I saw only the APA style guide mentioned; this has been changed since that old discussion. According to [5] the current APA style guide uses a format like this:

"Retrieved May 2, 2006, from http://www.alistapart.com/articles/writeliving"

That is, there is no "on" after "Retrieved". The "on" is my biggest beef with the current Wikipedia template. Clearly the word "on" should be removed. I don't think we need to wait for universal agreement among all the templates here; the other templates are inconsistent with this one in other ways, this wouldn't be that big a deal by comparison with the other issues, and we can update the other templates later. Eubulides (talk) 22:23, 13 February 2009 (UTC)

No—we need to get agreement and remove it everywhere. If you pull it out of only some of the templates you're going to get a lot of complaints from FA writers that you've created inconsistencies in their articles that they can't fix without manually formatting their references. It has a good chance of getting reverted. It may not seem like a big deal to you, but trust me—it is a big deal to a lot of other editors. Pagrashtak 14:13, 16 February 2009 (UTC)

Most other templates now generate their 'retrieved on' text using {Citation/core}. (There may be a couple of templates where discussion regarding the change is ongoing; feel free to hurry things along there if it accelerates your reaching a resolution here). Therefore one change made here would affect all cite templates at once. [Consequently it should be at least mentioned on all the talk pages of affected templates!] Martin (Smith609 – Talk) 14:58, 16 February 2009 (UTC)

I just wanted to throw my support behind the removal of the word "on". I don't have a real opinion about use of "Retrieved" vs. "Accessed", though.
— Ω (talk) 09:09, 7 August 2009 (UTC)

(← indent) I support either "Accessed" or "Retrieved" (without the "on"). Plastikspork (talk) 19:16, 7 August 2009 (UTC)

origyear where year missing

There are articles where {{cite book}} has been used with an "origyear" parameter but no "year" parameter. Until a few months ago this worked, in that the origyear parameter always got printed. When the template structure gor reorganised "origyear" was at first forgotten about, then reinserted on 12 December. However this was done so that it was only used where "year" was also present. I raised the problem on the Template talk:Cite book page on 16 - 19 December, and it was agreed that it could and should be rectified, but nothing got done. On looking at it, it seems to me that it could easily be put right, as follows.

Where at the moment the code in Citation/core has #if: {{{Date|}}} | ({{{Date}}}){{ #if:{{{YearNote|}}} | [{{{YearNote}}}] }}

it could perhaps instead have #if: {{{Date|}}} | ({{{Date}}}) #if:{{{YearNote|}}} | [{{{YearNote}}}]

I wonder if someone with the right skills and privileges might check out this change and make it? Thanks. SamuelTheGhost (talk) 16:52, 1 March 2009 (UTC)

I'd be happy to implement the change, if it works - the best thing would be to test out your suggested edit in Template:Citation/core/sandbox and check that it works as you expect. If so, give me a nudge and I'll make the edit. Martin (Smith609 – Talk) 14:55, 31 March 2009 (UTC)

Change to way archived links are handled

Hello,

I am currently working on a BOT that will greatly increase the percentage of cites with archived versions. You can read the details here: Wikipedia:Bots/Requests_for_approval/WebCiteBOT

As part of the discussion, I came to the conclusion that most users (see discussion there) would prefer working URLs with archived versions to be displayed more like:

Last, First (2008-12-20). "Article Title", Coolstuff.com, Retrieved on 2009-01-25. (Archived on 2009-01-26.)

with the main link being to the page & the secondary one being to the archive unless the actual page is now dead in which case the archive URL would become the main one.

If this change is indeed desirable, I think it can be accomplished through Citation/Core, although it may have to go through all the individual templates that use it. In either case, a new parameter such as "DeadURL" would be added. The idea being that if that parameter is set to 1, the archive URL is used as the main one. Otherwise, the original URL is used, much like is done currently.

Any opinions on how best to proceed? --ThaddeusB (talk) 21:30, 5 March 2009 (UTC)

Proposal to change accessdate handling

I am currently trying to make the citations in a large article uniform, because it's undergoing FAC. The last access dates currently appear in the following form:

retrieved on 2009-03-24.

Above in section #Change "Retrieved on" to "Accessed" there is a proposal that would change this to:

accessed 2009-03-24.

Of course I could easily get either of:

retrieved on 24 March 2009.

retrieved on March 24, 2009.

But that's not what I want. In my opinion the exact day of access is excessive precision. And if we drop it, we can avoid the date format issue altogether. What I would like to do is one of the following:

retrieved March 2009.

accessed March 2009.

Unfortunately it doesn't seem to be possible. Obviously, if I just try "access-date=March 2009" I get the following unacceptable result:

retrieved on March 2009.

Am I doing anything wrong here? If not, can we please have the word "on" removed? --Hans Adler (talk) 11:54, 31 March 2009 (UTC)

PS: Date autoformatting was removed from this template, but the documentation for Template:Citation was not updated to reflect this. But I am not sure whether to remove mention of the "dateformat" parameter altogether or mark it as not currently in use. --Hans Adler (talk) 11:54, 31 March 2009 (UTC)

I too would like to remove "on", but have not had the time and energy to pursue it yet. PS. Although I understand your dislike of the exact date of retrieval, all the style guides I know of ask for the full date, I guess under the theory that the Web changes often enough so that the exact date matters. Eubulides (talk) 14:42, 31 March 2009 (UTC)

This theory is clearly erroneous for convenience links to scholarly articles, but of course you know that. Are you talking about WP style guides (which ones?) or external ones? --Hans Adler (talk) 15:42, 31 March 2009 (UTC)

External guides. They all use full dates. Convenience links to scholarly articles by and large do not need accessdate= at all. If they're published by a stable source (e.g., Oxford University Press) a DOI or URL suffices and no accessdate= is needed. If they're published at some academic's personal page then they should have full date, as academics move around. Eubulides (talk) 16:11, 31 March 2009 (UTC)

Thanks, that's good advice. I will try to remove them and hope that nobody adds them again. However, even academics' homepages tend not to move around several times a month. --Hans Adler (talk) 16:17, 31 March 2009 (UTC)

Can anyone think of any compelling reason to keep the 'on'? I can't see one. The edit would be pretty simple to implement if supported by consensus. Martin (Smith609 – Talk) 14:52, 31 March 2009 (UTC)

Agreed. I just now checked three standards and none uses "on":

• a Chicago Manual of Style example, which uses "accessed June 1, 2005"
• a Turabian example, which also uses "accessed June 1, 2005" (not too surprising as Turabian is based on Chicago)
• an ISO 690-2 example, which uses "cited 1994-08-04"; the standard itself that you should use 'the word "cited" or an equivalent term'.
• I suppose somebody should plant notices in the talk pages for {{cite journal}} etc., asking about the "on", and separately (if we have the energy) about "retrieved"/"accessed"/"cited". I'll add that to my list of things to do if nobody else wants to do it.

Eubulides (talk) 16:11, 31 March 2009 (UTC)

Vote on date autoformatting and linking

The Vote on date autoformatting and linking is now open. All users are invited to participate. Lightmouse (talk) 15:08, 31 March 2009 (UTC)

Separator in list of authors

Currently this is hard coded as ; which presents a problem when trying to generate Vancouver style citations (as used by nearly all biomedical journals and by PubMed) which are separated by a comma between authors. This forces articles to use author=[[Any Body Jones|Jones AB]], Smith CD, Gold EF instead of using the author1-link=Any Body Jones that would normally be expected. Could we have a parameter that would allow editors to choose a comma for this instead, much as the Sep parameter allows choice elsewhere? LeadSongDog come howl 19:21, 1 April 2009 (UTC)

I've implemented the parameter |AuthorSep= for this purpose; for testing purposes, use Template:Citation/core/editprotected. Once you are convinced that my edits work correctly in all circumstances, let me know (or post an editprotected request) and I'll gladly implement it. Martin (Smith609 – Talk) 21:02, 1 April 2009 (UTC)

Thank you, I'll check it out.LeadSongDog come howl 22:16, 1 April 2009 (UTC)

I suspect I'm not trying the right approach to testing, but no luck. I get Augenbraum, Harold; Fernández Olmos, Margarite, eds. (1997), "Introduction: An American Literary Tradition", The Latino Reader, Boston: Houghton Mifflin, ISBN 978-0395765289 for instance. LeadSongDog come howl 23:17, 1 April 2009 (UTC)

Which template are you using - Citation, or Cite journal? The calling template also needs some modification; let me know which one you are using and I'll create a sandbox of those too. Martin (Smith609 – Talk) 18:45, 2 April 2009 (UTC)

I tried using Citation/Sandbox and Citation/testcases, then reverted after failure. Please see my contribs yesterday. LeadSongDog come howl 19:14, 2 April 2009 (UTC)

I think I've got it now: Smith; Jones; Western, {{citation}}: Missing or empty |title= (help); Unknown parameter |author-separator= ignored (help); Unknown parameter |lastauthoramp= ignored (|name-list-style= suggested) (help)

I'll leave further testing to you, and implement the change here on your approval. The change should probably also be requested at Template:Citation, Template:Cite journal and Template:Cite book. Martin (Smith609 – Talk) 23:42, 2 April 2009 (UTC)

I've run through all the Citation/testcases and added a few new ones. They work as expected except that when no author-seperator value is specified there is no default. I'd have expected the default to be a semicolon. I'll leave the test cases for now, feel free to revert. I'll move on to Cite journal/testcases tomorrow. Thank you for your efforts.LeadSongDog come howl 03:50, 3 April 2009 (UTC)

If you leave the parameter blank, then the template assumes that you are specifying 'author-separator=*none*' - this is how the WP software works. Implementing a workaround would be possible, but I don't think it should be done, because if there was some reason for removing the separator (say it was included with author surnames or something), it would be impossible to do so. Martin (Smith609 – Talk) 14:07, 3 April 2009 (UTC)

If I understand things correctly, this shouldn't be a big problem. It just means that all users of Citation/core need to be updated to set the new parameter before Citation/core is updated. --Hans Adler (talk) 14:35, 3 April 2009 (UTC)

How could we roll out the change if it would break every extant usage of the template that didn't have an explicitly provided author-sep value? LeadSongDog come howl 16:10, 3 April 2009 (UTC)

I understand Martin as referring only to Citation/core. If that's what he means, the default can still be set to ";" in Citation, Cite journal etc. This must be done before the change to Citation/core goes live; otherwise they would indeed be broken. --Hans Adler (talk) 21:11, 3 April 2009 (UTC)

Gotcha. I'll give it a whirl later. Say, there are two spellings separator and seperator used in the Citation sandbox. I wonder how widespread that is?LeadSongDog come howl 22:39, 3 April 2009 (UTC)

• Actually, no other templates should need updating; if citation/core is not passed any parameter, it will default to a semicolon. Only if it explicitly sent a blank parameter will this default be overridden. Martin (Smith609 – Talk) 23:01, 3 April 2009 (UTC)

Great. I guess what I saw was just because of the typo in the Citation/Sandbox code:

  |AuthorSep = {{{author-separator|{{{author-seperator|;}}}}}}
  |Sep = {{{separator|{{{seperator|,}}}}}} 

This second line is also present in the current Citation code. Or is this explicit code to tolerate an input error? LeadSongDog come howl 23:38, 3 April 2009 (UTC)

I'm not quite sure what you mean. The 'separator' / 'Sep' parameters are for the separators between fields such as the title and journal: Authors, "Title", Journal {{citation}}: Unknown parameter |separator= ignored (help)

By specifying a default there, it doesn't matter if the default at citation/core is changed; the template itself will display the same default behaviour. Does that answer your question? Martin (Smith609 – Talk) 15:08, 4 April 2009 (UTC)

I don't think I got my question across. The code has two spellings of the word: separator and seperator. I'm not sure reading the code if this is on purpose (to tolerate differences in editor input) or if it is by error.LeadSongDog come howl 15:15, 4 April 2009 (UTC)

Ah, okay. It is indeed to tolerate editor mis-spellings. Martin (Smith609 – Talk) 17:31, 4 April 2009 (UTC)

Great, so that spelling is nothing to worry about then. I (belatedly) tried out the Cite journal/testcases, plugging Citation/core/editprotected in to replace Citation/core/sandbox but the effect was not what I was expecting. I left my changes in place for now, please have a look and feel free to revert as required. Thanks again, LeadSongDog come howl 21:55, 6 April 2009 (UTC)

Solved. The AuthorSep line was missing from Cite journal/sandbox.LeadSongDog come howl 19:04, 7 April 2009 (UTC)

Example please?

Sorry, I'm having trouble following the above thread. Can someone please give an example of what's being proposed here? For example, how would this proposal be used to format the following citation?

When the above discussion is talking about a separator, is it talking about the space that separates "Myers" from "SM", or the comma that separates "Myers SM" from "Johnson CP", or the semicolon that separates both from "American Academy of Pediatrics Council on Children with Disabilities"? This space/comma/semicolon style is taken from PubMed (see PMID 17967921) and my assumption, I guess, is that something is being done to add support for that, but I'm a bit lost as to how this is being done. Eubulides (talk) 17:44, 4 April 2009 (UTC)

The change would allow the author to produce the output 'Myers SM, Johnson CP' by using the parameters:

• author1=Myers SP
• author2=Johnson CP
• author-separator=,

Giving each author their own parameter is good for metadata reasons; currently doing so would enforce the output 'Myers SM; Johnson CP', which may be undesirable in some articles. Martin (Smith609 – Talk) 18:00, 4 April 2009 (UTC)

Moreover, if you put all authors together into one field, any author links must be included by hand rather than with an author-link field. I believe (although I haven't checked) that this breaks Harvard citations. --Hans Adler (talk) 21:00, 4 April 2009 (UTC)

Ok, so now that sandbox example would look like

and if we added |author1-link=Scott M Myers|author2-link=Chris Plauché Johnson|author3=American Academy of Pediatrics Council on Children With Disabilities (links to nonexistent articles) we would get

redlinked as expected.LeadSongDog come howl 19:04, 7 April 2009 (UTC)

YearNote not working with editor fields?

I've discovered what I think is a problem with the output of this template: not displaying the YearNote field with editors (and no authors). (I noticed this using {{cite book}} which sends the correct parameters in both cases.)

This:

{{Citation/core |Citation class=book |Year=2009 |YearNote = 1999 |Date = {{#if:|{{{date}}}| 2009}} |Title=A sample title |EditorSurname1 = Smith |EditorGiven1 = Robert |DateFormat=none |Sep = . |PS = {{#if:||.}} }}

(As generated by {{cite book | editor-last = Smith | editor-first = Robert | year = 2009 | origyear = 1999 | title = A sample title }})

produces:

Smith, Robert, ed. (2009) [1999]. A sample title. 

without a bracketed 1999, while the same citation with author parameters:

{{Citation/core |Citation class=book |Surname1 = Smith |Given1 = Robert |Year=2009 |YearNote = 1999 |Date = {{#if:|{{{date}}}| 2009}} |Title=A sample title |DateFormat=none |Sep = . |PS = {{#if:||.}} }}

(As generated by {{cite book | last = Smith | first = Robert | year = 2009 | origyear = 1999 | title = A sample title }})

gives this:

Smith, Robert (2009) [1999]. A sample title. 

Is this intentional behavior of the template? — Bellhalla (talk) 12:24, 6 May 2009 (UTC)

This should be fixed at Template:Citation/core/fix. Please check that it produces the desired output and doesn't break any testcases - if it is working successfully, I'll update the main template. Martin (Smith609 – Talk) 16:15, 6 May 2009 (UTC)

Subbing a "/fix" into the first example above provides the expected output:

• Smith, Robert, ed (2009) [1999]. A sample title. 

I don't know about other test cases, though. — Bellhalla (talk) 18:21, 6 May 2009 (UTC)

In March I raised what is essentially the same issue at Template talk:Citation/core#origyear where year missing above. I didn't take it further because I haven't had the time to develop the necessary skills with templates. I'm not sure if the modification I suggested there is exactly right but I'm pretty sure that something as simple as that will do the trick. I'd appreciate it if you could make sure that the case I described is also covered by any fix you insert. SamuelTheGhost (talk) 23:29, 6 May 2009 (UTC)

Any progress on this? The same problem is still occurring… — Bellhalla (talk) 12:18, 14 May 2009 (UTC)

Presumably that means it is safe for me to update the main template with /fix. I'll do that now. Martin (Smith609 – Talk) 13:33, 14 May 2009 (UTC)

Thanks! — Bellhalla (talk) 18:19, 14 May 2009 (UTC)

I also thank you for your involvement, but unfortunately the cases I had in mind still seem not to be working. For example

• {{cite book |last=McCullough |first=W. D. H. |coauthors=Fougasse |title= Aces Made Easy |origyear=1934 |publisher=Methuen & Co. |location= London }}

displays as

• McCullough, W. D. H. Aces Made Easy. London: Methuen & Co. {{cite book}}: Unknown parameter |coauthors= ignored (|author= suggested) (help)

This generated, I presume,

• {{citation/core |Citation class=book |Surname1=McCullough |Given1=W. D. H. |Surname2=Fougasse |Title= Aces Made Easy |YearNote =1934 |Publisher=Methuen & Co. |PublicationPlace= London }}

which also displays as

• McCullough, W. D. H.; Fougasse, Aces Made Easy, London: Methuen & Co. 

so still not displaying the origyear, although the insertion of a date makes them both do so. SamuelTheGhost (talk) 16:22, 15 May 2009 (UTC)

This appears to be the intended behaviour - see Template:Cite book/doc

origyear: Original publication year, for display alongside the date or year.
 For clarity, please specify as much information as possible, for instance
 "First published 1859" or "Composed 1904". This parameter only displays 
if a there is a value for "year" or "date".

Why would you want to use the 'origyear' parameter but not the 'year' parameter? Martin (Smith609 – Talk) 16:47, 15 May 2009 (UTC)

A (perhaps weak) argument is that one might have access to, or be aware of, several publication dates, and feel that only the earliest of them was worth mention. Another (perhaps weak) argument is that templates should support what editors want to do, rather than impose unnecessary disciplines, particularly if the failure to conform is not made obvious to the person who does it. The strong argument is backwards compatibility. The Donald McCullough example worked until the restructuring of the templates last year. An unknown number of articles now contain an unknown number of such uses, where the date simply does not show, but the editor who put the citation in did in good faith supply a date, which was visible at the time he did it. SamuelTheGhost (talk) 17:51, 15 May 2009 (UTC)

I can pretty easily train the Citation bot to rename 'origyear' to 'year' if a year parameter is present. I think that the argument goes that if you do not cite a specific source, it is difficult for a sceptic to consult the exact volume you used to construct the article. Forcing an editor to enter the result 'correctly' removes any ambiguity, where it is unclear what an editor intended. Martin (Smith609 – Talk) 18:41, 15 May 2009 (UTC)

Using the bot wouldn't be my first choice, but I'd regard it as acceptable, so please do it. SamuelTheGhost (talk) 22:57, 15 May 2009 (UTC)

I'd also like to make a response to your remark "This appears to be the intended behaviour" above. You quote Template:Cite book/doc as saying This parameter only displays if a there is a value for "year" or "date". (your emphasis). That sentence in the template documentation was added on 1st January 2009, well after the date of those of the affected uses of which I am aware. It is reasonable to ask users of templates to use them in accordance with their documentation. It is not reasonable to ask them to use them in accordance with unknown subsequent changes to their documentation. SamuelTheGhost (talk) 17:03, 18 May 2009 (UTC)

The bot will now update the origyear parameter when it comes across it. Martin (Smith609 – Talk) 18:24, 18 May 2009 (UTC)

access date formatting

In the past the access date was automatically formatted as "Day Month Year" now it is coming out as entered "yyyy-mm-dd" for example (which at one time was the required input format and it was changed to a readable format - making this problem worse). I propose that we pass the AccessDate parameter through the date template using the format "dmy" see {{date}} for documentation. This should handle all of the different cases

Input format	Output text
Month Year	January 2001
Year	2001
ISO	15 January 2001
Month day, year	15 January 2001
Day Month Year	15 January 2001
misspelling	Janary 15, 2001

The updated text(changes in red):

  }}{{
     #if: {{{AccessDate|}}}
     | <span class="reference-accessdate">{{#ifeq:{{{Sep|,}}}|,|, r|. R}}etrieved on {{date|{{{AccessDate}}}|dmy}}</span>
     }}

--Trödel 15:29, 18 May 2009 (UTC)

No. Access date should use the same format as the body of the article, and the template has no way to know what that format is. --Jc3s5h (talk) 15:48, 18 May 2009 (UTC)

then please fix what you have broken -i.e. go through all the citations templates I have used from 2006 until this change and update the parameter that required an ISO format to match the current article --Trödel 15:51, 18 May 2009 (UTC)

Why don't you try to make the people who introduced date autoformatting do it? That is the root of this evil. Oh, by the way, you know that every ISO 8601 date is either in the Gregorian calendar, or wrong, right? I suspect we have a few citations to sources printed before the British adopted the Gregorian calendar. --Jc3s5h (talk) 16:14, 18 May 2009 (UTC)

For more on this topic, please see #Please don't mess with editor's date format above, along with the following topics. Eubulides (talk) 19:29, 18 May 2009 (UTC)

I understand the problem started with the introduction of using ISO dates - however, date format has been a constant matter of debate since the early days of Wikipedia with good arguments on both sides. Maybe you guys could have done something intelligent and converted only ISO dates to something human readable.

Secondly, regardless of the source of the problem, there were many articles that had dates that displayed properly that were broken by the decision to just output the date as inserted. Templates SHOULD NOT break the displayed text ever. I have designed templates, and fixed issues in templates that were introduced by other well intentioned, and excellently implemented ideas that after being implemented for some time, were discovered to not work as effectively or as efficiently as desired. In these cases, I fixed the impacted articles myself, or enlisted those with bots to help with the fix.

Perhaps instead of being dogmatic you could think of a way to fix the problem that has been created by this new standardization.

What really is insulting is that you assume that your way will be "the way for all time" - when, in fact, you don't know if it will be or if consensus will over time decide something different. I am sure that you don't want all the articles that you edited and used the citation templates, to suddenly not output the information as you expect it to be outputted, and as it did output when you inserted the template into the article.

Maybe you could find it in your heart to help figure out a solution to this problem, you never know if you will be asking someone to not undo all your hard work a couple years from now. --Trödel 01:00, 19 May 2009 (UTC)

Short of visiting each template instance and adjusting it to match the rest of the article, I can see no solution. There just isn't enough information accessible to the template to decide what the date format should be. --Jc3s5h (talk) 01:19, 19 May 2009 (UTC)

I have reviewed the comments above and have been doing some research on this issue. As you state there is no easy solution, and it is much more complicated than I thought when I initially posted. Thanks for your patience while I've caught up to speed.

The templates that I have a problem with are {{Cite web}}, {{Cite journal}}, {{Cite news}}, {{Cite press release}}, and {{Cite book}}. These all had a parameter "accessdate" that you were required to put in yyyy-mm-dd format and that automatically converted to the dd mmmm yyyy format. Now they, from what I can tell, pass the "accessdate" into {{Citation}} as "AccessDate". The documentation was changed to not require yyyy-mm-dd format with this change on 9 November 2008 with no real explanation of why it was changed. Therefore we have two things that I think can help solve this problem.

1. There is no issue with old dates - the parameter in question is the last time the source was accessed or referred to, so we don't have to worry about Julian or other different calendar formats (unless someone travels back in time to refer to a source prior to the adoption of the Gregorian calendar :) and
2. The date automatically converted until November 2008.

Therefore, it seems reasonable to convert the older templates Cite web, Cite journal, Cite news, Cite press release, Cite book to reformat yyyy-mm-dd formated accessdate (only) to dd mmmm yyyy format, and leave the other citation templates as is so that the accessdate will work like they do now.

Thoughts? Am I missing something here? --Trödel 16:58, 19 May 2009 (UTC)

Your solution presumes that in an article using the format month dd month yyyy, it is better to reformat an accessdate in the yyyy-mm-dd format to dd month yyyy than to leave it alone. Since both yyyy-mm-dd and dd month yyyy are wrong in such an article, I don't see the improvement. Furthermore, the change would make the templates behave in a manner that is indecipherable to someone who does not find the right spot in the documentation. I beleive it is better to have simple, predictable templates than to substitute one error for another. --Jc3s5h (talk) 17:18, 19 May 2009 (UTC)

I assume you mean "... an article using the format month dd yyyy..." However, there is an improvement because the articles that inserted the templates knowing that it would reformat dd mmmm yyyy would now format correctly and as expected. We could even do a test on the date - if the retrieved on date is between 2005 and 2008 then reformat the date - then all the articles that had the template inserted into them during that time would work exactly as when the template was inserted. --Trödel 21:33, 20 May 2009 (UTC)

• Would it be simpler for a bot to reformat unsavoury dates in the articles themselves, rather than coding redundancy into the template? I could easily make the Citation bot do this, if you gave me a set of requirements to follow. Martin (Smith609 – Talk) 22:47, 20 May 2009 (UTC)

I think a citation bot run that changes the YYYY-MM-DD format to the dd month yyyy format only for the 2005 through 2008 period would have the benefit mentioned by Trödel of restoring the appearance of the displayed citation to the same format it had when the original editor looked at it, without burdening future users with a quirky interface, and future coders with lots of special case code. If the date range can be narrowed down some more, that would be even better. --Jc3s5h (talk) 22:57, 20 May 2009 (UTC)

The formatting was finally removed with this edit. Happy‑melon 23:27, 20 May 2009 (UTC)

Well, feel free to give me a precisely worded definition of what the bot should do, and I'll gladly code and run it. User talk:Citation bot would be the best place to post this description. Martin (Smith609 – Talk) 16:53, 21 May 2009 (UTC)

Thank you for the offer - I will think carefully about how to word the instructions that address the concerns here. --Trödel 12:36, 22 May 2009 (UTC)

Have the MOSNUM date debates finally come to a conclusion? Has the injunction against mass conversion of dates been lifted? Until then, I'd suggest not touching it with a 10 feet (3.0 m) pole.LeadSongDog come howl 23:03, 20 May 2009 (UTC)

Just checked. The Wikipedia:Requests_for_arbitration/Date_delinking#Temporary_injunction still is in effect.LeadSongDog come howl 23:07, 20 May 2009 (UTC)

Let's please just leave the dates alone. A template should not try to format a date, or make it look nicer, or wikilink it, etc. Such efforts in the long run cause more trouble than they cure. Any hack that would format only dates in the 2005–2008 range would be enormously confusing. Eubulides (talk) 23:23, 20 May 2009 (UTC)

Indeed; the template should, at most, do what it's told, not what it thinks is the clever thing to do. Happy‑melon 23:27, 20 May 2009 (UTC)

• if you want dates formatted, wrap them in {{date}}. for example: |accessdate={{Date|2009-05-29|mdy}}. it's not much more work for the editor, and each page can be formatted consistently according to the consensus for that page.  —Chris Capoccia ^T⁄_C 08:53, 29 May 2009 (UTC)

• • The {{date}} template is essentally useless in this situation. The format must be specified (unless you want the default, d month yyyy). It's easier to just put the date in the format you want to begin with. --Jc3s5h (talk) 16:25, 29 May 2009 (UTC)

but with the template, i don't have to worry about mistakes like spelling, capitalization, forgetting a comma... i just type the digits and i'm off. later if someone wants to change the dates from mdy to dmy or something, it's trivial to do so.  —Chris Capoccia ^T⁄_C 16:35, 29 May 2009 (UTC)

Minor change - separator in front of "Retrieved on"

Suggesting update by replacing

 ifeq:{{{Sep|,}}}|,|, r|. R}}etrieved on

with [6]

 ifeq:{{{Sep|,}}}|.|. R|{{{Sep|,}}} r}}etrieved on

Before:

{{Citation/core
 |Surname1          = Doe, John
 |Title             = My favorite things part II
 |Publisher         = Open Publishing
 |Date              = 2005-04-30
 |IncludedWorkTitle = Encyclopedia of things
 |URL               = http://www.example.org/
 |AccessDate        = 2005-07-06
 |Sep               = ;
}}

Doe, John (2005-04-30); "Encyclopedia of things"; My favorite things part II; Open Publishing; http://www.example.org/. Retrieved 2005-07-06 

After:

{{http://en.wikipedia.org/w/index.php?title=Template:Citation/core/sandbox&oldid=290990853
 |Surname1          = Doe, John
 |Title             = My favorite things part II
 |Publisher         = Open Publishing
 |Date              = 2005-04-30
 |IncludedWorkTitle = Encyclopedia of things
 |URL               = http://www.example.org/
 |AccessDate        = 2005-07-06
 |Sep               = ;
}}

Doe, John (2005-04-30); "Encyclopedia of things"; My favorite things part II; Open Publishing; Retrieved on 2005-07-06

Ma3ko7 (talk) 18:23, 19 May 2009 (UTC)

Date autoformatting

It might be worth considering using {{#formatdate:xxx}} in this template. It will format (but not link) dates according to logged in editors preferences. See Help:Magic words on the MediaWiki site. —Locke Cole • t • c 02:45, 30 May 2009 (UTC)

Any such usage should not change existing dates, which by default should not be formatted. Please see #Please don't mess with editor's date format and #access date formatting above. It could be a new parameter, though; that would be upward-compatible. Eubulides (talk) 03:45, 30 May 2009 (UTC)

Date autoformatting has been rejected by the community in its present form. While a RfC in late 2008/early 2009 showed a narrow majority favors some form of date autoformatting, no particular form has been decided on. Adopting any particular form in templates in advance of general use in articles will create the same kind of entanglements that we are presently recovering from as template editors try to decontaminate the templates from the influence of the woefully bad design of the present autoformatting system. --Jc3s5h (talk) 14:38, 30 May 2009 (UTC)

The formatdate function was developed after the community rejected the current system, and the two are unrelated (other than formatdate utilizing Special:Preferences to determine what date format to use for logged in readers). Further, it's highly unlikely you'd want linked and autoformatted dates in citations, so it's unlikely we'll need to change this once implemented. —Locke Cole • t • c 14:50, 30 May 2009 (UTC)

There is no consensus to use the formatdate function. It was put into the wiki software by a developer with no attempt to seek consensus from the editing community. --Jc3s5h (talk) 15:15, 30 May 2009 (UTC)

Not everything need be discussed prior to being implemented (especially in a case like this where it makes sense). As an aside, we're here right now discussing adding this. It avoids one of the core problems with the prior system (linked dates/years) while keeping what the community seemed to accept as "useful" (date autoformatting). That seems like a good enough reason to use it if. —Locke Cole • t • c 15:29, 30 May 2009 (UTC)

Date autoformatting is currently depricated in articles. Using formatdate in the citations but not in the article will cause an inconsistent display of dates between the body text and the citations for those who log in choose a date preference. --Jc3s5h (talk) 15:45, 30 May 2009 (UTC)

It would however make citations consistent which is a step in the right direction. Article consistency will come, hopefully with a fixed Dynamic Dates system that loses the auto linking and retains the auto formatting. —Locke Cole • t • c 16:01, 30 May 2009 (UTC)

• Per your wishes, Locke, Ryan’s date linking RfC was not on a specific date autoformatting technology, but on the generalities of date autoformatting, which the community rejected. Ryan and the ArbCom concluded that the RfC results constituted a consensus.

  I know this outcome was not to your liking, but I know full well you are aware of these facts. Yet here you are, persisting in yet another venue. This was tedious before, and now it is exceedingly tedious. Do you not see something else for you to do on Wikipedia you would find rewarding? Greg L (talk) 19:11, 30 May 2009 (UTC)

• Trojan Horse. Ohconfucius (talk) 12:05, 31 May 2009 (UTC)

It could be useful if we could write i.e. {{reflist|2|dmy}} to format all the reference dates to dmy format. That would require some kind of communication between templates though, which I think is currently impossible. Per-user autoformatting is rather useless and would cause inconsistencies within the article, as pointed out above. Well, unless we start doing article text autoformatting again, which we won't. --Apoc2400 (talk) 20:29, 30 May 2009 (UTC)

The inconsistencies would only exist until a system of auto formatting was developed that could be used in articles. The preference would be used for both and provide consistency. —Locke Cole • t • c 21:04, 30 May 2009 (UTC)

The inconsistencies would only exist until all dates in articles are consistently formatted. At present, there is no requirement for that - it's only a guideline, remember?? ;-) Ohconfucius (talk) 12:13, 31 May 2009 (UTC)

Unnecessary code

Isn't the second

#if:{{{OriginalURL|}}}

always true? Tocant (talk) 12:25, 3 June 2009 (UTC)

Well spotted. I've removed it. Martin (Smith609 – Talk) 13:45, 3 June 2009 (UTC)

Looking at this again there are other problems with this code, the following returns the wrong error when url is empty:

{{cite news | author=Author | title=Title | url= | accessdate=11 December 2005 | archiveurl=http://archiveurl/ | archivedate=28 June 2008 }}

Author. "Title". {{cite news}}: |access-date= requires |url= (help); |archive-url= requires |url= (help); |author= has generic name (help)

Tocant (talk) 14:31, 3 June 2009 (UTC)

 Fixed. I hope I've not caused any side-effects - I didn't notice any. Martin (Smith609 – Talk) 22:42, 3 June 2009 (UTC)

Test cases

All 8 combinations of url, archiveurl and archivedate:

1. {{cite news | author=Author | title=Title | url= | archiveurl= | archivedate= }}
2. {{cite news | author=Author | title=Title | url=http://url/ | archiveurl= | archivedate= }}
3. {{cite news | author=Author | title=Title | url= | archiveurl=http://archiveurl/ | archivedate= }}
4. {{cite news | author=Author | title=Title | url= | archiveurl= | archivedate=28 June 2008 }}
5. {{cite news | author=Author | title=Title | url=http://url/ | archiveurl=http://archiveurl/ | archivedate= }}
6. {{cite news | author=Author | title=Title | url=http://url/ | archiveurl= | archivedate=28 June 2008 }}
7. {{cite news | author=Author | title=Title | url= | archiveurl=http://archiveurl/ | archivedate=28 June 2008 }}
8. {{cite news | author=Author | title=Title | url=http://url/ | archiveurl=http://archiveurl/ | archivedate=28 June 2008 }}

1. Author. "Title". {{cite news}}: |author= has generic name (help)

2. Author. "Title". {{cite news}}: |author= has generic name (help); Check |url= value (help)

3. Author. "Title". {{cite news}}: |archive-url= requires |archive-date= (help); |author= has generic name (help)

4. Author. "Title". {{cite news}}: |archive-date= requires |archive-url= (help); |author= has generic name (help)

5. Author. "Title". {{cite news}}: |archive-url= requires |archive-date= (help); |author= has generic name (help); Check |archiveurl= value (help)

6. Author. "Title". {{cite news}}: |archive-date= requires |archive-url= (help); |author= has generic name (help); Check |url= value (help)

7. Author. "Title". {{cite news}}: |archive-url= requires |url= (help); |author= has generic name (help)

8. Author. "Title". Archived from the original on 28 June 2008. {{cite news}}: |author= has generic name (help); Check |archiveurl= value (help); Check |url= value (help)

---

Some of these errors are incorrect or absent. Maybe it is easier not to have any requirements that certain parameters must be specified when archiveurl and archivedate are used? What if the archive is a scanned copy of a newspaper with unknown (unimportant) archivedate?

It is also illogical that Citation/core complains about missing url (it is OriginalUrl that is missing) and archiveurl (not even a Citation/core parameter), the error handling should probably be done by the calling template. Tocant (talk) 09:48, 4 June 2009 (UTC)

Would this be fixed if I changed the error message to something along the lines of 'Missing URLs in citation template'? In the case you state, a url would suffice (without an archiveurl). Martin (Smith609 – Talk) 14:06, 4 June 2009 (UTC)

Yes, that might be a good solution! Tocant (talk) 14:21, 4 June 2009 (UTC)

Titles that start with a quote

I've noticed that in order to render properly (itallic, not bolded) I occasionally have to hack cite news title parameters with initial quotation, e.g.
title= 'Ya fiyad': Ivana
I'm not sure where this problem originates, in the core or in {{cite news}}, but headline writers evidently love to lead off with a quote, making this rather annoying. Any hints? LeadSongDog come howl

Sounds like a bug in the template to me. Surely can work around it with {{'}}, e.g., "title= {{'}}Ya fiyad': Ivana". Eubulides (talk) 16:41, 3 June 2009 (UTC)

That seems to have its own problems. I'm wondering about the metadata emitted in each case, but I suppose either hack could be readily bot-fixed once the bug is found. Oddly the bolding bug doesn't exhibit today on IE6, but there still is strangeness. Consider the following cases that I'd expect to yield much the same thing (evidently the curly single quote breaks in {{’}}where the straight single works in {{'}}. Case 8 is particularly weird:

Nowiki:

1. {{cite news |url=http://www.nytimes.com/2009/05/28/health/policy/28flu.html |title='Underlying conditions' may add to flu worries |publisher=New York Times |date=27 May 2009}}
2. {{cite news |url=http://www.nytimes.com/2009/05/28/health/policy/28flu.html |title= 'Underlying conditions' may add to flu worries |publisher=New York Times |date=27 May 2009}}
3. {{cite news |url=http://www.nytimes.com/2009/05/28/health/policy/28flu.html |title={{'}}Underlying conditions' may add to flu worries |publisher=New York Times |date=27 May 2009}}
4. {{cite news |url=http://www.cbc.ca/health/story/2009/06/01/ontario-swineflu-death.html |title='Atypical' Toronto swine flu victim had other medical condition: official |date=May 25, 2009}}
5. {{cite news |url=http://www.cbc.ca/health/story/2009/06/01/ontario-swineflu-death.html |title= 'Atypical' Toronto swine flu victim had other medical condition: official |date=May 25, 2009}}
6. {{cite news |url=http://www.cbc.ca/health/story/2009/06/01/ontario-swineflu-death.html |title={{'}}Atypical' Toronto swine flu victim had other medical condition: official |date=May 25, 2009}}
7. {{cite news|title='Ya fiyad': Ivana}}
8. {{citation|title='Ya fiyad': Ivana}}
9. {{cite web|title='Ya fiyad': Ivana|url=http://x.com}}
10. {{cite news|title={{'}}Ya fiyad': Ivana}}
11. {{citation|title={{'}}Ya fiyad': Ivana}}
12. {{cite web|title={{'}}Ya fiyad': Ivana|url=http://x.com}}
13. {{cite news|title= 'Ya fiyad': Ivana}}
14. {{citation|title= 'Ya fiyad': Ivana}}
15. {{cite web|title= 'Ya fiyad': Ivana|url=http://x.com}}

Bare cites:

1. "'Underlying conditions' may add to flu worries". New York Times. 27 May 2009.
2. " 'Underlying conditions' may add to flu worries". New York Times. 27 May 2009.
3. "'Underlying conditions' may add to flu worries". New York Times. 27 May 2009.
4. "'Atypical' Toronto swine flu victim had other medical condition: official". May 25, 2009.
5. " 'Atypical' Toronto swine flu victim had other medical condition: official". May 25, 2009.
6. "'Atypical' Toronto swine flu victim had other medical condition: official". May 25, 2009.
7. "'Ya fiyad': Ivana".
8. 'Ya fiyad': Ivana
9. "'Ya fiyad': Ivana".
10. "'Ya fiyad': Ivana".
11. 'Ya fiyad': Ivana
12. "'Ya fiyad': Ivana".
13. " 'Ya fiyad': Ivana".
14.  'Ya fiyad': Ivana
15. " 'Ya fiyad': Ivana".

Same ones wrapped in ref tags:

LeadSongDog come howl 21:46, 3 June 2009 (UTC)

Argh! How about "&#39;" to work around the problem instead? That's yucky, but it should work. Thus:

• {{cite news |url=http://www.nytimes.com/2009/05/28/health/policy/28flu.html |title=&#39;Underlying conditions' may add to flu worries |publisher=New York Times |date=27 May 2009}}
• "'Underlying conditions' may add to flu worries". New York Times. 27 May 2009.

Eubulides (talk) 22:14, 3 June 2009 (UTC)

I'm not seeing any bolding problems in Firefox - the only thing I have noticed is that the opening quote may be inappropriately unitalicised (as in #8). I've fixed that; it's possible that my fix will resolve other issues. If it doesn't, please post an example, along with an explanation of how it differs from the expected behaviour. Martin (Smith609 – Talk) 22:59, 3 June 2009 (UTC)

Is there any way to check if someone has used the {{'}} work-around already? That breaks COinS. --Karnesky (talk) 23:19, 3 June 2009 (UTC)

Thanks Martin, whatever you did seems to have sorted the problem with #8, putting the backlink caret where it belongs. I'm not seeing the bolding now on IE7 either. I'll check on IE6 tomorrow to see how that fared. It looks like the wikitext hacks are no longer needed.LeadSongDog come howl 04:10, 4 June 2009 (UTC)

A quibble: this change added about 2.2 kilobytes to Autism. Granted, the article's big already, but is there some way to fix the bug that requires fewer bytes than putting <span></span> around every title? For example, could we surround a title with a span only if the title starts or ends with troublesome characters? Eubulides (talk) 16:22, 4 June 2009 (UTC)

It does look the same on IE6 as IE7, though Eubulides point makes sense. I must comment that visually, I find having some type of perceivable gap breaking up the triple quote is a good thing, not only for stylistic reasons but for clarity of intent. When someone (e.g. a google spider) copies the browser-rendered html of a citation and puts it somewhere as plain text it should remain intelligible in an ideal world. LeadSongDog come howl 16:43, 4 June 2009 (UTC)

As In understand it, addressing Eublides' point would increase page load times. Currently, the page parser evaluates the entirety of an {if:} template call - both the true and the false part - before discarding the part that it doesn't need. Putting in functions to deduce whether the title started with an apostrophe would add more, not less, overhead. I would interpret WP:DWAP to suggest that looking for ways to remove every surplus byte would not be time well spent. Martin (Smith609 – Talk) 16:58, 4 June 2009 (UTC)

Please see #A shorter fix for "title='Ouch" below. Eubulides (talk) 20:26, 4 June 2009 (UTC)

A shorter fix for "title='Ouch"

I looked into this a bit more, and found that it's easy to fix the problem without adding a couple of kilobytes to Autism. First, <span></span> isn't needed for titles appearing in double-quotes. Second, <span></span> isn't needed for italicized titles that are external links, since the brackets protect against misinterpretation of apostrophes. The only problem case is an italicized title that is not an external link (as in #8 above). It's easy and cheap to introduce <span></span> only in that case. I have tested this in the sandbox, and it fixes #8. The idea is to remove the <span></span>s, and to use {{Italiclink}} rather than ''{{Link}}''. Could you please install that fix? Thanks. Eubulides (talk) 20:26, 4 June 2009 (UTC)

That looks much more elegant - good work. In your fix, you have only replaced one link template with an italiclink. Before I make the change, I thought I should check that this was intentional, and that the removal of the span in the first link template won't perpetuate problems. Martin (Smith609 – Talk) 14:31, 5 June 2009 (UTC)

Yes, that was intentional. The span isn't needed in the other case, because that case is surrounded by double-quote ("), not by two single-quote (''), and double-quote can't cause the problem. Eubulides (talk) 17:32, 5 June 2009 (UTC)

 Done. Martin (Smith609 – Talk) 21:56, 5 June 2009 (UTC)

Why can't we just use the more reliable <i> tag instead of the fancy MediaWiki single-quote syntax? —Remember the dot ^(talk) 01:33, 5 June 2009 (UTC)

Ah, I figured it out. It's so that you can toggle the italics automatically, for example "Critics Praise The Importance of Being Earnest, Call it a 'Smashing success'." Now that I understand that, I agree that your Template:Italictitle solution is probably the best we can do. —Remember the dot ^(talk) 02:22, 5 June 2009 (UTC)

are congratulations already in order?

Guys, if what I see under development and testing here is what I think it is—plain, unlinked dates that editors can easily force to the format used in the article—you should all be congratulated. This would be a very beneficial outcome for the project. Tony (talk) 10:14, 4 June 2009 (UTC)

Problem...

Can anyone tell me why all of a sudden this * {{cite book |url=http://british-history.ac.uk/report.aspx?compid=34422 |author=Barrow, J. S. |title= Fasti Ecclesiae Anglicanae 1066–1300: volume 8: Hereford: Bishops|year=2002 |publisher=Institute of Historical Research}} Retrieved on 26 October 2007 is suddenly putting the "Retrieved on..." bits on its own line? It's never done this before, suddenly it's doing it in the last day or so. Ealdgyth - Talk 16:58, 6 June 2009 (UTC) And it's not just {{cite book}}, it's {{cite web}} or {{cite encyclopedia}} whenever there is data after the template, whether or not there is an url in the template. It's also creating extra spacing between lines, which is quite annoying for very long reference lists. Ealdgyth - Talk 17:00, 6 June 2009 (UTC)

Agreed. That extra spacing between lines, in particular, is making long bibliographies unreadable. Please, someone fix this. – iridescent 17:16, 6 June 2009 (UTC)

• Here it is again, for reference:

• Barrow, J. S. (2002). Fasti Ecclesiae Anglicanae 1066–1300: volume 8: Hereford: Bishops. Institute of Historical Research.. Retrieved on 26 October 2007. Ling.Nut (talk) 17:23, 6 June 2009 (UTC)

{{editprotected}} Please revert the most recent change to {{Citation/core}}, which is causing the severe formatting problem noted above. Here's what the above example currently renders:

---

• Barrow, J. S. (2002). Fasti Ecclesiae Anglicanae 1066–1300: volume 8: Hereford: Bishops. Institute of Historical Research. Retrieved on 26 October 2007.

---

Note that the "Retrieved on" is incorrectly put at the start of a new line, with a blank line intervening. Here's what the example currently renders in the sandbox, where I've reverted that change:

---

• Barrow, J. S. (2002). Fasti Ecclesiae Anglicanae 1066–1300: volume 8: Hereford: Bishops. Institute of Historical Research. Retrieved on 26 October 2007.

---

The edit message for that change notes that it's for forward compatibility, so it's OK to revert it for now, until it gets corrected. I note that the documentation for {{COinS}} says " The citation itself, and the template, should be placed within a <cite></cite> tag", but currently {{Citation/core}} violates that rule; perhaps that's related to the problem? Anyway, a revert for now is the simplest. Eubulides (talk) 17:30, 6 June 2009 (UTC)

Reverted

Per the above and this discussion, I've undone this edit. Please, don't restore it without fixing the bugs; this was screwing up reference sections across the entire project. – iridescent 17:50, 6 June 2009 (UTC)

Thanks. Eubulides (talk) 18:33, 6 June 2009 (UTC)

Fixed?

Sorry guys - I copied an additional </span> tag into the code, which I didn't spot in my testing. It looks like the sandbox is working now - I'd be grateful if people usign different browsers/plugins could double-check before I commit the edits. Thanks, Martin (Smith609 – Talk) 21:09, 6 June 2009 (UTC)

Translation

I have added a new parameter, TransTitle, to enable translation of foreign titles. This adds HTML square brackets around the translated title and includes it within the main quotes. I plan to add documentation after some testing. Please revert if any problem is encountered with it. Crum375 (talk) 05:47, 23 June 2009 (UTC)

what happens if only the translated title is known? like this: [7]   —Chris Capoccia ^T⁄_C 06:30, 23 June 2009 (UTC)

For the time being, in that situation you can use the main title parameter (only) and include the square brackets: ...|title=[The protective effects of total flavonoids from Lycium Barbarum L. on lipid peroxidation of liver mitochondria and red blood cell in rats]|... Crum375 (talk) 13:18, 23 June 2009 (UTC)

I think it should work now. Here is your example, using the {{cite web}} template. I can try to get other wrappers updated if needed ({{cite news}} should already be OK).

It seems there is some problem displaying the footnotes on this page; you can just copy-paste the example elsewhere in the meanwhile (or try your own test). Crum375 (talk) 01:24, 25 June 2009 (UTC)

Using span to display the footnote locally:
{{cite journal |author=Huang Y, Lu J, Shen Y, Lu J |trans_title=The protective effects of total flavonoids from Lycium Barbarum L. on lipid peroxidation of liver mitochondria and red blood cell in rats |language=Chinese |journal=Wei Sheng Yan Jiu |volume=28 |issue=2 |pages=115–6 |year=1999 |month=March |pmid=11938998}}
→ Huang Y, Lu J, Shen Y, Lu J (1999). Wei Sheng Yan Jiu (in Chinese). 28 (2): 115–6. PMID 11938998. {{cite journal}}: Missing or empty |title= (help); Unknown parameter |month= ignored (help); Unknown parameter |trans_title= ignored (|trans-title= suggested) (help)CS1 maint: multiple names: authors list (link)

Crum375 (talk) 02:06, 25 June 2009 (UTC)

thanks. it works great. i tried it out in my sandbox. hopefully diberri will be updating his tool to take advantage of this new feature.  —Chris Capoccia ^T⁄_C 06:56, 25 June 2009 (UTC)

Thanks for the feedback, as well as pointing out the need for the 'unavailable original title' mode. I have copied your {{cite journal}} example from your sandbox to this thread above. The trans_title parameter is now supported for cite web, news, and journal. I may add others soon. Crum375 (talk) 12:28, 25 June 2009 (UTC)

---

I have made changes to support translated titles for two additional "client" templates, so the list is: {{cite news}}, {{cite web}}, {{cite journal}}, {{cite book}} and {{cite press release}}. For {{cite book}}, there is support for two simultaneous translations, of the main title as well as chapter title. See (future) docs for details. Crum375 (talk) 19:46, 25 June 2009 (UTC)

URL link inside quotes

There was a complaint made that there is a difference in the behavior of the URL link relating to the quotes of a title. In {{cite journal}}, which was presumably correct, the link was inside the quotes, whereas in {{cite web}} it was outside. I put in a fix for that, so that now the title rendering of both cite web and cite journal is identical. If there are any problems with it, the change can be reverted. Thanks, Crum375 (talk) 14:14, 30 June 2009 (UTC)

ISBN is not linked

In the following example:

• {{Citation/core |Title= Foundations of Evolutionary Psychology |IncludedWorkTitle= The evolution of brain mechanisms for social behavior |Surname1= Baron-Cohen S |At=pp. 415–32 |EditorSurname1= Crawford C, Krebs D (eds.) |Publisher= Lawrence Erlbaum |Date=2008 |ISBN=0‑8058‑5957‑8}}
• Baron-Cohen S (2008), "The evolution of brain mechanisms for social behavior", in Crawford C, Krebs D (eds.), Foundations of Evolutionary Psychology, Lawrence Erlbaum, pp. 415–32, ISBN 0‑8058‑5957‑8 

the ISBN is not a link; it's just plain text. Why is that? I originally ran into this with {{cite book}} and added some test cases in Template:Cite book/testcases #ISBN test cases. Eubulides (talk) 07:24, 6 July 2009 (UTC)

• It seems you need to use plain hyphens. If you use those strange characters, the ISBN link doesn't work. Crum375 (talk) 13:36, 6 July 2009 (UTC)

Any thoughts on stripping the hyphens entirely, leaving just the numeric string? It would give a more consistent result.LeadSongDog come howl 14:29, 6 July 2009 (UTC)

absolutely a bad idea. separating the digits with hyphens or spaces is actually required by the isbn standard whenever people are reading the number (see section 4).  —Chris Capoccia ^T⁄_C 15:29, 6 July 2009 (UTC)

Thanks for the link. Yes it says that the separators are required for human readable forms, but we have been routinely ignoring that. If we're going to be serious about following the 2005 standard, we should consider proactively converting isbn-10 numbers to 978-prefixed isbn-13 (see p.48), but we seldom do. Please note that the position of the separators (per Table 6 on p.15) varies on a basis that (afaik) we have no mechanism in place to check and correct (or does citation bot fix this?) LeadSongDog come howl 17:00, 6 July 2009 (UTC)

Thanks for explaining it. I got the ISBN off a publisher's website, if I recall correctly, and I guess they used a non-breaking hyphen (U+2011). This is arguably just as much of a hyphen as a regular hyphen is, and I can see why someone might not want an ISBN to be broken across line boundaries, but this bug (if it is a bug) belongs to the underlying Mediawiki software, not to this template. Eubulides (talk) 16:02, 6 July 2009 (UTC)

fix for URL= issues

{{editprotected}}

In {{citation/core}}, would someone with the bits please replace all instances of "{{Link" with "{{citation/make_link" ? The change (i.e. the invocation of {{citation/make_link}}) implements the following:

• It makes it possible to use url= or chapter-url= to pass the name of a wp article to link to. It is then possible to specify {{citation|title=A Title|url=wp_article|...}} instead of {{citation|title=[[wp_article|A Title]]|...}} as has been so far necessary. (kudos to Martin for this idea)
• It provides a workaround for the problem described in this section, viz. that url= functions as chapter-url= when the latter is undefined. This in turn implies that there is no way to provide a url for the title without also having a url for the chapter. The workaround works by allowing an editor to specify chapter-url=none, which then stops url= from replacing it.
• Additionally, by naming the "subroutine" {{citation/make_link}}, the sub-template is "under" citation space, and thus less likely to be confused for a general-purpose template. It also ensures that related discussion is seen by those who are familiar with {{citation[/core]}}.

I've also made the "{{Link" => "{{citation/make_link" replacements in the sandbox, so just copying that over should do the trick. Thanks. -- Fullstop (talk) 20:51, 25 July 2009 (UTC)

Not done. titleparts should not be abused like this. I reverted a similar change at Template:Link about a month ago. --- RockMFR 21:19, 25 July 2009 (UTC)

There is a related and recent discussion at Template talk:Link#Internal URLs. Eubulides (talk) 21:46, 25 July 2009 (UTC)

And RockMFR did not in fact revert "a similar change". What is it with you guys anyhow? You sit in the dark and then say there is no need to turn on the light because you can't see. WHY DON'T YOU TRY IT? -- Fullstop (talk) 22:18, 25 July 2009 (UTC)

I don't see a valid objection to this change. RockMFR, please explain the problems with using titleparts: in this rather ingenious fashion. Martin (Smith609 – Talk) 04:06, 28 July 2009 (UTC)

Further testing has found that this change mishandles URLs containing "%"; please see Template talk:Link #URLs with % mishandled. Eubulides (talk) 15:33, 1 August 2009 (UTC)

(cc) :Good catch! This fix did the trick. Cost is two {lcfirst}s. -- Fullstop (talk) 22:20, 1 August 2009 (UTC)

< Maybe I don't understand the issue here, but wouldn't it be more consistent to add a parameter "titlelink" for internal links? Similar to authorlink? And a related question: what happens to the metadata if you use something like title=[[Bugs (book)|Bugs: Entymology as a way of life]]? Does the metadata just use the whole mess as the title? ---- CharlesGillingham (talk) 12:46, 8 August 2009 (UTC)

It might make more sense to have a separate option, yes. The MediaWiki tradition seems to be that an editor must know whether a link is internal or external; that's why there is [ ] versus [[ ]] notation. To some extent the main part of the current proposal undermines this tradition, and having titlelink= would keep to it. Eubulides (talk) 20:16, 8 August 2009 (UTC)

It just seems kind of kludgey to me to overload the "url" parameter. ---CharlesGillingham (talk) 11:01, 9 August 2009 (UTC)

May I ask at this point whether any of these proposed changes will link any items that are not currently linked? Tony (talk) 12:54, 8 August 2009 (UTC)

No, they wouldn't. Eubulides (talk) 20:16, 8 August 2009 (UTC)

• To summarize the above discussion: There is consensus that {{Citation/core}} should not depend on publicly-visible templates like {{link}} and {{para}}, but should instead stick with the {{Citation}} name space; the easiest way to do this is to move or copy {{link}} to {{Citation/make link}} and to have {{Citation/core}} use {{Citation/make link}}; also, it should simply inline the tt elements rather than invoke {{para}}. There is also consensus that the current method of supporting italic links with {{link}} and {{italiclink}} is not as good as the <nowiki> method described above, because it bloats the HTML with <span>s. There does not seem to be consensus to have url= parameters link to Wikipedia articles if they don't look like URLs.
• To implement the consensus, please install this sandbox change to {{Citation/core}}, and please protect {{Citation/make link}}.
• We can discuss later how better to link titles to Wikipedia articles.

Eubulides (talk) 03:51, 10 August 2009 (UTC)

I've removed the {{editprotected}} for now, as this change seems to be affected by the cite element change discussed below. Eubulides (talk) 17:09, 10 August 2009 (UTC)

I missed the comment on (in)consistency. So, the response here:

This is citation/core, which editors do not invoke. In this template, it does not matter whether we continue to call the parameter IncludedWorkURL=/URL=, or we rename it IncludedWorkLink=/Link= (or whatever). There is no practical difference.

As far as {citation} is concerned, i.e. the template that editors actually use, titlelink=/chapterlink= would be synonyms of url=/chapter-url= respectively. After all, a title cannot have two links.

Thus, the value being passed to (and held in) /core's IncludedWorkURL= is simply

{{{chapter-url|{{{chapterurl|{{{chapter-link|{{{chapterlink|}}}}}}}}}}}}.

What that construct is called is not important. Its currently called "IncludedWorkURL", which is ok. Rename it to "IncludedWorkLink" (or whatever) if it makes someone's day. Just don't sweat the small stuff. :) -- Fullstop (talk) 18:34, 10 August 2009 (UTC)

In {{Citation}} I do not see any documentation for any titlelink or chapterlink parameters. In the absence of documentation, editors will have to figure out the meaning through analogy with the author-link parameter. Thus titlelink is the title of a Wikipedia article about the work (for example, Newcomb's Tables of the Sun). Similarly, chapterlink is the title of a Wikipedia article about the chapter (although this would be rare). --Jc3s5h (talk) 18:50, 10 August 2009 (UTC)

Right, there isn't any documentation in {citation} because it isn't useful to document functionality that doesn't yet exist. Otherwise we'd have editors crying that the parameter doesn't work.

Incidentally, citations describe sources. Wikipedia articles can't be used as sources, so a link to 'Newcomb's Tables of the Sun' wouldn't be appropriate. I understand what you mean though. -- Fullstop (talk) 21:02, 10 August 2009 (UTC)

A link to an article about the work is perfectly legitimate. There is no reason not to make the person reading the citation that Wikipedia has an article about a particular work. Such an article could inform the reader about the reaction of critics to the work, describe the different editions available, or provide information about how to obtain copies of older works. --Jc3s5h (talk) 23:20, 10 August 2009 (UTC)

Erm, no. Citations are not prose. Citations exist for a writer to indicate where he/she got the sourced statement from, to give due credit to a source, to demonstrate that the sourced statement are not one's own thoughts, to demonstrate reliability, and to indicate where more discussion/information on the cited context is available. This is true for citations everywhere, and always has been.

In any case, links to an article about a work are not at all^[a][b][c]... "perfectly" legitimate.

But this is is really way off-topic, so if you would like to discuss this, let's do it somewhere else (e.g. WT:CITE). -- Fullstop (talk) 14:56, 11 August 2009 (UTC)

Use of cite element

Currently, this template uses a cite element to wrap the whole citation. However, this is incompatible with its definition in HTML 5. This also creates the need to add silly code like style="font-style:normal" to all citations. I propose to use a plain span instead, which I implemented in the sandbox. (This also happens to reduce the markup by 17 bytes.) Note that we'll have to add some code to MediaWiki:Common.css before deploying this, though. Any comments? —Ms2ger (talk) 12:34, 3 August 2009 (UTC)

I agree, this is a Bad Thing. (also)Happy‑melon 17:08, 3 August 2009 (UTC)

Agree that this sort of fix is needed. What would go into Common.css? Eubulides (talk) 19:50, 3 August 2009 (UTC)

Agree too. But what are class="citation" and "some code" (?) in Common.css needed for? -- Fullstop (talk) 20:51, 5 August 2009 (UTC)

Basically, everything that applies to cite right now, should also apply to span.citation. That's the :target magic (the blue background if you click a link to a citation), the word-wrap (to break URLs when necessary) and the printonly rule (used for URLs). —Ms2ger (talk) 14:42, 8 August 2009 (UTC)

I see you applied a change to the sandbox along those lines. Is that's all that's needed here? Should it be installed now? If not, what else needs to be done first? Eubulides (talk) 03:53, 10 August 2009 (UTC)

As I said, this needs some edits to MediaWiki:Common.css first. —Ms2ger (talk) 08:14, 10 August 2009 (UTC)

I've added an {editprotected} at MediaWiki_talk:Common.css#reference:target -- Fullstop (talk) 16:27, 10 August 2009 (UTC)

See also changes to ./core, and to ./make_link -- Fullstop (talk) 16:47, 10 August 2009 (UTC)

I'd just wait until the new CSS is decached, i.e., 30 days after the edit to Common.css. —Ms2ger (talk) 10:00, 11 August 2009 (UTC)

That would be after 11 September. —Ms2ger (talk) 12:19, 11 August 2009 (UTC)

Date formatting test

A discussion regarding date formatting has been started at Talk:Ares I#Date formatting test
— Ω (talk) 19:20, 7 August 2009 (UTC)

Foreign language source citations

Are there any plans to make this template include {{lang|Language tag|Text}} on Titles and author names that are foreign language sources? If not, are there some alternative citation templates that specifies foreign language citations? This is to mainly use on other language wikipedias that translate english articles, but like to use {{lang|Language tag|Text}} on foreign text (to prevent transliteration etc.)--Pepsi Lite (talk) 05:33, 9 August 2009 (UTC)

Unknown archive date

Is there a convention for what to use for the archivedate parameter when the date is unknown? I have used "archivedate=an unknown date", but the result looks a bit silly, in my opinion.  --Lambiam 19:12, 10 August 2009 (UTC)

Could you please post the link to such an archive? Thx. -- Fullstop (talk) 20:25, 10 August 2009 (UTC)

Checking Lambiam's contribs, I found one here with "an unknown date" given for the archivedate. Plastikspork (talk) 21:12, 10 August 2009 (UTC)

The "Economist" one? Even though the periodical= field says "The Economist", the url= and contribution= refer to a website unrelated to the Economist. That makes that citation a classic case of false citation. The ostensible "archive" is not an archive. Its the source that was used by the other website. -- Fullstop (talk) 22:01, 10 August 2009 (UTC)

Methinks that url=http://www.economist.com/opinion/displaystory.cfm?story_id=9116747 actually does refer to a website very much related to The Economist. What is more, there are no periodical= or contribution= fields in the template, nor in fact in any other template used on the page. You must be talking about some other citation in some other article.  --Lambiam 06:08, 12 August 2009 (UTC)

So 'tis. Its ./core's formatting that makes "archive"s appear as the source. -- Fullstop (talk) 10:56, 18 August 2009 (UTC)

Next to the one already given by Plastikspork (which actually uses "an unspecified date"), there is also one (not created by me) in the article İhsan Hakan.  --Lambiam 06:13, 12 August 2009 (UTC)

Neither of those "archives" is an archive. What's "needed" there is a linked "(mirror)" or some such at the end of the citation. Moreover, those are newspaper articles, not "web". -- Fullstop (talk) 10:56, 18 August 2009 (UTC)

Z3988

For some reason the end of this "microformat" contains <span style="display: none;"> </span>. I do not see what it's purpose is. —TheDJ (talk • contribs) 14:35, 11 August 2009 (UTC)

found the diff. It seems to me, this extra span can be remove and the style be added to the Z3988 span itself. —TheDJ (talk • contribs) 14:40, 11 August 2009 (UTC)

That's how we had it before, but there were problems with that. The April 2008 discussion is here. -- Fullstop (talk) 15:03, 11 August 2009 (UTC)

Ah, the button inserts itself into the content of the span ? That is unfortunate. —TheDJ (talk • contribs) 16:07, 11 August 2009 (UTC)

authorlink w/o author or last/first set

(I searched the archive of Wikipedia talk:Citation templates and saw no discussion of this)

For {{cite web}} and the similar templates supporting author, first, last, authorlink, I'd like to request the following: if authorlink is set, and author/first/last are not set, the template should consider authorlink to be the author's name and display it as a wikilink. In other words, setting authorlink alone would be treated as shorthand for setting both authorlink and author to the same thing. If you're concerned about unknown potential backwards compatibility issues, creating a new parameter called authorwikilink or whatever is an alternative. The point of all of this is that it is not uncommon for published authors to have articles about them, and if authorlink is set, it is better to do what is done in the main text of articles and assume that the un-disambiguated version is the right version. Thanks. 66.167.48.5 (talk) 01:54, 23 August 2009 (UTC)

But don't we always want the format of the author name to be "surname, given"? We can't do that if we only have the authorlink. — RockMFR 13:56, 23 August 2009 (UTC)

Deactivated request pending clarification and further discussion. — Martin (MSGJ · talk) 22:23, 23 August 2009 (UTC)

"Surname, given" is preferred by {{cite book}} (which says the use of author is deprecated there) but {{cite web}}, {{cite news}}, and {{cite journal}} allow for both formats. Thanks. 67.101.7.151 (talk) 06:34, 25 August 2009 (UTC).