Sie sind auf Seite 1von 36

Feature request: trans_quote parameter

I'd like to request the addition of a trans_quote parameter that would be, at least, a
repository for a translation of a quote in a foreign-language source. (I'd be happy enough if the
parameter were just ignored for display purposes, as long as the quote translation is available to
someone who digs deep enough, though if anybody has better ideas about display, cool.) I've
actually used this parameter in a few places in hopes that it might exist someday, but that's
become problematic now that unknown parameters are showing an error message. Can we add
this? —chaos5023 (talk) 17:30, 4 June 2013 (UTC)

Date formatting and machine readability


[Not sure whether this belongs here or on one of the related talk pages]

At some point, it's going to be useful to have the dates in citations made machine-readable, so
that they can be included in emitted metadata. That could be achieved in a number of ways, for
example, having separate parameters for their day, month and year; using YYYY-MM-DD
format, or using a subtemplate. Each has advantages and disadvantages. In the first two
examples, it's still possible to have the rendered output in the form "17 May 2013" or "May 17th,
2013", according to a setting (see {{Start date}} or {{Birth date}} for examples if this in
practice), or even user preference. Anyone got any thoughts? Andy Mabbett (Pigsonthewing);
Talk to Andy; Andy's edits 15:32, 17 May 2013 (UTC)

Dates used in citations are not always simple dates - you will get things like 13–19
December 2011, or Summer 1975. This would make this sort of automatic generation of
metadata difficult.Nigel Ish (talk) 15:47, 17 May 2013 (UTC)
Not at all; we already manage to emit metadata for regular birth/ death dates, while
accommodating (and not emitting as metadata) irregular dates such as "fl. 1735". Andy
Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 16:00, 17 May 2013 (UTC)
No thanks. Please don't try to bring back something that was binned two years ago.
Machines are perfectly capable of parsing all the date formats that are permitted under
our style guidelines, witness the dates that inhabit {{persondata}}. Thus extra Date
Autoformatting templates that consume extra processing and compilation resources
without bringing significant benefits should not be contemplated. -- Ohc ¡digame!¿que pasa?
15:54, 17 May 2013 (UTC)
I'm not "trying to bring back something that was binned two years ago". I'm proposing
something new. Persondata is only read by our own tools; not generic metadata parsers,
like the ones that read dates in our infoboxes. We already use date templates such as the
ones I mention, elsewhere; with no undue overheads; and with significant benefits. Andy
Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 16:01, 17 May 2013 (UTC)
I was merely using {{persondata}} as an example. Our MOSNUM-permitted date
formats, of which there are only three, are all capable of being parsed by machine, all that
is needed is software configuration that's not rocket science. In the average article, there
may be up to 200 references, and thus up to 600 dates. Each set of dates is specific to one
citation but most are unimportant. If each set of dates is already sitting in a citation
template, we hardly need to nest in another three for each date type. If the dates are not
already in citation templates, metadata is next to useless. Without contemplating in detail
the computing resources consumed, and the benefit of standardising something that
scarcely needs standardising is potentially highly disruptive to the 'pedia. -- Ohc ¡digame!¿que
pasa? 16:37, 17 May 2013 (UTC)
Nigel Ish, above, has already shown that there are more than three ways to enter date
information. Using a sub-template was only one of the example methods I gave; there are
others. If we want to include machine readable dates to standard metadata formats like
COinS or a microformat, then they need to be formatted consistently, not as prose. Your
comments about potential for disruption are a straw man. Andy Mabbett
(Pigsonthewing); Talk to Andy; Andy's edits 16:59, 17 May 2013 (UTC)

:oppose until there is a way to set the default date on a page or to read the user preference date. -
- Gadget850 talk 16:10, 17 May 2013 (UTC)

What do you mean by "default date on a page"? User preference for date formatting could
be achieved by the same CSS technique that {{Coord}} uses for coordinates. Andy
Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 16:36, 17 May 2013 (UTC)
That CSS simply places the displayed coordinates. There is no magic word or parser
function that will unify all dates on a page, thus citation template can't inherit the date
format. The only user preference that I know can be read is gender. There was a
'dateformat' parameter for a brief time after date linking was removed, but there were
technical issues an it was removed; you can check the archives. -- Gadget850 talk 17:16,
17 May 2013 (UTC)
That (your first sentence) simply isn't the case; see Template:Coord#Per-user display
customization. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 18:37, 17
May 2013 (UTC)
Currently dates in citations are not machine readable because there is no indication what
calendar they are stated in, Julian or Gregorian. I suggest Andy go discuss with the
various metadata folks about how they should modify their formats to indicate a calendar
of Julian, Gregorian, or unknown, and come back when the metadata formats have been
suitably modified. Jc3s5h (talk) 16:57, 17 May 2013 (UTC)
This is already resolved for the date templates mentioned above (and which are used on
many thousands of articles); see their documentation. It is also resolved in the metadata
standards I mentioned. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits
17:11, 17 May 2013 (UTC)
Wait. Your original post is confusing, but it looks like this has nothing to do with date
formats, and I don't know why you threw that in. You simply want to include the date
metadata, which is very possible. We could add an algorithm that would convert the
standard date that is displayed to a metadata date that is now shown. For example, May
17, 2013 would be shown and converted to <time datetime="2013-05-17"> which
would not be shown. <time> is an HTML metadata element now supported by
MediaWiki. -- Gadget850 talk 17:27, 17 May 2013 (UTC)
I want to include the date metadata, and pointed out that how we store the values does not
need to limit the display format. But yes, we could do as up suggest (providing we don't
change the actual date ;-) )Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits
18:37, 17 May 2013 (UTC)
We've moved to what is, IMO, a very desirable simplicity in both the display and the
syntaxing of chronological items. When you say, "separate parameters for their day,
month and year", I start to quail that the whole system will become complex—which is
not good for the "anyone can edit" principle. I'm also quite unconvinced that metadata
systems cannot be developed without the use of localised syntax. And we already have
significant tools at our disposal for searching for years and dates. Tony (talk) 04:37, 18
May 2013 (UTC)
This isn't about "searching for years and dates" within Wikipedia. I'm not clear what you
mean by your "localised syntax" comment - please clarify, bearing in mind that we
already do this for other dates, mentioned above. Separate parameters are only suggested
as one of several options what's your proposed solution? Andy Mabbett (Pigsonthewing);
Talk to Andy; Andy's edits 11:07, 18 May 2013 (UTC)
We don't need separate parameters. There is no need to change the template input, thus
this would be user transparent. <time> is a standard HTML5 tag. -- Gadget850 talk 10:16,
18 May 2013 (UTC)
4.6.10 The time element at W3C --Redrose64 (talk) 11:00, 18 May 2013 (UTC)
How could that be deployed, in this case? Andy Mabbett (Pigsonthewing); Talk to Andy;
Andy's edits 11:07, 18 May 2013 (UTC)
Let's say that a given use of {{cite news}} emits <span class="citation
news">Lane, Lois (18 May 2013). "Superman prevents another trainwreck".
''Daily Planet''.</span>. All of that is generated by Module:Citation/CS1 using the
{{cite news}} parameters as input. We could amend the module so that it tests to see if
|date= is a valid date (to cover the situations like 13–19 December 2011, or Summer
1975 mentioned above). If the test succeeds, we put the date through the Lua equivalent
of {{#time:Y-m-d}} to generate a valid date string, place that in the datetime= attribute
of a <time>...</time> element which is wrapped around the original date, and output it
with the rest, something like <span class="citation news">Lane, Lois (<time
datetime="2013-05-18">18 May 2013</time>). "Superman prevents another
trainwreck". ''Daily Planet''.</span> --Redrose64 (talk) 12:07, 18 May 2013
(UTC) Sorry. I misread the documentation for the time element, so I've rewritten the
approprate bits here. --Redrose64 (talk) 16:25, 18 May 2013 (UTC)
OK, so that deals with publication dates. I don't understand to what use the metadata
would be put, so please explain to Dummy here how exactly this would be done in the
case of access dates, archive dates, and dates within the titles? And to what end? -
- Ohc ¡digame!¿que pasa? 12:42, 18 May 2013 (UTC)
We could use exactly the same technique for access dates and archive dates, in fact these
should be easier because they ought to only ever be a single date, and not cases like 13–
19 December 2011, or Summer 1975. We shouldn't try to detect dates in titles, these are
pretty much free-form, and trying to write code to extract a date sensibly would be a
nightmare, and I don't think it's worth the hassle. As regards "to what end"; well, that's up
to the harvesters of metadata. --Redrose64 (talk) 16:15, 18 May 2013 (UTC)
Does seem like typical YAGNI request: I am also not convinced the date format even
matters, here, because any metadata-processing tools could reformat whatever dates, on
their end, and using their processing time. So, beware typical YAGNI options ("You
aren't gonna need it"). Instead, wait for the issue to become a top headline in a major tech
newspaper:

 "Riot at Wikimedia when users screamed date format more important than fixing
Edit-conflicts" (just not likely)

There are probably some huge numbers of feature requests that are just typical YAGNI
requests, and so it is a common problem which distracts from fixing the major problems,
such as not external-linking the "trans_title=" to the URL address, to allow the trans_title
to contain wikilinks, or footnotes, which could better explain the translation. -Wikid77
16:58, 18 May 2013 (UTC)
You seem to present this as an "either/or" choice: a false dichotomy. And that's before we
consider the valid use-cases. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits
20:15, 18 May 2013 (UTC)
Well, instead of dismissing the opposition to the idea of collecting it, you ought to
demonstrate a solid need on our part for ever-increasing quantities of metadata when the
data is already in existence and in an exploitable form. Let's have some valid use-cases,
then, instead of just saying or implying we need it. If Google (or any other third party)
needs it, they can jolly well create it from what we give them – if they are not doing it
already. ;-) -- Ohc ¡digame!¿que pasa? 05:09, 19 May 2013 (UTC)
It's not in a (readily, to machines) exploitable form; I'm proposing that we make it so.
Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 12:32, 22 May 2013 (UTC)

 strong support -- i'm not a coder, but i can certainly see the usefulness of this proposal. it
would be USEFUL both for us & for external (i.e.: outside of wp/wm/mw) uses. calling
it "yagni" it just a fancy way of saying "can't be arsed"; it's a good idea, & it anticipates (a
wide range of) future needs & uses. to put it another way: if we don't do it now (machine-
readable dates, as per ISO 8601), we WILL be doing it later...

Lx 121 (talk) 20:02, 5 June 2013 (UTC)


as for the question of "extra processing", wouldn't it SAVE processing, if we standardize
everything/most-things into one date format? Lx 121 (talk) 20:07, 5 June 2013 (UTC)
Lx 121, ISO 8601 is not suitable for Wikipedia dates. Go read it and let us know if the
reason is as obvious to you as it is to me. Jc3s5h (talk) 23:18, 5 June 2013 (UTC)
Pure FUD. You've been banging on about this for years; yet we use ISO 8601 for dates in
templates like those listed above, on many thousands of articles. It's trivial, in Lua, to put
switches in to suppress metadata emission for pre-Gregorian dates. Andy Mabbett
(Pigsonthewing); Talk to Andy; Andy's edits 23:51, 5 June 2013 (UTC)
Yea, just like your obsession with all things 'metadata' is well known. You still haven't
elaborated how "useful" it is, despite having been asked more than once. -- Ohc ¡digame!¿que
pasa? 02:07, 6 June 2013 (UTC)

Feature request: possibility of having two ISBNs, one for


hard bound, the other for paperback
I noticed that there are a couple of entries in the International Phonetic Alphabet article, Further
reading section that are having trouble with the use of the cite book template, because an editor
entered two ISBNs for the |isbn= parameter. The books apparently do have two ISBNs: one each
for hard bound and for paperback. It seems that the only way to handle this now is to make two
separate citation entries, which seems overkill. So how about two parameters that can produce
two ISBNs in the listing (and differentiate hb from pb)? Other solutions are fine with me. I'm just
looking for some unclunky way to handle such a situation. Evenssteven (talk) 02:20, 31 May
2013 (UTC)

The idea of two parameters for different ISBNs has been suggested before, several times.
Where would we stop? Some books have more than two ISBNs - there are deluxe/limited
editions/gift sets, eBooks, abridged versions, large print, etc. My copy of the Concise
Oxford Dictionary has two ISBNs on the copyright page - both are for hardback editions,
the only difference is whether there's a thumb index or not. The back cover shows just
one.
When this topic comes up with ref sources, the usual response is: give only the ISBN for
the edition which was actually used. I think that for books given under "Further reading",
the same principle applies: you are recommending a particular book, so you must have
read it yourself, therefore give the details for the edition which you read, which will have
only one ISBN. --Redrose64 (talk) 09:52, 31 May 2013 (UTC)
Ok, that seems a perfectly reasonable rationale that I can use in my own writing. Do you
have a suggestion about how I might go about editing the International Phonetic
Alphabet article? I don't know which edition the person who put in the ref had read, and I
myself have read neither. So let me answer my own query, and you can supply a better
one if you know. Since I am in doubt, or don't know something, I am the wrong person to
edit the ref. WP is allowed to be imperfect, and if I don't know or expect my change to be
an improvement, then it's really not much of a contribution, and so I walk away from that
one. Thanks for the excellent advice; practical on two counts. Evenssteven (talk) 12:33,
31 May 2013 (UTC)
There are two possibilities: one is to alter |isbn=0-521-65236-7 (hb); ISBN 0-521-
63751-1 (pb)}} to |isbn=0-521-65236-7 }} ISBN 0-521-63751-1 or to |isbn=0-
521-65236-7 }} - either way, the hardback one is the one that I'd leave inside the
{{cite book}}. Do the same with the other one as well. --Redrose64 (talk) 13:27, 31
May 2013 (UTC)
"the only way to handle this now" Just want to point out that this never worked properly,
as the link to Special:BookSources would contain two ISBNs, which is parsed as a single
ISBN, thus is invalid. The templates now do error checking on the ISBN. -
- Gadget850 talk 13:38, 31 May 2013 (UTC)
I think |isbn=, like any other parameter expecting a single value, should have only a
single value; perhaps this should be documented somewhere? In this case the second
ISBN should be added following the template. ~ J. Johnson (JJ) (talk) 20:24, 31 May
2013 (UTC)
I thought that's what I put above... nevertheless, I've added a warning to the doc page. --
Redrose64 (talk) 23:01, 31 May 2013 (UTC)
I've run into this problem as well. Why not optionally allow a comma-separated list of
ISBNs to be given (separated by either "," or ";"). If it is undesirable to link them all, just
extract the first one for the link and display the remainder as normal text. Or add support
for the comment= parameter I proposed already (Help
talk:Citation_Style_1/Archive_2#Proposal_for_comment_parameter), where people
could add such extra information in free format. Adding it after the template sounds like a
work-around (which sometimes could look rather strange), not a solution. --Matthiaspaul
(talk) 09:00, 6 June 2013 (UTC)
The ISBN field is not for identifying all available copies, it is to identify the particular
source you read. You can stuff whatever you want in the |id= parameter. If you want 16
ISBNs, then go for it. But you must have read each of them and ensured the page
numbers match. WP:SAYWHEREYOUGOTIT. I'm tired of repeating this, and will let it
fall out when you try to take the article to FA. -- Gadget850 talk 09:28, 6 June 2013
(UTC)
I beg to pardon, but there is not the slightest reason to be aggressive. As has been pointed
out by others, there are books, which carry more than one ISBN on a single sample of the
book (I've seen up to four). There are also cases, where someone has more than one
edition of a book, each with its own ISBN, and has read both of them to be sure that they
contain the same information. Of course, we could just pick one of them, but we could
also just allow more than one ISBN. The later would be more correct, IMHO. --
Matthiaspaul (talk) 09:45, 6 June 2013 (UTC)
And how do you plan to handle different dates? -- Gadget850 talk 09:36, 6 June 2013
(UTC)
I haven't seen this in combination with differing dates so far, but just in case, I would
propose to handle it in the same way as comma-separated list. Alternatively, the first1
last1 first2 last2 approach could be used here as well, isbn[1], date[1], isbn2, date2, ... --
Matthiaspaul (talk) 09:45, 6 June 2013 (UTC)

Here you go:

 Drucker, Sam. The World of ISBNs. ISBN [[Special:BookSources/978-0812695939


(1999) p. 23 (hardback); ISBN 978-0812695935 Parameter error in {{ISBN}}: Invalid ISBN.
(2001) p. 26 (paperback); ISBN 978-0812691234 Parameter error in {{ISBN}}: Invalid ISBN.
(2010) loc. 123-987 (Kindle); ISBN 978-0812691234 Parameter error in {{ISBN}}: Invalid
ISBN. (2013) p.22 (Kindle Fire); ISBN 978-0812345935 Parameter error in {{ISBN}}: Invalid
ISBN. (2013) p.32 (ePub)|978-0812695939 (1999) p. 23 (hardback); •'"`UNIQ--
templatestyles-0000000C-QINU`"'•[[International Standard Book
Number|ISBN]]&nbsp;[[Special:BookSources/978-0812695935 |978-
0812695935]]<span style="font-size:85%;"><span class="error">&nbsp;Parameter
error in &#123;&#123;[[Template:ISBN|ISBN]]&#125;&#125;: Invalid
[[ISBN]].</span></span> (2001) p. 26 (paperback); •'"`UNIQ--templatestyles-
0000000E-QINU`"'•[[International Standard Book
Number|ISBN]]&nbsp;[[Special:BookSources/978-0812691234 |978-
0812691234]]<span style="font-size:85%;"><span class="error">&nbsp;Parameter
error in &#123;&#123;[[Template:ISBN|ISBN]]&#125;&#125;: Invalid
[[ISBN]].</span></span> (2010) loc. 123-987 (Kindle); •'"`UNIQ--templatestyles-
0000000F-QINU`"'•[[International Standard Book
Number|ISBN]]&nbsp;[[Special:BookSources/978-0812691234 |978-
0812691234]]<span style="font-size:85%;"><span class="error">&nbsp;Parameter
error in &#123;&#123;[[Template:ISBN|ISBN]]&#125;&#125;: Invalid
[[ISBN]].</span></span> (2013) p.22 (Kindle Fire); •'"`UNIQ--templatestyles-
00000010-QINU`"'•[[International Standard Book
Number|ISBN]]&nbsp;[[Special:BookSources/978-0812345935 |978-
0812345935]]<span style="font-size:85%;"><span class="error">&nbsp;Parameter
error in &#123;&#123;[[Template:ISBN|ISBN]]&#125;&#125;: Invalid
[[ISBN]].</span></span> (2013) p.32 (ePub)]] Check |isbn= value: invalid character
(help). templatestyles stripmarker in |ISBN= at position 41 (help)

Infinite diversity in infinite combinations. -- Gadget850 talk 10:10, 6 June 2013 (UTC)

PMID parameter not working in template "cite journal"?


I used the citation {{cite journal|last=Todd|first=Andrew S|coauthors=R. Mark
Sattelberg|title=Actinides in Deer Tissues at the Rocky Flats Environmental Technology
Site|journal=Integrated Environmental Assessment and
Management|year=2005|month=November|volume=1|issue=4|pages=391–
396|pmid=16639905|url=http://onlinelibrary.wiley.com/doi/10.1002/ieam.5630010408/pdf|acces
sdate=9 June 2013}}, and the PMID external link in the reference takes me here instead of here.
Am a doing something wrong, or is there an error with the template? Thanks! VQuakr (talk)
19:23, 9 June 2013 (UTC)

Here is a version of your citation with most stuff removed. I notice that when PMID is
immediately followed by a pipe or vertical bar (|) then the PMID parameter gets
corrupted somehow:
{{cite journal |title=Actinides in Deer Tissues at the Rocky Flats
Environmental Technology Site|pmid=16639905|volume=1}}
→"Actinides in Deer Tissues at the Rocky Flats Environmental Technology Site". 1.
PMID 16639905 Check |pmid= value (help).
If I move |pmid= to the end of the citation then there isn't a problem:
{{cite journal |title=Actinides in Deer Tissues at the Rocky Flats
Environmental Technology Site|volume=1|pmid=16639905}}
→"Actinides in Deer Tissues at the Rocky Flats Environmental Technology Site". 1.
PMID 16639905.
So, that's the work around until the problem is fixed.
—Trappist the monk (talk) 20:02, 9 June 2013 (UTC)
The problem is that there is an invisible character immediately after the 16639905,
specifically a U+200E (Left-to-right mark). It may be removed by placing the cursor
somewhere within the PMID value (but before its end), marking text from there to
somewhere after the pipe, pressing Delete and retyping:

 Todd, Andrew S (2005). "Actinides in Deer Tissues at the Rocky Flats


Environmental Technology Site". Integrated Environmental Assessment and
Management. 1 (4): 391–396. PMID 16639905. Retrieved 9 June 2013. Unknown
parameter |coauthors= ignored (|author= suggested) (help); Unknown
parameter |month= ignored (help)

Not directly related, but in templates with more than two or three named parameters, I
normally put a space just before each pipe to aid visual separation - trying to spot where
one parameter ends and the next begins is more difficult when they're all jammed
together. --Redrose64 (talk) 22:48, 9 June 2013 (UTC)
Many thanks to both of you for the rapid feedback! VQuakr (talk) 04:30, 10 June 2013
(UTC)

chapterurl problem in cite book


In {{cite book| editorlink = Robert J. Sternberg| last = Hyman | first = Ray| authorlink =
Ray_Hyman|| editor1 = Robert J. Sternberg |editor2 = Henry L. Roediger| editor3 = Diane F.
Halpern| title = Critical Thinking in Psychology| url =
http://books.google.com/?id=3mA9NPAgWR0C| year = 2007| publisher = Cambridge University
Press| isbn = 978-0-521-60834-3| page = 218| chapter = Evaluating Parapsychological Claims }}

Hyman, Ray (2007). "Evaluating Parapsychological Claims". In Robert J. Sternberg;


Henry L. Roediger; Diane F. Halpern (eds.). Critical Thinking in Psychology. Cambridge
University Press. p. 218. ISBN 978-0-521-60834-3.

The url links from the title of the chapter, rather than the title of the book. (This link may still not
be accurate, because I modified it from one with two authorlink fields, which was, in tern,
modified from one which had first and last (referring to the chapter author) and authors (referring
to the book authors, which I called editors). Shouldn't the url link from the book title. — Arthur
Rubin (talk) 16:17, 10 June 2013 (UTC)

As can be seen from this comparison, the new version of {{cite book}} links the
|chapter= with |url= just as the old {{citation/core}} version did:
Cite book comparison
{{cite book |chapter=Evaluating Parapsychological Claims |last=Hyman
|isbn=978-0-521-60834-3 |editor3=Diane F. Halpern |first=Ray
|page=218 |editor2=Henry L. Roediger |title=Critical Thinking in
WT Psychology |publisher=Cambridge University Press |year=2007
|authorlink=Ray_Hyman |url=http://books.google.com/?id=3mA9NPAgWR0C
|editorlink=Robert J. Sternberg |editor1=Robert J. Sternberg}}
Hyman, Ray (2007). "Evaluating Parapsychological Claims". In Robert J. Sternberg;
Live Henry L. Roediger; Diane F. Halpern (eds.). Critical Thinking in Psychology.
Cambridge University Press. p. 218. ISBN 978-0-521-60834-3.
Hyman, Ray (2007). "Evaluating Parapsychological Claims". In Robert J. Sternberg;
Sandbox Henry L. Roediger; Diane F. Halpern (eds.). Critical Thinking in Psychology.
Cambridge University Press. p. 218. ISBN 978-0-521-60834-3.
I'm inclined to believe that |url= should link |title= and not |chapter= when
|chapterurl= is omitted. Doing so complies with the {{cite book}} documentation.
Editor Arthur Rubin can add
|chapterurl=http://books.google.com/books?id=3mA9NPAgWR0C&pg=PA216 to the
citation as a work-around.
—Trappist the monk (talk) 10:57, 11 June 2013 (UTC)
Even if it's been that way since the old {{citation/core}} days, it still should be
fixed.... — Arthur Rubin (talk) 14:02, 11 June 2013 (UTC)
I didn't say that is shouldn't be fixed. The initial goal of the conversion to the Lua module
is and should be to be compatible with the existing {{citation/core}} templates. The
point of the comparison was to show that the developers did not introduce a bug into
Module:Citation/CS1.
—Trappist the monk (talk) 14:44, 11 June 2013 (UTC)

template errors on type


Perhaps someone familiar with this template's intricacies will know what to do: there are
template errors showing on the documentation at WP:CS1#Type. I expect they are related to
recent reorganization toward a LUA implementation. —EncMstr (talk) 17:34, 14 June 2013
(UTC)

Fixed -- Gadget850 talk 17:38, 14 June 2013 (UTC)

Formatting, readability
Is there any way to have the 'publisher' break to a new line below the author's name, year and
title? As it is, when the cite book items are all filled out, it generates a source listing that is
entirely strung together on one line, often listing the publisher on the other side of the screen.
The wrap around isn't much help because often times the only items that wrap to the next line are
page numbers and isbn numbers, etc. When panning through a lengthy bibliography it is much
easier to read the individual sources when the author's name, year and title are on one line, and
the publisher, page number, isbn are on the second line, with the publisher always at the
beginning of the second line. Since many cite book listings wrap around to a second line anyway,
(unless you're using a very wide screen) it would be nice if this was accomplished with a little
order and uniformity. Below is an example of how the listing would look. A <br> has been
placed in the publisher field to accomplish this but in practice these are sometimes removed by
bots. If there is reluctance to alter this cite book template could an alternative cite book template
be created? e.g.'cite book2'. -- Gwillhickers (talk) 22:18, 16 June 2013 (UTC)

 Dorwart, Jeffery M.; Wolf, Jean K. (2001). The Philadelphia Navy Yard: From the Birth
of the U.S. Navy to the Nuclear Age.
University of Pennsylvania Press. p.271,. ISBN 0812235754.
 Dresel, H.G. (1896). United States Naval Institute Proceedings, Volume 22 (Naval
warfare, tactics, weapons, etc,).
United States Naval Institute, Annapolis. p. 866.

 Dull, Jonathan R. (2012). American Naval History, 1607-1865: Overcoming the Colonial
Legacy.
Univ of Nebraska Press. p. 216. ISBN 9780803244719.

That break is going to be stuffed into the COinS output and will be picked up by
reference management software. A better solution is to add a class to the 'publisher' field.
Then you can add the break in your personal CSS. -- Gadget850 talk 00:07, 17 June 2013
(UTC)
Okay, I'm more of a writer than I am a computer software hack. I have no idea what's
going on with 'COinS', and I'm not clear on how you add a 'class' to the publisher field or
about adding a break to CSS. Any help would be a big help. One more question: Will this
only effect my viewing of bibliographies? I was thinking in terms of adding uniformity
and readability to bibliographies for the sake of the readers. Many bibliographies are
quite long, and when all the source items are just strung together on one line, line after
line, it tends to make the bibliography look like a blur. Any help along these lines also
would be most useful. -- Gwillhickers (talk) 03:25, 17 June 2013 (UTC)
COinS is invisible metadata that is readable by reference management software. If you
stuff markup like a break into a field, then it pollutes the metadata. We have an open
feature request to add classes to each field for microdata purposes. This would also allow
readers to style fields as desired.
Adding a hard coded break is not the best solution, as it will probably mangle the display
for mobile users, and it will create shortened lines for users with large displays. -
- Gadget850 talk 08:34, 17 June 2013 (UTC)

eBooks
A question recently came up at the Teahouse where an editor was trying to use cite-book for an
eBook citation. The problem arose as for an eBook a page number is not really appropriate.
There's a sort of workaround with using a "location (LOC)" within an eBook and the "at"
parameter. However it seems the template and/or the documentation needs to be adjusted in
order to help users wanting to cite specific locations within eBooks easily. --LukeSurl t c 21:45,
17 June 2013 (UTC)

Link to archived discussion where this was also discussed --LukeSurl t c 22:36, 17 June
2013 (UTC)

I'm the original user that had the issue. I've been thinking about this from the standpoint of a data
designer. I think I may have been over thinking this. There are already various interpretations for
the page number based on the edition, paperback, hardcover, etc. So the loc is just one more
example. I think the right answer here might just be use the loc as a regular page number.
Mdebellis (talk) 02:40, 18 June 2013 (UTC)
Italicisation of websites in references
I don't understand why websites are italicised in references when we do not italicise them in any
other form on Wikipedia. to me, this seems to be improper formatting, and unless there is a
convincing argument in support of it, I propose to have it altered in our system so that websites
are no longer italicised in references. an example of this: a reference to an article by the website
AllMusic:

True, Chris. "Faith – The Cure: Songs, Reviews, Credits, Awards: AllMusic". AllMusic. AllRovi.
Retrieved 15 June 2013.

notice that "AllMusic" is italicised. Lachlan Foley 03:39, 15 June 2013 (UTC)

This is a perennial question, and it comes down to this: the |work= parameter is treated as
synonymous with |journal=, |newspaper=, |magazine= (and some others, see
Module:Citation/CS1/Configuration and search for the entry beginning "['Periodical'] =").
This is the gross work; the |title= specifies an included work. Gross works are
italicised; included works are quoted. --Redrose64 (talk) 06:54, 15 June 2013 (UTC)
In my experience, the "work" parameter isn't usually relevant in "cite web". You have the
title of the page (title) and the entity who published it (publisher), which is usually the
name of the website. I'm not even sure what "work" means in this context. Whereas in
e.g. "cite news", "work" is the name of the publication and rightly appears in italics. In
the AllMusic example that Lachlan Foley cites, AllMusic has been included in the title of
the page so there is no need to also call it a "work". Although, since AllMusic is a well-
known website, I'd have been inclined to call AllMusic the publisher and ignore the fact
that the copyright is held by a wider entity called AllRovi. In that case, the inclusion of
the word AllMusic in the page title would be redundant. At all events, this seems a rather
untypical example. -- Alarics (talk) 07:24, 15 June 2013 (UTC)
there is a |website= parameter (which I have actually only just noticed), and |work= is
the alias, meaning that |work= is the correct field to put the title of the website under.
|publisher=, it seems to me, is for the entity in charge of or powering the website. the
|title= field is for, in this case, the title of the page which the URL is linking to, not the
website itself. Lachlan Foley 11:44, 15 June 2013 (UTC)
I have occasionally used |work= for the name of the section of the website or for the type
of document this page is, when there are multiple pages of the same type elsewhere on
the site.
Consider, in cite web,
|url=http://example.com/safety-directives/left-handed-scredrivers
|title=Safety Directives - Safely Using Left-Handed Screwdrivers
|publisher=The Safety Society
vs.
|url=http://example.com/safety-directives/left-handed-scredrivers
|title=Safely Using Left-Handed Screwdrivers |work=Safety Directives
|publisher=The Safety Society
-- 31.54.63.131 (talk) 19:08, 22 June 2013 (UTC)
In your example it is a "work". As you point out it is not the publisher, AllRovi is. It
seems quite properly cited. --Bejnar (talk) 07:49, 15 June 2013 (UTC)
 I tend to view these from a practical standpoint – they are the same sides of a coin
but used to manage italicisation: |work= italicised, |published= doesn't. The
notion of 'publisher' is much more important for books, and the {{citation}}
templates instruct us not to cite publishers for periodicals. I would never put
Allmusic in the title. It needs to go in |publisher= or |work= depending on
whether it is properly italicised or not. -- Ohc ¡digame!¿que pasa? 11:38, 15 June 2013
(UTC)

in response to Bejnar: it is properly cited, the issue is that "AllMusic" is italicised in the
reference, and websites are not italicised anywhere else on Wikipedia, making this a flaw
in the citing system. if your message was directed at Alarics, ignore this. Lachlan Foley
11:44, 15 June 2013 (UTC)
Is AllMusic the main work? If it should not be italicized, then should a web page from
AllMusic be in quotes as the included work? -- Gadget850 talk 08:38, 17 June 2013
(UTC)

Cite book template does not display "others" parameter


It seems that {{Cite book}} does not display the value in the |others= parameter, such as this
reference from Johann Heinrich Alsted:

 {{cite book | first = Paolo| last = Rossi | authorlink = | coauthors =


| year = 2000 | month = | title = Logic and the Art of Memory | chapter
= |others=Translated by Stephen Clucas | others = | edition = | pages =
| publisher = University of Chicago Press | location = | id = | url = |
isbn = 0-226-72826-9 }}
 Rossi, Paolo (2000). Logic and the Art of Memory. University of Chicago Press. ISBN 0-
226-72826-9.

GoingBatty (talk) 01:02, 24 June 2013 (UTC)

It shows the value of the second |others= which is blank. -- Gadget850 talk 01:10, 24
June 2013 (UTC)
Facepalm - sorry for not seeing the obvious - thanks! GoingBatty (talk) 01:20, 24 June
2013 (UTC)

Wikidata
Perhaps others here will be interested by what's going on at d:Wikidata:Books_task_force.
Seems like there's some commonality of interest. LeadSongDog come howl! 21:04, 28 June 2013
(UTC)

Your link doesn't appear to be correct. It goes to a blank page. Dragons flight (talk)
21:50, 28 June 2013 (UTC)
I've fixed the link. — Mr. Stradivarius ♪ talk ♪ 02:20, 29 June 2013 (UTC)
Template:Cite journal; Edition
Is there a reason why "edition" is not mentioned in the full parameter set of Template:Cite
journal? --82.170.113.123 (talk) 20:37, 23 June 2013 (UTC)

No. I have updated everything but those full parameter sets, as I don't think they are a
good idea, so I am leaving someone else to do it. -- Gadget850 talk 20:41, 23 June 2013
(UTC)
Edition is rarely useful for journals. Books have editions, since a given book may be
revised from time to time, each update gets a new edition but is substantially the same as
the previous. Journals (or any other periodicals) do have progressive identifiers, but these
are dates, or volume/issue numbers - the change from one issue to the next is close to
100%. To be honest, I've only come across two instances of a single issue of a periodical
going through more than one edition - in both cases an article had to be removed for legal
reasons. In one case, the "second edition" got a suffixed issue number (i.e. 1234a where
the original was 1234); in the other, the only way you could tell that you had a "second
edition" was because the page numbering on a particular two-page spread was 34/37. --
Redrose64 (talk) 20:55, 23 June 2013 (UTC)
Just for the record, I think these full parameter sets are very useful. I usually start with
those, fill in everything I can find and if any of the parameters are unclear I look for
information further down these template pages. To give you an example, I just copied the
full parameter set of Template:Cite journal, filled in whatever I could find and voilà: [1]
Too many templates to know by heart, no time to read through the entire Parameters
section, and frequently the most commonly used parameters do not include some
additional information I can provide. --82.170.113.123 (talk) 21:01, 23 June 2013 (UTC)
Could you please provide an example of an article that contains a reference with {{cite
journal}} where |edition= would be useful? Thanks! GoingBatty (talk) 23:05, 23 June
2013 (UTC)
Me? I have no idea, maybe it's not useful anywhere. I only noticed it wasn't part of the
full parameter set, that's all. --82.170.113.123 (talk) 10:09, 24 June 2013 (UTC)
Since cite journal is used for magazines as well as journals, how would we denote that an
article was published in a specific national edition of a news magazine, but not in the
regular edition? I'm thinking of an article in the US edition of The Economist, which is
published in the UK. I used the edition parameter in this footnote for instance for that
reason. Imzadi 1979 → 15:16, 24 June 2013 (UTC)
That's why we have |location=. In this instance you would put |location=New York. -
-Redrose64 (talk) 17:37, 24 June 2013 (UTC)
Except that the news database I consulted specifically stated "U.S. edition" and didn't
mention location. Based on the publication's website, how am I to determine based on the
information given if it was published in New York or San Francisco? (They have offices
in both locations, neither of which is specified as originating the U.S. edition.) How
would either U.S. location inform a reader seeking to find a copy of the article, when the
databases categorize it as the "U.S. edition"? Yes, there are limited uses for the
parameter, but that doesn't mean there are no uses for it. Imzadi 1979 → 17:58, 24 June
2013 (UTC)
In that case, how about putting the title as "Economist US edition" and maintaining the
location as London? It is still essentially a London-produced magazine, I think -- or does
it have a whole team people in USA producing an entirely different publication from the
UK one? -- Alarics (talk) 11:48, 29 June 2013 (UTC)

Formatting of references: archive and quote.


Another suggestion for formatting references in order to make them easier to read. When cite
web references occupy two or more columns, start the text "archived from the original on
{date}" on a new line. Additionally, start any quoted text on a new line. These changes would
rarely result in the reference occupying more lines in total. - 109.176.243.180 (talk) 18:30, 29
June 2013 (UTC)

I don't think it's possible to set up fixed-position line breaks to apply only when there is a
columnar layout. We could set a forced line break at one or another of these positions, but
not on a dynamic basis: they would always be present, regardless of the number of
columns. That said, when the CSS Multi-column Layout Module gets promoted from
Candidate Recommendation to W3C Recommendation, browser writers should then start
supporting the Column breaks feature, and it may then be possible to force column breaks
to occur between two list items and not inside a list item. --Redrose64 (talk) 18:47, 29
June 2013 (UTC)
{{Reflist}} cannot see the content inside <ref>...</ref> tags- it simply applies the
column styling to <references /> which is the tag used by the Cite software to generate
the reference list. -- Gadget850 talk 19:39, 29 June 2013 (UTC)
{{Multiple issues}} uses CSS to change the look of the embedded templates. Could the
same technique be used here, so that {{reflist}} exposes newlines inside the cite
templates that are normally invisible? -- John of Reading (talk) 05:08, 30 June 2013
(UTC)
Is this a question about a single reference that happens to span two columns, or about all
references within a multi-column list? I suspect the latter. Starting a new line for archives
and quotes would appear to be more readable, however in a single column list the
suggestion would always result in many more lines being used. --212.139.98.247 (talk)
20:47, 29 June 2013 (UTC)
@John of Reading: Yes, that is possible. Two things need to be done: first, we need to set
up a new class - say reflist-br-condit - and set up the global CSS for that, like this
br.reflist-br-condit {
display: none;
}
.references-column-count br.reflist-br-condit {
display: inline;
}
Second, we would modify Module:Citation/CS1 to emit <br class=reflist-br-
condit /> at suitable points. Linebreaks would then be visible in reflists, only when the
multi-column feature is used. --Redrose64 (talk) 12:58, 30 June 2013 (UTC)

time parameter?
It's very common these days for web-based material have both a date and time of publication. To
my knowledge there's no mechanism to include the time information in the cite templates. I
suppose the current closet place for it to be put is in the "date" parameter but that's not what that
is meant for. Should a new "time" parameter be introduced? Of course, the question is begged: is
this level of granularity necessary for the references? I believe it is valuable when included for
two reasons. The time would be useful when used in search engines to find a lost source (e.g.
current url is dead) and a time-stamp match would produce confidence that one has actually re-
located the proper missing source (date alone is insufficient as big news events often have
multiple stories released on the same day). It would be especially useful for the {{cite web}} and
{{cite news}} templates. Ideas? Jason Quinn (talk) 04:24, 2 July 2013 (UTC)

@Jason Quinn: - Could you please provide an example of a web page where the time is
relevant? (i.e. a reliable source that has content posted for less than a day) Thanks!
I would imagine, for a "breaking news" story, where details arrive in the newsroom at
random intervals and they then update the web page as and when they have more
information. This story, for example, is currently marked 6:23AM BST 03 Jul 2013 -
that's 06:23 British Summer Time, which is 05:23 UTC. Check back in a couple of hours.
--Redrose64 (talk) 07:43, 3 July 2013 (UTC)
The CS1 templates do support 'time' and 'timecaption':
Markup Renders as
{{cite web |title=Title "Title". July 3, 2013. 6:21AM BST.
|url=http://www.example.org
|date=July 3, 2013 |time=6:21AM BST
|timecaption=&#8203;}}

'timecaption' defaults to 'Event occurs at ', so I worked around by using a zero width
space. If this is going to be used, then we should add an explicit 'none' value to suppress
the timecaption, as there is a hard-coded space between 'timecaption' and 'time'. -
- Gadget850 talk 10:34, 3 July 2013 (UTC)
The time and timecaption are documented at {{Cite video}}. Their purpose is to
document where in a video the relevant information may be found. This is a different
meaning than the time the information was published. There is a potential conflict.
Updated videos about a developing news story may be posted by a reliable source. In
principle, it could be useful to specify both when the update was published, and at what
time within the video the information being cited may be viewed. Although, news stories
tend to be short so in most cases the reader would just view the whole story. Jc3s5h (talk)
22:36, 3 July 2013 (UTC)
With the Lua-based templates, all or most parameters are available to all templates. The
key is context. And {{Cite video}} is now {{Cite AV media}}. -- Gadget850 talk 22:55,
3 July 2013 (UTC)
It isn't unusual for templates to be switched from, for example, Cite AV media to Cite
web or Cite news when it is determined the source really falls into a different category. It
is a bad practice to use the same parameter name for substantially different concepts.
Jc3s5h (talk) 23:11, 3 July 2013 (UTC)
We already do it: 'title' in {{cite web}} for a page included in the 'website/work', as
compared to 'chapter' for the work included in the 'title'. Which causes problems for some
editors. But, time is time— whether is is the time of publication or the time an even
occurs. Again, it is a matter of context— this is the first time I am aware that someone
wanted to include a time in a source other than audiovisual. Perhaps 'at' would be the
better field. -- Gadget850 talk 23:23, 3 July 2013 (UTC)

┌─────────────────┘The variable meaning of title is a perfect example of what not


to do. As for "at", you mean that videos should use the at parameter rather than the minutes or
time parameter to specify where within the video the relevant information is? Not unreasonable.

If we're going to stretch the meaning of an existing parameter to include time, I suggest
redocumenting the date and accessdate parameters to state they can include publication or access
time when that would be helpful. This would be less of a conceptual difference than the
difference between time within a video vs. publication time. Jc3s5h (talk) 00:35, 4 July 2013
(UTC)

'date' is problematic, as it emits COinS metadata. -- Gadget850 talk 00:51, 4 July 2013
(UTC)
Consider a more complete example:
{{cite web |title=Title |url=http://www.example.org |date=July 3, 2013 |time=6:21AM
BST |timecaption=&#8203;| last1 = Doe| first1 = John}}
renders as
Doe, John (July 3, 2013). "Title". 6:21AM BST.
The concept behind the time parameter shows through; it sticks by the title where it
belongs, since it is describing the time within the video. It does not stick by the
publication date, which it has nothing to do with. Jc3s5h (talk) 01:03, 4 July 2013 (UTC)

 Put publication time in date parameters: With the common re-updating of news
articles, then the time of news update could be inserted into the date, either prepended
(14:30, July 3, 2013) or appended after the date (July 3, 2013, 14:30) or as "2:30 pm"
format:

{cite web |title=Web Page |url=http://www.example.org |date=July 3, 2013, 14:30 |


last1=Smyth| first1 = John |ref=harv}
Smyth, John (July 3, 2013, 14:30). "Web Page". Check date values in: |date= (help)
The year is time-extracted from the "date=" value, to set the Harvard referencing, so the
time-of-day must be a valid time when using ref=harv. Then the year is extracted to set
"<span id="CITEREFSmyth2013">". Otherwise, if the time-of-day contains an invalid
hour, then the year will be omitted from the span-tag id (but no error message). -Wikid77
(talk) 11:00, 6 July 2013 (UTC)
How can the time zone be indicated without breaking year extraction for Harvard
referencing? The possibility of adding a time should be documented for the date
parameters for all types of works where adding a time might make sense. As far as I'm
concerned, coders shouldn't bother adding features if there isn't a plan to document them
so end users will know how to use them. Jc3s5h (talk) 14:05, 6 July 2013 (UTC)
Append time zone "CST" or "EDT" or such, where "3 May 92, 14:30 CST" still extracts
the year as 1992. -Wikid77 11:21, 8 July 2013 (UTC)
If the date/time is a form recognised by {{#time:}} then it should work. For example,
{{#time:Y|14:05, 6 July 2013 (UTC)}} yields 2013 ... oh, hang on, that's the old
way. Now that it uses a Lua module, I don't know - it's very difficult to trace the code
through. --Redrose64 (talk) 14:30, 6 July 2013 (UTC)

 Lua uses pcall with lang.formatDate and 'Y': The line of Lua script, to extract
the year, is:

good, result = pcall( lang.formatDate, lang, 'Y', str )


where the variable 'good' is a boolean set to true when the year has been extracted, into
variable 'result'. A Lua function can return multiple variables, separated by commas (such
as "good,result"). We could write a rapid Lua YearExtract function to ignore time
validation, and just extract the year-number regardless of invalid hour, but the easy way
was to use lang.formatDate to transform the date into just the year portion, inside the Lua
Module:Citation/CS1. It's funny how {cite_web} will give error messages for obvious
ISBN trouble, but an insideous mismatch of years in Harvard referencing will give no
error message at all, just fail to link. I guess I should fix that to auto-correct and find the
year else error message when ref=harv, since no one else has yet. We have
Module:Citation/CS1/sandbox2 for debugging more complex problems. -Wikid77 11:21,
8 July 2013 (UTC)
I ran some experiments in my sandbox, and found the harv anchor isn't correct if the year
is fewer than 3 digits, or if it has a BC after it. Regardless of whether we start putting
times into dates, the range of valid years should be documented in the date and year
parameters. As for time, I found that EST worked but a random three character group,
"BQR", did not. If we are going to put times into dates, the documentation should
indicate which time zone symbols are valid for the English Wikipedia. Better still, always
use UT, since there will be no facility to convert times to the reader's timezone. Jc3s5h
(talk) 12:35, 8 July 2013 (UTC)
Bad harv/sfn links - such as typos in years - may be detected quite easily, by installing
this script. They then show up as big red error messages like "Harv error: link from
#CITEREFDow1859 doesn't point to any citation", which is how I was alerted to make
this fix. --Redrose64 (talk) 20:50, 8 July 2013 (UTC)

Cite journal template


This edit request has been answered. Set the |answered= or |ans= parameter to no to
reactivate your request.

I understand this template is also used for newsletters but not everybody knows that. I would
appreciate it if the word "newsletters" was added to the opening description as follows (bold for
highlighting here only): "This Citation Style 1 template is used to create citations for articles in
journals, magazines, newsletters and for academic papers." Helen (talk) 06:00, 9 July 2013
(UTC)
The documentation page isn't fully protected, so anyone could have implemented that
change. Imzadi 1979 → 06:04, 9 July 2013 (UTC)

New wp:VECITE essay for VisualEditor cites


Although the wp:VisualEditor (VE) can edit more references than just the wp:CS1 cites, I have
created an essay (wp:VECITE or wp:VEREF) which mentions using the CS1 cite templates
within the VisualEditor:

 "WP:VisualEditor editing of references" - new essay mentions CS1 cite templates

Currently, the responses about using VE have been horrendous, with many experienced users
vowing to no longer or never use it, but it can be a "teachable moment" (or "learnable
nightmare") about the difficulty of using point-and-click interfaces to select each parameter from
a list, rather than using the power of free-form text technology, followed by using a batch-mode
"syntax checker" to proofread for invalid parameters in a macro scripting language (in this case,
proofreading as red-error messages from the CS1 templates during edit-preview).

As for the fate of VE, with over 300 reported bugs, the onward mandate is pushed by the mindset
that there is no "bad software" but that all software is inherently full of bugs and should be used
whenever, regardless of the corruption of text files or psychological scarring of users. Hence, I
have created that essay to help users cope with problems when being herded into a channel of
VE-centric editing. Currently, all users have the option to use the prior edit-source mode for
pages, but the VisualEditor provides a slippery slope of luring editors into a point-and-click
interface for revising words, which leads to a tedious, slow, click-click-click-on-parameter mode
to insert each separate parameter for citations. The new essay wp:VECITE is just a start to
providing more help about that slow process. -Wikid77 (talk) 16:42, 9 July 2013 (UTC)

Perhaps a Lua Cite_fast as even 4x faster


I think it would be easy to create a Lua-based {Cite_fast}, which would format cites even 4x
times faster (over 300 per second) for large articles (lists) which have 400-900 cites. I can
understand I might sound like the "mad scientist" in wanting even more speed, more speed.
However, what if we discovered some new technique which could make the current cites run
perhaps 2x faster, as a result of experimenting with even faster speeds. This is just a suggestion,
because I think a Lua {cite_fast} could easily be 4x faster (or more). We could break the sound
barrier, then the next step: cites on Mars! (just kidding). Things to ponder. Wikid77 (talk) 14:55,
27 June 2013 (UTC)

Faster is better. But instead of another fork, why not work on improving the CS1
module? What can be done to make it more efficient? -- Gadget850 talk 16:32, 27 June
2013 (UTC)
I'm talking about "thinking outside the box" to see what is possible, and then look back
inside the box. The assumption of "fork" is the old-style thinking again. -Wikid77 (talk)
10:00, 28 June 2013 (UTC)
Right now a citation takes about 7.7 ms on average to render. Of that, about 2 ms is the
parser overhead associated with entering Lua. In other words, we lose 2 ms every time
Lua is used even if it does nothing. Given that limitation, it is already clear that no
amount of clever Lua code is going to give you a 4x speed boost. You would have to
improve Mediawiki itself to cut down on the Lua overhead first. In addition, about 3.5 ms
is the average parser time spent converting the wikitext that Lua cites generate into
HTML (e.g. [[George Washington|Washington, George]] (1776) ''[http://dreams.info/ My
dreams]''. ⇒ Washington, George (1776) My dreams.). Again, that is time that Lua really
has very little control over. The parser needs to handle most of that conversion in order to
do things like determine whether links are blue or red and update the internal and external
links tables. So, of the 7.7 ms spent on the typical Lua citation, about 5.5 ms is pre and
post processing overhead that Lua has little control over. As complex as
Module:Citation/CS1 might seem, it is only responsible for about 30% of the total run
time right now. Maybe there are some clever tricks to make that faster (and I've certainly
been paying attention to performance), but even if you could reduce the Lua execution
time to near zero you would not even double the total rendering time. At this point one
might well get more benefit from finding ways to make the associated Mediawiki parser
behavior faster (not to mention that any improvements to the parser would have many
advantages in other applications). For example, I think it may be possible to halve the
overhead associated with entering Lua. Dragons flight (talk) 16:42, 27 June 2013 (UTC)
Excellent time to re-think the structure: The Lua developers have already quickened
the interface, as over 625 #invoke's per second, or 500 per second with 7 parameters, so
based on those advancements, then perhaps the new speed would be: 350 cites per
second. I did not realize it would be so easy to achieve. -Wikid77 (talk) 10:00, 28 June
2013 (UTC)
Ummm, did you read what I said? I explained in some detail why it is essentially
impossible at this point to get a 4x (or even 2x improvement) by making changes within
Lua itself. I can't figure out how you could read what I said, and then come to the
conclusion that large speed enhancements are easy. Dragons flight (talk) 16:20, 28 June
2013 (UTC)
Another way to see this. If you attempt to preview 310 distinct citations, it takes about
2.9 s to load the page (according to Mediawiki's "served by" clock); however, Mediawiki
also reports that only 0.82 s was spent executing Lua code. In other words 70% of the
execution time was spent outside of Lua doing things like converting wikicode into
HTML, updating links tables, and everything else Mediawiki does during every page
render. Of course suggestions for making the citation code faster would be appreciated,
but the idea that any change to Lua might somehow go from 130 distinct citations per
second to 350 distinct citations per second is simply not realistic. Dragons flight (talk)
16:50, 28 June 2013 (UTC)
As a footnote, let me add that it is important to test using distinct citations if you want to
fully understand the real world case. The time required by the parser to resolve blue links
and update links tables is dependent on the number of distinct links used on the page. If
you simply repeat the same citation 300 times, then the parser doesn't have to work quite
as hard and you get an unrealistic estimate of total time. Dragons flight (talk) 17:28, 28
June 2013 (UTC)
 Re-run and average 3 fastest runs then subtract overhead: Beware false
premises in the testing. You have been calculating with the overhead of page
processing, added as a part of citation speed, but it should be subtracted. Typical
short citations can be formatted at 200 per second, with 200 different URL
addresses in the linked titles. However, if the testing includes a wikilink to every
author name, every publisher, and every location, as well as linking every title,
then that is not a realistic test of 300 citations from a typical article or list of
footnoted entries. To gain some broader perspectives, run timing tests of pages
with no templates (or #invoke's) but hundreds of URLs or wikilinks, and
determine the speed of formatting a page with 1,000 such links (to different pages
and URLs), versus no links to those 1,000, and compare the runtimes to see the
impact of links. -Wikid77 (talk) 21:01, 28 June 2013 (UTC)

I'm using the 310 citations that appeared in Barack Obama as of whenever I copied them.
Hence it is a perfectly real world example (though skewed towards "news" citations).
Also, you can use Special:ExpandTemplates to fully expand citations into wikicode, and
then time the parser on rendering that wikicode. The parser processing of that citation
wikicode actually takes longer than the Lua runtime at this point. Dragons flight (talk)
21:49, 28 June 2013 (UTC)
Since you want to argumentative about this. Here are 310 Lua citations [2]. The served
by times for page preview in 15 trials are: 3.303, 3.448, 2.727, 2.840, 3.473, 2.953, 4.147,
2.832, 2.907, 2.874, 2.810, 3.550, 2.862, 2.998, 2.830. That gives a mean time of 3.1036
seconds and median time of 2.907 seconds.
Consider the same citations expanded to wikicode by Special:ExpandTemplates [3]. The
served by times for page preview in 15 trials are: 1.308, 1.457, 1.129, 1.560, 1.261,
1.586, 1.624, 1.606, 1.302, 1.194, 1.582, 1.549, 1.198, 1.500, 1.170. That gives a mean
time of 1.4017 seconds and median time of 1.457 seconds. This helps isolate the post-
processing time that citations presently require.
Next, consider the same citation list, but with each Lua call replaced with a call to the
Module:DoNothing via {{cite nothing}} which allows us to measure the citation template
and Lua overhead [4]. The served by times for page preview in 15 trials are: 1.299, 1.634,
1.384, 1.231, 1.253, 1.157, 1.328, 1.365, 1.163, 1.332, 1.465, 1.401, 1.359, 1.433, 1.545.
That gives a mean time of 1.357 seconds and median time of 1.359 seconds. This helps to
isolate the overhead associated with Lua citation calls.
Lastly, consider a completely blank page, e.g. [5]. The served by times for page preview
in 15 trials are: 0.304, 0.261, 0.289, 0.329, 0.334, 0.337, 0.328, 0.249, 0.264, 0.324,
0.327, 0.285, 0.343, 0.325, 0.313. That gives a mean time of 0.3075 seconds and median
time of 0.324 seconds.
Using the median times, the global overhead of Mediawiki for every page preview is
about 0.324 seconds. That means the Lua DoNothing overhead on 310 citation invokes is
about 1.359 - 0.324 = 1.035 seconds (3.3 ms per citation). The post-processing render
time of citation wikicode into HTML on these 310 citations is then 1.457 - 0.324 = 1.133
seconds (3.7 ms per citation). Then we can isolate the Lua citation code execution time as
2.907 - 0.324 - 1.035 - 1.133 = 0.415 seconds (1.3 ms per citation). In other words, of the
2.583 seconds spent rendering citations (= 2.907 - 0.324, 8.3 ms per citation), about 40%
goes to the overhead of calling the citation templates and invoking Lua, another roughly
40% goes to parser post-processing of the resulting wikicode into HTML, and only about
20% goes into the actual execution time of the code within Module:Citation/CS1. As I
suggested before, that creates a dynamic where most of the execution time is associated
with things that Lua Module authors have no control over. I think that further
improvements to Mediawiki may alleviate some of those bottlenecks, but no amount of
clever Lua code is likely to provide a 2x gain in overall performance at this point.
Dragons flight (talk) 23:10, 28 June 2013 (UTC)
'Run more tests without busy servers, then average the 3 fastest times: Do not use the
median (middle runtime) of all tests. Subtracting the typical page-format overhead, of
0.324 seconds, from the average of fastest times, will reveal the speed. I think the
pre/post Lua processing is delayed by the busy servers; however, even pure Lua
execution has been slowed somewhat by busy servers as well. When tests are run on busy
servers, then the runtimes treat the other people's server delays as being a major part of
citation formatting, and there are some hours when the servers are very busy for hour
after hour. Look for a fast runtime of 2.4s when the average tends to be 3.1s. -Wikid77
(talk) 20:39, 2 July 2013 (UTC)
While servers can be busy, it is better to measure real performance of a computing cluster
rather than go hunting for the fastest performance. Also, Wikimedia is not a
homogeneous server farm, some machines really are 30% faster than others. Regardless,
you are free to run your own tests. You won't get a different conclusion. Dragons flight
(talk) 20:52, 2 July 2013 (UTC)
I suspect that Cite could be improved. There have been a lot of complaints about the data
array. -- Gadget850 talk 16:27, 30 June 2013 (UTC)

 Lua fast-cite would run 380/second for max 10,700 cites: The extensive timing tests,
for more than 30 runs scattered over several hours, have confirmed the speed would be
2x-3x faster, as over 380 cites per second, or 1,000 cites in nearly 3 seconds. A large
article (400 cites) would reformat 2-7 seconds faster. The max capacity would be 10,700
cites, due to the 10-second Lua timeout limit. Otherwise, the parser would allow 23,500
Lua cites per page, but the 60-second parser timeout also limits capacity, below 11,000
cites per page. -Wikid77 (talk) 21:33, 18 July 2013 (UTC)

Confusing (cite episode)


Hi. I've found a lot of errors like ". Error: |episodelink= requires |number= when using Empty
citation (help). " This comes up when the program doesn't work with episode numbers. Unlike
"seasons" or "series" with distinct numbers of episodes (I think it's 20 something, but you'll have
to correct me on that), we have a lot of programs over here which are ongoing - that is they have
been weekly for years on end. I'm sure they do have a production number, but as far as I know
the episode number is effectively the date. Is there any way to get around the error? Should the
template require a number, when a link is present? Flying Buttress (talk) 14:48, 12 July 2013
(UTC)

It is confusing... in fact, it's only shown if all of |season= |seriesno= |number= are
blank (or omitted). If there is no suitable value for |number=, do you have something
suitable for either |season= or |seriesno=? --Redrose64 (talk) 15:18, 12 July 2013
(UTC)
I have also noticed that this error message is inconsistent with the documentation and
possibly erroneous itself. For example, "Error: |episodelink= requires |number= when
using {{Cite episode}}" appears in Bradbury Fields. There are two problems with this:
1. The citation in question uses a url instead of a wikilink in the episodelink parameter.
The current documentation says that episodelink takes a wikilink, so the error should be
"Error: |episodelink= requires a wikilink".
2. The documentation for {{cite episode}} does not show number as a prerequisite for
episodelink in the table. Jonesey95 (talk) 04:19, 17 July 2013 (UTC)
After further research, it appears that the error message listed above was added to the
template's code on May 12, 2013 by User:MSGJ. I will drop that user a note. Jonesey95
(talk) 04:38, 17 July 2013 (UTC)
MSGJ did make that edit to the live template, but the coding was done by
117Avenue (talk · contribs). The background is at Help talk:Citation Style 1/Archive
2#Cite episode deprecated parameters. --Redrose64 (talk) 07:21, 17 July 2013 (UTC)
This is the Bradbury Fields citation:
{{cite episode| title = Visually impaired people in TV ads, and
charities working together | episodelink =
http://www.bbc.co.uk/programmes/b01l0fkf | url =
http://www.bbc.co.uk/programmes/b01l0fkf | series = | serieslink = |
credits = | network = BBC | station = Radio 4 | city = | airdate = 24th
July 2012}}
Which gives this:
"Visually impaired people in TV ads, and charities working together". [[6]]. 24th July
2012. BBC. Radio 4. Check |episodelink= value (help); Check date values in: |=
(help); Missing or empty |series= (help)
This citation could and perhaps should be changed to use {{cite AV media}}:
{{cite AV media |title=Visually impaired people in TV ads, and
charities working together
|url=http://www.bbc.co.uk/programmes/b01l0fkf |publisher=[[BBC Radio
4]] |date=24 July 2012 |medium=Radio broadcast |work=[[In Touch (BBC
Radio 4 programme)|In Touch]]|author=Miles, Ffion (Reporter)
|author2=Kumutat, Lee (Producer)}}
Which gives this:
Miles, Ffion (Reporter); Kumutat, Lee (Producer) (24 July 2012). Visually impaired
people in TV ads, and charities working together. In Touch (Radio broadcast). BBC
Radio 4.
—Trappist the monk (talk) 12:27, 17 July 2013 (UTC)
Yes, this particular citation could be changed, but that doesn't fix the problems with the
cite episode template errors. And yes, I read through the long discussion that led to this
change. I don't see where in the discussion the consensus was formed that |serieslink
requires |number, which is also not documented in the template's documentation. Maybe
I'm missing something. Jonesey95 (talk) 16:56, 17 July 2013 (UTC)
Well, that was the citation that you chose for an example ...
The "consensus" (if it can be called that) arose from two editors in favor of
|serieslink= requiring |number=, one opposed (me), and from the broader
community's general apathy.
—Trappist the monk (talk) 13:06, 18 July 2013 (UTC)

The documentation is correct, episodelink is an existing Wikipedia article. The Bradbury


Fields example is an incorrect use of the template, and it is being placed into a maintenance
category (Category:Articles with incorrect citation syntax), bringing attention to its incorrect use.
A perquisite for episodelink, serieslink, and url was brought up in the discussion because
we didn't want users to be providing a link that went unused. To activate these links provide the
appropriate number, season, series, seriesno, title, or trans_title. If the episode doesn't
have these, what is there to link? 117Avenue (talk) 03:00, 19 July 2013 (UTC)

Initials vs first
For years we have lived with author initials being used to populate |first1= .. |firstn=, with
resultant confusion. For many cited authors this has not been a large problem. If an editor
abbreviates "John Paul" to "J.P.", "J. P." or "JP" no one is terrible surprised. But how to handle
"Jean-Paul"? Any of the preceding might be used, plus "J-P", "J.-P.", "J.-P" or even "J. -P". Is it
time to discuss supporting a distinct parameter |initial1= for such choices? Some article
editors seem to prefer full names while others want the most succinct initials possible. Authority
control might be used to limit variations, with improved wikidata functionality as a result. See
[7] for more. LeadSongDog come howl! 17:49, 15 July 2013 (UTC)

Is it worthwhile to apply a band-aid, or is it more appropriate to provide a set of


parameters that truly represents most of the naming practices out there? The first issue is
the number of names, and when a name is considered a compound name. For example,
for a while, a former first lady of the US used to consider her surname to be Rodham
Clinton, which was one compound name. In Republic of China people often have a
compound given name. In the English tradition people may have any number of middle
names.
Then there is the question of name order. In regular prose, the surname may be first, or
the given name may be first. In an alphabetical index, the surname may be first or the
given name may be first (the latter is the case in Iceland, I understand). Just adding an
initial parameter is an incomplete solution. Jc3s5h (talk) 18:24, 15 July 2013 (UTC)
Name ordering comes under the heading of collation, an extremely complex topic. I don't
know how the use of initials enters here, as the terms by which ordering is done are
generally not initialized. ~ J. Johnson (JJ) (talk) 22:56, 15 July 2013 (UTC)
If the source being cited does not provide a name, only an initial, there is no choice but to
sort the bibliography according to the initial. Jc3s5h (talk) 23:06, 15 July 2013 (UTC)
I'm a little confused by what is being said here. We are discussing the use of initials for
first names, right? And by that we mean, in accord with typical practice in English, the
author's personal name. Also, we are assuming the primary key for sorting (collating) an
author list is the surname ("last" name in Western practice unless inverted, but comes
first in Chinese, Japanese, and Hungarian). So the only (?) ambiguity is where, for a
given surname, two different "first" (personal) names start with the same letter. E.g.,
"Jones, Jean-Paul", and "Jones, Jim". Is that the essence of the alleged problem? ~
J. Johnson (JJ) (talk) 21:57, 18 July 2013 (UTC)
RFC: Consistent date location
The following discussion is closed. Please do not modify it. Subsequent comments should
be made on the appropriate discussion page. No further edits should be made to this
discussion.

Should the Citation Style 1 family of citation templates be modified to always place the date of
publication in parentheses immediately after the first element (that is, after the authors or editors
if those are given, or after the title if not)? If so, since citations were inspired in part by APA
style, should the date be followed by a period after the right parenthesis when the separator is set
to the period? Jc3s5h (talk) 10:31, 13 June 2013 (UTC)

Summary of results

Since I was unable to find an uninvolved editor to close the discussion, I will ignore all rules and
summarize it myself, for the convenience of whoever implements the consistent style. Editors in
this section are listed in no particular order.

Eight editors supported having the date consistently as the second element (Dragons Flight,
bender235, Carl, sroc, Imzadi1979, Andrew327, Trappist the Monk, and myself).

Three editors supported having the date consistently near the end (Alarics, SlimVirgin, and
DoctorKubla). Of these, Alarics and SlimVirgin supported date-second as a second choice.

Two editors indicated support, but there comments didn't seem consistent with the proposal (J
Johnson and Lachlan Foley).

The "Let's get specific" section had two editors (Dragons Flight and Trappist the monk) favoring
this style for a newspaper article with no author:

 "The Story" (2005). The Times. p. 25.

On the other hand I preferred to adhere more closely to the APA style:

 "The Story." (2005). The Times. p. 25.

Alarics consisdered the APA style an improvement over the current situation but would prefer
fewer brackets:

 "The Story." 2005. The Times. p. 25.

Jc3s5h (talk) 19:11, 22 July 2013 (UTC)

Discussion of consistent date location


As the originator of the RFC I favor a fixed location for the date, as do some others in the Date
location section above. I favor placing the date as the second element because in articles using
parenthetical referencing without linking (or which have been printed on paper) it is easier for
the reader to find the full source information. Also, when there is a sorted reference list, it is
easier for editors to see if sources by the same author have been sorted correctly. Finally, I favor
a period after the right parenthesis because the templates were inspired by APA style and will be
more comfortable for the many people who already use APA style. I note that the current cite
journal template only separates the last character of the last author's name from the date with a
space, while APA style would separate them with a period and a space. Thus in APA style, the
example below would read ...Kenneth. (2011)...

Example:

 Finkleman, David; Allen, Steve; Seago, John; Seaman, Rob; Seidelmann, P. Kenneth
(2011). "The Future of Time: UTC and the Leap Second". American Scientist. 99 (July–
August 2011): 312. arXiv:1106.3141v1. doi:10.1511/2011.91.1.

Jc3s5h (talk) 10:31, 13 June 2013 (UTC)

 Support. I agree that there should be a fixed location for the date. I and many other
editors have said so many times. My main concern is with "cite news" refs. As things
stand now, if the news item has a byline (author), the author comes first and then the
publication date in brackets, followed by title of article and name of newspaper. If it
doesn't have an author, as many news items don't, the ref starts with the title of the article
and then name of newspaper and only then the date. Here are two contrasting examples
from Eton College:

 Doward, Jamie (26 June 2005). "Eton waits for verdict in Harry 'cheating' case".
The Observer. London.
 "Society is 'ashamed' of elitism, says Eton headmaster". The Daily Telegraph.
London. 4 August 2011. Retrieved 12 June 2013.

This inconsistency looks silly. In my view, the date should come after the name of the
newspaper in both cases. -- Alarics (talk) 14:35, 13 June 2013 (UTC)

 Support. I support making the date position consistent across all the templates. My
preference would be that the date always appear at the end. For example:

 Susan Smith, Book title, Name of publisher, 2013.


 Susan Smith, "Article title," Name of newspaper, 13 June 2013.
 "Article title without a byline," Name of newspaper, 13 June 2013.

SlimVirgin (talk) 17:02, 13 June 2013 (UTC)


Note: For the benefit of the closing editor, my support includes following the date by a
period after the right parenthesis, if that option is chosen, although my first preference is
to position the date at the end of the citation. SlimVirgin (talk) 00:04, 15 June 2013 (UTC)
That particular option isn't feasible - the templates are already well used in articles that
use author/date citations (Harvard style), and those citations are much more difficult to
find in the reference section unless the year appears immediately after the author. — Carl
(CBM · talk) 17:27, 13 June 2013 (UTC)
If the short cite is "Smith 2012," and the long cite is "Smith, Susan. Book, Publisher,
2013," that's easy enough to find, even if there is more than one Smith.
But either of these:

 (13 June 2013), "Article title without byline," Name of newspaper


 Name of newspaper (13 June 2013), "Article title without byline"

would be better than the current situation where we have dates at the beginning and end,
and with and without brackets, within the same article. SlimVirgin (talk) 17:40, 13 June
2013 (UTC)
APA style (6th ed, p. 200) would call for

 Obesity affects economic, social status. (1993, September 30). The Washington
Post, pp. A1, A4.

The in-text citation would look like (fictitious text):


A statement about stuff. ("Obesity affects," 1993)
The Chicago author-date system is similar. The year is moved from the end of the
bibliography entry (where it is in their note system) to the second item. So the in-text
citation would look like
A statement about stuff. ("Obesity affects" 1993, A1, A4)
And the bibliography entry would look like

 "Obesity affects economic, social status." 1993 The Washington Post, September
30.

So there does seem to be general agreement that the year should be the second element. I
suspect we don't want to follow Chicago's idea of putting the year as the second element
and the rest of the date as the last element. Jc3s5h (talk) 18:39, 13 June 2013 (UTC)
I agree with CBM. author (year) is widely used as short identification for a particular
bibliographic entry. Thereofore author (year) should be the first information to appear
in the bibliography, not author and then year at the end. --bender235 (talk) 18:34, 15 June
2013 (UTC)

 Comment. For my part, I strongly support the current practice that a date should appear
immediately after the authors / editors, if given (e.g. Jones, John (1999). Some Things.
Random House Books. p. 24.). This works well with SFN and other footnote styles
presently in use. That formatting is also present for most current CS1 citations, as most
such citations have authors listed. In the absence of authors/editors, I don't have have a
strong opinion whether the date should be placed

First (1999). Some Things. Random House Books. p. 24.


Second Some Things. (1999). Random House Books. p. 24.
Late (present behavior) Some Things. Random House Books. 1999. p. 24.
or somewhere else entirely. Dragons flight (talk) 19:43, 13 June 2013 (UTC)
Comment. I think we have to draw a distinction between "cite book" and "cite news".
Very few books have no author, but many news items do. We need to fix "cite news" so
that it no longer shows the inconsistency I have illustrated further up this thread. In the
case of "cite news", I agree with SlimVirgin that the date should come after the name of
the newspaper, whether or not the news article has a byline. -- Alarics (talk) 05:55, 14
June 2013 (UTC)
If the goal is consistency, then making one set of rules for cite news and different rules
for cite web / journal / book would seem to be exactly the wrong idea. Dragons flight
(talk) 07:19, 14 June 2013 (UTC)
But surely the greater inconsistency is the one that exists already between different news
citations within the same article, using "cite news", as in the examples already quoted.
That must be worse than an inconsistency between news item references and book
references. If you don't like it, let's put the date at the end for books as well. -- Alarics
(talk) 09:22, 14 June 2013 (UTC)
Exactly; see the two refs in Shiplake railway station. Both use {{cite news}}; both ref
the same newspaper; the only real difference is that one of the two URLs, if followed,
shows a credited author, the other shows "By Reading Post" - which I took to be
synonymous with "By Staff Reporter", so I omitted it from the {{cite news}}, with the
result that the two refs are significantly different in layout. --Redrose64 (talk) 09:47, 14
June 2013 (UTC)
If a newspaper article with no author is a source, and parenthetical citations are being
used, most styles including APA and Chicago will put a short version of the newspaper
article title and the year in the parenthesis, like (Benson townwide sale 2013). The
newspaper article title will be the first item in the bibliography. So why would CS1 be
unique among all citation styles in making the reader look at the end of the bibliography
entry to be sure he/she had the right source? Why should the date be in proximity to the
name of the newspaper when the newspaper name isn't even mentioned in the
parenthetical cite? Jc3s5h (talk) 16:49, 14 June 2013 (UTC)
I am not talking about parenthetical citations. I am talking about the vast majority of
ordinary articles with ordinary news references at the bottom of the page, using the "cite
news" template. All we ask is that, within that situation, references to news items that
happen not to have an author are presented similarly to references to news items that do
have an author. At the moment this is not the case and, as pointed out many times now by
numerous editors, the resulting inconsistency within any one article looks bizarre and
inexplicable. -- Alarics (talk) 07:08, 15 June 2013 (UTC)

 Support consistent location near the end of the citation. DoctorKubla (talk) 06:45, 14
June 2013 (UTC)
 Support the proposal that dates consistently follow authors. (I wonder if DoctorKubla
really means "oppose"?) Even if one is note using author-date short cites the date is too
important to be buried at the end of the citation after various bibliographic codes. ~
J. Johnson (JJ) (talk) 20:37, 14 June 2013 (UTC)
 Comment: my "support" does extend to the matter of the period, which should be
dealt with separately. ~ J. Johnson (JJ) (talk) 20:37, 14 June 2013 (UTC)

 Support: I support the proposal that dates consistently follow authors, but when there is
no author I believe it should go article title > title of publication >
year/date, with the exception of {{cite news}}, since I feel there is more emphasis on
date in that case. Lachlan Foley (talk) 10:20, 16 June 2013 (UTC)

But then you haven't dealt with the problem with "cite news", which is that there will still
be inconsistency between different refs in the same article, depending on whether a news
item has an author or not. See the examples I quoted further up this thread. -- Alarics
(talk) 09:59, 16 June 2013 (UTC)
I see, and I agree; there is more emphasis on the date in a news citation. Lachlan Foley
(talk) 10:20, 16 June 2013 (UTC)
It's not a problem that is specific to {{cite news}}, because {{cite book}}, {{cite
journal}} and {{cite web}} exhibit exactly the same inconsistency in date
positioning. It is however more noticeable with {{cite news}}, because that sometimes
has credited authors and sometimes doesn't, whereas {{cite book}}/{{cite
journal}} almost always have credited authors, and a true {{cite web}} (one where
{{cite news}}/{{cite journal}} are not appropriate) rarely has a credited author. --
Redrose64 (talk) 11:50, 16 June 2013 (UTC)

 I support this so long as the year is kept near the beginning of the citation. Why not just
make the best effort possible to convert these to APA style? Then we would have a
reference to compare against. — Carl (CBM · talk) 15:47, 16 June 2013 (UTC)
 Support making the positioning and formatting of dates as consistent as possible across
all {{cite}} templates. My preference would be to have the date nearer the beginning of
the citation for consistency with existing citations where authors are named, in keeping
with the Harvard referencing system, e.g.:

 Susan Smith. 2013. Book title. Name of publisher.


 Susan Smith. 13 June 2013. "Article title". Name of newspaper.
 "Article title without a byline". 13 June 2013. Name of newspaper.

OR, switching the order of the newspaper title and the article title, as would be my
preference:

 Susan Smith. 2013. Book title. Name of publisher.


 Susan Smith. 13 June 2013. Name of newspaper. "Article title".
 Name of newspaper. 13 June 2013. "Article title without a byline".

However, my support is not conditional on any particular ordering, formatting or


punctuation. —sroc (talk) 13:30, 22 June 2013 (UTC)

 The citation style 1 templates are intended to be used both in articles that use
footnote citations, and in articles that use Harvard citations. In case the editors
don't choose to create links between the Harvard inline citation and the
bibliography entry, or in case the article has been printed on paper, it is necessary
to be able for the reader to figure out which bibliography entry goes with the
inline citation. When there is no byline, the inline citation must include an article
title, possibly shortened. If only the newspaper name were given, there would be
no way to tell which article on the given page is the right article. Since the article
name is the first item in the inline citation, it should be the first item in the
bibliography entry too. Jc3s5h (talk) 17:23, 27 June 2013 (UTC)

 Support putting the date as the second item, consistently. Burying it always at the end is
not helpful. Imzadi 1979 → 20:11, 27 June 2013 (UTC)
 Support. The date is one of the most important things about a citation and this style
should follow academic norms. Andrew327 14:05, 5 July 2013 (UTC)

Seeking editor to close discussion. Since the RFC has expired and discussion seems to have
more or less reached a consensus, someone should close this discussion. I would suggest the
subsections about specifics below also be included in the closure. Jc3s5h (talk) 12:41, 13 July
2013 (UTC)

Let's get specific

In the above discussion, it appears that most people favor consistency, and a majority also seem
to want the date to stay near the front, though that is somewhat less clear. There is also some
discussion of style changes (e.g. parenthesis, periods, etc.) but I don't think that is well enough
developed to be ready to come to any conclusion. In the following I am going to offer some
specific styles for current and future citations that aim to keep the date near the front in various
cases, and would like feedback on what people think.

In the examples below, the current case generally shows examples where a date appears at the
end. The "Suggestion 1" case places the date as the second element, and "Suggestion 2" case
places it as the first element (essentially where it would be if it were left in the same slot even
though no author is given).

The basic, traditional case

I think most people want to keep this as is, <AUTHOR> <DATE> <TITLE>, i.e.

 {{cite news | first = John | last = Knox | newspaper = The Times | title = The story | year
= 1945 | page = 25 }}

Knox, John (1945). "The story". The Times. p. 25.

No author, with both minor and major title

 {{cite news | newspaper = The Times | title = The story | year = 1945 | page = 25 }}
Current: "The story". The Times. 1945. p. 25.
Suggestion 1: "The story" (1945). The Times. p. 25.
Suggestion 2: (1945). "The story". The Times. p. 25.

No author, with only minor title

 {{cite web | url = http://www.funny.com | title = The story | year = 2005 | page = 25 }}

Current: "The story". 2005. p. 25.


Suggestion 1: "The story" (2005). p. 25.
Suggestion 2: (2005). "The story". p. 25.

No author, with only major title

 {{cite book | title = The Book | year = 2005 | page = 25 }}

Current: The Book. 2005. p. 25.


Suggestion 1: The Book (2005). p. 25.
Suggestion 2: (2005). The Book. p. 25.

No author, with major title and publisher

 {{cite book | title = The Book | publisher = My Publishing House | year = 2005 | page =
25 }}

Current: The Book. My Publishing House. 2005. p. 25.


Suggestion 1: The Book (2005). My Publishing House. p. 25.
Suggestion 2: (2005). The Book. My Publishing House. p. 25.

No author, with minor title, language, and format

 {{cite web | url=http://www.russia.ru/ | title = Russian Tourism | language = Russian |


format = PDF | year = 2005 | page = 25 }}

Current: "Russian Tourism" (PDF) (in Russian). 2005. p. 25.


Suggestion 1a: "Russian Tourism" (2005) (PDF) (in Russian). p. 25.
Suggestion 1b: "Russian Tourism" (PDF) (2005) (in Russian). p. 25.
Suggestion 2: (2005). "Russian Tourism" (PDF) (in Russian). p. 25.

No author, with major title, minor title, and volume

 {{cite journal| journal = The Neighbor Watch | title=Police Blotter | volume = 17 |


publisher = Daly City HOA | date = June 17, 2005 | page = 25 }}

Current: "Police Blotter". The Neighbor Watch. Daly City HOA. 17: 25. June 17, 2005.
Suggestion 1: "Police Blotter" (June 17, 2005). The Neighbor Watch (Daly City HOA)
17: 25.
Suggestion 2: (June 17, 2005). "Police Blotter". The Neighbor Watch (Daly City HOA)
17: 25.

Discussion

Some of the above are somewhat complicated edge cases, but then we need to remember that
there are many different elements that can end up in citations. Personally, I think I prefer
Suggestion 1, though I don't have an overly strong opinion either way. However, I did think it
would be useful to further the discussion by showing more examples of possible date location
changes. Do people have any additional feedback after seeing more examples? I wanted to add
some more examples, in part, because it wasn't entirely clear from the previous discussion how
people would want to handle some of these edge cases, and hence it would have been difficult to
implement any specific change. Dragons flight (talk) 01:13, 29 June 2013 (UTC)

Thanks for spelling out the alternatives. Your "Suggestion 2" is the only one that will
deal with the problem I keep pointing out, which is that at the moment
newspaper/magazine citations are wildly inconsistent within the same article, depending
on whether or not they have an author. -- Alarics (talk) 07:50, 29 June 2013 (UTC)
I favor the Suggestion 1 styling. The date should not be the first item listed in a citation.
For the No author, with minor title, language, and format, the Suggestion 1a and
Suggestion 1b items are cluttered with parentheses. So, I propose this:
Suggestion 1c: "Russian Tourism" (2005; PDF; in Russian). p. 25.
Within the parentheses, date is always first; the order of other parenthetical information
can be in whatever order. A semicolon is the separator here because dates may include
commas.
—Trappist the monk (talk) 11:24, 29 June 2013 (UTC)
I nearly agree with Trappist the monk. At the same time, I hope editors won't provide
formats for sources that virtually anyone can read. Sure, mark videos and proprietary
formats like Excel, but do we really need to indicate a source is PDF?
The only quibble I would have, since were getting so specific, is that since we're so close
to the APA format, maybe we should go ahead and use it as a model, with just changes to
take advantage of hyperlinking and wikilinking. So the basic traditional case would
become

 {{cite news | first = John | last = Knox | newspaper = The Times | title = The story
| year = 1945 | page = 25 }}

Suggestion 3

 Knox, John. (1945). "The story". The Times. p. 25.

Note the new period after "John". I don't know if it would be a technical issue to detect if
the author's name already ends with a period and suppress the template-provided period
in that case. Jc3s5h (talk) 14:49, 29 June 2013 (UTC)
How would Suggestion 3 deal with a newspaper ref without an author? -- Alarics (talk)
21:22, 29 June 2013 (UTC)

 "The story." (1945). The Times. p. 25.

Or, if we wanted to stay even closer to APA,

 The story. (1945). The Times. p. 25.

Jc3s5h (talk) 02:24, 30 June 2013 (UTC)


OK, Suggestion 3 would at least be an improvement on what we have now. Personally
though, I would rather not have those brackets round the year. I don't see what purpose
they serve. -- Alarics (talk) 08:10, 30 June 2013 (UTC)
Here's an example where the brackets (American: parentheses) might be helpful:

 Astronomical Almanac for the Year 2011. (2010). Washington: US Government


Printing Office.

Jc3s5h (talk) 14:53, 30 June 2013 (UTC)

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

Open Library IDs


The (book) template automatically prepends 'OL' to the Open Library ID, presumably on the
assumption that all Open Library IDs start with that. The problem is, they don't, and this prevents
linking to those that have Open Library IDs of other formats. For example, the Open Library
uses IDs that begin with 'ia:' to refer to works that originate with the Internet Archive. This
results in bad links to the Open Library website for such a work. (One such ID is
'ia:publicrecords02conn', which should link to, e.g.,
http://openlibrary.org/works/ia:publicrecords02conn but instead links to
http://openlibrary.org/OLia%3Apublicrecords02conn.) —Gordon P. Hemsley→✉ 13:37,
22 July 2013 (UTC)

The OL is checked to ensure it ends with A, M or W so you should be getting an error:


The public records of the colony of Connecticut from 1636-1776.
OL /ia:publicrecords02conn Check |ol= value (help).
This error may still be hidden. We need to check to see if the OL begins with ia: and
adjust the URL.
Is there an OL document for the various id numbers? -- Gadget850 talk 14:10, 22 July
2013 (UTC)
And {{OL}} needs to be updated as well. -- Gadget850 talk 15:22, 22 July 2013 (UTC)
Indeed, there is an error when attempting to use an ia: ID. I note that your example uses a
preceding slash, which seems to fix the issue of a bad URL, if only in a hackish way. I
also want to note that although these two linking methods (parameter and separate
template) make a distinction between a "book" and a "work", OL seems to be smart
enough to differentiate automatically; at least, it does when using an ia: ID. (I can't speak
to "author".) —Gordon P. Hemsley→✉ 01:34, 24 July 2013 (UTC)
The slash is a typo. I notice that your original example of
http://openlibrary.org/works/ia:publicrecords02conn is redriected to
http://openlibrary.org/books/ia:publicrecords02conn. I have noted this issue at Module
talk:Citation/CS1/Archive 7#Open Library: Internet Archive. -- Gadget850 talk 10:32, 24
July 2013 (UTC)
I attempted a bold fix to {{OL}}, but evidently I got it wrong, as Gadget has reverted me.
Guess my command of the template syntax still needs work.LeadSongDog come howl!
13:14, 24 July 2013 (UTC)

Cite news template has rotten introduction


The documentation for Cite news fails to explain what it is for. Is it just for citing paper
newspapers? Maybe news telecasts? How about Usenet newsgroups? Jc3s5h (talk) 23:14, 3 July
2013 (UTC)

The documentation lead states "news articles in print, video, audio or web". What is
missing or vague?
And thanks for reminding me: I have been meaning to add a short version of the table at
Help:Citation Style 1#General use to the documentation lead. -- Gadget850 talk 23:30, 3
July 2013 (UTC)
Sorry, I missed it. The huge lua notice and the table of contents box dwarfed it and I just
didn't see the lead. Jc3s5h (talk) 00:30, 4 July 2013 (UTC)
I added a CS1 template list to {{cite book}}. I think it works well with the TOC. I need
to polish up the documentation for the Lua templates so we can ditch the notice. -
- Gadget850 talk 02:21, 4 July 2013 (UTC)

 Shortened Lua-cite notice to 5 phrases: I moved the prior notice into a new
essay ("WP:Lua-based cite templates") and shortened the new notice as just 5
phrases, with a link to that essay for more information. That avoids the clutter of
the prior 4 paragraphs, and so people can easily see the wording, "news articles in
print, video, audio or web". In general, WP has had too much wp:Rulespam,
cluttering the top of pages, and recently, the rulespam for a View-source was
condensed as a shorter blurb at the top of edit-protected pages, but later restored
as a long tedious "shaggy dog story" as to why, oh why, has the page been
protected, oh why oh why, yada yada yada, ad infinitum, ad nauseam, and more
and more and then some. -Wikid77 (talk) 12:27, 8 July 2013 (UTC)

Back on the original point, it would certainly be good if a way could be found of making clearer
to editors that "cite news" is to be used in preference to "cite web" for refs to news articles from
bona fide news outlets, whether or not said articles are on line. At present a great many refs put
"cite web" when it should be "cite news". (I think the Reflinks tool may be to blame for a fair bit
of this.) (On the other hand, one also sometimes finds people using "cite news" when they
shouldn't, especially in the case of press releases, which have their own "cite press release"
template; the distinction matters because a press release is a piece of news produced by a non-
news organisation about itself, and is not therefore objective "news" such as one would hope to
find in a reliable news source.) -- Alarics (talk) 14:34, 8 July 2013 (UTC)

There is no semantic difference between the various templates, other than the unused
class. The output should also be the same, except when a periodical is defined. The
original purpose of the different templates was to provide parameters designed for each
type of citation. That dichotomy is not as important now that parameters are pretty much
available across the series. -- Gadget850 talk 14:53, 8 July 2013 (UTC)
Well, but the output isn't the same. For instance, with "cite news" the location appears in
brackets, whereas with "cite web" it doesn't. -- Alarics (talk) 17:34, 8 July 2013 (UTC)
You are right on that one. -- Gadget850 talk 19:56, 8 July 2013 (UTC)
And {{Cite press release}} includes "(press release)" in the output. GoingBatty (talk)
03:53, 10 July 2013 (UTC)
Perhaps these templates should be merged, with a |type= parameter added? Andy
Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 12:05, 27 July 2013 (UTC)

Proposal to rename Cite album-notes


I propose to rename Cite album-notes to Cite album notes because I believe the hyphen is
unnecessary and improper use of punctuation. Lachlan Foley (talk) 11:17, 15 July 2013 (UTC)

I'm about to propose changing it to {{Cite AV media notes}} to match {{Cite AV


media}} and expand it to cover all audio and visual sources. -- Gadget850 talk 11:31, 15
July 2013 (UTC)
Good call, but I suggest making a redirect at the first proposed alternative name. Andy
Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 06:55, 19 July 2013 (UTC)
Now at Wikipedia:Templates_for_discussion/Log/2013_July_18#Template:Cite_album-
notes. -- Gadget850 talk 19:44, 20 July 2013 (UTC)

Now at {{Cite AV media notes}}. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits
23:24, 27 July 2013 (UTC)

Quotation marks for chapters, article titles


Could someone please change the use of "..." to “...” for article titles, chapters, etc. in the
citation templates? Or is there a style rule requiring "..."? --bender235 (talk) 08:35, 28 July
2013 (UTC)

MOS:QUOTEMARKS
—Trappist the monk (talk) 09:42, 28 July 2013 (UTC)
For those who haven't time or inclination to plough through MOS:QUOTEMARKS:
Curly quotes are deprecated. Always use straight quotes. -- Alarics (talk) 11:19, 28 July
2013 (UTC)
Correct. I do have a feature request to move styles to CSS, which would allow users to
apply custom styling. -- Gadget850 talk 11:42, 28 July 2013 (UTC)
Thanks, I wasn't aware of that. Does anyone have an idea what's the rational behind this?
Wikipedia:Manual of Style/Register#Quotation marks lists a boatload of discussions
about this, but I'm unable to identify a valid argument against curly quotation marks in
this case. --bender235 (talk) 17:27, 28 July 2013 (UTC)
There has been so much discussion on various talk pages- you will just have to do some
searching. Regardless, we follow the MOS, so if the consensus were changed there we
would follow. -- Gadget850 talk 17:52, 28 July 2013 (UTC)
Here's one I made earlier. That was my most recent decline; there have been others. --
Redrose64 (talk) 19:41, 28 July 2013 (UTC)
I didn't mean we should ignore MOS. I just wondered whether there was a simple,
obvious reason to prohibit curly quotations. --bender235 (talk) 20:08, 28 July 2013
(UTC)
One good reason is because they are "special characters" which don't work on all
systems. Also they are a needless complication in life. Keep things simple. There may
also be other reasons. -- Alarics (talk) 23:27, 28 July 2013 (UTC)
“ and ” are not valid characters in HTML documents unless they are encoded. See
Character Entity Reference Chart at W3. - 79.67.242.207 (talk) 12:08, 30 July 2013
(UTC)
That's a list of possible encodings, it's not mandatory: it contains commonplace characters
such as &comma; &period; which are almost never encoded. Only three characters must
always be encoded when they occur in the text part of a HTML doc: &amp; &lt; &gt; -
a fourth &quot; should be encoded where its meaning might be ambiguous, such as
within an attribute value. All the other encodings are provided for situations where the
desired character might not be directly typeable, or where a program which processes the
doc might trash a multibyte character. --Redrose64 (talk) 13:55, 30 July 2013 (UTC)

No period after title option


Is there a way to supress the period after the title in {{cite book}}?--TonyTheTiger
(T/C/BIO/WP:CHICAGO/WP:FOUR) 04:53, 21 July 2013 (UTC)

No. -- Gadget850 talk 11:01, 21 July 2013 (UTC)


Why do you want to? An example I could think of would be if the title already contains
terminal punctuation such as "!" or "?". Jc3s5h (talk) 12:24, 21 July 2013 (UTC)
Those are probably more common reasons than mine, but I was just wondering if it was
possible. I am misusing the template at Whaam! for short citations that result in double
periods, but I think the functionality should be there for titles ending in another
punctuation mark (most likely !, ? or …).--TonyTheTiger
(T/C/BIO/WP:CHICAGO/WP:FOUR) 12:44, 21 July 2013 (UTC)
We can probably add terminal punctuation detection and suppress the period. These
templates were never designed for use as shortened citations. We have {{sfn}} and
related templates for that. -- Gadget850 talk 13:22, 21 July 2013 (UTC)

Das könnte Ihnen auch gefallen