![]() | This is an archive of past discussions. Do not edit the contents of this page. If you wish to start a new discussion or revive an old one, please do so on the current talk page. |
Archive 5 | ← | Archive 8 | Archive 9 | Archive 10 | Archive 11 | Archive 12 |
|lccn=
This one won't come up very often, but an invalid |lccn=
can make it so that the automatic link to lccn.loc.gov does not work. I came across one in a citation today. I'm guessing that there are approximately a few dozen invalid LCCN parameters in all of WP, but they should be easy to detect.
Here is a straightforward explanation (scroll to "identifier-syntax") of valid LCCN syntax that will work with the LCCN web site. – Jonesey95 ( talk) 05:16, 17 March 2014 (UTC)
{{
cite book}}
: Check |lccn=
value (
help){{
cite book}}
: Check |lccn=
value (
help){{
cite book}}
: Check |lccn=
value (
help){{
cite book}}
: Check |lccn=
value (
help){{
cite book}}
: Check |lccn=
value (
help){{
cite book}}
: Check |lccn=
value (
help){{
cite book}}
: Check |lccn=
value (
help){{
cite book}}
: Check |lccn=
value (
help){{
cite book}}
: Check |lccn=
value (
help){{
cite book}}
: Check |lccn=
value (
help)Well, not quite right. The check needs to be improved so that lccns with hyphens are normalized before they are checked.
— Trappist the monk ( talk) 14:20, 30 March 2014 (UTC)
normalize_lccn()
normalizes the lccn according to the
Normalization of LCCNs procedure. These test citations all work correctly. normalize_lccn()
is able to normalize them all; the two fails are because there are spaces in the lccn that cause improper display of the lccn link
{{
cite book}}
: Check |lccn=
value (
help) [http://lccn.loc.gov/n 78890351 n 78890351]
{{
cite book}}
: Check |lccn=
value (
help) [http://lccn.loc.gov/79139101 /AC/r932 79139101 /AC/r932]
I think I have found a small bug in the new year range code (which is great, by the way!). Here's what I have so far:
Author (1901–02).
"Foo Title". Journal Name. 23: 4. {{
cite journal}}
: |author=
has generic name (
help); Check date values in: |year=
(
help)
Author (1901–04).
"Foo Title". Journal Name. 23: 4. {{
cite journal}}
: |author=
has generic name (
help); Check date values in: |year=
(
help)
Author (1909–10).
"Foo Title". Journal Name. 23: 4. {{
cite journal}}
: |author=
has generic name (
help); Check date values in: |year=
(
help)
Author (1911–12).
"Foo Title". Journal Name. 23: 4. {{
cite journal}}
: |author=
has generic name (
help); Check date values in: |year=
(
help)
Author (1918–20).
"Foo Title". Journal Name. 23: 4. {{
cite journal}}
: |author=
has generic name (
help)
Author (1921–22).
"Foo Title". Journal Name. 23: 4. {{
cite journal}}
: |author=
has generic name (
help)
Author (1931–36).
"Foo Title". Journal Name. 23: 4. {{
cite journal}}
: |author=
has generic name (
help)
Author (1984–86).
"Foo Title". Journal Name. 23: 4. {{
cite journal}}
: |author=
has generic name (
help)
Author (2001–02).
"Foo Title". Journal Name. 23: 4. {{
cite journal}}
: |author=
has generic name (
help); Check date values in: |year=
(
help)
Author (2001–04).
"Foo Title". Journal Name. 23: 4. {{
cite journal}}
: |author=
has generic name (
help); Check date values in: |year=
(
help)
Author (2009–10).
"Foo Title". Journal Name. 23: 4. {{
cite journal}}
: |author=
has generic name (
help); Check date values in: |year=
(
help)
Author (2011–12).
"Foo Title". Journal Name. 23: 4. {{
cite journal}}
: |author=
has generic name (
help); Check date values in: |year=
(
help)
Author - future year (2018–20).
"Foo Title". Journal Name. 23: 4. {{
cite journal}}
: |author=
has generic name (
help)
The year ranges are changed and are in |year=
. The citations are otherwise identical except for the future year. –
Jonesey95 (
talk)
00:17, 31 March 2014 (UTC)
|year=
and (b) all use endashes, I propose that they should be acceptable to the date-checking code. –
Jonesey95 (
talk)
02:44, 31 March 2014 (UTC)|year=
go the way of |day=
and |month=
.|date=1901–02
is |date=1901–1902
.|date=1901–02
is |date=1901–1902
." This is wrong on a few levels. First, this thread is about a bug in checking code. The checking code doesn't fix anything, an editor does. Next, since MOSNUM allows 1901–02 (that's an n-dash) this style of range should be acceptable by the checking code. I think the code already would disallow a hyphen in any date expression except YYYY-MM-DD, so even after the code is fixed to accept 1901–02 the expressions 1901-02 and 1901-99 (with hyphens) would still be flagged as errors.
Jc3s5h (
talk)
15:11, 31 March 2014 (UTC)PC-XT, I think this is the wrong place to argue that YYYY–YY is too ambiguous to use in a citation, because a citation has less context than other parts of an article. If that's what you believe, you should bring it up at Help talk:Citation Style 1, and argue that page should declare that Citation Style 1 permanently rejects YYYY–YY, as an exception to the general acceptance of WP:MOSNUM date guidance, and it should be spelled out the rejection is on the basis of ambiguity (which is permanent) rather than it being unfeasible to check (which may be temporary). Jc3s5h ( talk) 01:13, 1 April 2014 (UTC)
{{
citation/core}}
. Continuing evolution is bringing them all into
Module:Citation/CS1; new features are added, old features are pared away, and somehow, somehow, it is beginning to coalesce into a single entity. There is no plan for this, it just happens because Wikipedia happens. Documentation in this kind of environment lags behind the implementation; it will always lag behind.a description of free choices to create differences between CS1 and MOSNUM, though it does reflect those choices; it isn't even good user documentation. It is a mess. Help:Citation Style 1 is merely a collection of writings that attempts to describe how CS1 works and how to use it. Expecting more from it than that will lead to despair.
defiance of WP:MOSNUM, but rather, to the benefit of CS1.
It is a mess, and documentation isn't going to be perfect. Nevertheless, when it is clear what the documentation says, and it is reasonably feasible to write checking code that follows the documentation, that should be done. It is inappropriate to use a position as a code writer to ignore the consensus process and just implement whatever the coder prefers. If you think 1901–02 is ambiguous in the context of a citation, get consensus to modify Help:Citation Style 1 accordingly, instead of throwing it on a list of stuff that is infeasible or in the queue. Jc3s5h ( talk) 01:21, 1 April 2014 (UTC)
Should we deprecate origyear and make it a synonym of a new parameter called origdate so that the naming format is consistent. Jason Quinn ( talk) 03:43, 3 April 2014 (UTC)
|origyear=
is mainly used for books, where a second or subsequent edition is common, but the exact publication date is unimportant; for a non-first edition of a book, the actual and original year of publication are both useful. The exact publication date is mainly of use for periodicals, where although there is almost always more than one issue, there is rarely more than one edition. Some newspapers do have one or more pages re-set during a print run, in order to cover breaking news; but the cover date doesn't change, and so the "original date" is pretty much a non-existent concept. --
Redrose64 (
talk)
10:02, 3 April 2014 (UTC)An RFC that sought to determine whether YYYY-MM was an acceptable date format was recently closed.
The YYYY-MM format is currently in the Unacceptable column of the table at WP:BADDATEFORMAT, but I expect that to change soon. It was added there because the initial RFC closure said that there was "no consensus to change anything", implying that the state of the table at the opening of the RFC (YYYY-MM was in the Unacceptable column at that point) was how it should remain. The closure was subsequently revised to read: "There is no consensus that YYYY-MM is an acceptable format, nor any consensus that it is an unacceptable format. I would recommend against any mass changes being made purely on the basis of this RfC."
Based on this reasonably-attended RFC, despite the lack of consensus, it appears that the CS1 module's date-checking code should stop flagging YYYY-MM as an invalid date format. Thoughts? – Jonesey95 ( talk) 00:48, 3 April 2014 (UTC)
The recent (29 Nov 2013) banning of the yyyy-mm format ...which apparently arises from this conversation and this change to the table at WP:BADDATEFORMAT.
remove YYYY-MM from the Unacceptable list, which would would leave us in a state different from that which existed at the initiation of the RfC. If you are looking to undo this change to the table at WP:BADDATEFORMAT, then I think that Module talk:Citation/CS1 is the wrong forum.
|mr=
This is pretty esoteric, so it's OK if it goes onto the Feature Requests list, but I think we can validate |mr=
. I haven't found a spec for the number, but it appears to be seven numeric digits, optionally preceded by "MR".
We might want to consult with Wikipedia_talk:WikiProject_Mathematics about the preferred formatting for this link in the citation templates. We could show it as "MR1234567" or "MR MR1234567" or "MR 1234567". We show one of the latter two now, depending on whether someone puts "MR" in the value of the parameter. The first "MR" is linked to Mathematical Reviews. The number is linked to the cited source at mathscinet.org.
The article Uniform module contains links to a number of MR citations (some of them recently fixed so that they link to the right cited source). I haven't played around with case sensitivity, spaces, or other formatting to see how good the mathscinet.org processor is at handling what you throw at it. – Jonesey95 ( talk) 23:49, 8 April 2014 (UTC)
{{
citation}}
: Check |mr=
value (
help)OK, it's an edge case, but it looks like a tiny little bug that may be manifesting itself in other situations.
Cite book with only period in |title=
makes everything after it bold and adds a single quote mark before the title. Something about the wikimarkup difference between using single quotes for bold and using single quotes for italics, perhaps.
Wikitext | {{cite book
|
---|---|
Live | Author (2001). p. 3. {{
cite book}} : |author= has generic name (
help)
|
Sandbox | Author (2001). p. 3. {{
cite book}} : |author= has generic name (
help)
|
Using |url=
makes the problem go away.
Wikitext | {{cite book
|
---|---|
Live | Author (2001). p. 3
http://www.example.com. {{
cite book}} : |author= has generic name (
help); |url= missing title (
help)
|
Sandbox | Author (2001). p. 3
http://www.example.com. {{
cite book}} : |author= has generic name (
help); |url= missing title (
help)
|
|title=.
? --
Redrose64 (
talk)
16:13, 11 April 2014 (UTC)safejoin()
. Change to |title=;
and |separator=;
and the same thing occurs:
|url=
fix 'works' because the last character in the title string is not the separator but is the closing
of the assembled external link: [http://www.example.com ''.'']
. You can see in your second example that there is a linked period followed by an unlinked period.Would it be possible to make |lang=
an alias for |language=
?
It Is Me Here
t /
c
11:33, 13 April 2014 (UTC)
|language=
is clear, straightforward, and unambiguous. |lang=
is an abbreviation that is not as clear. I believe that we generally avoid abbreviations for parameter names or aliases, except where the full name of the parameter would be absurdly long, e.g. |internationalstandardbooknumber=
. –
Jonesey95 (
talk)
04:25, 14 April 2014 (UTC)
I just noticed that {{ PDFlink}} is being merged into CS1 as of May 2013. I don't recall the discussion. -- Gadget850 talk 19:57, 14 April 2014 (UTC)
|formatsize=
is required in order to eliminate the template, nor is it clear to me that there is a CITEVAR-friendly path from instances of PDFlink to CS1 citations in all or even most cases. The mechanics of how to make the transition, showing how existing instances of the template would be converted, were not explored thoroughly. –
Jonesey95 (
talk)
20:33, 14 April 2014 (UTC)hi what about removing /sandbox from
--local cfg = mw.loadData( 'Module:Citation/CS1/Configuration/sandbox' );
and
--local whitelist = mw.loadData( 'Module:Citation/CS1/Whitelist/sandbox' );
please
86.173.55.186 ( talk) 14:53, 21 April 2014 (UTC)
In about a week's time I intend to update these files from their respective sandboxes:
The update makes these changes to Module:Citation/CS1:
to Module:Citation/CS1/Configuration:
to Module:Citation/CS1/Whitelist:
— Trappist the monk ( talk) 11:54, 25 March 2014 (UTC)
Corrected item 5 for Module:Citation/CS1 to read: Added support for |postscript=none;
— Trappist the monk ( talk) 12:53, 25 March 2014 (UTC)
I do not agree that WP:MOS or WP:MOSNUM control date formats in citations (although Wikipedia talk:Manual of Style/Archive 128#Which guideline for citation style? shows there is no consensus about this).But here you are invoking WP:MOS#Months to support your argument that Sept. and Feb. should be allowed in CS1 citations.
There is no clear consensuslink above, points to Module_talk:Citation/CS1/sandbox#Invalid_year_doesn.27t_generate_error. Was that what you intended?
section | compliant | comment |
---|---|---|
Acceptable date formats table | yes | Exceptions: linked dates not supported; sortable dates not supported ( {{
dts}} etc);proper name dates not supported; |
Unacceptable date formats table | yes | |
Consistency | no | article level restriction beyond the scope of CS1 |
Strong national ties to a topic | no | |
Retaining existing format | no | |
Era style | no | dates eariler than 100 not supported; |
Julian and Gregorian calendars | limited | Module:Citation/CS1 cannot know if a date is Julian or Gregorian; assumes Gregorian |
Ranges | yes | Exceptions: does not support the use of – or does not support dates prior to 100; does not support solidus separator (/) does not support " to " as a date separator; |
Uncertain, incomplete, or approximate dates | yes | Exceptions: does not support {{
circa}} or {{
floruit}} ;does not support dates prior to 100; |
Days of the week | no | |
Months | yes | Exceptions: shortened month names longer than three characters or with terminating periods are not supported in keeping with the Acceptable date formats table; |
Seasons | no | seasons are treated as if they were months so must be capitalized; |
Decades | no | |
Centuries and millennia | no | |
Abbreviations for long periods of time | no |
|date=
|accessdate=
and |archivedate=
), whereas a lot more space can be saved by other means: using initials instead of author's first names; by the use of |displayauthors=
; by judicious use of |location=
and |publisher=
; by the non-use of |quote=
- there are several other ways of reducing the length of a ref, which can easily achieve a saving of more than 18 characters. --
Redrose64 (
talk)
19:49, 25 March 2014 (UTC)|date=31 December 1999
(or |date=December 31, 1999
if you really have to) for publication dates, and |archivedate=1999-12-31
and |accessdate=1999-12-31
for archive and access dates. This visually separates the publication date from other dates which are relevant only within Wikipedia. --
79.67.241.76 (
talk)
14:55, 28 March 2014 (UTC)HTML entity: – does not seem to be supported in date ranges. Example:
Jc3s5h ( talk) 18:43, 25 March 2014 (UTC)
{{
ndash}}
. Also, {{
cite journal/sandbox}}
invokes the live module, not the sandbox version as you might expect. I don't know what the IP editor who made that change had in mind. Use {{
cite journal/new}}
:
So far, I haven't seen any objections to the changes listed in the original list above, only objections to the current operation of the module code. It might be better to split the above discussion into sections with appropriate titles. I can try to do that in an NPOV manner unless there are objections. If there are objections, I will leave the discussion as is and will not be offended.
The only note I see above that may be read as an objection to the list is in reference to the date checking. Trappist the monk may have been overly concise in item 7 on the first list, which might be clearer if it read something like "Expand date validation; all acceptable date formats in the table at WP:DATESNO should now be supported, along with most ranges listed at WP:DATERANGE (see exceptions)" – Jonesey95 ( talk) 20:55, 25 March 2014 (UTC)
I found this attempt at |issn=
in the wild, and it did not cause a citation error:
{{cite journal | author=Moraes KCM, Quaresma AJ, Kobarg, J |title= Identification and characterization of proteins that selectively interact with isoforms of the mRNA binding protein AUF1 (hnRNP D) |journal=BIOLOGICAL CHEMISTRY |volume=384 |issue= 1 |pages= 25–37 |year= 2003 |pmid= 12674497 | ISSN: 1431-6730 pmc= |doi=10.1515/BC.2003.004}}
{{
cite journal}}
: Cite has empty unknown parameter: |ISSN: 1431-6730 pmc=
(
help)CS1 maint: multiple names: authors list (
link)Look specifically at the attempted ISSN parameter. Is there no error because there is nothing following the "=", and parameters with blank values are ignored?
I fixed this one, but I thought I'd drop this example here to offer some food for thought. There's a lot of craziness out there. – Jonesey95 ( talk) 23:40, 21 April 2014 (UTC)
This date range is marked as invalid. It is from 1999 in archaeology.
Baker, Dorie (December 13, 1999 – January 17, 2000). "Finding sheds new light on the alphabet's origins". Yale Bulletin and Calendar. 28 (16). Retrieved 2012-03-16.
Can anyone help turn it into a valid date range? It looks to me like it matches MOSDATE. I checked the source, and the date range matches that of the source. – Jonesey95 ( talk) 04:17, 24 April 2014 (UTC)
'"`UNIQ--templatestyles-00000052-QINU`"'<cite class="citation book cs1">''Title''. 13 December 1999 – 17 January 2000a.</cite><span title="ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Abook&rft.genre=book&rft.btitle=Title&rft.date=1999-12-13%2F2000-01-17&rfr_id=info%3Asid%2Fen.wikipedia.org%3AModule+talk%3ACitation%2FCS1%2FArchive+10" class="Z3988"></span> <span class="cs1-visible-error citation-comment"><code class="cs1-code">{{[[Template:cite book|cite book]]}}</code>: </span><span class="cs1-visible-error citation-comment">Invalid <code class="cs1-code">|ref=harv</code> ([[Help:CS1 errors#invalid_param_val|help]])</span>
{{
cite book}}
: Check date values in: |date=
(
help)'"`UNIQ--templatestyles-00000056-QINU`"'<cite class="citation book cs1">''Title''. December 13, 1999 – January 17, 2000a.</cite><span title="ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Abook&rft.genre=book&rft.btitle=Title&rft.date=1999-12-13%2F2000-01-17&rfr_id=info%3Asid%2Fen.wikipedia.org%3AModule+talk%3ACitation%2FCS1%2FArchive+10" class="Z3988"></span> <span class="cs1-visible-error citation-comment"><code class="cs1-code">{{[[Template:cite book|cite book]]}}</code>: </span><span class="cs1-visible-error citation-comment">Invalid <code class="cs1-code">|ref=harv</code> ([[Help:CS1 errors#invalid_param_val|help]])</span>
{{
cite book}}
: Check date values in: |date=
(
help)We have a parameter, |ol=
which displays in the citation and links to the
Open Library. Currently the link prefixes a "OL" to the value of the parameter and an "OL" is displayed to identify that this is an OLID:
{{cite book |last=Last |first=First |title=Title |ol = 1135607M }}
Last, First. Title.
OL
1135607M.
However, in their
listing pages the Open Library lists their identifiers already including the "OL" prefix (e.g. "OL1135607M"). It would be normal for an editor to expect to be able to copy and paste the identifier from the Open Library page into the citation template:
{{cite book |last=Last |first=First |title=Title |ol = OL1135607M }}
Last, First. Title.
OL
1135607M.
Unfortunately, this does not currently work. The link is non-functional. In addition, no indication is given to the editor that there is a problem. In order to determine that there is an issue, the editor has to examine or test the link.
The "OL" in the ID appears to actually be a part of the ID. While I have not found an actual spec for the ID, looking at their API implies that the OL is part of the ID. We have been enforcing, by not linking properly with the "OL" present, not entering the "OL" in the |ol=
. That means that we can not suddenly switch to requiring it. We need to accept |ol=
both with and without "OL" as the first two characters.
At a minimum, we should change the module such that it does not add an additional "OL" to the link if one already exists in the provided OLID.
As to the visual aspect: While I do not find it visually appealing, having it appear as "OL OL1135607M" is consistent with the format which we have adopted of having a descriptor prior to each ID and displays the complete OLID.
The result of this is that that |ol=
parameters should be processed prior to both linking and display to add an OL to the |ol=
value if an "OL" does not already exist as the first two characters of the parameter value. —
Makyen (
talk)
06:11, 16 May 2014 (UTC)
I was wondering if it could be possible to make the subscription required message a little bit prettier. Right now it has a double parentheses: "(subscription required (help))", and the "help" shows a tooltip. Couldn't the whole "(help)" just be removed and the tooltip applied to the whole message instead? -- Atethnekos ( Discussion, Contributions) 17:04, 20 May 2014 (UTC)
If I'm understanding this correctly.... If the parameter is ISBN=, the module will not check the ISBN number for errors. Should the 4,964 articles that contain | isbn =
be converted via a bot to | isbn =
? Amount of articles obtained from April's dump.
Bgwhite (
talk)
07:16, 27 April 2014 (UTC)
|id=
it is not completely checked for format, but is linked if it does not fail some course format checking. If it is 13 digits and starts with 978 or 979 it is linked (e.g.
ISBN
9781234567890 Parameter error in {{
ISBN}}: checksum), but is not linked if it does not start with those digits (e.g. ISBN 9801234567890). If it is 10 digits (with X as a possible 10th character) it is linked (e.g.
ISBN
123456789X). If it is not 10 or 13 digits it is not linked (e.g. ISBN 12345678901). [NOTE: I have not looked at the code for this which is part of MediaWiki, not the citation templates.]|id=
into |isbn=
. In many cases |id=
was used because |isdn=
is already occupied and would generate an error if it contained more than one ISBN. In addition, if the editor desired to have additional text prior to, or after, the ISBN then it may have been placed in |id=
for that reason. The |isbn=
parameter accepts nothing other than a strictly formatted ISBN with no other text permitted. If the |isbn=
is already occupied, then obviously an additional ISBN should not be moved out of |id=
into |isbn=
. If there is additional text in |id=
then it is a contextual edit where human editorial judgement should be applied and should not be performed by bot.|isbn=
does not exist and an ISBN is in |id=
without additional text – other than "ISBN" – then yes it should be moved into |isbn=
. The contents of |id=
are not included in the COinS data, but |isbn=
is – NOTE: This is contrary to the documentation stating that "any of the identifiers" are included in the COinS data. However, |isbn=
is included in the COinS without any format corrections, which, I assume, is why it has been programmed to generate an error if the value is not strictly compliant as an ISBN (i.e. no other characters are tolerated).|isbn=
parameter. We could easily strip out all non-numeric characters prior to performing the ISBN format/check-digit verifications and passing that stripped version in the COinS. This would result in fewer errors, both for our editors and in the COinS data at the cost of a single regular expression substitution. In effect we would be permitting additional non-numeric text in the |isbn=
value. If desired, the regular expression could also strip a preceding "1[03]:" as that sequence is somewhat commonly used by editors, for some reason, to indicate that it is a 10, or 13 digit ISBN. —
Makyen (
talk)
08:42, 27 April 2014 (UTC)
|isbn=
value. We should continue to do so.|isbn=
or by moving a second ISBN into the |isbn=
where it will be an error when an editor has already placed the second ISBN in |id=
where it does not create an error. I made no comment about the editorial choice to have multiple ISBNs in the citation, only that the bot should be programed to not create errors in the citation when it comes across some situations that are known to exist. —
Makyen (
talk)
13:57, 27 April 2014 (UTC)|type=
is the proper parameter for your examples "{paperback}", "(pbk)", "(hardback)", "(hdb)" – without the brackets.|type=
being most appropriate. When making these changes I have no history on the page, and no knowledge of any possible agreement about format. In my opinion, changes to correct citation errors should remain as close to the original editors intent as possible. Thus, for many cases I feel that it is more important to retain the intent of the original editor rather than use the "correct" parameter |type=
.{{
cite book}}
: Check |isbn=
value: invalid character (
help); Unknown parameter |editors=
ignored (|editor=
suggested) (
help)|type=
and |id=
(location of "Print" disassociates it from the ISBN):
{{
cite book}}
: More than one of |ISBN=
and |isbn=
specified (
help); Unknown parameter |editors=
ignored (|editor=
suggested) (
help)|id=
:
{{
cite book}}
: Unknown parameter |editors=
ignored (|editor=
suggested) (
help)|type=
is closer to what the original editor intended.{{
cite book}}
: External link in |series=
(
help)|type=
doesn't work so well in your example, not because |type=
is wrong but because the original editor is wrong. The CS1 templates are designed to provide information about a single source. Here, the editor is trying to cite two versions of the same source in a single template. We should be glad that he didn't want to include the softcover version as well (
ISBN
978-1-4757-8801-3). Perhaps the better solution to the multiple isbn problem is to choose one to use in the template and include the other(s) parenthetically outside the template. This at least avoids the error, includes an isbn in the
COinS metadata, and still keeps the rest available:|url=
, |chapter-url=
, |pages=
, and removed the external link from |series=
. |doi=
gets the reader to the same place as |chapter-url=
where all you get is a sample of the table of contents and part of the introduction teaser as part of the publisher's effort to sell you a copy of the book; |url=
and the external link in |series=
is more selling. There is no point in listing a chapter and all of the pages that make up the chapter; that does nothing to help a reader find the cited information.
id = ISBN
should not be changed wholesale to ISBN =
, for the reasons noted above. I think it would be reasonable for an editor using AWB to convert instances of id = ISBN
that contain plain ISBNs with no extraneous text, in citations where an ISBN is not present.
Some data: I have fixed about 3,000 of the 8,000 articles in Category:Pages with ISBN errors using an AutoEd script in the past couple of months. I have about 2,500 more articles to examine. The script has been able to fix about 60% of the articles I have examined. The most common fixable error, by far, is two ISBNs separated by a comma. These two ISBNs are usually the 10-digit ISBN followed by the 13-digit ISBN.
As for extra text, the examples given above are often present. Sometimes a "printing" or "edition" is present, though it is almost always redundant with |year=
. Sometimes multiple volumes, each with its own ISBN, are specified; I don't touch those.
When I am done going through the category, I expect there to be about 2,500 articles left. The large majority of those errors will be legitimate errors: ISBNs with too few or too many numbers. There will be somewhere under 1,000 "low-hanging fruit" still left, primarily ASINs, multiple ISBNs that were too strange or ambiguous for my scripting skills to handle, ISSNs, publisher names, and other easy fixes. After those are fixed, I expect we'll have under 2,000 actual ISBN problems to track down.
Anyone who would like to contribute to clearing out this category is welcome to do so. I recommend starting at the end of the alphabet, since the remaining articles that my script hasn't touched are in the A–N portion of the alphabet (I've been working my way from Z to A). – Jonesey95 ( talk) 17:39, 27 April 2014 (UTC)
|isbn=
into |isbn=
and |id=
until
Redrose64
commented that a large number of them were just both the 10 and 13 digit ISBN for the same book and expressed a belief that the 10 digit one should be removed. I don't agree that there is consensus for us to wholesale override the choice of editors to put both a 10 and 13 digit ISBN into the citation. I fully agree that it is not needed, and would not do so myself. I just don't think that there is a wide enough consensus for us to remove them from thousands of articles. I have not been splitting them wholesale since that point. My intent was to go back through once it was clearer as to how to handle them. I also have not translated the code I wrote for a different purpose which decodes/formats/checks ISBNs from JavaScript to what is needed for AWB (which is the tool I use). Something which actually compares the two and verifies that they are 10/13 duplicates would be needed.|isbn=
parameter this might be sufficiently specific. On the other hand it might not. You might want to consider adding/changing your regular expressions to more specifically limit them to only being within citation templates. I use the following (or a variation upon):
({{\s*[cC]it[ea](?:[^}{]*(?:\{\{[^}{]*}}[^}{]*)*)\|\s*)isbn(\s*=\s*)
|isbn=
in the citation this will match the one furthest from the {{\s*[Cc]it[ae]
.B0[0-9A-Za-z]{8}
can safely be considered an ASIN even when not explicitly stated as an "ASIN". However, I have been actually clicking on the links created to verify the fact that is is an ASIN and is valid. I have not found a formal specification for ASIN numbers, but aside from those which are also ISBNs, that format has fit the ones I have seen. —
Makyen (
talk)
23:58, 27 April 2014 (UTC)
B0[0-9A-Za-z]{8}
as indicating an ASIN. I just encountered 4 on a page. Three of them were invalid as ASINs. Although, I have not previously encountered ones which turned up invalid when changed to |asin=
based on that criteria.—
Makyen (
talk)
00:07, 28 April 2014 (UTC)
|isbn=
is not appropriate, but neither is removing all but one ISBN. Using |id=
or putting the ISBNs outside of the citation template might work; I haven't given it enough thought yet, since I've been working on the easy fixes. –
Jonesey95 (
talk)
01:17, 28 April 2014 (UTC)
Would it be feasible to have multiple instances of {{{isbn}}}, each associated with a {{{type}}}?
For example, the above example could be converted to
{{cite book |chapter=Fifty Years of the Shell Model — The Quest for the Effective Interaction |date=2003 |publisher=[[Springer-Verlag]] |doi=10.1007/0-306-47916-8_1 |title=Advances in Nuclear Physics |volume=27 |first=Igal |last=Talmi |editor1-first=J. W. |editor1-last=Negele |editor2-first=E. W. |editor2-last=Vogt |isbn1 = 978-0-306-47708-9 |type1=hardback |issn=0065-2970 |series = Advances in the Physics of Particles and Nuclei (APPN)|isbn2 = 978-0-306-47916-8 | type2 = Online | isbn3 = 978-1-4757-8801-3 | type3 = softcover}}
We would default to {{{isbn1}}} or simply {{{isbn}}} for generating
COinS metadata, just like at present.
HTH HAND —
Phil |
Talk
17:40, 15 May 2014 (UTC)
|id=
is used, but that should be an exception, not a rule. If we were going to start listing all of the different identifiers for every edition/version of a book, as
Redrose64 said "where would it stop?" As an example: a reference on which I was attempting to fix the ISBN earlier today was citing Magic and Mystery in Tibet. Should we be listing identifiers for all of the
60 versions listed in WorldCat?|id=
parameter can be used for this purpose and as long as the text "ISBN" precedes a valid format ISBN it will be linked to
Special:BookSources by the MediaWiki software. (see
Help:Magic links)
|isbn=
parameter. Removing everything other than digits is trivial.If I'm understanding this correctly.... If the parameter is ISBN=, the module will not check the ISBN number for errors. Should the 4,964 articles that contain | isbn =
be converted via a bot to | isbn =
? Amount of articles obtained from April's dump.
Bgwhite (
talk)
07:16, 27 April 2014 (UTC)
|id=
it is not completely checked for format, but is linked if it does not fail some course format checking. If it is 13 digits and starts with 978 or 979 it is linked (e.g.
ISBN
9781234567890 Parameter error in {{
ISBN}}: checksum), but is not linked if it does not start with those digits (e.g. ISBN 9801234567890). If it is 10 digits (with X as a possible 10th character) it is linked (e.g.
ISBN
123456789X). If it is not 10 or 13 digits it is not linked (e.g. ISBN 12345678901). [NOTE: I have not looked at the code for this which is part of MediaWiki, not the citation templates.]|id=
into |isbn=
. In many cases |id=
was used because |isdn=
is already occupied and would generate an error if it contained more than one ISBN. In addition, if the editor desired to have additional text prior to, or after, the ISBN then it may have been placed in |id=
for that reason. The |isbn=
parameter accepts nothing other than a strictly formatted ISBN with no other text permitted. If the |isbn=
is already occupied, then obviously an additional ISBN should not be moved out of |id=
into |isbn=
. If there is additional text in |id=
then it is a contextual edit where human editorial judgement should be applied and should not be performed by bot.|isbn=
does not exist and an ISBN is in |id=
without additional text – other than "ISBN" – then yes it should be moved into |isbn=
. The contents of |id=
are not included in the COinS data, but |isbn=
is – NOTE: This is contrary to the documentation stating that "any of the identifiers" are included in the COinS data. However, |isbn=
is included in the COinS without any format corrections, which, I assume, is why it has been programmed to generate an error if the value is not strictly compliant as an ISBN (i.e. no other characters are tolerated).|isbn=
parameter. We could easily strip out all non-numeric characters prior to performing the ISBN format/check-digit verifications and passing that stripped version in the COinS. This would result in fewer errors, both for our editors and in the COinS data at the cost of a single regular expression substitution. In effect we would be permitting additional non-numeric text in the |isbn=
value. If desired, the regular expression could also strip a preceding "1[03]:" as that sequence is somewhat commonly used by editors, for some reason, to indicate that it is a 10, or 13 digit ISBN. —
Makyen (
talk)
08:42, 27 April 2014 (UTC)
|isbn=
value. We should continue to do so.|isbn=
or by moving a second ISBN into the |isbn=
where it will be an error when an editor has already placed the second ISBN in |id=
where it does not create an error. I made no comment about the editorial choice to have multiple ISBNs in the citation, only that the bot should be programed to not create errors in the citation when it comes across some situations that are known to exist. —
Makyen (
talk)
13:57, 27 April 2014 (UTC)|type=
is the proper parameter for your examples "{paperback}", "(pbk)", "(hardback)", "(hdb)" – without the brackets.|type=
being most appropriate. When making these changes I have no history on the page, and no knowledge of any possible agreement about format. In my opinion, changes to correct citation errors should remain as close to the original editors intent as possible. Thus, for many cases I feel that it is more important to retain the intent of the original editor rather than use the "correct" parameter |type=
.{{
cite book}}
: Check |isbn=
value: invalid character (
help); Unknown parameter |editors=
ignored (|editor=
suggested) (
help)|type=
and |id=
(location of "Print" disassociates it from the ISBN):
{{
cite book}}
: More than one of |ISBN=
and |isbn=
specified (
help); Unknown parameter |editors=
ignored (|editor=
suggested) (
help)|id=
:
{{
cite book}}
: Unknown parameter |editors=
ignored (|editor=
suggested) (
help)|type=
is closer to what the original editor intended.{{
cite book}}
: External link in |series=
(
help)|type=
doesn't work so well in your example, not because |type=
is wrong but because the original editor is wrong. The CS1 templates are designed to provide information about a single source. Here, the editor is trying to cite two versions of the same source in a single template. We should be glad that he didn't want to include the softcover version as well (
ISBN
978-1-4757-8801-3). Perhaps the better solution to the multiple isbn problem is to choose one to use in the template and include the other(s) parenthetically outside the template. This at least avoids the error, includes an isbn in the
COinS metadata, and still keeps the rest available:|url=
, |chapter-url=
, |pages=
, and removed the external link from |series=
. |doi=
gets the reader to the same place as |chapter-url=
where all you get is a sample of the table of contents and part of the introduction teaser as part of the publisher's effort to sell you a copy of the book; |url=
and the external link in |series=
is more selling. There is no point in listing a chapter and all of the pages that make up the chapter; that does nothing to help a reader find the cited information.
id = ISBN
should not be changed wholesale to ISBN =
, for the reasons noted above. I think it would be reasonable for an editor using AWB to convert instances of id = ISBN
that contain plain ISBNs with no extraneous text, in citations where an ISBN is not present.
Some data: I have fixed about 3,000 of the 8,000 articles in Category:Pages with ISBN errors using an AutoEd script in the past couple of months. I have about 2,500 more articles to examine. The script has been able to fix about 60% of the articles I have examined. The most common fixable error, by far, is two ISBNs separated by a comma. These two ISBNs are usually the 10-digit ISBN followed by the 13-digit ISBN.
As for extra text, the examples given above are often present. Sometimes a "printing" or "edition" is present, though it is almost always redundant with |year=
. Sometimes multiple volumes, each with its own ISBN, are specified; I don't touch those.
When I am done going through the category, I expect there to be about 2,500 articles left. The large majority of those errors will be legitimate errors: ISBNs with too few or too many numbers. There will be somewhere under 1,000 "low-hanging fruit" still left, primarily ASINs, multiple ISBNs that were too strange or ambiguous for my scripting skills to handle, ISSNs, publisher names, and other easy fixes. After those are fixed, I expect we'll have under 2,000 actual ISBN problems to track down.
Anyone who would like to contribute to clearing out this category is welcome to do so. I recommend starting at the end of the alphabet, since the remaining articles that my script hasn't touched are in the A–N portion of the alphabet (I've been working my way from Z to A). – Jonesey95 ( talk) 17:39, 27 April 2014 (UTC)
|isbn=
into |isbn=
and |id=
until
Redrose64
commented that a large number of them were just both the 10 and 13 digit ISBN for the same book and expressed a belief that the 10 digit one should be removed. I don't agree that there is consensus for us to wholesale override the choice of editors to put both a 10 and 13 digit ISBN into the citation. I fully agree that it is not needed, and would not do so myself. I just don't think that there is a wide enough consensus for us to remove them from thousands of articles. I have not been splitting them wholesale since that point. My intent was to go back through once it was clearer as to how to handle them. I also have not translated the code I wrote for a different purpose which decodes/formats/checks ISBNs from JavaScript to what is needed for AWB (which is the tool I use). Something which actually compares the two and verifies that they are 10/13 duplicates would be needed.|isbn=
parameter this might be sufficiently specific. On the other hand it might not. You might want to consider adding/changing your regular expressions to more specifically limit them to only being within citation templates. I use the following (or a variation upon):
({{\s*[cC]it[ea](?:[^}{]*(?:\{\{[^}{]*}}[^}{]*)*)\|\s*)isbn(\s*=\s*)
|isbn=
in the citation this will match the one furthest from the {{\s*[Cc]it[ae]
.B0[0-9A-Za-z]{8}
can safely be considered an ASIN even when not explicitly stated as an "ASIN". However, I have been actually clicking on the links created to verify the fact that is is an ASIN and is valid. I have not found a formal specification for ASIN numbers, but aside from those which are also ISBNs, that format has fit the ones I have seen. —
Makyen (
talk)
23:58, 27 April 2014 (UTC)
B0[0-9A-Za-z]{8}
as indicating an ASIN. I just encountered 4 on a page. Three of them were invalid as ASINs. Although, I have not previously encountered ones which turned up invalid when changed to |asin=
based on that criteria.—
Makyen (
talk)
00:07, 28 April 2014 (UTC)
|isbn=
is not appropriate, but neither is removing all but one ISBN. Using |id=
or putting the ISBNs outside of the citation template might work; I haven't given it enough thought yet, since I've been working on the easy fixes. –
Jonesey95 (
talk)
01:17, 28 April 2014 (UTC)
Would it be feasible to have multiple instances of {{{isbn}}}, each associated with a {{{type}}}?
For example, the above example could be converted to
{{cite book |chapter=Fifty Years of the Shell Model — The Quest for the Effective Interaction |date=2003 |publisher=[[Springer-Verlag]] |doi=10.1007/0-306-47916-8_1 |title=Advances in Nuclear Physics |volume=27 |first=Igal |last=Talmi |editor1-first=J. W. |editor1-last=Negele |editor2-first=E. W. |editor2-last=Vogt |isbn1 = 978-0-306-47708-9 |type1=hardback |issn=0065-2970 |series = Advances in the Physics of Particles and Nuclei (APPN)|isbn2 = 978-0-306-47916-8 | type2 = Online | isbn3 = 978-1-4757-8801-3 | type3 = softcover}}
We would default to {{{isbn1}}} or simply {{{isbn}}} for generating
COinS metadata, just like at present.
HTH HAND —
Phil |
Talk
17:40, 15 May 2014 (UTC)
|id=
is used, but that should be an exception, not a rule. If we were going to start listing all of the different identifiers for every edition/version of a book, as
Redrose64 said "where would it stop?" As an example: a reference on which I was attempting to fix the ISBN earlier today was citing Magic and Mystery in Tibet. Should we be listing identifiers for all of the
60 versions listed in WorldCat?|id=
parameter can be used for this purpose and as long as the text "ISBN" precedes a valid format ISBN it will be linked to
Special:BookSources by the MediaWiki software. (see
Help:Magic links)
|isbn=
parameter. Removing everything other than digits is trivial.|website=
is listed on the Whitelist; however, if used in conjunction with |archiveurl=
, it generates an error message:
{{cite book |archiveurl=//www.web.archive.org |archivedate=May 15, 2014 |deadurl=no |author=Johnson, Malcom |title=Sample Title |website=http://www.example.com}}
If |url=
is populated, the error is resolved, but a bare url displays in the citation. (This is also what happens if |archiveurl=
isn't populated.)
{{cite book |url=http://www.example.com |archiveurl=//www.web.archive.org |archivedate=May 15, 2014 |deadurl=no |author=Johnson, Malcom |title=Sample Title |website=http://www.example.com}}
{{
cite book}}
: |website=
ignored (
help); External link in |website=
(
help); Unknown parameter |deadurl=
ignored (|url-status=
suggested) (
help)Is this the desired behavior of this parameter, or is it a glitch? I would think that |website=
is an alias of |url=
; the
AWB renaming script currently replaces it with |url=
. Should it continue to do so? Or is this a glitch that will be fixed? I'm about to post a lengthy list of valid alias parameters that the script is currently replacing on that
talk page; if the script shouldn't continue to replace |website=
with |url=
, please be sure to comment there. Thanks!—
D'Ranged 1
VTalk
00:14, 28 May 2014 (UTC)
|website=
is an alias of |work=
, for the name of a website, not the address.
Imzadi 1979
→
00:17, 28 May 2014 (UTC)
|website=
with |work=
, which is unnecessary. Sorry I was confused; I've straightened it out over there. Thanks again!—
D'Ranged 1
VTalkThese parameters are not on the Whitelist, but are used successfully in templates.
|eprint=
in {{
cite arXiv}}; a valid alias for |arxiv=
, which is required.|class=
in {{
cite arXiv}}; optional|pmc-embargo-date=
in {{
arxiv}} coding; however, it doesn't appear in the documentation. Possibly an alias for |embargo=
on the Whitelist.I thought this was supposed to be a current, complete listing of all approved parameters for the templates. If it isn't, one is needed. I've made changes to the list of parameters for Citation bot based on this list in an attempt to avoid the bot making errors; I now have to undo some of those changes.— D'Ranged 1 VTalk 16:58, 30 May 2014 (UTC)
|eprint=
is not used in any of those cite templates.|eprint=
may need to be added to the Whitelist. There is a list of cite templates that use the module at
Help:Citation Style 1; they are highlighted in light green in the left column. –
Jonesey95 (
talk)
19:25, 30 May 2014 (UTC)
{{
Cite arXiv}}
is essentially a special case of {{
cite journal}}
, where some of the parameters (like |journal=
|work=
and |publisher=
) put the page into an error category, and a few extra parameters are recognised. These, |eprint=
(and its alias |arxiv=
), |version=
and |class=
are used to construct special links. To cope with these variations, it still uses the older {{
Citation/core}}
method instead of
Module:Citation/CS1. --
Redrose64 (
talk)
21:39, 30 May 2014 (UTC)Could there be a check on the author field to detect when it contains date type information, such as |author=Published on Mon May 19 14:30:16 BST 2008
, that occurs in numerous articles. Probably need to add a tracking category when this occurs so that they can be fixed by removal or transferring information to the |date=
field. Regards.
Keith D (
talk)
00:46, 20 June 2014 (UTC)
|title=
parameter - usually separated by an HTML entity for a hyphen, dash or suchlike.
Andy Mabbett (Pigsonthewing);
Talk to Andy;
Andy's edits
11:02, 20 June 2014 (UTC)
|title=
parameter.
GoingBatty (
talk)
16:47, 20 June 2014 (UTC)|date=
field before removing.
Keith D (
talk)
23:18, 22 June 2014 (UTC)
|date=
field.
GoingBatty (
talk)
02:22, 23 June 2014 (UTC)
![]() | This
edit request has been answered. Set the |answered= or |ans= parameter to no to reactivate your request. |
doix
is used in {{
Cite doi/preload}} to prefill a version of the DOI that the citation bot fixes up; it then changes doix
to doi
. doix
was
added to the whitelist but subsequently
removed in an update from the sandbox. I think that was unintentional. Would an administrator please add doix
back into
Module:Citation/CS1/Whitelist, maybe with a comment to keep it from disappearing again? Thank you.
– Minh Nguyễn ( talk, contribs) 21:55, 6 July 2014 (UTC)
|doix=
should be included in
Module:Citation/CS1/Whitelist. I think that including parameters that have nothing to do with CS1 blurs a very distinct line that should not be blurred. Without some discussion that shows that |doix=
must be included, I'm not ready to accommodate this request.|doix=
is an unsupported parameter used temporarily by Citation Bot, I believe. The bot removes it during creation of cite doi templates. The bot is currently blocked, which is why you are seeing |doix=
. It should never be seen by a human editor under normal circumstances. –
Jonesey95 (
talk)
23:12, 6 July 2014 (UTC)doix
to doi
, but without decoding the .2F
escape, the link was broken. I went ahead and reimplemented the conversion from doix
to doi
in
Module:Cite doi. Let me know if you see any bugs. –
Minh Nguyễn (
talk,
contribs)
23:17, 6 July 2014 (UTC)The module apparently checks that season names are spelled Spring, Summer, Fall (or Autumn), or Winter. But season names are not capitalized (look them up in, for example, American Heritage Dictionary 3rd. ed.) Jc3s5h ( talk) 05:29, 26 August 2014 (UTC)
|date=
or |issue=
field.{{
cite journal}}
: Check date values in: |date=
(
help)In the list of identifiers, PMID is one result that usually (if not always) results in a free full text of the citation. I'm not a programmer so I'm suggesting this in the form of a logical sentence: if 'url'="null" and PMID is valid (not flag "bad pmid") then set 'URL' can be set to PMID-url. It looks like this could be built into function 'buildlist'. ~
Technophant (
talk)
14:04, 28 August 2014 (UTC)
|pmid=
parameter is present, then one link is already there. I don't see a particular advantage of creating a redundant link from the citation's title.
Boghog (
talk)
14:18, 28 August 2014 (UTC)|pmc=
parameter already does exactly what you want to do.
PubMed Central by definition does contain the free full text. In addition, if |pmc=
is present and |url=
is empty, then the citation's title is automatically linked.
Boghog (
talk)
14:45, 28 August 2014 (UTC)|pmc=
is present, then the title should be linked because pmc provides full free text.
Boghog (
talk)
06:17, 29 August 2014 (UTC)Could some form of check be made on title fields that include a URL? The URL is usually at the end of the title after something like "Read more". May be these could be categorised and a BOT set-up to remove this clutter. Thanks. Keith D ( talk) 01:36, 8 September 2014 (UTC)
|title=
parameter, you sometimes find that you've copied more than you intended. Among the extra text is often "Read more:" and a URL. I always delete the unintended extras, but there must be people who either didn't notice, or didn't realise that it was not part of what we want in a |title=
--
Redrose64 (
talk)
14:09, 8 September 2014 (UTC)|title=
parameter's value?Would it be possible to change, at
/Configuration, the |zbl=
URL from
http://www.zentralblatt-math.org to
https://zbmath.org? E.g. for me,
http://www.zentralblatt-math.org/zmath/en/search/?format=complete&q=an:1177.37036 redirects to
https://zbmath.org/?format=complete&q=an:1177.37036.
It Is Me Here
t /
c
11:46, 4 September 2014 (UTC)
|jfm=
parameter also redirect. --
Gadget850
talk
13:51, 9 September 2014 (UTC)Ok. Done in the sandbox.
{{
cite book}}
: Check |jfm=
value (
help)— Trappist the monk ( talk) 12:37, 13 September 2014 (UTC)
{{
jfm}}
and {{
zbl}}
templates also updated.
— Trappist the monk ( talk) 13:07, 13 September 2014 (UTC)
At Norwegian Bokmål Wikipedia we have added support for formatting ISO 8601 dates (YYYY-MM-DD) and recommend using them. If more wikipedias could support ISO 8601, it would be easier to copy citations from one wikipedia to another. It could also make life easier for bots that need to insert dates, or scripts relying on Citoid. Are there any objections to adding ISO 8601 date support on enwiki? Here's an example of how it could be done (with testcases), inspired by our implementation at nowiki. One possible problem is that any fixed output format like 'j M Y' might not confirm to WP:MOS#Choice_of_format. – Danmichaelo ( talk) 16:58, 14 September 2014 (UTC)
{{
citation/core}}
days where the templates automatically converted from year-initial numeric dates to the user's preferred format. For a while. That functionality was removed.I see from the template that {{ PDFlink}} is in the process of being merged into CS1. The TfD discussion noted that wikipedia's CSS adds the PDF icon where an external link indicates the document is a pdf, however not all links will do this. Some (e.g. this one used on Ford Island) generate a pdf and force the browser to download it. Even for sites which don't force a download, sometimes the content type is displayed in the header, not the url. For resources like that we should have some way of indicating to the user that the resource is a PDF. How do we do that when the merger is complete with CS1? Protonk ( talk) 14:26, 19 September 2014 (UTC)
[http://www.example.com/example.pdf Example]
turns into this:
Example – there is no such file, by the way. Your Ford Island example does not have the '.pdf' extension so Wikimedia can't know it's file format. To notify readers that the link is to a pdf file, use |format=pdf
which gives:
"Historic Hawaii" (pdf).{{
PDFlink}}
into CS1 so don't expect anything soon. {{PDFlink}}
should not be used within CS1 templates.CS1 doesn't seem equipped to handle a range of seasons as the "date=" parameter; see for example here. I managed to get both a single season and a range of years displayed correctly, so I don't think it's me. Huon ( talk) 20:35, 20 September 2014 (UTC)
{{
ndash}}
or –
; like this:
{{cite book |title=Title |date=Winter 2013 – Spring 2014}}
→ Title. Winter 2013 – Spring 2014.{{
ndash}}
, it's {{
spaced ndash}}
that shouldn't be used. I'll tweak the help a bit.How should Winter 2005 / 2006 be formatted to not get cs1 errors? I cannot get it to work in the Susanna Paine article: Michael R. and Suzanne R. Payne (Winter 2005 / 2006). "Roses and Thorns: The Life of Susanna Paine". Folk Art. p. 63. Check date values in: |date= (help)
Thanks!-- CaroleHenson ( talk) 13:28, 22 September 2014 (UTC)
|date=Winter 2005–2006
I have split this off from
Module talk:Citation/CS1/Archive 11#non-italic titles. It is related but I want to focus this discussion on right-to-left language support. |script-title=
is a new parameter in the sandbox version of
Module:Citation/CS1 Its purpose is to hold citation title text that must not be italicized in the final rendered citation. It is concatenated with the value in |title=
which is to be italicized. See
non-italic titles for the discussion that led to the creation of |script-title=
. At the time of this writing, |script-title=
is just hacked into the CS1 sandbox as a proof of concept. Its full use and purpose is not clearly defined. I am seeking a better name for this parameter. Ideas for a better name and for use definition and restrictions welcome.
The post that I split from non-italic titles begins here:
This citation comes from a discussion now in
WP:VPT archive 129. I changed it from {{
cite web}}
to {{
cite book}}
so that |script-title=
would apply because {{cite web}}
doesn't italicize |title=
). You'll notice that title and translated title are malformed:
{{
cite book}}
: Unknown parameter |trans_title=
ignored (|trans-title=
suggested) (
help)I added code to
Module:Citation/CS1/sandbox to wrap |script-title=
in <bdi>...</bdi>
tags. The sandbox version of the citation renders correctly:
{{cite book/new |author=Tova Green |date=6 May 2010 |script-title=12 ימים|language=he |trans_title=13 days |publisher=Maybe So |url=http://MaybeSo.com/12days.html |accessdate=15 May 2010}}
I'm beginning to think that values assigned to |title=
and|script-title=
(or whatever it finally becomes) should be wrapped in <bdi>...</bdi>
tags – the value assigned to |trans-title=
is always supposed to be English so wrapping it seems unnecessary.
— Trappist the monk ( talk) 14:46, 13 September 2014 (UTC)
|logogram=
with |script-title=
. All instances of |logogram=
in the above post have also been replaced.<bdi>...</bdi>
. We're in the position of not really knowing what direction the value assigned to |script-title=
might use. We could wrap |script-title=
in <span dir=auto>...</span>
but, yet again, IE doesn't support dir=auto
. That, I think, leaves us with two options: do nothing and wait for IE to join the 21st century, or wrap |script-title=
in <bdi>...</bdi>
. In the former case, the problem that led to this discussion is a problem for everyone; in the latter, its only a problem for those who use IE. I think that we should use <bdi>...</bdi>
because eventually, I presume, IE will get its act together.<bdi>...</bdi>
"; it says "Internet Explorer, Safari and Opera do not support bdi." --
Redrose64 (
talk)
15:28, 20 September 2014 (UTC)dir=auto
is how we will be using <bdi>...</bdi>
, then it would seem that the basic test results indicate that all but IE 'support' <bdi>...</bdi>
.<bdi>...</bdi>
would probably fix it. The title string would get the direction of its first strongly directional character and wouldn't be affected by neighboring strings.<bdi>...</bdi>
is 11 bytes. With a lot of cites, that could add a considerable amount of data to everyone's download, on every page. Would it work to look at the first byte in the title string and wrap the title in <bdi>...</bdi>
if it's a number or another weak character? --
Margin1522 (
talk)
22:30, 20 September 2014 (UTC)|script-title=
will be wrapped with <bdi>...</bdi>
to isolate whatever directionality it has from the ltr direction in |title=
. <bdi>...</bdi>
will only be applied when a citation contains a non-empty |script-title=
so this imposes relatively little download penalty. This is how the sandbox is working now.|script-title=
so that we can get some experience with it. Then let us decide how to proceed. It may be that we should consider renaming |script-title=
to |rtl-title=
because the original reason for the parameter's existence (italics and Asian scripts) is probably not the issue it was now that wikimarkup can be used to undo default title italics without corrupting the metadata.{{cite web|rtl=y|...
or {{cite web|cjk=Yes|...
. This would be an easy-to-understand fix for editors who enter the cite with the regular menu UI and then notice that the output looks funny. They wouldn't have to edit the |title=
parameter name or escape the kanji. Just add the parameter. In a future UI, they could be check boxes instead of separate entry fields. --
Margin1522 (
talk)
09:14, 22 September 2014 (UTC)|title=
, <bdi>...</bdi>
isn't clever enough to figure out which part is which. To mimic what you suggest, I have changed our current favorite citation. Here I put both the translation and the rtl script in |script-title=
so that it contains both ltr and rtl. The whole is wrapped with <bdi>...</bdi>
. The title should be: 13 days ימים 12 but instead we get this:
{{
cite book}}
: Invalid |script-title=
: missing prefix (
help)|rtl=
and |cjk=
parameters; one each for every standard parameter that might contain rtl or cjk script (and it isn't just cjk scripts that should be rendered in upright font style). Wikimarkup is something that editors are familiar with and understand so allowing them to undo default styling that way seems best. If we have to have another parameter to indicate that this 'thing' is rtl, why not just assign that parameter the value of 'thing'? |script-title=
, |script-chapter=
, |script-author=
, etc.|script-title=he:ימים 12
. This would then let us wrap the script with <bdi lang="he">...</bdi>
. This prefix would not be required and could be escaped in the unlikely event that the first three characters in a |script-title=
value make a legitimate ISO639-1 code followed by a colon. If the prefix is used, we can check it for validity and emit appropriate error messages.|title=
, |chapter=
, |work=
and maybe |author=
. This is en.wikipedia. There probably needs to be more thought given to what parameters after |title=
get this option. Just you and me in this ghost-town of a talk page is not enough.|transcript=
parameter that is used as the title of an external link to the transcript of something (interview, speech, etc). We can certainly alias |title=
with another parameter, perhaps |xscr-title=
or some-such, if that is required.{{cite book|last1=Kinoshita|first1=Masahi ...
, write {{cite book|author=Kinoshita Masahi <kanji> ...
But, that might be problematic because: What will the metadata contain? That's why I suggested |script-author=
above. |author=
is part of the metadata but should |script-author=
or for that matter any |script-whatever=
parameter values be part of the metadata? But you want to use |author=
anyway, don't you? Aren't Japanese names properly surname first without the comma?I've added code that accepts an ISO639-1 prefix (no validity testing yet, spaces aren't allowed) but the language code is added to <bdi>...</bdi>
. Our favorite citation, stripped of just about everthing for clarity:
{{cite book/new |script-title=he:12 ימים |trans_title=13 days}}
produces this:
Here is what the html looks like:
'"`UNIQ--templatestyles-00000092-QINU`"'<cite class="citation book cs1 cs1-prop-script"> <bdi lang="he" >12 ימים</bdi>.</cite><span title="ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Abook&rft.genre=book&rft.btitle=12+%D7%99%D7%9E%D7%99%D7%9D&rfr_id=info%3Asid%2Fen.wikipedia.org%3AModule+talk%3ACitation%2FCS1%2FArchive+10" class="Z3988"></span> <span class="cs1-visible-error citation-comment"><code class="cs1-code">{{[[Template:cite book|cite book]]}}</code>: </span><span class="cs1-visible-error citation-comment">Unknown parameter <code class="cs1-code">|trans_title=</code> ignored (<code class="cs1-code">|trans-title=</code> suggested) ([[Help:CS1 errors#parameter_ignored_suggest|help]])</span>
Because this citation doesn't use I guess that this argues for inclusion of the |title=
for a transcription, there isn't any title information in the metadata.|script-title=
. Do we always include it? Or, do we only include it when |title=
is missing or empty?
— Trappist the monk ( talk) 00:12, 23 September 2014 (UTC)
|title=
, the non-Latin title is included in the metadata. So, lacking direction to the contrary, I'll make sure that the content of |script-title=
is also part of the metadata.|title=
and |script-title=
.lang
attribute and leave the prefix with the script.I have adjusted the code so that |script-title=
is applied to all CS1 templates (heretofore only those that italicized |title=
. Here is a simplified {{
cite journal}}
:
{{
cite journal}}
: Unknown parameter |trans_title=
ignored (|trans-title=
suggested) (
help)— Trappist the monk ( talk) 15:02, 24 September 2014 (UTC)
For this citation:
With Firefox 33 and IE 11, I see 12 space followed by the Hebrew then [13 days]]. -- Gadget850 talk 23:21, 20 September 2014 (UTC)
|script-title=
and wrap the script in <bdi>...</bdi>
:
|script-title=
with <bdi>...</bdi>
doesn't break anything and appears to provide mostly-correct rendering across browsers. This, I think, argues for its inclusion in the module.unicode-bidi: embed; unicode-bidi: -webkit-isolate; unicode-bidi: -moz-isolate; unicode-bidi: -ms-isolate; unicode-bidi: isolate;
unicode-bidi:
works with direction:
which can have the values ltr
, rtl
, or inherit
. That means that we would need to know beforehand the direction required by the content of |script-title=
. Therein lies the value of <bdi>...</bdi>
.![]() | This is an archive of past discussions. Do not edit the contents of this page. If you wish to start a new discussion or revive an old one, please do so on the current talk page. |
Archive 5 | ← | Archive 8 | Archive 9 | Archive 10 | Archive 11 | Archive 12 |
|lccn=
This one won't come up very often, but an invalid |lccn=
can make it so that the automatic link to lccn.loc.gov does not work. I came across one in a citation today. I'm guessing that there are approximately a few dozen invalid LCCN parameters in all of WP, but they should be easy to detect.
Here is a straightforward explanation (scroll to "identifier-syntax") of valid LCCN syntax that will work with the LCCN web site. – Jonesey95 ( talk) 05:16, 17 March 2014 (UTC)
{{
cite book}}
: Check |lccn=
value (
help){{
cite book}}
: Check |lccn=
value (
help){{
cite book}}
: Check |lccn=
value (
help){{
cite book}}
: Check |lccn=
value (
help){{
cite book}}
: Check |lccn=
value (
help){{
cite book}}
: Check |lccn=
value (
help){{
cite book}}
: Check |lccn=
value (
help){{
cite book}}
: Check |lccn=
value (
help){{
cite book}}
: Check |lccn=
value (
help){{
cite book}}
: Check |lccn=
value (
help)Well, not quite right. The check needs to be improved so that lccns with hyphens are normalized before they are checked.
— Trappist the monk ( talk) 14:20, 30 March 2014 (UTC)
normalize_lccn()
normalizes the lccn according to the
Normalization of LCCNs procedure. These test citations all work correctly. normalize_lccn()
is able to normalize them all; the two fails are because there are spaces in the lccn that cause improper display of the lccn link
{{
cite book}}
: Check |lccn=
value (
help) [http://lccn.loc.gov/n 78890351 n 78890351]
{{
cite book}}
: Check |lccn=
value (
help) [http://lccn.loc.gov/79139101 /AC/r932 79139101 /AC/r932]
I think I have found a small bug in the new year range code (which is great, by the way!). Here's what I have so far:
Author (1901–02).
"Foo Title". Journal Name. 23: 4. {{
cite journal}}
: |author=
has generic name (
help); Check date values in: |year=
(
help)
Author (1901–04).
"Foo Title". Journal Name. 23: 4. {{
cite journal}}
: |author=
has generic name (
help); Check date values in: |year=
(
help)
Author (1909–10).
"Foo Title". Journal Name. 23: 4. {{
cite journal}}
: |author=
has generic name (
help); Check date values in: |year=
(
help)
Author (1911–12).
"Foo Title". Journal Name. 23: 4. {{
cite journal}}
: |author=
has generic name (
help); Check date values in: |year=
(
help)
Author (1918–20).
"Foo Title". Journal Name. 23: 4. {{
cite journal}}
: |author=
has generic name (
help)
Author (1921–22).
"Foo Title". Journal Name. 23: 4. {{
cite journal}}
: |author=
has generic name (
help)
Author (1931–36).
"Foo Title". Journal Name. 23: 4. {{
cite journal}}
: |author=
has generic name (
help)
Author (1984–86).
"Foo Title". Journal Name. 23: 4. {{
cite journal}}
: |author=
has generic name (
help)
Author (2001–02).
"Foo Title". Journal Name. 23: 4. {{
cite journal}}
: |author=
has generic name (
help); Check date values in: |year=
(
help)
Author (2001–04).
"Foo Title". Journal Name. 23: 4. {{
cite journal}}
: |author=
has generic name (
help); Check date values in: |year=
(
help)
Author (2009–10).
"Foo Title". Journal Name. 23: 4. {{
cite journal}}
: |author=
has generic name (
help); Check date values in: |year=
(
help)
Author (2011–12).
"Foo Title". Journal Name. 23: 4. {{
cite journal}}
: |author=
has generic name (
help); Check date values in: |year=
(
help)
Author - future year (2018–20).
"Foo Title". Journal Name. 23: 4. {{
cite journal}}
: |author=
has generic name (
help)
The year ranges are changed and are in |year=
. The citations are otherwise identical except for the future year. –
Jonesey95 (
talk)
00:17, 31 March 2014 (UTC)
|year=
and (b) all use endashes, I propose that they should be acceptable to the date-checking code. –
Jonesey95 (
talk)
02:44, 31 March 2014 (UTC)|year=
go the way of |day=
and |month=
.|date=1901–02
is |date=1901–1902
.|date=1901–02
is |date=1901–1902
." This is wrong on a few levels. First, this thread is about a bug in checking code. The checking code doesn't fix anything, an editor does. Next, since MOSNUM allows 1901–02 (that's an n-dash) this style of range should be acceptable by the checking code. I think the code already would disallow a hyphen in any date expression except YYYY-MM-DD, so even after the code is fixed to accept 1901–02 the expressions 1901-02 and 1901-99 (with hyphens) would still be flagged as errors.
Jc3s5h (
talk)
15:11, 31 March 2014 (UTC)PC-XT, I think this is the wrong place to argue that YYYY–YY is too ambiguous to use in a citation, because a citation has less context than other parts of an article. If that's what you believe, you should bring it up at Help talk:Citation Style 1, and argue that page should declare that Citation Style 1 permanently rejects YYYY–YY, as an exception to the general acceptance of WP:MOSNUM date guidance, and it should be spelled out the rejection is on the basis of ambiguity (which is permanent) rather than it being unfeasible to check (which may be temporary). Jc3s5h ( talk) 01:13, 1 April 2014 (UTC)
{{
citation/core}}
. Continuing evolution is bringing them all into
Module:Citation/CS1; new features are added, old features are pared away, and somehow, somehow, it is beginning to coalesce into a single entity. There is no plan for this, it just happens because Wikipedia happens. Documentation in this kind of environment lags behind the implementation; it will always lag behind.a description of free choices to create differences between CS1 and MOSNUM, though it does reflect those choices; it isn't even good user documentation. It is a mess. Help:Citation Style 1 is merely a collection of writings that attempts to describe how CS1 works and how to use it. Expecting more from it than that will lead to despair.
defiance of WP:MOSNUM, but rather, to the benefit of CS1.
It is a mess, and documentation isn't going to be perfect. Nevertheless, when it is clear what the documentation says, and it is reasonably feasible to write checking code that follows the documentation, that should be done. It is inappropriate to use a position as a code writer to ignore the consensus process and just implement whatever the coder prefers. If you think 1901–02 is ambiguous in the context of a citation, get consensus to modify Help:Citation Style 1 accordingly, instead of throwing it on a list of stuff that is infeasible or in the queue. Jc3s5h ( talk) 01:21, 1 April 2014 (UTC)
Should we deprecate origyear and make it a synonym of a new parameter called origdate so that the naming format is consistent. Jason Quinn ( talk) 03:43, 3 April 2014 (UTC)
|origyear=
is mainly used for books, where a second or subsequent edition is common, but the exact publication date is unimportant; for a non-first edition of a book, the actual and original year of publication are both useful. The exact publication date is mainly of use for periodicals, where although there is almost always more than one issue, there is rarely more than one edition. Some newspapers do have one or more pages re-set during a print run, in order to cover breaking news; but the cover date doesn't change, and so the "original date" is pretty much a non-existent concept. --
Redrose64 (
talk)
10:02, 3 April 2014 (UTC)An RFC that sought to determine whether YYYY-MM was an acceptable date format was recently closed.
The YYYY-MM format is currently in the Unacceptable column of the table at WP:BADDATEFORMAT, but I expect that to change soon. It was added there because the initial RFC closure said that there was "no consensus to change anything", implying that the state of the table at the opening of the RFC (YYYY-MM was in the Unacceptable column at that point) was how it should remain. The closure was subsequently revised to read: "There is no consensus that YYYY-MM is an acceptable format, nor any consensus that it is an unacceptable format. I would recommend against any mass changes being made purely on the basis of this RfC."
Based on this reasonably-attended RFC, despite the lack of consensus, it appears that the CS1 module's date-checking code should stop flagging YYYY-MM as an invalid date format. Thoughts? – Jonesey95 ( talk) 00:48, 3 April 2014 (UTC)
The recent (29 Nov 2013) banning of the yyyy-mm format ...which apparently arises from this conversation and this change to the table at WP:BADDATEFORMAT.
remove YYYY-MM from the Unacceptable list, which would would leave us in a state different from that which existed at the initiation of the RfC. If you are looking to undo this change to the table at WP:BADDATEFORMAT, then I think that Module talk:Citation/CS1 is the wrong forum.
|mr=
This is pretty esoteric, so it's OK if it goes onto the Feature Requests list, but I think we can validate |mr=
. I haven't found a spec for the number, but it appears to be seven numeric digits, optionally preceded by "MR".
We might want to consult with Wikipedia_talk:WikiProject_Mathematics about the preferred formatting for this link in the citation templates. We could show it as "MR1234567" or "MR MR1234567" or "MR 1234567". We show one of the latter two now, depending on whether someone puts "MR" in the value of the parameter. The first "MR" is linked to Mathematical Reviews. The number is linked to the cited source at mathscinet.org.
The article Uniform module contains links to a number of MR citations (some of them recently fixed so that they link to the right cited source). I haven't played around with case sensitivity, spaces, or other formatting to see how good the mathscinet.org processor is at handling what you throw at it. – Jonesey95 ( talk) 23:49, 8 April 2014 (UTC)
{{
citation}}
: Check |mr=
value (
help)OK, it's an edge case, but it looks like a tiny little bug that may be manifesting itself in other situations.
Cite book with only period in |title=
makes everything after it bold and adds a single quote mark before the title. Something about the wikimarkup difference between using single quotes for bold and using single quotes for italics, perhaps.
Wikitext | {{cite book
|
---|---|
Live | Author (2001). p. 3. {{
cite book}} : |author= has generic name (
help)
|
Sandbox | Author (2001). p. 3. {{
cite book}} : |author= has generic name (
help)
|
Using |url=
makes the problem go away.
Wikitext | {{cite book
|
---|---|
Live | Author (2001). p. 3
http://www.example.com. {{
cite book}} : |author= has generic name (
help); |url= missing title (
help)
|
Sandbox | Author (2001). p. 3
http://www.example.com. {{
cite book}} : |author= has generic name (
help); |url= missing title (
help)
|
|title=.
? --
Redrose64 (
talk)
16:13, 11 April 2014 (UTC)safejoin()
. Change to |title=;
and |separator=;
and the same thing occurs:
|url=
fix 'works' because the last character in the title string is not the separator but is the closing
of the assembled external link: [http://www.example.com ''.'']
. You can see in your second example that there is a linked period followed by an unlinked period.Would it be possible to make |lang=
an alias for |language=
?
It Is Me Here
t /
c
11:33, 13 April 2014 (UTC)
|language=
is clear, straightforward, and unambiguous. |lang=
is an abbreviation that is not as clear. I believe that we generally avoid abbreviations for parameter names or aliases, except where the full name of the parameter would be absurdly long, e.g. |internationalstandardbooknumber=
. –
Jonesey95 (
talk)
04:25, 14 April 2014 (UTC)
I just noticed that {{ PDFlink}} is being merged into CS1 as of May 2013. I don't recall the discussion. -- Gadget850 talk 19:57, 14 April 2014 (UTC)
|formatsize=
is required in order to eliminate the template, nor is it clear to me that there is a CITEVAR-friendly path from instances of PDFlink to CS1 citations in all or even most cases. The mechanics of how to make the transition, showing how existing instances of the template would be converted, were not explored thoroughly. –
Jonesey95 (
talk)
20:33, 14 April 2014 (UTC)hi what about removing /sandbox from
--local cfg = mw.loadData( 'Module:Citation/CS1/Configuration/sandbox' );
and
--local whitelist = mw.loadData( 'Module:Citation/CS1/Whitelist/sandbox' );
please
86.173.55.186 ( talk) 14:53, 21 April 2014 (UTC)
In about a week's time I intend to update these files from their respective sandboxes:
The update makes these changes to Module:Citation/CS1:
to Module:Citation/CS1/Configuration:
to Module:Citation/CS1/Whitelist:
— Trappist the monk ( talk) 11:54, 25 March 2014 (UTC)
Corrected item 5 for Module:Citation/CS1 to read: Added support for |postscript=none;
— Trappist the monk ( talk) 12:53, 25 March 2014 (UTC)
I do not agree that WP:MOS or WP:MOSNUM control date formats in citations (although Wikipedia talk:Manual of Style/Archive 128#Which guideline for citation style? shows there is no consensus about this).But here you are invoking WP:MOS#Months to support your argument that Sept. and Feb. should be allowed in CS1 citations.
There is no clear consensuslink above, points to Module_talk:Citation/CS1/sandbox#Invalid_year_doesn.27t_generate_error. Was that what you intended?
section | compliant | comment |
---|---|---|
Acceptable date formats table | yes | Exceptions: linked dates not supported; sortable dates not supported ( {{
dts}} etc);proper name dates not supported; |
Unacceptable date formats table | yes | |
Consistency | no | article level restriction beyond the scope of CS1 |
Strong national ties to a topic | no | |
Retaining existing format | no | |
Era style | no | dates eariler than 100 not supported; |
Julian and Gregorian calendars | limited | Module:Citation/CS1 cannot know if a date is Julian or Gregorian; assumes Gregorian |
Ranges | yes | Exceptions: does not support the use of – or does not support dates prior to 100; does not support solidus separator (/) does not support " to " as a date separator; |
Uncertain, incomplete, or approximate dates | yes | Exceptions: does not support {{
circa}} or {{
floruit}} ;does not support dates prior to 100; |
Days of the week | no | |
Months | yes | Exceptions: shortened month names longer than three characters or with terminating periods are not supported in keeping with the Acceptable date formats table; |
Seasons | no | seasons are treated as if they were months so must be capitalized; |
Decades | no | |
Centuries and millennia | no | |
Abbreviations for long periods of time | no |
|date=
|accessdate=
and |archivedate=
), whereas a lot more space can be saved by other means: using initials instead of author's first names; by the use of |displayauthors=
; by judicious use of |location=
and |publisher=
; by the non-use of |quote=
- there are several other ways of reducing the length of a ref, which can easily achieve a saving of more than 18 characters. --
Redrose64 (
talk)
19:49, 25 March 2014 (UTC)|date=31 December 1999
(or |date=December 31, 1999
if you really have to) for publication dates, and |archivedate=1999-12-31
and |accessdate=1999-12-31
for archive and access dates. This visually separates the publication date from other dates which are relevant only within Wikipedia. --
79.67.241.76 (
talk)
14:55, 28 March 2014 (UTC)HTML entity: – does not seem to be supported in date ranges. Example:
Jc3s5h ( talk) 18:43, 25 March 2014 (UTC)
{{
ndash}}
. Also, {{
cite journal/sandbox}}
invokes the live module, not the sandbox version as you might expect. I don't know what the IP editor who made that change had in mind. Use {{
cite journal/new}}
:
So far, I haven't seen any objections to the changes listed in the original list above, only objections to the current operation of the module code. It might be better to split the above discussion into sections with appropriate titles. I can try to do that in an NPOV manner unless there are objections. If there are objections, I will leave the discussion as is and will not be offended.
The only note I see above that may be read as an objection to the list is in reference to the date checking. Trappist the monk may have been overly concise in item 7 on the first list, which might be clearer if it read something like "Expand date validation; all acceptable date formats in the table at WP:DATESNO should now be supported, along with most ranges listed at WP:DATERANGE (see exceptions)" – Jonesey95 ( talk) 20:55, 25 March 2014 (UTC)
I found this attempt at |issn=
in the wild, and it did not cause a citation error:
{{cite journal | author=Moraes KCM, Quaresma AJ, Kobarg, J |title= Identification and characterization of proteins that selectively interact with isoforms of the mRNA binding protein AUF1 (hnRNP D) |journal=BIOLOGICAL CHEMISTRY |volume=384 |issue= 1 |pages= 25–37 |year= 2003 |pmid= 12674497 | ISSN: 1431-6730 pmc= |doi=10.1515/BC.2003.004}}
{{
cite journal}}
: Cite has empty unknown parameter: |ISSN: 1431-6730 pmc=
(
help)CS1 maint: multiple names: authors list (
link)Look specifically at the attempted ISSN parameter. Is there no error because there is nothing following the "=", and parameters with blank values are ignored?
I fixed this one, but I thought I'd drop this example here to offer some food for thought. There's a lot of craziness out there. – Jonesey95 ( talk) 23:40, 21 April 2014 (UTC)
This date range is marked as invalid. It is from 1999 in archaeology.
Baker, Dorie (December 13, 1999 – January 17, 2000). "Finding sheds new light on the alphabet's origins". Yale Bulletin and Calendar. 28 (16). Retrieved 2012-03-16.
Can anyone help turn it into a valid date range? It looks to me like it matches MOSDATE. I checked the source, and the date range matches that of the source. – Jonesey95 ( talk) 04:17, 24 April 2014 (UTC)
'"`UNIQ--templatestyles-00000052-QINU`"'<cite class="citation book cs1">''Title''. 13 December 1999 – 17 January 2000a.</cite><span title="ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Abook&rft.genre=book&rft.btitle=Title&rft.date=1999-12-13%2F2000-01-17&rfr_id=info%3Asid%2Fen.wikipedia.org%3AModule+talk%3ACitation%2FCS1%2FArchive+10" class="Z3988"></span> <span class="cs1-visible-error citation-comment"><code class="cs1-code">{{[[Template:cite book|cite book]]}}</code>: </span><span class="cs1-visible-error citation-comment">Invalid <code class="cs1-code">|ref=harv</code> ([[Help:CS1 errors#invalid_param_val|help]])</span>
{{
cite book}}
: Check date values in: |date=
(
help)'"`UNIQ--templatestyles-00000056-QINU`"'<cite class="citation book cs1">''Title''. December 13, 1999 – January 17, 2000a.</cite><span title="ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Abook&rft.genre=book&rft.btitle=Title&rft.date=1999-12-13%2F2000-01-17&rfr_id=info%3Asid%2Fen.wikipedia.org%3AModule+talk%3ACitation%2FCS1%2FArchive+10" class="Z3988"></span> <span class="cs1-visible-error citation-comment"><code class="cs1-code">{{[[Template:cite book|cite book]]}}</code>: </span><span class="cs1-visible-error citation-comment">Invalid <code class="cs1-code">|ref=harv</code> ([[Help:CS1 errors#invalid_param_val|help]])</span>
{{
cite book}}
: Check date values in: |date=
(
help)We have a parameter, |ol=
which displays in the citation and links to the
Open Library. Currently the link prefixes a "OL" to the value of the parameter and an "OL" is displayed to identify that this is an OLID:
{{cite book |last=Last |first=First |title=Title |ol = 1135607M }}
Last, First. Title.
OL
1135607M.
However, in their
listing pages the Open Library lists their identifiers already including the "OL" prefix (e.g. "OL1135607M"). It would be normal for an editor to expect to be able to copy and paste the identifier from the Open Library page into the citation template:
{{cite book |last=Last |first=First |title=Title |ol = OL1135607M }}
Last, First. Title.
OL
1135607M.
Unfortunately, this does not currently work. The link is non-functional. In addition, no indication is given to the editor that there is a problem. In order to determine that there is an issue, the editor has to examine or test the link.
The "OL" in the ID appears to actually be a part of the ID. While I have not found an actual spec for the ID, looking at their API implies that the OL is part of the ID. We have been enforcing, by not linking properly with the "OL" present, not entering the "OL" in the |ol=
. That means that we can not suddenly switch to requiring it. We need to accept |ol=
both with and without "OL" as the first two characters.
At a minimum, we should change the module such that it does not add an additional "OL" to the link if one already exists in the provided OLID.
As to the visual aspect: While I do not find it visually appealing, having it appear as "OL OL1135607M" is consistent with the format which we have adopted of having a descriptor prior to each ID and displays the complete OLID.
The result of this is that that |ol=
parameters should be processed prior to both linking and display to add an OL to the |ol=
value if an "OL" does not already exist as the first two characters of the parameter value. —
Makyen (
talk)
06:11, 16 May 2014 (UTC)
I was wondering if it could be possible to make the subscription required message a little bit prettier. Right now it has a double parentheses: "(subscription required (help))", and the "help" shows a tooltip. Couldn't the whole "(help)" just be removed and the tooltip applied to the whole message instead? -- Atethnekos ( Discussion, Contributions) 17:04, 20 May 2014 (UTC)
If I'm understanding this correctly.... If the parameter is ISBN=, the module will not check the ISBN number for errors. Should the 4,964 articles that contain | isbn =
be converted via a bot to | isbn =
? Amount of articles obtained from April's dump.
Bgwhite (
talk)
07:16, 27 April 2014 (UTC)
|id=
it is not completely checked for format, but is linked if it does not fail some course format checking. If it is 13 digits and starts with 978 or 979 it is linked (e.g.
ISBN
9781234567890 Parameter error in {{
ISBN}}: checksum), but is not linked if it does not start with those digits (e.g. ISBN 9801234567890). If it is 10 digits (with X as a possible 10th character) it is linked (e.g.
ISBN
123456789X). If it is not 10 or 13 digits it is not linked (e.g. ISBN 12345678901). [NOTE: I have not looked at the code for this which is part of MediaWiki, not the citation templates.]|id=
into |isbn=
. In many cases |id=
was used because |isdn=
is already occupied and would generate an error if it contained more than one ISBN. In addition, if the editor desired to have additional text prior to, or after, the ISBN then it may have been placed in |id=
for that reason. The |isbn=
parameter accepts nothing other than a strictly formatted ISBN with no other text permitted. If the |isbn=
is already occupied, then obviously an additional ISBN should not be moved out of |id=
into |isbn=
. If there is additional text in |id=
then it is a contextual edit where human editorial judgement should be applied and should not be performed by bot.|isbn=
does not exist and an ISBN is in |id=
without additional text – other than "ISBN" – then yes it should be moved into |isbn=
. The contents of |id=
are not included in the COinS data, but |isbn=
is – NOTE: This is contrary to the documentation stating that "any of the identifiers" are included in the COinS data. However, |isbn=
is included in the COinS without any format corrections, which, I assume, is why it has been programmed to generate an error if the value is not strictly compliant as an ISBN (i.e. no other characters are tolerated).|isbn=
parameter. We could easily strip out all non-numeric characters prior to performing the ISBN format/check-digit verifications and passing that stripped version in the COinS. This would result in fewer errors, both for our editors and in the COinS data at the cost of a single regular expression substitution. In effect we would be permitting additional non-numeric text in the |isbn=
value. If desired, the regular expression could also strip a preceding "1[03]:" as that sequence is somewhat commonly used by editors, for some reason, to indicate that it is a 10, or 13 digit ISBN. —
Makyen (
talk)
08:42, 27 April 2014 (UTC)
|isbn=
value. We should continue to do so.|isbn=
or by moving a second ISBN into the |isbn=
where it will be an error when an editor has already placed the second ISBN in |id=
where it does not create an error. I made no comment about the editorial choice to have multiple ISBNs in the citation, only that the bot should be programed to not create errors in the citation when it comes across some situations that are known to exist. —
Makyen (
talk)
13:57, 27 April 2014 (UTC)|type=
is the proper parameter for your examples "{paperback}", "(pbk)", "(hardback)", "(hdb)" – without the brackets.|type=
being most appropriate. When making these changes I have no history on the page, and no knowledge of any possible agreement about format. In my opinion, changes to correct citation errors should remain as close to the original editors intent as possible. Thus, for many cases I feel that it is more important to retain the intent of the original editor rather than use the "correct" parameter |type=
.{{
cite book}}
: Check |isbn=
value: invalid character (
help); Unknown parameter |editors=
ignored (|editor=
suggested) (
help)|type=
and |id=
(location of "Print" disassociates it from the ISBN):
{{
cite book}}
: More than one of |ISBN=
and |isbn=
specified (
help); Unknown parameter |editors=
ignored (|editor=
suggested) (
help)|id=
:
{{
cite book}}
: Unknown parameter |editors=
ignored (|editor=
suggested) (
help)|type=
is closer to what the original editor intended.{{
cite book}}
: External link in |series=
(
help)|type=
doesn't work so well in your example, not because |type=
is wrong but because the original editor is wrong. The CS1 templates are designed to provide information about a single source. Here, the editor is trying to cite two versions of the same source in a single template. We should be glad that he didn't want to include the softcover version as well (
ISBN
978-1-4757-8801-3). Perhaps the better solution to the multiple isbn problem is to choose one to use in the template and include the other(s) parenthetically outside the template. This at least avoids the error, includes an isbn in the
COinS metadata, and still keeps the rest available:|url=
, |chapter-url=
, |pages=
, and removed the external link from |series=
. |doi=
gets the reader to the same place as |chapter-url=
where all you get is a sample of the table of contents and part of the introduction teaser as part of the publisher's effort to sell you a copy of the book; |url=
and the external link in |series=
is more selling. There is no point in listing a chapter and all of the pages that make up the chapter; that does nothing to help a reader find the cited information.
id = ISBN
should not be changed wholesale to ISBN =
, for the reasons noted above. I think it would be reasonable for an editor using AWB to convert instances of id = ISBN
that contain plain ISBNs with no extraneous text, in citations where an ISBN is not present.
Some data: I have fixed about 3,000 of the 8,000 articles in Category:Pages with ISBN errors using an AutoEd script in the past couple of months. I have about 2,500 more articles to examine. The script has been able to fix about 60% of the articles I have examined. The most common fixable error, by far, is two ISBNs separated by a comma. These two ISBNs are usually the 10-digit ISBN followed by the 13-digit ISBN.
As for extra text, the examples given above are often present. Sometimes a "printing" or "edition" is present, though it is almost always redundant with |year=
. Sometimes multiple volumes, each with its own ISBN, are specified; I don't touch those.
When I am done going through the category, I expect there to be about 2,500 articles left. The large majority of those errors will be legitimate errors: ISBNs with too few or too many numbers. There will be somewhere under 1,000 "low-hanging fruit" still left, primarily ASINs, multiple ISBNs that were too strange or ambiguous for my scripting skills to handle, ISSNs, publisher names, and other easy fixes. After those are fixed, I expect we'll have under 2,000 actual ISBN problems to track down.
Anyone who would like to contribute to clearing out this category is welcome to do so. I recommend starting at the end of the alphabet, since the remaining articles that my script hasn't touched are in the A–N portion of the alphabet (I've been working my way from Z to A). – Jonesey95 ( talk) 17:39, 27 April 2014 (UTC)
|isbn=
into |isbn=
and |id=
until
Redrose64
commented that a large number of them were just both the 10 and 13 digit ISBN for the same book and expressed a belief that the 10 digit one should be removed. I don't agree that there is consensus for us to wholesale override the choice of editors to put both a 10 and 13 digit ISBN into the citation. I fully agree that it is not needed, and would not do so myself. I just don't think that there is a wide enough consensus for us to remove them from thousands of articles. I have not been splitting them wholesale since that point. My intent was to go back through once it was clearer as to how to handle them. I also have not translated the code I wrote for a different purpose which decodes/formats/checks ISBNs from JavaScript to what is needed for AWB (which is the tool I use). Something which actually compares the two and verifies that they are 10/13 duplicates would be needed.|isbn=
parameter this might be sufficiently specific. On the other hand it might not. You might want to consider adding/changing your regular expressions to more specifically limit them to only being within citation templates. I use the following (or a variation upon):
({{\s*[cC]it[ea](?:[^}{]*(?:\{\{[^}{]*}}[^}{]*)*)\|\s*)isbn(\s*=\s*)
|isbn=
in the citation this will match the one furthest from the {{\s*[Cc]it[ae]
.B0[0-9A-Za-z]{8}
can safely be considered an ASIN even when not explicitly stated as an "ASIN". However, I have been actually clicking on the links created to verify the fact that is is an ASIN and is valid. I have not found a formal specification for ASIN numbers, but aside from those which are also ISBNs, that format has fit the ones I have seen. —
Makyen (
talk)
23:58, 27 April 2014 (UTC)
B0[0-9A-Za-z]{8}
as indicating an ASIN. I just encountered 4 on a page. Three of them were invalid as ASINs. Although, I have not previously encountered ones which turned up invalid when changed to |asin=
based on that criteria.—
Makyen (
talk)
00:07, 28 April 2014 (UTC)
|isbn=
is not appropriate, but neither is removing all but one ISBN. Using |id=
or putting the ISBNs outside of the citation template might work; I haven't given it enough thought yet, since I've been working on the easy fixes. –
Jonesey95 (
talk)
01:17, 28 April 2014 (UTC)
Would it be feasible to have multiple instances of {{{isbn}}}, each associated with a {{{type}}}?
For example, the above example could be converted to
{{cite book |chapter=Fifty Years of the Shell Model — The Quest for the Effective Interaction |date=2003 |publisher=[[Springer-Verlag]] |doi=10.1007/0-306-47916-8_1 |title=Advances in Nuclear Physics |volume=27 |first=Igal |last=Talmi |editor1-first=J. W. |editor1-last=Negele |editor2-first=E. W. |editor2-last=Vogt |isbn1 = 978-0-306-47708-9 |type1=hardback |issn=0065-2970 |series = Advances in the Physics of Particles and Nuclei (APPN)|isbn2 = 978-0-306-47916-8 | type2 = Online | isbn3 = 978-1-4757-8801-3 | type3 = softcover}}
We would default to {{{isbn1}}} or simply {{{isbn}}} for generating
COinS metadata, just like at present.
HTH HAND —
Phil |
Talk
17:40, 15 May 2014 (UTC)
|id=
is used, but that should be an exception, not a rule. If we were going to start listing all of the different identifiers for every edition/version of a book, as
Redrose64 said "where would it stop?" As an example: a reference on which I was attempting to fix the ISBN earlier today was citing Magic and Mystery in Tibet. Should we be listing identifiers for all of the
60 versions listed in WorldCat?|id=
parameter can be used for this purpose and as long as the text "ISBN" precedes a valid format ISBN it will be linked to
Special:BookSources by the MediaWiki software. (see
Help:Magic links)
|isbn=
parameter. Removing everything other than digits is trivial.If I'm understanding this correctly.... If the parameter is ISBN=, the module will not check the ISBN number for errors. Should the 4,964 articles that contain | isbn =
be converted via a bot to | isbn =
? Amount of articles obtained from April's dump.
Bgwhite (
talk)
07:16, 27 April 2014 (UTC)
|id=
it is not completely checked for format, but is linked if it does not fail some course format checking. If it is 13 digits and starts with 978 or 979 it is linked (e.g.
ISBN
9781234567890 Parameter error in {{
ISBN}}: checksum), but is not linked if it does not start with those digits (e.g. ISBN 9801234567890). If it is 10 digits (with X as a possible 10th character) it is linked (e.g.
ISBN
123456789X). If it is not 10 or 13 digits it is not linked (e.g. ISBN 12345678901). [NOTE: I have not looked at the code for this which is part of MediaWiki, not the citation templates.]|id=
into |isbn=
. In many cases |id=
was used because |isdn=
is already occupied and would generate an error if it contained more than one ISBN. In addition, if the editor desired to have additional text prior to, or after, the ISBN then it may have been placed in |id=
for that reason. The |isbn=
parameter accepts nothing other than a strictly formatted ISBN with no other text permitted. If the |isbn=
is already occupied, then obviously an additional ISBN should not be moved out of |id=
into |isbn=
. If there is additional text in |id=
then it is a contextual edit where human editorial judgement should be applied and should not be performed by bot.|isbn=
does not exist and an ISBN is in |id=
without additional text – other than "ISBN" – then yes it should be moved into |isbn=
. The contents of |id=
are not included in the COinS data, but |isbn=
is – NOTE: This is contrary to the documentation stating that "any of the identifiers" are included in the COinS data. However, |isbn=
is included in the COinS without any format corrections, which, I assume, is why it has been programmed to generate an error if the value is not strictly compliant as an ISBN (i.e. no other characters are tolerated).|isbn=
parameter. We could easily strip out all non-numeric characters prior to performing the ISBN format/check-digit verifications and passing that stripped version in the COinS. This would result in fewer errors, both for our editors and in the COinS data at the cost of a single regular expression substitution. In effect we would be permitting additional non-numeric text in the |isbn=
value. If desired, the regular expression could also strip a preceding "1[03]:" as that sequence is somewhat commonly used by editors, for some reason, to indicate that it is a 10, or 13 digit ISBN. —
Makyen (
talk)
08:42, 27 April 2014 (UTC)
|isbn=
value. We should continue to do so.|isbn=
or by moving a second ISBN into the |isbn=
where it will be an error when an editor has already placed the second ISBN in |id=
where it does not create an error. I made no comment about the editorial choice to have multiple ISBNs in the citation, only that the bot should be programed to not create errors in the citation when it comes across some situations that are known to exist. —
Makyen (
talk)
13:57, 27 April 2014 (UTC)|type=
is the proper parameter for your examples "{paperback}", "(pbk)", "(hardback)", "(hdb)" – without the brackets.|type=
being most appropriate. When making these changes I have no history on the page, and no knowledge of any possible agreement about format. In my opinion, changes to correct citation errors should remain as close to the original editors intent as possible. Thus, for many cases I feel that it is more important to retain the intent of the original editor rather than use the "correct" parameter |type=
.{{
cite book}}
: Check |isbn=
value: invalid character (
help); Unknown parameter |editors=
ignored (|editor=
suggested) (
help)|type=
and |id=
(location of "Print" disassociates it from the ISBN):
{{
cite book}}
: More than one of |ISBN=
and |isbn=
specified (
help); Unknown parameter |editors=
ignored (|editor=
suggested) (
help)|id=
:
{{
cite book}}
: Unknown parameter |editors=
ignored (|editor=
suggested) (
help)|type=
is closer to what the original editor intended.{{
cite book}}
: External link in |series=
(
help)|type=
doesn't work so well in your example, not because |type=
is wrong but because the original editor is wrong. The CS1 templates are designed to provide information about a single source. Here, the editor is trying to cite two versions of the same source in a single template. We should be glad that he didn't want to include the softcover version as well (
ISBN
978-1-4757-8801-3). Perhaps the better solution to the multiple isbn problem is to choose one to use in the template and include the other(s) parenthetically outside the template. This at least avoids the error, includes an isbn in the
COinS metadata, and still keeps the rest available:|url=
, |chapter-url=
, |pages=
, and removed the external link from |series=
. |doi=
gets the reader to the same place as |chapter-url=
where all you get is a sample of the table of contents and part of the introduction teaser as part of the publisher's effort to sell you a copy of the book; |url=
and the external link in |series=
is more selling. There is no point in listing a chapter and all of the pages that make up the chapter; that does nothing to help a reader find the cited information.
id = ISBN
should not be changed wholesale to ISBN =
, for the reasons noted above. I think it would be reasonable for an editor using AWB to convert instances of id = ISBN
that contain plain ISBNs with no extraneous text, in citations where an ISBN is not present.
Some data: I have fixed about 3,000 of the 8,000 articles in Category:Pages with ISBN errors using an AutoEd script in the past couple of months. I have about 2,500 more articles to examine. The script has been able to fix about 60% of the articles I have examined. The most common fixable error, by far, is two ISBNs separated by a comma. These two ISBNs are usually the 10-digit ISBN followed by the 13-digit ISBN.
As for extra text, the examples given above are often present. Sometimes a "printing" or "edition" is present, though it is almost always redundant with |year=
. Sometimes multiple volumes, each with its own ISBN, are specified; I don't touch those.
When I am done going through the category, I expect there to be about 2,500 articles left. The large majority of those errors will be legitimate errors: ISBNs with too few or too many numbers. There will be somewhere under 1,000 "low-hanging fruit" still left, primarily ASINs, multiple ISBNs that were too strange or ambiguous for my scripting skills to handle, ISSNs, publisher names, and other easy fixes. After those are fixed, I expect we'll have under 2,000 actual ISBN problems to track down.
Anyone who would like to contribute to clearing out this category is welcome to do so. I recommend starting at the end of the alphabet, since the remaining articles that my script hasn't touched are in the A–N portion of the alphabet (I've been working my way from Z to A). – Jonesey95 ( talk) 17:39, 27 April 2014 (UTC)
|isbn=
into |isbn=
and |id=
until
Redrose64
commented that a large number of them were just both the 10 and 13 digit ISBN for the same book and expressed a belief that the 10 digit one should be removed. I don't agree that there is consensus for us to wholesale override the choice of editors to put both a 10 and 13 digit ISBN into the citation. I fully agree that it is not needed, and would not do so myself. I just don't think that there is a wide enough consensus for us to remove them from thousands of articles. I have not been splitting them wholesale since that point. My intent was to go back through once it was clearer as to how to handle them. I also have not translated the code I wrote for a different purpose which decodes/formats/checks ISBNs from JavaScript to what is needed for AWB (which is the tool I use). Something which actually compares the two and verifies that they are 10/13 duplicates would be needed.|isbn=
parameter this might be sufficiently specific. On the other hand it might not. You might want to consider adding/changing your regular expressions to more specifically limit them to only being within citation templates. I use the following (or a variation upon):
({{\s*[cC]it[ea](?:[^}{]*(?:\{\{[^}{]*}}[^}{]*)*)\|\s*)isbn(\s*=\s*)
|isbn=
in the citation this will match the one furthest from the {{\s*[Cc]it[ae]
.B0[0-9A-Za-z]{8}
can safely be considered an ASIN even when not explicitly stated as an "ASIN". However, I have been actually clicking on the links created to verify the fact that is is an ASIN and is valid. I have not found a formal specification for ASIN numbers, but aside from those which are also ISBNs, that format has fit the ones I have seen. —
Makyen (
talk)
23:58, 27 April 2014 (UTC)
B0[0-9A-Za-z]{8}
as indicating an ASIN. I just encountered 4 on a page. Three of them were invalid as ASINs. Although, I have not previously encountered ones which turned up invalid when changed to |asin=
based on that criteria.—
Makyen (
talk)
00:07, 28 April 2014 (UTC)
|isbn=
is not appropriate, but neither is removing all but one ISBN. Using |id=
or putting the ISBNs outside of the citation template might work; I haven't given it enough thought yet, since I've been working on the easy fixes. –
Jonesey95 (
talk)
01:17, 28 April 2014 (UTC)
Would it be feasible to have multiple instances of {{{isbn}}}, each associated with a {{{type}}}?
For example, the above example could be converted to
{{cite book |chapter=Fifty Years of the Shell Model — The Quest for the Effective Interaction |date=2003 |publisher=[[Springer-Verlag]] |doi=10.1007/0-306-47916-8_1 |title=Advances in Nuclear Physics |volume=27 |first=Igal |last=Talmi |editor1-first=J. W. |editor1-last=Negele |editor2-first=E. W. |editor2-last=Vogt |isbn1 = 978-0-306-47708-9 |type1=hardback |issn=0065-2970 |series = Advances in the Physics of Particles and Nuclei (APPN)|isbn2 = 978-0-306-47916-8 | type2 = Online | isbn3 = 978-1-4757-8801-3 | type3 = softcover}}
We would default to {{{isbn1}}} or simply {{{isbn}}} for generating
COinS metadata, just like at present.
HTH HAND —
Phil |
Talk
17:40, 15 May 2014 (UTC)
|id=
is used, but that should be an exception, not a rule. If we were going to start listing all of the different identifiers for every edition/version of a book, as
Redrose64 said "where would it stop?" As an example: a reference on which I was attempting to fix the ISBN earlier today was citing Magic and Mystery in Tibet. Should we be listing identifiers for all of the
60 versions listed in WorldCat?|id=
parameter can be used for this purpose and as long as the text "ISBN" precedes a valid format ISBN it will be linked to
Special:BookSources by the MediaWiki software. (see
Help:Magic links)
|isbn=
parameter. Removing everything other than digits is trivial.|website=
is listed on the Whitelist; however, if used in conjunction with |archiveurl=
, it generates an error message:
{{cite book |archiveurl=//www.web.archive.org |archivedate=May 15, 2014 |deadurl=no |author=Johnson, Malcom |title=Sample Title |website=http://www.example.com}}
If |url=
is populated, the error is resolved, but a bare url displays in the citation. (This is also what happens if |archiveurl=
isn't populated.)
{{cite book |url=http://www.example.com |archiveurl=//www.web.archive.org |archivedate=May 15, 2014 |deadurl=no |author=Johnson, Malcom |title=Sample Title |website=http://www.example.com}}
{{
cite book}}
: |website=
ignored (
help); External link in |website=
(
help); Unknown parameter |deadurl=
ignored (|url-status=
suggested) (
help)Is this the desired behavior of this parameter, or is it a glitch? I would think that |website=
is an alias of |url=
; the
AWB renaming script currently replaces it with |url=
. Should it continue to do so? Or is this a glitch that will be fixed? I'm about to post a lengthy list of valid alias parameters that the script is currently replacing on that
talk page; if the script shouldn't continue to replace |website=
with |url=
, please be sure to comment there. Thanks!—
D'Ranged 1
VTalk
00:14, 28 May 2014 (UTC)
|website=
is an alias of |work=
, for the name of a website, not the address.
Imzadi 1979
→
00:17, 28 May 2014 (UTC)
|website=
with |work=
, which is unnecessary. Sorry I was confused; I've straightened it out over there. Thanks again!—
D'Ranged 1
VTalkThese parameters are not on the Whitelist, but are used successfully in templates.
|eprint=
in {{
cite arXiv}}; a valid alias for |arxiv=
, which is required.|class=
in {{
cite arXiv}}; optional|pmc-embargo-date=
in {{
arxiv}} coding; however, it doesn't appear in the documentation. Possibly an alias for |embargo=
on the Whitelist.I thought this was supposed to be a current, complete listing of all approved parameters for the templates. If it isn't, one is needed. I've made changes to the list of parameters for Citation bot based on this list in an attempt to avoid the bot making errors; I now have to undo some of those changes.— D'Ranged 1 VTalk 16:58, 30 May 2014 (UTC)
|eprint=
is not used in any of those cite templates.|eprint=
may need to be added to the Whitelist. There is a list of cite templates that use the module at
Help:Citation Style 1; they are highlighted in light green in the left column. –
Jonesey95 (
talk)
19:25, 30 May 2014 (UTC)
{{
Cite arXiv}}
is essentially a special case of {{
cite journal}}
, where some of the parameters (like |journal=
|work=
and |publisher=
) put the page into an error category, and a few extra parameters are recognised. These, |eprint=
(and its alias |arxiv=
), |version=
and |class=
are used to construct special links. To cope with these variations, it still uses the older {{
Citation/core}}
method instead of
Module:Citation/CS1. --
Redrose64 (
talk)
21:39, 30 May 2014 (UTC)Could there be a check on the author field to detect when it contains date type information, such as |author=Published on Mon May 19 14:30:16 BST 2008
, that occurs in numerous articles. Probably need to add a tracking category when this occurs so that they can be fixed by removal or transferring information to the |date=
field. Regards.
Keith D (
talk)
00:46, 20 June 2014 (UTC)
|title=
parameter - usually separated by an HTML entity for a hyphen, dash or suchlike.
Andy Mabbett (Pigsonthewing);
Talk to Andy;
Andy's edits
11:02, 20 June 2014 (UTC)
|title=
parameter.
GoingBatty (
talk)
16:47, 20 June 2014 (UTC)|date=
field before removing.
Keith D (
talk)
23:18, 22 June 2014 (UTC)
|date=
field.
GoingBatty (
talk)
02:22, 23 June 2014 (UTC)
![]() | This
edit request has been answered. Set the |answered= or |ans= parameter to no to reactivate your request. |
doix
is used in {{
Cite doi/preload}} to prefill a version of the DOI that the citation bot fixes up; it then changes doix
to doi
. doix
was
added to the whitelist but subsequently
removed in an update from the sandbox. I think that was unintentional. Would an administrator please add doix
back into
Module:Citation/CS1/Whitelist, maybe with a comment to keep it from disappearing again? Thank you.
– Minh Nguyễn ( talk, contribs) 21:55, 6 July 2014 (UTC)
|doix=
should be included in
Module:Citation/CS1/Whitelist. I think that including parameters that have nothing to do with CS1 blurs a very distinct line that should not be blurred. Without some discussion that shows that |doix=
must be included, I'm not ready to accommodate this request.|doix=
is an unsupported parameter used temporarily by Citation Bot, I believe. The bot removes it during creation of cite doi templates. The bot is currently blocked, which is why you are seeing |doix=
. It should never be seen by a human editor under normal circumstances. –
Jonesey95 (
talk)
23:12, 6 July 2014 (UTC)doix
to doi
, but without decoding the .2F
escape, the link was broken. I went ahead and reimplemented the conversion from doix
to doi
in
Module:Cite doi. Let me know if you see any bugs. –
Minh Nguyễn (
talk,
contribs)
23:17, 6 July 2014 (UTC)The module apparently checks that season names are spelled Spring, Summer, Fall (or Autumn), or Winter. But season names are not capitalized (look them up in, for example, American Heritage Dictionary 3rd. ed.) Jc3s5h ( talk) 05:29, 26 August 2014 (UTC)
|date=
or |issue=
field.{{
cite journal}}
: Check date values in: |date=
(
help)In the list of identifiers, PMID is one result that usually (if not always) results in a free full text of the citation. I'm not a programmer so I'm suggesting this in the form of a logical sentence: if 'url'="null" and PMID is valid (not flag "bad pmid") then set 'URL' can be set to PMID-url. It looks like this could be built into function 'buildlist'. ~
Technophant (
talk)
14:04, 28 August 2014 (UTC)
|pmid=
parameter is present, then one link is already there. I don't see a particular advantage of creating a redundant link from the citation's title.
Boghog (
talk)
14:18, 28 August 2014 (UTC)|pmc=
parameter already does exactly what you want to do.
PubMed Central by definition does contain the free full text. In addition, if |pmc=
is present and |url=
is empty, then the citation's title is automatically linked.
Boghog (
talk)
14:45, 28 August 2014 (UTC)|pmc=
is present, then the title should be linked because pmc provides full free text.
Boghog (
talk)
06:17, 29 August 2014 (UTC)Could some form of check be made on title fields that include a URL? The URL is usually at the end of the title after something like "Read more". May be these could be categorised and a BOT set-up to remove this clutter. Thanks. Keith D ( talk) 01:36, 8 September 2014 (UTC)
|title=
parameter, you sometimes find that you've copied more than you intended. Among the extra text is often "Read more:" and a URL. I always delete the unintended extras, but there must be people who either didn't notice, or didn't realise that it was not part of what we want in a |title=
--
Redrose64 (
talk)
14:09, 8 September 2014 (UTC)|title=
parameter's value?Would it be possible to change, at
/Configuration, the |zbl=
URL from
http://www.zentralblatt-math.org to
https://zbmath.org? E.g. for me,
http://www.zentralblatt-math.org/zmath/en/search/?format=complete&q=an:1177.37036 redirects to
https://zbmath.org/?format=complete&q=an:1177.37036.
It Is Me Here
t /
c
11:46, 4 September 2014 (UTC)
|jfm=
parameter also redirect. --
Gadget850
talk
13:51, 9 September 2014 (UTC)Ok. Done in the sandbox.
{{
cite book}}
: Check |jfm=
value (
help)— Trappist the monk ( talk) 12:37, 13 September 2014 (UTC)
{{
jfm}}
and {{
zbl}}
templates also updated.
— Trappist the monk ( talk) 13:07, 13 September 2014 (UTC)
At Norwegian Bokmål Wikipedia we have added support for formatting ISO 8601 dates (YYYY-MM-DD) and recommend using them. If more wikipedias could support ISO 8601, it would be easier to copy citations from one wikipedia to another. It could also make life easier for bots that need to insert dates, or scripts relying on Citoid. Are there any objections to adding ISO 8601 date support on enwiki? Here's an example of how it could be done (with testcases), inspired by our implementation at nowiki. One possible problem is that any fixed output format like 'j M Y' might not confirm to WP:MOS#Choice_of_format. – Danmichaelo ( talk) 16:58, 14 September 2014 (UTC)
{{
citation/core}}
days where the templates automatically converted from year-initial numeric dates to the user's preferred format. For a while. That functionality was removed.I see from the template that {{ PDFlink}} is in the process of being merged into CS1. The TfD discussion noted that wikipedia's CSS adds the PDF icon where an external link indicates the document is a pdf, however not all links will do this. Some (e.g. this one used on Ford Island) generate a pdf and force the browser to download it. Even for sites which don't force a download, sometimes the content type is displayed in the header, not the url. For resources like that we should have some way of indicating to the user that the resource is a PDF. How do we do that when the merger is complete with CS1? Protonk ( talk) 14:26, 19 September 2014 (UTC)
[http://www.example.com/example.pdf Example]
turns into this:
Example – there is no such file, by the way. Your Ford Island example does not have the '.pdf' extension so Wikimedia can't know it's file format. To notify readers that the link is to a pdf file, use |format=pdf
which gives:
"Historic Hawaii" (pdf).{{
PDFlink}}
into CS1 so don't expect anything soon. {{PDFlink}}
should not be used within CS1 templates.CS1 doesn't seem equipped to handle a range of seasons as the "date=" parameter; see for example here. I managed to get both a single season and a range of years displayed correctly, so I don't think it's me. Huon ( talk) 20:35, 20 September 2014 (UTC)
{{
ndash}}
or –
; like this:
{{cite book |title=Title |date=Winter 2013 – Spring 2014}}
→ Title. Winter 2013 – Spring 2014.{{
ndash}}
, it's {{
spaced ndash}}
that shouldn't be used. I'll tweak the help a bit.How should Winter 2005 / 2006 be formatted to not get cs1 errors? I cannot get it to work in the Susanna Paine article: Michael R. and Suzanne R. Payne (Winter 2005 / 2006). "Roses and Thorns: The Life of Susanna Paine". Folk Art. p. 63. Check date values in: |date= (help)
Thanks!-- CaroleHenson ( talk) 13:28, 22 September 2014 (UTC)
|date=Winter 2005–2006
I have split this off from
Module talk:Citation/CS1/Archive 11#non-italic titles. It is related but I want to focus this discussion on right-to-left language support. |script-title=
is a new parameter in the sandbox version of
Module:Citation/CS1 Its purpose is to hold citation title text that must not be italicized in the final rendered citation. It is concatenated with the value in |title=
which is to be italicized. See
non-italic titles for the discussion that led to the creation of |script-title=
. At the time of this writing, |script-title=
is just hacked into the CS1 sandbox as a proof of concept. Its full use and purpose is not clearly defined. I am seeking a better name for this parameter. Ideas for a better name and for use definition and restrictions welcome.
The post that I split from non-italic titles begins here:
This citation comes from a discussion now in
WP:VPT archive 129. I changed it from {{
cite web}}
to {{
cite book}}
so that |script-title=
would apply because {{cite web}}
doesn't italicize |title=
). You'll notice that title and translated title are malformed:
{{
cite book}}
: Unknown parameter |trans_title=
ignored (|trans-title=
suggested) (
help)I added code to
Module:Citation/CS1/sandbox to wrap |script-title=
in <bdi>...</bdi>
tags. The sandbox version of the citation renders correctly:
{{cite book/new |author=Tova Green |date=6 May 2010 |script-title=12 ימים|language=he |trans_title=13 days |publisher=Maybe So |url=http://MaybeSo.com/12days.html |accessdate=15 May 2010}}
I'm beginning to think that values assigned to |title=
and|script-title=
(or whatever it finally becomes) should be wrapped in <bdi>...</bdi>
tags – the value assigned to |trans-title=
is always supposed to be English so wrapping it seems unnecessary.
— Trappist the monk ( talk) 14:46, 13 September 2014 (UTC)
|logogram=
with |script-title=
. All instances of |logogram=
in the above post have also been replaced.<bdi>...</bdi>
. We're in the position of not really knowing what direction the value assigned to |script-title=
might use. We could wrap |script-title=
in <span dir=auto>...</span>
but, yet again, IE doesn't support dir=auto
. That, I think, leaves us with two options: do nothing and wait for IE to join the 21st century, or wrap |script-title=
in <bdi>...</bdi>
. In the former case, the problem that led to this discussion is a problem for everyone; in the latter, its only a problem for those who use IE. I think that we should use <bdi>...</bdi>
because eventually, I presume, IE will get its act together.<bdi>...</bdi>
"; it says "Internet Explorer, Safari and Opera do not support bdi." --
Redrose64 (
talk)
15:28, 20 September 2014 (UTC)dir=auto
is how we will be using <bdi>...</bdi>
, then it would seem that the basic test results indicate that all but IE 'support' <bdi>...</bdi>
.<bdi>...</bdi>
would probably fix it. The title string would get the direction of its first strongly directional character and wouldn't be affected by neighboring strings.<bdi>...</bdi>
is 11 bytes. With a lot of cites, that could add a considerable amount of data to everyone's download, on every page. Would it work to look at the first byte in the title string and wrap the title in <bdi>...</bdi>
if it's a number or another weak character? --
Margin1522 (
talk)
22:30, 20 September 2014 (UTC)|script-title=
will be wrapped with <bdi>...</bdi>
to isolate whatever directionality it has from the ltr direction in |title=
. <bdi>...</bdi>
will only be applied when a citation contains a non-empty |script-title=
so this imposes relatively little download penalty. This is how the sandbox is working now.|script-title=
so that we can get some experience with it. Then let us decide how to proceed. It may be that we should consider renaming |script-title=
to |rtl-title=
because the original reason for the parameter's existence (italics and Asian scripts) is probably not the issue it was now that wikimarkup can be used to undo default title italics without corrupting the metadata.{{cite web|rtl=y|...
or {{cite web|cjk=Yes|...
. This would be an easy-to-understand fix for editors who enter the cite with the regular menu UI and then notice that the output looks funny. They wouldn't have to edit the |title=
parameter name or escape the kanji. Just add the parameter. In a future UI, they could be check boxes instead of separate entry fields. --
Margin1522 (
talk)
09:14, 22 September 2014 (UTC)|title=
, <bdi>...</bdi>
isn't clever enough to figure out which part is which. To mimic what you suggest, I have changed our current favorite citation. Here I put both the translation and the rtl script in |script-title=
so that it contains both ltr and rtl. The whole is wrapped with <bdi>...</bdi>
. The title should be: 13 days ימים 12 but instead we get this:
{{
cite book}}
: Invalid |script-title=
: missing prefix (
help)|rtl=
and |cjk=
parameters; one each for every standard parameter that might contain rtl or cjk script (and it isn't just cjk scripts that should be rendered in upright font style). Wikimarkup is something that editors are familiar with and understand so allowing them to undo default styling that way seems best. If we have to have another parameter to indicate that this 'thing' is rtl, why not just assign that parameter the value of 'thing'? |script-title=
, |script-chapter=
, |script-author=
, etc.|script-title=he:ימים 12
. This would then let us wrap the script with <bdi lang="he">...</bdi>
. This prefix would not be required and could be escaped in the unlikely event that the first three characters in a |script-title=
value make a legitimate ISO639-1 code followed by a colon. If the prefix is used, we can check it for validity and emit appropriate error messages.|title=
, |chapter=
, |work=
and maybe |author=
. This is en.wikipedia. There probably needs to be more thought given to what parameters after |title=
get this option. Just you and me in this ghost-town of a talk page is not enough.|transcript=
parameter that is used as the title of an external link to the transcript of something (interview, speech, etc). We can certainly alias |title=
with another parameter, perhaps |xscr-title=
or some-such, if that is required.{{cite book|last1=Kinoshita|first1=Masahi ...
, write {{cite book|author=Kinoshita Masahi <kanji> ...
But, that might be problematic because: What will the metadata contain? That's why I suggested |script-author=
above. |author=
is part of the metadata but should |script-author=
or for that matter any |script-whatever=
parameter values be part of the metadata? But you want to use |author=
anyway, don't you? Aren't Japanese names properly surname first without the comma?I've added code that accepts an ISO639-1 prefix (no validity testing yet, spaces aren't allowed) but the language code is added to <bdi>...</bdi>
. Our favorite citation, stripped of just about everthing for clarity:
{{cite book/new |script-title=he:12 ימים |trans_title=13 days}}
produces this:
Here is what the html looks like:
'"`UNIQ--templatestyles-00000092-QINU`"'<cite class="citation book cs1 cs1-prop-script"> <bdi lang="he" >12 ימים</bdi>.</cite><span title="ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Abook&rft.genre=book&rft.btitle=12+%D7%99%D7%9E%D7%99%D7%9D&rfr_id=info%3Asid%2Fen.wikipedia.org%3AModule+talk%3ACitation%2FCS1%2FArchive+10" class="Z3988"></span> <span class="cs1-visible-error citation-comment"><code class="cs1-code">{{[[Template:cite book|cite book]]}}</code>: </span><span class="cs1-visible-error citation-comment">Unknown parameter <code class="cs1-code">|trans_title=</code> ignored (<code class="cs1-code">|trans-title=</code> suggested) ([[Help:CS1 errors#parameter_ignored_suggest|help]])</span>
Because this citation doesn't use I guess that this argues for inclusion of the |title=
for a transcription, there isn't any title information in the metadata.|script-title=
. Do we always include it? Or, do we only include it when |title=
is missing or empty?
— Trappist the monk ( talk) 00:12, 23 September 2014 (UTC)
|title=
, the non-Latin title is included in the metadata. So, lacking direction to the contrary, I'll make sure that the content of |script-title=
is also part of the metadata.|title=
and |script-title=
.lang
attribute and leave the prefix with the script.I have adjusted the code so that |script-title=
is applied to all CS1 templates (heretofore only those that italicized |title=
. Here is a simplified {{
cite journal}}
:
{{
cite journal}}
: Unknown parameter |trans_title=
ignored (|trans-title=
suggested) (
help)— Trappist the monk ( talk) 15:02, 24 September 2014 (UTC)
For this citation:
With Firefox 33 and IE 11, I see 12 space followed by the Hebrew then [13 days]]. -- Gadget850 talk 23:21, 20 September 2014 (UTC)
|script-title=
and wrap the script in <bdi>...</bdi>
:
|script-title=
with <bdi>...</bdi>
doesn't break anything and appears to provide mostly-correct rendering across browsers. This, I think, argues for its inclusion in the module.unicode-bidi: embed; unicode-bidi: -webkit-isolate; unicode-bidi: -moz-isolate; unicode-bidi: -ms-isolate; unicode-bidi: isolate;
unicode-bidi:
works with direction:
which can have the values ltr
, rtl
, or inherit
. That means that we would need to know beforehand the direction required by the content of |script-title=
. Therein lies the value of <bdi>...</bdi>
.