Oh, forgot to mention Special:Sources:

It should contain forms like

+-- Search for book ---------------+

+----------------------------------+

+-- Search for magazine------------+

+----------------------------------+

+-- Search for patent -------------+

+----------------------------------+

etc...

where each search button would take user to proper Special:Sources subpage.

Will need another MediaWiki page, let's say MediaWiki:SearchSources with content:

• Search for book|ISBN
• Search for magazine|ISSN
• Search for patent|patent #

ui2t5v002 wrote:

Also see Bug 3663 ISSN Magic Numbers (though an ISSN would just link to a single publication...)

(In reply to comment #2)

Also see Bug 3663 ISSN Magic Numbers (though an ISSN would just link to a
single publication...)

I know about that one, that's also why I threw this idea in.

And there are many other identifiers: DOI, ISAN, ISMN, ISRC, ISRN, ISWC, EAN, UPC and other barcodes, also international (such as ISO, ECMA) or local (such as ČSN in Czech) norms and stadards, laws, company identification numbers, etc... So many many different identificators with different ways to find them or rather their content. Therefore some general interface will be very useful.

Also map sources (currently outsourced from toolserver - Magnus' Geohack) could be less or more solved with this.

ui2t5v002 wrote:

According to the talk page, [[Wikipedia:Book sources]] itself is becoming unwieldy, and people would like the ability to split it into subpages for each continent, too, which they apparently can't do with the current setup.

Interestingly, the various number types that can be mapped to the EAN international standard (which encompass them all) can also be parsed by recognizing a list of known prefixes, from which we could automatically determine the product type, or the geographical area (or linguistic area).

If such an application for automatic determination of these types of information is developed, the table of prefixes should include:

• the exact standard identifier (such as "ISBN", "ASIN", "ISMN", possibly "UPC", but NOT "EAN" which is not qualifying and includes all the other standards in their longest number form...)
• the total length of the identifier (including its prefix below and the check digit)
• the prefix (possibly a regular expression) : it may be empty if all numbers with the above length are part of the standard.
• an optional qualifier (such as country or language zone in ISBN)
• a comment containing a verifiable reference for this prefix.
• an optional field containing a bigger length on which the shorter

The table should be editable somewhere (possibly restricted by admins) And there may exist several lines for the same standard identifier (because there are alternate forms using other lengths, or different mappings from a shorter legacy number to the longer number, or because one wants to subdivide the standard space for easier identification of products of the same type, for building specific search pages per product type and or optional subdivision like the geographic area).

Note that the geographic area can be complex to determine (it may require lots of lines, notably for ISBN), and some legacy geographical areas are remaining in the standards that are now split across distinct countries: if you want to search a book with vendors for a specific geographic zone, they may need to support the legacy numbers that were allocated to larger zones.

(and these legacy zones are still in use for newer products, because the geographic subdivisions are then subdivided by producer/editor company which still have unallocated space in their current number blocks, or because the vendors have disappeared, have been split or merged, and their existing number blocks became shared, so they no longer map exactly to the exact geographic area in which the block prefixes were allocated).

Another table could contain optional equivalent identifiers, or could contain a list of regular expressions used to recognize them, and another one used to parse the acceptable number formats (because there may be letters sometimes), and an identifier for the method used to verify the number validity (by its check digit) : the legacy ISBN-10 check digit is computed diferently from the newer ISBN-13 identifier that uses the EAN method.

These tables do not necessarily have to be on a Wiki page or in the database. They may perfectly reside in a PHP source file, because the number validation or remapping methods will frequently require specific PHP code, and also because it will probably be more efficient there.

EAN and UPC numbers/barcodes are now very valid sources. They act like URNs, and shold be treated as a generic URN that encompasses the functionality of URLs and URIs.

Additionally, it would be extremely helpful to have an extension that generates Barcodes or QRCodes from these URNs. Notably for mobile users that have difficulty to type them. These barcodes are just another presentation of those URNs.

All wiki pages should also be able to display their own URN as a barcode or QRCode, without having to upload images to Commons (the extension should have a policy about which URN naming scheme it accepts, just like there's a policy for URLs/URIs).

For me the EAN or UPC numbers are just the path part of an URI scheme with a URN prefix, so they should be handled in Mediawiki just like other links: reserving the "urn:" prefix for such use in links, and adding some feature to generate the QRCode from any link displayed or active on the page would (a right click, or a mousehover action ?) would do the trick.

Note also that Mediawiki is not restricted to just opensourced projects like Wikimedia sites. There's a legitimate use for these URNs on commercial deployments of MediaWikis (notably online shops, shopping guides, products guides, personal wiki-based blogs, scientific or medical databases). Textual links or clickable images are not always the best option for accessibility).

Just think about MMS, ads or information links displayed on TV without any keyboard/mouse interface, or on street advertizing displays: take a photo with your mobile phone with one of those many Barcode reader apps, and you can immediately link to the site in one button press or screen touch, znd without typing errors (a good thing against domain name cybersquating exploiting typing errors).

This should obsolete the "RFC " special case by the way, which should be autoconverted by an upgrade script and from that revision on may be treated at pre-parse time for some revisions with a warnig that support it going to be dropped.

fyi, this one was marked low because it is a four-year-old feature request with no actual work done.