gangleri wrote:

(In reply to comment #0)

...
Rosemary Skinner Keller, Rosemary Radford Ruether and Marie Cantlon.
Encyclopedia of women and religion in North America. Bloomington: Indiana
University Press, 2006. ISBN: 0253346851; 025334686X; 0253346878; 0253346886;
9780253346858; 9780253346865; 9780253346872; 9780253346889.

I can imagine that instead of ; also commas or spaces could be delimiters.

In order to keep the ideas together:

http://de.wikipedia.org/w/index.php?oldid=43728381#Auffinden_von_Buchrefferenzen
lists:

ISBN-10 0061132179, 0312307411, 0061131229, 0739466542
ISBN-13 9780061132179, 9780312307417, 9780061131226, 9780739466544

It would make sense to handle ISBN-10 and ISBN-13 the same way as ISBN and ISBN-10: and ISBN-13: the same way as ISBN:

Best regards Reinhardt [[user:Gangleri]]

Note that this bug is requesting several new allowed forms, including the following:

ISBN: 1401323251

ISBN: 978-1401323257

ISBN 10: 1401323251

ISBN 13: 978-1401323257

ISBN-10 0061132179, 0312307411, 0061131229, 0739466542

ISBN-13 9780061132179, 9780312307417, 9780061131226, 9780739466544

ISBN: 0253346851, 025334686X, 0253346878, 0253346886, 9780253346858, 9780253346865, 9780253346872, 9780253346889

ISBN: 0253346851; 025334686X; 0253346878; 0253346886; 9780253346858; 9780253346865; 9780253346872; 9780253346889

ISBN-10: 0061132179, 0312307411, 0061131229, 0739466542

ISBN-13: 9780061132179, 9780312307417, 9780061131226, 9780739466544

In my opinion, they should be addressed roughly in that order.

Note that the ISBN-13 format is just equivalent in its format to the EAN-13 standard in which it was allocated for books. But the EAN-13 standard has similar formats for identifying video products (ASIN numbers, also available in older 10-digits format), audio products like CDs (also available in older 10-digit format). Why restricting such references this to published books?

See related Bug #8758 (for ASIN support: this would avoid links to problematic audio/video clips shared illegally on sites like YouTube, that could still host some legal audio/video extracts from protected larger contents, by identifying them with their ASIN number : this would not promote only these commercial sites by more fairly, other online merchants that legally sell the full products ; this would allow verifiable references for these audio/video sources, that are still too badly considered even though they are perfectly valid and should still be usable as references for Wikipedia verifiability of article contents).

The ISBN numbers were introduced to allow easier identification of references, but also to avoid the direct insertion of advertizing links within the articles (because this promoted specific merchant sites, and was against a fair competition; before that, there were too many unnecessary links within Wikipedia articles or in their reference sections, but still not enough to offer a fair choice for visitors). This should also apply to references for audio and video products sold by various merchant sites or distributors.

Note: Although I think some of this may have already been implemented, it is not necessarily a good thing. People can type any format they want, but providing auto links for the non-preferred formats means that the non-preferred formats are less likely to get fixed.

I came across this change in a client's code, found this bug, and decided to try and commit. See gerrit change Ifda5ef59.

Note that this only addresses part of the issue -- when you have "ISBN: XXXX". I did throw in "RFC: XXX" and "PMID: XXX", too.

Comments in bug report are that this should be in an extension instead, hence removing patch-in-gerrit keyword.

I think Andre means in the Gerrit change. I'm not sure there is a consensus among MW developers to move magic linking to an extension. It would certainly be a bigger change than just supporting an optional colon.

Thus, adding back PATCH_TO_REVIEW.

Hm. Magic links are the red-headed stepchildren of the parser. They are latin-alphabet specific and rather eccentric -- why would a general-purpose Urdu encyclopedia (say) want special support for linking IETF RFCs?

It seems that explicit {{ISBN|nnnnnnn}} markup is preferred in the modern wiki to magical autolinks.

In T14900#842273, @cscott wrote:

Hm. Magic links are the red-headed stepchildren of the parser. They are latin-alphabet specific and rather eccentric -- why would a general-purpose Urdu encyclopedia (say) want special support for linking IETF RFCs?

It seems that explicit {{ISBN|nnnnnnn}} markup is preferred in the modern wiki to magical autolinks.

Yes. I think we should close this task.