Help talk:Citation Style 1/Archive 17

After RFC

@Trappist the monk: Hi. Do you think it is okay to implement the result of the RFC now? Best regards, Codename Lisa (talk) 15:26, 9 May 2016 (UTC)

You needn't seek my permission.

—Trappist the monk (talk) 17:29, 9 May 2016 (UTC)

Yes, I do. I don't have enough edit privileges to edit the module and if I did, I don't know where to start.

History suggests you are the right person to call.

Best regards,

Codename Lisa (talk) 19:28, 9 May 2016 (UTC)

No, you don't. Module:Citation/CS1/sandbox.

—Trappist the monk (talk) 21:48, 9 May 2016 (UTC)

Just editing Module:Citation/CS1/sandbox won't do it. 'PublicationPlace'/'Place' (|location=) must be edited too (see ln #2048) because it is also formatted within parentheses, and 'Publisher' is included in them (ln #2902). So just changing 'PublisherName'/'Publisher' (ln #2894) won't work in all cases. 72.43.99.146 (talk) 14:29, 11 May 2016 (UTC)

Btw, this is just by looking cursorily at the code. Did not actually test it. 72.43.99.146 (talk) 14:47, 11 May 2016 (UTC)

Editor Codename Lisa's question was where to start. The beginning is always a good place and that beginning for the cs1|2 modules is Module:Citation/CS1/sandbox. But what perplexes me is your claim that there is someplace else that needs changes but all of your line references supporting that claim are in Module:Citation/CS1/sandbox.

—Trappist the monk (talk) 15:35, 11 May 2016 (UTC)

Sorry, my comment should have been "Just editing publisher in Module etc". As I mentioned, it was a cursory look. Since other arguments make use of the same parentheses, and since I was not certain, at first glance, of all the possible dependencies, I thought it warranted a warning. 65.88.88.62 (talk) 16:51, 11 May 2016 (UTC)

Whatever. I don't know enough Lua or enough about Wikipedia's Lua API, and Wikipedia does not have IntelliSense. I am like a blind man looking for several needles in a haystack. I have touched Lua twice so far and on both occasions, I cheated. Best regards, Codename Lisa (talk) 19:37, 11 May 2016 (UTC)

Whatever, what??? I am trying to point out that there may be other dependencies between |publisher= and certain parameters (such as |location=) that could affect display of the citation, over and above the presence/absence of |work=. Since the result of the RFC specifies a new design consensus for an area of CS1, its implementation should avoid introducing possible new inconsistencies. 65.88.88.126 (talk) 21:46, 11 May 2016 (UTC)

This is not strictly a CS1 question, but I got no answer at

Princeton University contains 6 references to a book, all in need of page numbers. I don't have the book, and I'm not inclined to trudge down to the library and do the necessary research. How would you code this, assuming only one occurrence of {{Cite book}}?

• Named references, each followed by {{Page needed}}? That wouldn't work when the page numbers are identified, unless one wanted to use the "rarely used" {{Rp
  }} template for the page numbers.
• {{Sfn}} templates, sans page numbers, each followed by {{Page needed}}? Is it considered proper to use {{Sfn}} in association with inline {{Cite book}}, or should it only be used with bibliographic entries such as at Princeton University#Further reading?
• Other?

Thank you. ―Mandruss ☎ 07:49, 7 May 2016 (UTC)

I've added {{ref info}} at the top of this topic.

Is the book available at archive.org? google preview? Search the article history to identify and so contact the editor who added the book? Discuss on the article talk page?

Since the article isn't all that consistent in how it handles referencing, it looks like you can pretty much do what you'd like.

I think it is acceptable to have {{sfn}} link to an in-line citation when the article does not have a separate bibliography section – §Further reading is not a reference bibliography.

—Trappist the monk (talk) 10:47, 7 May 2016 (UTC)

Bingo! While I believe a separate bibliography ("sources") section is preferable (makes the full citations easier to find), it isn't really needed. The automagic of {{

harv}} (which is the essence of {{sfn}}) will find the full citation where ever it is. ~ J. Johnson (JJ) (talk

) 21:51, 11 May 2016 (UTC)

Mandruss: What is the book in question? – Jonesey95 (talk) 13:41, 7 May 2016 (UTC)

@Jonesey95: Princeton University: The First 250 Years. Some/most of the references are currently using {{Cite web}}, which is incorrect, and I'll fix that when this discussion is concluded. ―Mandruss ☎ 14:04, 7 May 2016 (UTC)

Through a series of coincidences, I own that book and can help you with sourcing. Contact me on my talk page. – Jonesey95 (talk) 14:34, 7 May 2016 (UTC)

Whereas the en-dashes that MOS prescribes for date ranges are special characters, not generally found on standard keyboards, and whereas the error message the cs code emits on finding a hyphen is not clear that the hyphen is the basis for the complaint, I propose that where the cs code finds hyphens in date ranges it should automatically convert them to en-dashes, without complaint.

Any objections? ~ J. Johnson (JJ) (talk) 22:05, 18 April 2016 (UTC)

The proposal is about dates not pages.

—Trappist the monk (talk) 22:39, 18 April 2016 (UTC)

I support the proposal. One caveat is that we can't do a universal replacement, since yyyy-mm-dd, whatever your opinion of it, is a valid date format that uses hyphens. I recommend that the proposer list the valid date formats shown at

MOS:DATERANGE or another appropriate location in order to start a conversation about the feasibility of the proposal. – Jonesey95 (talk

) 23:33, 18 April 2016 (UTC)

I am not the proposer but this is the answer to the list the valid date formats request taken from the date validation code:

• month day–day, year
• day–day month year
• day month – day month year
• month day – month day, year
• day month year – day month year
• month day, year – month day, year
• Winter year–year (YYYY–YY)
• Summer year–year (YYYY–YY)
• Winter year–year (YYYY–YYYY)
• Summer year–year (YYYY–YYYY)
• month year – month year
• season year – season year
• month–month year
• season–season year
• year–year

—Trappist the monk (talk) 12:10, 19 April 2016 (UTC)

Thank you. ~ J. Johnson (JJ) (talk) 17:21, 19 April 2016 (UTC)

ISO format uses 2 hyphens. That may be a unique attribute, to be used in coding the proposed date-checking/fixing scheme. Also: in general, I support the proposal. 72.43.99.146 (talk) 23:40, 18 April 2016 (UTC)

As long as the autoconversion leaves YYYY-MM-DD dates hyphenated, I am ok with converting other hyphens in dates to dashes. This is a much more constrained data format than pages where fewer things can go wrong. —David Eppstein (talk) 23:40, 18 April 2016 (UTC)

Again, I support the proposal, but not all hyphens should be auto-converted. |date=2008-03 and |date=March 27-April 3, 2002, for example, should still cause errors to be emitted and should not be auto-converted. We need to think this through. Maybe only dates that would be otherwise valid if the hyphens were en dashes should be auto-converted. Would that cover the whole list of possibilities? – Jonesey95 (talk) 00:29, 19 April 2016 (UTC)

This is getting complicated. It could be worth examining a different approach: ie whether |date= should require |df= (where |df=[full list of allowable date formats]). So a user would first have to specify a particular |df= choice, and then |date= could only be filled accordingly. Beforehand, I can't tell which programmatic approach would be optimal or easier. 72.43.99.146 (talk) 13:46, 19 April 2016 (UTC)

If I understand what it is that you wrote, your idea would break every cs1|2 template that has |date= and doesn't have |df=. Besides, |df= has a specific purpose which we should be changing without a bunch of deep thinking.

—Trappist the monk (talk) 15:03, 19 April 2016 (UTC)

You are correct. But I was thinking about new implementations. If such is to be considered, pre-existing uses will have to be bypassed by error checking until a mechanism to insert |df= (functioning as explained above) is devised. Just throwing around ideas. 72.43.99.146 (talk) 15:47, 19 April 2016 (UTC)

Not possible to distinguish a new cs1|2 template from an old one. Every time a page is parsed, whether that is because someone edited it, or because someone changed a template that the page transcludes, or for any other reason, each parsing causes Module:Citation/CS1 to process all of the cs1|2 templates as if they were new.

—Trappist the monk (talk) 16:37, 19 April 2016 (UTC)

I don’t mean to press this route, but indulge me for a minute.

1. In a new module iteration, introduce a date-related, non-displayed, flag with a short range of values (say, 0-3)
2. one-time maintenance routine: set this flag=0 in all existing templates
3. post-maintenance, set the default for the date-related flag=1
4. If flag=1, user-specified date format is required
5. if a template fulfills date requirements, flag=2
6. later, a mechanism can be devised to automate migration of templates where flag=0.

??? 65.88.88.127 (talk) 18:11, 19 April 2016 (UTC)

You forgot: PROFIT!!!

This is a mixture of module edits and bot edits (the module cannot edit wikisource).

—Trappist the monk (talk) 18:30, 19 April 2016 (UTC)

Sure. I think I had remarked previously about the cost/feasibility of doing complicated stuff like this. 65.88.88.127 (talk) 19:28, 19 April 2016 (UTC)

From the list above, these use hyphens:

Title. January 10–15, 2016.{{cite book}}: CS1 maint: date format (link)

Title. 10–15 January 2016.{{cite book}}: CS1 maint: date format (link)

Title. 10 January – 15 March 2016.{{cite book}}: CS1 maint: date format (link)

Title. January 10 – March 15, 2016.{{cite book}}: CS1 maint: date format (link)

Title. 10 November 2015 – 15 January 2016.{{cite book}}: CS1 maint: date format (link)

Title. November 10, 2015 – January 15, 2016.{{cite book}}: CS1 maint: date format (link)

Title. Winter 2015–16.{{cite book}}: CS1 maint: date format (link)

Title. Summer 2015–16.{{cite book}}: CS1 maint: date format (link)

Title. Winter 2015–2016.{{cite book}}: CS1 maint: date format (link)

Title. Summer 2015–2016.{{cite book}}: CS1 maint: date format (link)

Title. November 2015 – January 2016.{{cite book}}: CS1 maint: date format (link)

Title. Winter 2015 – Summer 2016.{{cite book}}: CS1 maint: date format (link)

Title. January–March 2016.{{cite book}}: CS1 maint: date format (link)

Title. Spring–Summer 2016.{{cite book}}: CS1 maint: date format (link)

Title. 2015–2016.{{cite book}}: CS1 maint: date format (link)

these use ndashes:

Title. January 10–15, 2016.

Title. 10–15 January 2016.

Title. 10 January – 15 March 2016.

Title. January 10 – March 15, 2016.

Title. 10 November 2015 – 15 January 2016.

Title. November 10, 2015 – January 15, 2016.

Title. Winter 2015–16.

Title. Summer 2015–16.

Title. Winter 2015–2016.

Title. Summer 2015–2016.

Title. November 2015 – January 2016.

Title. Winter 2015 – Summer 2016.

Title. January–March 2016.

Title. Spring–Summer 2016.

Title. 2015–2016.

ymd dates and |df= are not broken:

Title. 2016-03-15.

Title. 15 March 2016.

—Trappist the monk (talk) 15:24, 22 April 2016 (UTC)

Replace hyphens, or not?

So where are we at with this? If the code is smart enough to declare an error in regard of hyphens, should it fix it? ~ J. Johnson (JJ) (talk) 19:41, 4 May 2016 (UTC)

If you mean have the template fix the wiki text then, no, not going to happen.

—Trappist the monk (talk) 20:38, 4 May 2016 (UTC)

Why not? Because you're God? ~ J. Johnson (JJ) (talk) 23:28, 6 May 2016 (UTC)

Yes. And because templates are not allowed to modify wiki text.

—Trappist the monk (talk) 00:15, 7 May 2016 (UTC)

I don't think a template can do that. One might be able to create an AWB script that uses the logic in the template to detect hyphen errors in the current date error category and fix them, but it probably makes sense to wait for the revised template to be deployed, which will make the errors go away. – Jonesey95 (talk) 20:46, 4 May 2016 (UTC)

Does not BattyBot 25 already do this? If not, why not?

—Trappist the monk (talk) 21:26, 4 May 2016 (UTC)

Maybe. My regex-parsing skills are not good enough to read User:BattyBot/CS1 errors-dates, but it looks like the sections marked "fix range of" may be fixing separators for us. – Jonesey95 (talk) 21:30, 4 May 2016 (UTC)

"... templates are not allowed to modify wiki text"? Bullcrap. We are not talking about modifying the text, but processing the input. Which is already done in regards of italicization, and even the replacement of hyphens in page ranges. ~ J. Johnson (JJ) (talk) 22:00, 11 May 2016 (UTC)

See the section above. Hyphenated input is converted to dashed input. This is in the sandbox version of the CS1 module code. It will be deployed in the next update. Updates typically happen every month or two.

The module/template code will not "fix" the wikitext, i.e. it will not change it, but it will display the date properly, per MOS. Is that what you are asking for? – Jonesey95 (talk) 22:06, 11 May 2016 (UTC)

Yes. ~ J. Johnson (JJ) (talk) 22:01, 12 May 2016 (UTC)

I've just noticed a bunch of edits in which correct use of ignore-isbn-error is being removed. The as-printed ISBN has been replaced with an ASIN (IMO bad to add this so really bad to also remove the ISBN) an OCLC (IMO good to add this but bad to remove the ISBN) or a different ISBN (IMO not necessarily OK but not necessarily bad either):

• https://en.wikipedia.org/w/index.php?title=Henri_Piet&type=revision&diff=714230475&oldid=712193278
• https://en.wikipedia.org/w/index.php?title=Gianni_Caproni_Museum_of_Aeronautics&type=revision&diff=714202462&oldid=709538370
• https://en.wikipedia.org/w/index.php?title=Myroslava_Kot&type=revision&diff=714193281&oldid=699338004
• https://en.wikipedia.org/w/index.php?title=Deplanchea_tetraphylla&type=revision&diff=715346675&oldid=712730392
• https://en.wikipedia.org/w/index.php?title=Marie_Petipa&type=revision&diff=714353596&oldid=712193609

So my concern is that the new category is being misused to blindly remove all use of ignore-isbn-error and removing correct information about the source in the process. The removed ISBNs are confirmed to be as-printed either directly or based on library records which indicate that this is the case.

TuxLibNit (talk) 17:50, 7 May 2016 (UTC)

I think this is another off-topic issue raised here. To continue off-topic, there is a question of the origin of any "ignored-isbn-error". One assumes that the contributor handled the actual source in some form or other, and directly confirmed the isbn. It is conceivable that some time later the isbn was reassigned by the publisher who obtained it, or was obsoleted through an isbn reissue for the same title and edition. So even though the encyclopedia article text may no longer be verified through the original citation as formatted (if the reader decides to follow the erroneous isbn), it may be verified by an edited version of the citation. One that includes the newer isbn assignment or a different mechanism/identifier. If the citation editor does not have access to the source, but has only (through another, reliable source) information about the new correct identifier, h/she can input the new info, but the erroneous isbn has to be retained imo, and the error should be ignored. Because that was the only version of the supporting source that was actually consulted. To put it differently, the later editor cannot

WP:SAYWHEREYOUGOTIT

because s/he didn't. S/he only found information about the source, not the source itself. As I mentioned in the beginning, it is assumed that the original contributor did consult the source.

As an aside, (again off-topic) I think that IgnoreISBN should be flagged, precisely so that the situation is brought into wider attention and rectified one way or another. And also to avoid misleading readers who may try to verify the source by looking up a wrong isbn. 65.88.88.69 (talk) 20:19, 7 May 2016 (UTC)

To add, there is also the question of isbn formatting. There is no real standard about how the number may be sectioned/hyphenated. Some isbn search services may throw an error over a perfectly good isbn (as presented by the publisher), while others will correctly bring it right up. IgnoreISBN makes sense there too, and that isbn should be retained in the citation. 65.88.88.69 (talk) 20:29, 7 May 2016 (UTC)

The ISBN's being used in "ignore-isbn-error" are bad. ISBN's follow a pattern... country code, publisher code, checksum and so forth. If it is being flagged as bad, the ISBN is impossible to use within the ISBN system. These are not cases of reissued ISBNs or resigned, they are cases where they can never exist. There are cases of a publisher/self-publisher not wanting to spend the money to obtain ISBNs. Cases of people/publishers put a random ISBN on their work. Editor copies the wrong ISBN. Lastly, cases where the book never had an ISBN to begin with. Formatting has no bearing on if a ISBN is bad or not.

When a reader clicks on an ISBN, they are taken to a page where they can find the book, via Worldcat, Google, etc. There is now way to find them with the bad ISBN number. There is no way to look them up. The idea is for the reader to actually find the book. OCLC numbers used goes to the book used in the article.

This tag isn't "blindly" being removed. It is being removed when another source can be found.

Examples

1. isbn=0-9536475-4-8|ignore-isbn-error=yes <!-- invalid ISBN 0-9536475-4-8 is as used by british national library via worldcat --> This is a self published book. A 9 digit ISBN was used. No way to find it. ASIN was used, but this is a last resort.
2. isbn=978-88-8446-157-X|ignore-isbn-error=yes<!-- invalid ISBN 978-88-8446-157-X is as used by Harvard University library and more via worldcat --> Why use a made up ISBN (13 digits don't have X) that is only good at Harvard? Worldcat number was used so everybody can find it. Next item on the above list was also another Harvard one.
3. isbn= 90-286-0573-1| ignore-isbn-error=yes <!-- invalid ISBN 90-286-0573-1 appears on back cover of work --> This is a long series of books. Those before the late 1970's had bogus ISBNs, after that, they used correct ISBNs.
4. |=978-5-903368-45-0|ignore-isbn-error=yes It is a bad ISBN. It was replaced by the correct one.

Bgwhite (talk) 21:36, 7 May 2016 (UTC)

I think I'm being misunderstood. For most if not all of these ISBNs, if you click the ISBN link (taking you to the Special:BookSources page), scroll down a little to the "Online databases" section and then click the "Find this book" link for WorldCat, then you are taken to a database entry for the source. Are you all aware of that? Libraries around the world are recording the fact that these numbers (however invalid) are printed on these books and any of the "Find this book" links might work. For source-identification purposes they can be as useful as valid ISBNs. It is not that 978-88-8446-157-X ISBN is "only good at Harvard". Harvard is just one library of many that records in their database the fact that this number really is printed on this book even though it is invalid.

Regarding whether this is off-topic. I've raised this here because this is a question of how ignore-isbn-error=yes is supposed to be used in CS1 and whether the current CS1 templates are appropriately supporting its use. AFAIK this is the usual place to discuss CS1 and its template implementation.

I take the comments so far to imply either that ignore-isbn-error should be removed from the templates and/or that the documentation for Help:CS1_errors#Check_.7Cisbn.3D_value should be updated. That is fine, but I think it would help if you could be more explicit about exactly how you think ignore-isbn-error is supposed to be used (or not used).

TuxLibNit (talk) 23:12, 7 May 2016 (UTC)

I have seen a few different situations in which |ignore-isbn-error= is being used. Here are the ones I can think of and how I recommend dealing with them, after fixing a few thousand ISBN errors.

1. |ignore-isbn-error= used with a valid ISBN. In this case, remove the "ignore" parameter.
2. |ignore-isbn-error= used with an invalid ISBN that links through to WorldCat and that is sometimes even listed in WorldCat with the book. In this case, insert a comment that the ISBN is invalid but that it is listed in WorldCat.
3. |ignore-isbn-error= used with an invalid ISBN that is listed in the LCCN database as an invalid ISBN. This means that the invalid ISBN was printed in the book and should be left. Add a comment explaining why the invalid ISBN is there, with a reference to LCCN, and add the |LCCN= parameter if it is there.
4. |ignore-isbn-error= used with an invalid ISBN that does not link through to WorldCat and that cannot be verified. In this case, if you can locate an OCLC for the source, add it, and comment out (but do not remove) the invalid ISBN.

Those are all I can think of right now. There are probably more. We should probably add guidance like this in some form to the category page. – Jonesey95 (talk) 01:19, 8 May 2016 (UTC)

At present, |ignore-isbn-error= takes a number of "yes/no" arguments only. Why don't we define a wider set of predefined tokens so that editors could systematically specify what's actually up with an invalid ISBN?

I find it particularly important to record if an invalid code was verified by someone to be actually printed on the book.

Some books lack any printed ISBNs on them but still have ISBNs assigned to them in printed or online catalogs - in this case, the ISBN isn't invalid "as is", but still cannot be used directly to identify a particular book. If known this info can help obtaining a copy of a book by extending the search to listings stating that a particular book does not show any ISBN.

Some books have different ISBNs printed in the preface and on the back-cover. In such cases, it might be useful to record which one was chosen, or - better - to use the |ignore-isbn-error= parameter to record the other ISBN as well. Alternatively, the |isbn= parameter could be changed to accept more than one value. As some databases may list the book under one ISBN, and others under the other, this is important information to know, and omitting one of the ISBNs may reduce chances to locate a copy of the book.

The same applies when a book became available under more than one ISBN over the years (often in different countries or for different prices), even by the same publisher and with identical contents and outer appearance.

In yet other cases, a single ISBN was used for different editions of a book (even with slightly different contents). If an editor happens to be already aware of such oddities, it would be helpful, if this could be recorded somewhere in the citation, so that buyers don't end up with the wrong edition.

In some cases, ISBNs listed in some widely used catalogs have been identified to be invalid. If the book carries a valid ISBN, we should use this, of course, but it might still help to record somewhere that a book is also listed under another ISBN.

--Matthiaspaul (talk) 11:50, 8 May 2016 (UTC)

If an invalid ISBN works in WorldCat, an editor, or a librarian helping that editor, will have no trouble locating the book. As for multiple editions with the same ISBN, |edition= is useful for that situation. As for multiple ISBNs in the template, that will lead to all sorts of trouble; the idea of citing a source is to cite the specific item from which you got the information. – Jonesey95 (talk) 13:06, 8 May 2016 (UTC)

I wouldn't have mentioned these example scenarios if I hadn't personally run into problems when I tried to obtain specific editions of old books on the international market.

Ad "invalid ISBN in WorldCat" - I wasn't talking about WorldCat at all. WorldCat is a great resource, but often enough I don't find books listed there although I know they exist (because I own copies of them or find references to them elsewhere).

Ad "multiple editions with same ISBN", yes, specifying the edition is definitely helpful, but knowing that an ISBN was used for more than one edition is helpful as well. People often take it for granted that an ISBN isn't used for multiple editions, so trying to obtain a book, they might search for the ISBN only. Some books don't specify the edition (or in ambiguous ways - in particular with translations). Also, sometimes editions aren't given in used book listings, and not knowing that an ISBN is used for multiple editions a buyer may end up with the wrong book.

Ad "multiple ISBNs in the template", quite to the contrary, if a book actually has multiple ISBNs (not for different editions or output formats, but for exactly the same book, the very book an editor is citing from), only specifying one of those ISBNs is causing trouble, because different people will refer to it under different numbers, and searching for the book, a researcher or buyer knowing only one of them may only find a fraction of listings. Also, not knowing this fact, he might come to the conclusion that there were several different editions of a book while in reality there is only one.

That's why I think that it would be most helpful to record such oddities (if known) in some systematic and machine-readable form in the template. It will enable readers to make more sense of invalid ISBNs as well as valid ISBNs, which are used in invalid ways. Also, it would allow us to develop more specific guidelines how to deal with the various scenarios.

--Matthiaspaul (talk) 14:07, 8 May 2016 (UTC)

I'm personally always agreeable that we should have parameter values which include more semantic information. So in general, your proposal seems good. --Izno (talk) 13:50, 8 May 2016 (UTC)

The question is this: did the original contributor actually consult the source with the wrong isbn? If s/he did, then this is the isbn as published, and the "ignore-isbn-error" applies. The point is not to make sure the isbn as provided by the publisher is right; the point is to provide a source that supports text in a Wikipedia article. Now an editor may find a correct identifier. If and only if s/he actually consulted the same source with the correct isbn, the wrong isbn and the accompanying error flag should be removed, and the new identifier should replace it. If the editor only found a correct identifier through a search, both the original isbn and the new identifier should be in the citation. Because only one source has been consulted: the one with the wrong isbn. And all that is off-topic as relates to this page, because they affect verifiability, not presentation. There has been one proposal that is actually relevant to this page: let's present to readers the IgnoreISBN flag. That way they will know that something is wrong with the isbn, and editors may also be immediately aware that this is a matter needing attention.

As also stated above, some ISBN search engines (Google Books is one of them) sometimes throw an error with correct isbns. I can only surmise that this is because the particular isbn has been entered in the Google Books database with a specific mask, and if it is queried as say, a non-hyphenated number it is going to return an error. 72.43.99.138 (talk) 16:05, 8 May 2016 (UTC)

Keep in mind that there is no mandatory universal isbn repository.

RR Bowker does maintain one, but unfortunately, national isbn agencies (or publishers) are under no obligation to provide the info to Bowker. AFAIK it is done voluntarily, and this may be another source of isbn errors that are not really errors. 72.43.99.138 (talk

) 16:13, 8 May 2016 (UTC)

It's perhaps worth pointing out that Bowker does have a tool to interconvert 10 and 13 digit ISBNs. You can also use the tool to produce a standard hyphenation, e.g. given a non-hyphenated 13 digit code, input it to get the hyphenated 10 digit code and then input that to get the hyphenated 13 digit code. Peter coxhead (talk) 16:39, 8 May 2016 (UTC)

I'm afraid I must require proof that there is an ISBN hyphenation converter. The reason for my skepticism? 3 of the 5 isbn elements (registration group, registrant and publication) are fields of variable length (www.isbn-international.org/content/what-isbn). Any hyphenation-convertion scheme would have an unwieldy number of possible cases. 72.43.99.138 (talk) 17:04, 8 May 2016 (UTC)

Can we please discuss hyphenation in a separate discussion? It is irrelevant to ISBN error-checking as it is currently implemented. Thanks. – Jonesey95 (talk) 01:10, 9 May 2016 (UTC)

??? Even though hyphens/spaces are for readability purposes only (www.isbn-international.org/sites/default/files/ISBN%20Manual%202012%20-corr.pdf#page=8), incorrectly hyphenating (or spacing, if not using hyphens) a valid ISBN may cause an "ISBN not found" error in some sites. How is this not pertinent in CS1 ISBN error-checking? 65.88.88.126 (talk) 13:00, 9 May 2016 (UTC)

Just a quick note. In some cases the invalid ISBN was used by worldcat at some point. That does not make it valid nor it provides any proof that this ISBN was ever actually connected to the book. In these cases the ISBN was only used to find the book in worldcat. OCLC is a better choice for that.

Moreover, we mainly need ISBNs to help readers retrieve a reference. We should use the way that makes it easier to spot a book. An invalid ISBN could rarerly be of any help. -- Magioladitis (talk) 18:20, 9 May 2016 (UTC)

Er, what?

Worldcat. Worldcat records are entered in the vast majority of cases by institutions such as libraries, universities, publishing companies, etc. who actually hold the item in question. As has been explained several times above, a so-called "invalid" ISBN may not be invalid at all. Nor can all valid ISBNs be found by using any one service. Bowker, whose Books-in-Print contains over 20 million records, certainly is not a complete ISBN repository, and also lists ISBNs that would appear "invalid" for a variety of reasons. The validity of the ISBN may make the citation harder to verify (and that should be noted), but does not automatically disqualify it. Other identifiers can/should be used. But until an editor actually consults the source with the proper identifier, the wrong ISBN has to stay, because it was published as such, and therefore it may be found as such. 72.43.99.130 (talk

) 20:09, 9 May 2016 (UTC)

"But until an editor actually consults the source with the proper identifier" So as soon as we can provide proper ASIN and OCLC numbers the invalid ISBN becomes useless. -- Magioladitis (talk) 22:08, 9 May 2016 (UTC)

And to reply to an argument written above: Yes, I 've seen a lot of cases where the ignore-isbn-error is misused. It was even used to hide typos or other kind of errors. -- Magioladitis (talk) 22:11, 9 May 2016 (UTC)

We are not talking about typos, missing digits or other malformed ISBNs. If an item is in Category:CS1 maint: Ignored ISBN errors it does not necessarily follow that it contains invalid ISBNs. The only criterion for inclusion is a citation that uses the undocumented parameter |ignore-isbn-error=. The only authoritative ISBN error-checking is the one indicated here:

• "Appendix 1: Check digit calculation and distribution of ranges" (PDF). ISBN User's Manual (6th International ed.). London: International ISBN Agency. 2012. pp. 27–31.
  ISBN 978-92-95055-02-5
  . Retrieved 2016-05-10.

Any ISBN error checking that does not exactly follow this 4-page ruleset is prone to be itself erroneous, and should be very carefully checked. There are cases, too many to be comfortable, where a valid ISBN cannot be found through some service or other or looks invalid. Blindly removing non-malformed ISBNs is not the right procedure, unless someone consults the same edition with a different correct identifier. 72.43.99.146 (talk) 14:47, 10 May 2016 (UTC)

I don't see a clear consensus that an ASIN or OCLC is so much better than an invalid ISBN that the ISBN information can be safely removed so I've reinstated that information. These are not reverts - I haven't removed the ASIN or OCLC. I've also added some documentation to Category:CS1_maint:_Ignored_ISBN_errors.

TuxLibNit (talk) 02:14, 14 May 2016 (UTC)

I've been working on an AWB script to cleanup Category:CS1 maint: Multiple names: authors list. In the process I've discovered and, I think, remedied a bug in the Vancouver style validation code.

—Trappist the monk (talk) 23:36, 14 May 2016 (UTC)

The new code to validate the format of an embargo date is flawed. I've fixed it in the sandbox. I left in a line of code that preset the embargo date to the year 9999. The purpose of that was debug test in the development of the code. I neglected to remove it. So, all |pmc= identifiers are being treated as if the cs1|2 template has |embargo=9999.

—Trappist the monk (talk) 01:07, 18 April 2016 (UTC)

is this going to be fixed any time soon?  —Chris Capoccia ^T⁄_C 12:20, 20 April 2016 (UTC)

fixed in live module.

—Trappist the monk (talk) 15:34, 23 April 2016 (UTC)

@Trappist the monk: Has this been fixed for CS2 as well, {{citation}} does not seem to be generating the URL from the PMC here?

"Preface: Situating...", Medical History, 43 (3): 283–85, 1999a,

PMID 16562317

Thanks Rjwilmsi 14:52, 16 May 2016 (UTC)

That functionality has never been part of cs2:

(hmm, there is a bug in the page rendering code; but that's a different topic).

—Trappist the monk (talk) 15:05, 16 May 2016 (UTC)

Forgot this: To get the cs2 style, use {{cite journal}} and set |mode=cs2:

"Preface: Situating...", Medical History, 43 (3): 283–85, 1999a,

PMID 16562317

—Trappist the monk (talk) 15:08, 16 May 2016 (UTC)

When {{citation}} is used to cite a journal (or any alias of |work=) and the template does not have |author= or |editor= parameters then it renders page numbers out of order. This is fixed in the sandbox:

—Trappist the monk (talk) 15:23, 16 May 2016 (UTC)