Jump to content

Template talk:Citation/core/Archive 11

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia
Archive 5←Archive 9Archive 10Archive 11Archive 12Archive 13→Archive 15

New Template:Citation/author to handle each name

While experimenting to reduce the internal processing stages of template {Citation/core}, I have created new Template:Citation/author to handle the formatting of each author name, perhaps allowing for displaying 12 or more authors in the future, while also reducing the "MediaWiki expansion depth" of {Citation/core}. Previously, each surname has been nested as if-else-else-else-else to 8 surnames deep, and if surname2/last2 is omitted, then surname3 and others would not appear. Instead, {Citation/author} allows any other surnames to be displayed, even if surname2 or surname7 were to be omitted. I noticed how some articles have surname15 (or last15?), so do we want to display those extra author names, beyond display-authors=8? -Wikid77 17:52, 9 January 2011 (UTC)

I think one should be able to insert 12 or more authors, but they should not all be displayed. It's better just to have them appear in the metatags (Z3988). We should think about an additional parameter that allows to set the number of authors to be displayed, and that adds a et al. for the remaining. —bender235 (talk) 19:38, 9 January 2011 (UTC)
The |Trunc= parameter already does this. Try providing {{citation/core}} with, say, six authors, and set |Trunc=3. In {{citation}}, {{cite book}} and {{cite journal}} (poss others) this is the |display-authors= parameter, and if omitted the default is 8. That's why giving nine authors replaces the last one with "et al.". --Redrose64 (talk) 20:10, 9 January 2011 (UTC)
Nice. Didn't know that. —bender235 (talk) 21:35, 9 January 2011 (UTC)

Rewriting templates for 2x smaller results

09-Jan-2011: I have found that combining Template:Cite_book with {Citation/core} can cut the resource usage by 56%, using less than half of the MediaWiki preprocessor resources, as when {Citation/core} is separate. The key resource is the "post-expand include size" such as 3800 bytes reduced to 1800 bytes per Cite_book entry (with total post-expand limit=2,000 kb or 2,048,000 bytes). At first, I tried omitting rare parameters, such as surname5 to surname8 or editor-surname3, but restored all the parameters, using only the technical change to combine templates. Even omitting the COinS metadata saved only 700 bytes, whereas combining templates saved 2,000 bytes per {Cite_book} usage. There are some possible alternatives:

  • Make {Citation/core} the actual top template, with "Cite_web" or "Cite_book" to be redirects to it (and change all the internal parameter names).
  • Create a {Template:Citation/core_markup} which has common markup text to be physically copied into each of the major top templates, rather than transcluding {Citation/core} as passed parameter names.

In a sample test, I ran an edit-preview of the {Cite_book} references in article "Abraham Lincoln" and they were reduced by over 55% from 198,000 to 90,000 bytes, just as a proof of concept. The post-expand limit mainly affects medical and chemistry articles; however, the 55% reduction could benefit many other subject areas as well. Currently, {Cite_web} has nearly 797,000 usages, while {Cite_book} has 284,000 and growing. I realize how rewriting these templates could be considered a major shock, so this is just the beginning of discussing various options. -talk 00:41, 10 January 2011 (UTC)

Please not option two. This is how things worked in the past, and led to a major headache because the separate templates were independently maintained, and thus drifted apart from one another, causing formatting nightmares and problems with incompatible parameters. Option one might be workable, as long as switches for the different parameter types in "Citation" and "cite xxx" can be coded in; the templates all use the same parameters and produce the same output, at least.
More importantly, have you demonstrated that the change in post-expand limit is measurable (in terms of page-load time) and thus worth worrying about? I spent this morning modifying a navbox with a post-expand size of 1,487,602 bytes, which puts the 10,000-byte saving into context. Martin (Smith609 – Talk) 02:48, 10 January 2011 (UTC)
  • Although navboxes might seem off-topic, they are definitely the "elephant in the room" of resource-limit nightmares, where half need to be external navpages not internal navboxes. Meanwhile, we want some scholarly articles to have many references without hogging resources, as fighting against huge navboxes. I had tried to preempt the navbox crisis, years ago, by writing essay "WP:Overlink crisis" but I was fought bitterly (with people even deleting facts from the essay they did not want to hear). I say we "cannot let templates rot" just because they are resource-hogs which might diverge with separate parameters. Compare the performance capabilities: a page can have 1 million tiny templates, but only 500 {Cite_xxx} references. That is how a "hog" is spotted, when performance goes from 1 million to just hundreds, rather than to thousands of utility templates. I understand the viewpoint, "It's not a problem until an article cannot format, and when admins are asked to desperately hack the article to fit". However, the day is fast approaching when admins (whose burnout limits are already being stressed) will be continually hacking templates to fit, and we need to avoid problems now rather than wait until they become numerous crisis issues. To thwart template-fork divergence, use the "80/20 Rule": only the most highly-used templates (used in "80%" of references: {Cite_web} & {Cite_book}) should be optimized by special markup coding, and the 20 lesser variations {Cite_xxx} can all share {Citation/core} with double or triple the resource usage. The optimization of {Cite_book} will not lead to "Heinz 57 varieties" of 57 incompatible cite templates, because {Citation/core} will remain to harness others to the common, shared parameters. -Wikid77 16:08, 10 January 2011 (UTC)
I've no particular opinion on the technical structure of the templates, but if we could improve performance it would address one of the main general criticisms of citation templates (possible increased page load time) made by detractors. Rjwilmsi 17:27, 26 January 2011 (UTC)

Consensus for volume-name and no-sep Volume

12-Jan-2011: Weeks have passed, and no one has objected to removing the separator between Series and Volume, to show a volume 4 as "Title of Series 4". Also, new optional parameter "volume-name" will show the unbolded title of a volume, in the same location, but with a separator. Those changes will be requested, below, as topic: "#Update for Volume and volume-name". Do we want to include any other related changes at the same time? The doc page will be updated soon after the changes are installed successfully. Any changes to template {Cite_book} will be discussed there, on the Template_talk:Cite_book page instead. -Wikid77 09:47, 12 January 2011 (UTC)

  • My suggestions at "Display of work date when authorless" above, appear to have gained no consensus through no response. I'd invite people to respond, given that the issue of display of work date when works are authorless would impact on hundreds of thousands of pages; and I'd rather go down in flames than stew in the belief that nobody cared about the issue. Fifelfoo (talk) 11:48, 12 January 2011 (UTC)
"Also, new optional parameter "volume-name" will show the unbolded title of a volume, in the same location, but with a separator."
Wouldn't "volume-unbold" be a more distinctive name? Especially if it was a "y/n" type of parameter.
The contents of volume-name would be like "Volume IX: Inventions which Changed the World" to show as italicized. -Wikid77 13:57, 12 January 2011 (UTC)
"Do we want to include any other related changes at the same time?"
The proposed change of ed./eds. to (ed.)/(eds.) is a couple of months old, too. And no objections thus far. —bender235 (talk) 11:51, 12 January 2011 (UTC)
I agree that it would be better as either "(ed.)/(eds.)" and is another simple change which does not affect the display order of other parameters. -Wikid77 13:57, 12 January 2011 (UTC)
  • The templates seem to generally name after the variable's function, rather than display features, and is intended for named volumes. Have you tested what happens when both Volume and volume-name exist? Fifelfoo (talk) 12:41, 12 January 2011 (UTC)
When both, the display includes both, as in: "Title of Work 17. Volume 17: Supplement for 1891. Should the volume-name not be italicized? -Wikid77 13:57, 12 January 2011 (UTC)
  • Generally named volumes are not italicised. If the author wanted to include the volume name in the work name, they could have. Compare Goats of Africa: Volume 4, tall goats where the title page reads "Goats of Africa: Volume 4, tall goats" versus Snails of Papua. Volume 4: the lesser snails. where the title page reads "Snails of Papua" and in the fourth volume of the work titled Snails of Papua, that work contains a volume title. Fifelfoo (talk) 14:31, 12 January 2011 (UTC)
Please remember in this discussion that citation templates are to be used to implement a style, not to define it. See Wikipedia:Citing_sources/Example_edits_for_different_methods#Footnotes for examples. To discuss what the implemented style should be, I'd suggest that Wikipedia talk:Citing_sources is a better venue for the discussion.LeadSongDog come howl! 19:16, 12 January 2011 (UTC)
Wikipedia talk:Citing_sources does not determine the "style" either, because right now there is no such thing as a Wikipedia citation style. Current guidelines say "use whatever citation style you prefer, as long as it is consistent throughout the article". Therefore discuss a change regarding this template here is correct. —bender235 (talk) 20:55, 12 January 2011 (UTC)
That's not exactly what wp:CITE#HOW says. Formats in an article should normally follow the first editor's choices unless there is consensus to change them. Hiding the discussion in a template talkpage doesn't cut it for establishing that consensus. We've been over this before. LeadSongDog come howl! 22:07, 12 January 2011 (UTC)
  • It is a bit obtuse to suggest we shouldn't define style here when a requested feature, named volumes, results in a template author suggesting italics for a non-title element. Now, the author of the template made a stylistic decision. It isn't yet implemented, and, to me it is fairly controversial as it breaks the generalised purpose of italics, which is to indicate the title of the published obtainable work containing the content. Worth mentioning before another million pages are impacted by a revision. Fifelfoo (talk) 22:46, 12 January 2011 (UTC)

Semi-auto-bolding of Volume

12-Jan-2011: Because templates can be lightning fast, when written considering performance options, there is ample time for {Citation/core} to generate "smart-formatting" of the Volume, such as bolded when Volume is only a number-and/or-letter combination (such as volume "15a" or "E" or "XIX") but unbolded otherwise (such as "Volume 4: The lesser snails"). Then, to handle the various exception cases, a new parameter "volume-bold=yes" or "volume-bold=no" would force the decision rather than have auto-bolding look for a volume number/letter. Such auto-bolding would avoid having to edit thousands of articles which currently have a volume name in Parameter "Volume" (rather than just having "15a"). Also, new users would just set a name (or number) in parameter "Volume" without worring about the format unless it was a rare exception. So, the smart-formatting would use a bolded value when parameter Volume was "15a" or "E" or "XIX" (etc.), but otherwise put a separator, then show the unbolded text from Volume. For exceptions (perhaps 1 in 500), include "volume-bold=yes" (or "no"). Does that seem more acceptable? I am listening and trying to follow real-world styles here. -Wikid77 23:51, 12 January 2011 (UTC)

  • I'd be happy with this. As Wikid77 recognises, there will be edge cases here, but the availability of manual handling within the template of edge cases looks fine to me. I'm pretty comfortable with automated detection of "numberlike" volume numbers and have high confidence in such automated content recognition techniques. The other advantage is that the volume parameter is used for both enumerated and titled volumes, encouraging a deeper logic around the field being citation role rather than formatting based. Fifelfoo (talk) 00:17, 13 January 2011 (UTC)
I agree how people should put any volume text in parameter "Volume", and I have successfully coded the unbold-detection logic for the "semi-auto-bolded" volume; plus due to rewriting for improved performance, the smart-formatting of the volume is actually 3x shorter than the prior formatting for volume. So, it will automatically unbold volume names but keep bolded volume numbers ("15a"), all 3x times quicker than before. -Wikid77 (talk) 19:32, 13 January 2011 (UTC)

Update for Volume and volume-bold

{{editprotected|Template:Citation/core}}
14-Jan-2011: Template:Citation/core needs to be updated from Template:Citation/core/sandbox3 (the 3rd sandbox version) to omit the separator {{{Sep}}} between Series & Volume, plus support new parameter "volume-bold=no" (or "=yes") and trigger the automatic unbolded formatting of volume (preceded by the separator "," or "."). The COinS metadata will be unchanged, because "&rft.volume" is set from "Volume" regardless of the bolded/unbolded format. The hyphenated name "volume-bold" was chosen to allow unique wikisearch for articles using it, similar to searching parameter "display-authors". (Template differences can be checked by editing {Citation/core/sandbox3}, replacing the edit-buffer from view {Citation/core} & then "Show changes" during edit-preview mode).
Performance: The post-expand size for Volume drops 66% due to omitting 2 <nowiki/> tags (of 44 bytes each); the expansion depth is unchanged, as 4 #if-#switch for Volume are smaller than if-else nesting for Surname2. IMPACT: At the least, 1.1 million articles will be reformatted, because Citation/core is used by {Cite_web}, {Cite_book}, {Cite_journal}, {Cite_news}, etc. Some testcases:

  • Expected: {{Cite book|title=Title of Book|volume=234c}} → Title of Book. 234c .
  • Currently: {{Cite book|title=Title of Book|volume=234c}} → Title of Book. Vol. 234c.
  • Expected: {{Cite book|title=Stuff|volume=Book 3: More stuff}} → Stuff. Book 3: More stuff.
  • Currently: {{Cite book|title=Stuff|volume=Book 3: More stuff}} → Stuff. Vol. Book 3: More stuff.
  • Expected: {{Cite journal|title=Nature|volume=Archive 2010b}} → Nature. Archive 2010b.
  • Currently: {{Cite journal|title=Nature |volume=Archive 2010b}} → "Nature". Archive 2010b. {{cite journal}}: Cite journal requires |journal= (help)
  • Expected: {{Cite book|title=Taxonomy Rules|volume=Vol. 4: Taxonomy of Invertebrates}}
     → Taxonomy Rules. Vol. 4: Taxonomy of Invertebrates .
  • Currently: {{Cite book|title=Taxonomy Rules|volume=Vol. 4: Taxonomy of Invertebrates}}
     → Taxonomy Rules. Vol. Vol. 4: Taxonomy of Invertebrates. {{cite book}}: |volume= has extra text (help)

After updating {Citation/core}, the results should match. Because prior bolding, of long volume names, was excessive bolding, this change will be perceived mostly as a "bug fix" which removes the glaring overkill of bolding when not wanted for volume names. -Wikid77 (talk) 13:35, 14 January 2011 (UTC)

Questions about Volume parameter

The following are questions about the Volume parameter:

Why do you want volume unbolded now? I thought we're talking about the edition off a new parameter, like volume-title or volume-unbold. —bender235 (talk) 14:39, 14 January 2011 (UTC)
Most will still be bolded in parameter Volume, but volume names will unbold, as discussed above. The new parameter is named "volume-bold" (rather than "volume-unbold") to avoid a double negative where unbold=no means "not not bolded" as un-no means "yes" so simply use "volume-bold=yes". The user could also specify "volume-bold=no" to remove the bolding of a specific volume number, but all still remain bolded as before. I hope that clarifies the confusion: volume numbers will remain bolded. -Wikid77 20:18, 21 January 2011 (UTC)
Without voicing an opinion about whether or not this should be done, or be done here vs. in transcluding templates, I'll suggest that if it is done and done here it might be more intuitive to implement Volume-notbold= as an alternative to Volume= rather than as a behavior toggle.
Also, see the wikitext for an ugly usage hack which relies on current behavior to produce the following:
  • Title of Book. Vol. 234c.
  • {{Cite book|title=Stuff|volume=</b>Book 3: More stuff<b>}}
  • {{Cite journal|title=Nature |volume=</b>Archive 2010b<b>}}
  • {{Cite book|title=Taxonomy Rules|volume=</b>Vol. 4: Taxonomy of Invertebrates<b>}}
That's just an observation re the hackish usage, not a suggestion. I'll also observe without suggesting it that this Citation/core worker template can be similarly hackishly parameterized by a transcluding template to produce
Those concerns are answered, below, for "Why not have Volume-notbold?" and using "</b>" to force unbolding. -Wikid77 15:24, 23 January 2011 (UTC)

Why not have Volume-notbold? Answer: The problems with having a 2nd Volume parameter named "Volume-notbold=myvolume" (rather than set switch: volume-bold=no) are several:

  • Some people might think to use both "Volume" & "Volume-notbold" at once and expect to see both volume ids listed.
  • If either "Volume" or "Volume-notbold" were an option override to the other, people might change the first one and wonder why that change was not displayed, or vice versa.
  • Storing the COinS metadata would have to choose: store "Volume", store alternate "Volume-notbold" as an override, or store both.
  • The name "Volume-notbold" would prompt many alternate spellings: Volume-Notbold, Volume-not-bold, Volume-Not-Bold, Volume-Bold, etc.
  • People might logically think the name "Volume-notbold" was a behaviour switch, after all, and try setting "Volume-notbold=yes".
  • Plus, other concerns too tedious to list here.

For all those reasons, considered earlier, the parameter "volume-name" was also dropped, and the single parameter "Volume" was selected to hold any volume id, with the bolding removed by setting new parameter "volume-bold=no". -Wikid77 15:24, 23 January 2011 (UTC)

Re repetition of and choosing between parameters, that's why I said "alternative" and "alias"; e.g., {{#if:{{{Volume|{{{Volume-bold|}}}}}}|'''{{{Volume|{{{Volume-bold|}}}}}}'''|{{{Volume-notbold}}}}}. Re the naming (notbold vs. unbold vs. whatever), I have no strong preference. Re people who have not read the docs misunderstanding the usage, they should RTFdocs. Re other concerns too tedious to list here, no comment.
I tend to prefer alternative parameter names over behavior-controlling switches, hence my suggestion that that might be more intuitive, but it's not really a big deal to me. Wtmitchell (talk) (earlier Boracay Bill) 00:02, 24 January 2011 (UTC)

What happens if unbolding was already forced by </b>? Answer: That technique would still work after volume-bold was implemented, due to the "<" being considered as starting a non-bolded name:

  • Proposed: with Volume=45a:              Test volume unbolding, 45a, 234, "This is a quote" .
  • Proposed: with Volume=</b>45a<b>: Test volume unbolding, 45a, 234, "This is a quote" .

So if, over the past years, many people had altered thousands of article citations to force a non-bolded volume id (using: </b>), those citations would still remain unbolded, despite allowing new option "volume-bold=no" as an alternative. No articles need to be changed after {{Citation/core}} is updated to have parameter volume-bold. -Wikid77 15:24, 23 January 2011 (UTC)

Yes, Understood. Wtmitchell (talk) (earlier Boracay Bill) 00:02, 24 January 2011 (UTC)

Space bug with quote

Someone noticed a problem in {{cite journal}} when using |quote= and I confirmed it in core: 


{{Citation/core |Periodical=Example |URL=http://example.org |quote=Now is the time to quote}}

Example, http://example.org,+"Now is the time to quote" 

As can be seen, a comma and an encoded space are being stuffed into the url. ---— Gadget850 (Ed) talk 18:14, 26 January 2011 (UTC)

At first, I thought it was {{citation/make link}}, but I now believe that it's the code below the heading "URL and AccessDate". --Redrose64 (talk) 20:44, 26 January 2011 (UTC)
That's what it looks like to me. Here's something else unexpected which appears to be related:
as expected, but
Wtmitchell (talk) (earlier Boracay Bill) 23:47, 27 January 2011 (UTC)
A fix (or workaround?) which could be put into core appears to be inserting a blank after the comma.
So, changing |{{{Sep|,}}}&#32;"{{{quote}}}" to |{{{Sep|,}}}<!--blank char required here--> &#32;"{{{quote}}}" should fix it. Wtmitchell (talk) (earlier Boracay Bill) 23:59, 27 January 2011 (UTC)

Help with an unusual citation.

This is a citation to a letter to the editor. It doesn't look right here:

(Check the source). Any suggestions? ---- CharlesGillingham (talk) 06:34, 3 February 2011 (UTC)

Don't wikilink |contribution=Darwin among the Machines
--Redrose64 (talk) 13:59, 3 February 2011 (UTC)

Sure, but this one of those cases where the source is famous enough to have an article of its own. Shouldn't we have a link to both the article and the online source? ---- CharlesGillingham (talk) 18:36, 3 February 2011 (UTC)

The article should link to the publication in question. If we want to present both links in the citation, we would have to come up with some sort of method. ---— Gadget850 (Ed) talk 19:05, 3 February 2011 (UTC)
In this case, the letter is reprinted as part of a collected volume, right? The url doesn't go to the newspaper page itself (although probably it could as many old NZ newspapers have been digitized). Also when citing from a journal or newspaper one should use title=, not contribution= (that's what's giving you the odd doubled comma) or maybe it's a contribution within a "title" that is letters to the editor. So I would format it as something like:
—David Eppstein (talk) 21:49, 11 February 2011 (UTC)

Template fails in pages with many transclusions

Check for instance:

  1. List of Heroes of the Russian Federation
  2. List of Major chapters
  3. Mountain peaks of North America

They all exceed some limit. -- Magioladitis (talk) 15:34, 11 February 2011 (UTC)

They all exceed the Post-expand include size of 2048000 bytes. --Tothwolf (talk) 16:00, 11 February 2011 (UTC)
This is why list articles often get split. Often such a page will not even open unless you log out. ---— Gadget850 (Ed) talk 16:47, 11 February 2011 (UTC)

Editor list issues

There appear to be two issues with the core citation template in regards to editor lists. First, unlike the author list, which displays et al. in italics, the editor list displays "et al." without italics. This is inconsistent. Also, long editor lists that get truncated to et al. create a double full stop: "et al.." – VisionHolder « talk » 21:02, 28 February 2011 (UTC)

Trans_title and URL seem incompatible

Perhaps I'm doing something wrong at Template:Cite_doi/10.1007.2FBF02986061, but the URL is not forming a wikilink, presumably because of the |trans_title= parameter. Martin (Smith609 – Talk) 17:10, 4 March 2011 (UTC)

 Fixed The http:// part is mandatory for all URLs unless they begin with some other protocol such as ftp:, mailto: etc. --Redrose64 (talk) 18:06, 4 March 2011 (UTC)
That was daft of me. Thanks for spotting it! Martin (Smith609 – Talk) 18:24, 4 March 2011 (UTC)

Looking for examples/suggestions for extension to replace this template

Due to the overly featurefull template this has become, it has also become increasingly slow, as most of you are undoubtedly aware. As such, I am working on an extension to write this template into PHP, which should generate a much faster output, known as TemplateAdventures. An unfortunate issue is - however - that it is lessen in ease of modification if such should be desired at a later point.

Therefore am I opening up for suggestions at its talk page (I'd prefer it if you replied there, as my watch list is ever growing here, and I receive email notifications on mw.org) as well as examples and their desired output, so I can get parameters and interests working.

It is currently in testing at my test wiki. --Svippong 18:47, 19 April 2011 (UTC)

Someone else is working on this, but I can't remember who. ---— Gadget850 (Ed) talk 22:12, 19 April 2011 (UTC)
They have not made such an announcement on the bug report, then. Perhaps they gave up? I know Template:Convert was rewritten as part of ParserFunctions. --Svippong 11:33, 22 April 2011 (UTC)
You are right— it was Convert. CRS. ---— Gadget850 (Ed) talk 12:02, 22 April 2011 (UTC)
Svip, I don't know what you've done about implementation so far but, requirements-wise, my first thought from having seen a lot of arguments over citation style in WP, are:
  • flexible enough to be able to handle different styles;
  • style identifier should be specifiable on a per-article basis -- probably on the initial invocation and with later conflicting invocations being errored (with a changeable WP-wide default style-identifier specifiable somewhere);
  • style details should be configurable and extensible on a per-supported-style basis without touching the php code.
To me that suggests, design-wise:
  • paramaterizing files for named supported styles located in some location specifiable at WP-configure-time, perhaps changeable on the fly after WP startup;
  • paramaterizing files for each supported style containing entries naming supported parameters, and specifying for each
  • name(s) of related-required parameters (error if not encountered),
  • placement in output ordering,
  • formatting (for bolding, italicizing, ...),
  • flag to attempt using conversion helper (for jstor, isbn, ...),
  • etc. (e.g., number of authors/editors to output for this style before going to "et. al.")
One-by-one, then, the Citation and Cite xxx templates could be replaced with templates using this new citation-generating function instead of Citation/core. The interface through those front-ending templates could be left as is and/or, possibly for high-usage ones, moved into the parser -- that'd be phase 2.
That's as far as I've thought about it, and there's a lot more thinking to do. When I was doing software I favored a Rapid application development approach, and I think that fits here. Does any of that makes sense? Wtmitchell (talk) (earlier Boracay Bill) 14:38, 22 April 2011 (UTC)
I agree with the above. And thanks, Svippong, for taking this on. This is a big project, and your code looks great. Something like this has been needed for a long time. I think that this template has become about twice as complex as it was when I wrote the first version in 2007, which was already probably the most complex template in use. And many pages transclude 50 or more of these templates. So I think that moving the core functionality to php ought to produce dramatic efficiencies. COGDEN 20:00, 22 April 2011 (UTC)
Well, MZMBride had been pushing for it as I was asking for ideas to pursue after I finished mw:Extension:NaturalLanguageList, but with the knowledge of efficiency and maintenance lost due to complexity, I am certain this extension will bring joy to many. --Svippong 22:26, 22 April 2011 (UTC)
As of right now, the extension does support a style type. Though, at present named silly issues such as 'news' and 'journal', but that can all change. The first parameter to the function is always the type/style, ununderstood input will be ignored, and it will default to a configured default style. A general example would be {{#citation:news|title=What is a title, truly?|url=http://example.com/}} which would use the style/type of 'news'. We can possibly come to an agreement on types of styles, and what difference they produce. --Svippong 22:26, 22 April 2011 (UTC)
Agreement in WP about citation styles? Surely you jest.
When I mentioned "different styles" above re requirements, I had in mind something like CMS vs. APA vs. MLA vs. Vancouver vs. Bluebook, etc. -- citation styles. I'm not clueful about the specifics of those, but I've looked at some of them closely enough to understand that it gets messy, and that variations exist. It'd be possible to have a WP-wide per-style default interpretation and supported variations (CMS, CMSv1, CMSv2, etc., but probably more mnemonically named), by providing appropriately-named paramaterizing files -- one for the WP-wide default interpretation of, say, CMS; one for each supported variation.
For some citation styles, it might be useful/necessary to be able to specify an item type (e.g., book, journal, etc.) as well. That could be supported as an option, with a default if not specified.
WP:CITEVAR says, "... the style used should be consistent. ...". As I tried to indicate re requirements above, this could be enforced on a per-article basis for cites which use this mechanism -- the first such cite encountered could set the article-wide style, and subsequent cites calling for a different style could be errored. Wtmitchell (talk) (earlier Boracay Bill) 23:59, 22 April 2011 (UTC)
One benefit of handling citations in php is that it would be relatively efficient to provide an article-by-article citation of standard styles like APA, MLA, Bluebook, Chicago Manual of Style, etc. Up until now, I don't think this has been realistic, given the fact that what we have now is already stretching the limits of what template code can realistically do. I don't know if all that functionality has to be included before version 1.0, but maybe there should at least be an infrastructure in place to allow the addition of standard citation styles later. COGDEN 20:45, 25 April 2011 (UTC)
Indeed, I think it will help the development if we divide it up into phases, where each phase have some pre-defined features that it needs to have finished before it can be considered done. That way we won't get caught up in extensive features and never get anything done. Roadmaps certainly help. However, I am currently ceasing development, since I realise that this extension may be more complicated that initially anticipated (not that is discouraging me from continuing however), which means we need to establish some clear definitions of how it works - both internally and front end - before we start with the real coding. It's a waste of time doing something then realising you'll have to do it over again; differently. --Svippong 20:53, 25 April 2011 (UTC)
I think that, like Citation/core, the php code should be able to determine what kind of citation it is (periodical, website, book, etc.) based on the particular configuration of parameters that get passed to it. It could work like {{Citation}} without having to specify a "news" or "book" style type. Perhaps the "style type" ought to instead be the particular reference standard, such as APA, MLA, Bluebook, Chicago, etc. For example, calling the function might look something like this: {{#citation:APA |last=Blow |first=Joe |title=What is a title, truly? |periodical=The Journal |volume=5 |year=2011 |url=http://example.com/}} To avoid rocking the boat too much upon implementation, the default would be styling like we have now (which is slightly non-standard APA). Version 1.0 would basically replicate {{Citation}} and ignore the first argument, then specific implementations for APA, MLA, Bluebook, etc., would come later.COGDEN 07:13, 27 April 2011 (UTC)
(edit conflict) Son of a gun! One wonders if this could be the application of something like SSADM to WP templates — breaking a software engineering task up by sub-discipline. Wonder of wonders! Wtmitchell (talk) (earlier Boracay Bill) 07:28, 27 April 2011 (UTC)
Retrieved from "https://en.wikipedia.org/w/index.php?title=Template_talk:Citation/core/Archive_11&oldid=1148626034"