Template talk:ISBNT

ISBN in tables

This template allows the creation of ISBN links in tables with an ISBN column (or similar circumstances) where including the letters ISBN in each link is redundant, and wasteful of space. —MJBurrage^(T•C) 17:18, 20 September 2008 (UTC)

Error tracking added

I have added error tracking to this template. See the documentation. – Jonesey95 (talk) 00:48, 11 March 2016 (UTC)

nowrap for hyphenated ISBNs

Can we get this put in class nowrap to prevent hyphenated ISBNs from wrapping at the hyphens? Full hyphenation only adds three (ISBN-10) or four hyphens (ISBN-13) to the total length making for thirteen (ISBN-10) or seventeen (ISBN-13) characters total. I tried making this change as per WP:BRD but it was reverted, so here I am discussing it. See lists like Codex Alera bibliography, The Dresden Files bibliography, Table of Cerebus novels and collections, List of Shadowrun books for examples where the wrapping at the hyphens is not useful in tables (the help for this template explicitly mentions use in tables as a supported application; I also believe the "T" in ISBNT originally meant "tables" or some such despite its current heavy usage via infobox templates like {{Infobox book}}).

If width is an issue for infobox usages, I recommend such infobox templates just implement the behavior of this template they want directly instead of invoking this template (this template is not particularly long and could be considered a typing aid). As an alternative, a {{{wrap}}} parameter could be added to remove nowrap and they can use such |wrap=yes (there are only a few such templates but many instantiations in tables so it would be easier to change the infobox templates than this template's usage within tables). Thank you. Uzume (talk) 15:44, 16 September 2016 (UTC)

They are not nowrapped in CS1 either. It would be good to propose same thing for CS1; otherwise, not apply anything elsewhere. --Obsuser (talk) 17:08, 16 September 2016 (UTC)

I am not particularly concerned about CS1. CS1 has different constraints and use cases as citations are not normally put into tables (or infoboxes) with constrained horizontal space (where wrapping is a concern), whereas {{ISBNT}} was specifically designed for such usage, e.g., CS1 includes the text "ISBN" (albeit with different linkage than auto-linked ISBN references) and this template does not. If you want to propose such for CS1 you are welcome to (it seems like it might be a good idea but I have not considered it). Uzume (talk) 19:06, 16 September 2016 (UTC)

I think no nowrapping is needed; you can add it to particular tables if needed but it is not needed there either because they get displayed nice – all examples you have given (except if you have monitor of very very small width).

In publications, I guess it is common to come across ISBNs broken at hyphens. --Obsuser (talk) 03:32, 17 September 2016 (UTC)

Can you link to a page or upload a screen shot where ISBN wrapping is a problem? I looked at a few pages that use {{infobox book}}, and I couldn't make the ISBN wrap. There was plenty of room for 13-digit ISBNs, including hyphens. – Jonesey95 (talk) 03:35, 17 September 2016 (UTC)

I provided some examples in my first post but probably the worst case can be seen in: List of Shadowrun books (dues to long content within the final "Notes" column). It should be noted this occurs not just with smaller screens (like mobile phones) but also when you resize your browser window (e.g., do not zoom it to encompass the entire screen). It maybe used in infoboxes but I did not look into those cases (just tables for which the template was originally designed for). Uzume (talk) 13:30, 17 September 2016 (UTC)

In my browser at least (Firefox 48.0.1 for Mac), none of those ISBNs wrap, no matter how much I shrink the page. The table just starts disappearing off the right side of the window, refusing to shrink columns beyond what is reasonable. That's why I asked for some problematic pages. It looks like it's working as desired, at least for me. – Jonesey95 (talk) 17:19, 17 September 2016 (UTC)

I just tried Firefox and you are right, however, those definitely wrap in Chrome. I also tried Edge and they also wrap there too (though not as severely). Uzume (talk) 22:05, 17 September 2016 (UTC)

I've added one nowrap for 978 ISBN in List of Shadowrun books and it solved problem there for Chrome. In other example you gave, no ISBN get wrapped (at least for me in Chrome, even if I zoom in). --Obsuser (talk) 01:32, 18 September 2016 (UTC)

That only works around the problem by why of fixing on instance and happens to work because the other items are narrower (you picked a wider 978 ISBN, etc.). It is not about zooming—it is about resizing the browser window. Why is it a problem to just add the nowrap to the template (like I did)? Uzume (talk) 02:13, 18 September 2016 (UTC)

Codex Alera bibliography wraps for me in Chrome for Mac and Safari for iOS 9. The wrapping does not appear to affect functionality, but it does look less nice than keeping the identifier on a single line. I would support making it so that these ISBNs do not wrap. I don't know the best technical way to do it. Whether CS1 citation templates wrap them or not is not relevant to this template, as far as I know. – Jonesey95 (talk) 04:02, 18 September 2016 (UTC)

Curious display

There's something curious about the display at Justice Society of America#Collected editions. In the table with the first row beginning with The Next Age, this template appears to be leaking some HTML of some sort. Any ideas? --Izno (talk) 04:33, 24 August 2017 (UTC)

Matthiaspaul made some significant changes to the template today. User:Jonesey95/sandbox2 has a simplified example that shows the problem. – Jonesey95 (talk) 04:38, 24 August 2017 (UTC)

Fixed. It was caused by a stray linefeed. --Matthiaspaul (talk) 08:45, 24 August 2017 (UTC)

False-positive {error} transclusion problem

Matthiaspaul: The recent changes are causing mass-false-positive {{error}} transclusions: Pages transcluding Template:Error

Can you fix this? Thanks, wbm1058 (talk) 05:21, 29 August 2017 (UTC)

Wbm1058‬: Thanks for the report. I just had a look but I'm not sure if we should really regard this as a problem, after all reporting transclusions (besides other links) is what WhatLinksHere is designed to do (and it does so not only in this case, but also with uncountable other templates), so IMHO showing these transclusions might not be particularly desirable here, but they are no "mass-false-positives" either. After all, WhatLinksHere is not some kind of "error tracking category". As far as I see it, the template does correctly populate the two specific tracking categories designed for this purpose. Or do I miss something here?

Either way, if there is consensus that this is undesired behaviour, one ad-hoc method to avoid it would be to replace the usage of the {{error}} template by hand-crafted HTML (as was done in a previous version of the template). However, from the software development point of view I think is is desirable to leave the actual formatting of error messages to a template like {{error}} for easier central maintenance. Perhaps it would be possible to tweak the template using <includeonly> or (safe)subst:, but I'd have to study their documentation first. Any ideas welcome. --Matthiaspaul (talk) 11:10, 29 August 2017 (UTC)

Matthiaspaul, you have two error tracking categories:

• Category:Pages with listed invalid ISBNs – 573 members
• Category:Pages with ISBN errors – 70 members
• Transclusion count – 3426 transclusions found.

I set up the {{error}}-transclusion patrol, and am the primary person working the patrol. This wasn't easy to do. It can be tricky coding work to avoid false-positive transclusions.

The idea is that I patrol one centralized report of errors... the transclusions. I am not aware of all of the dozens or hundreds of categories that have been set up, like the two for ISBNs listed above. I don't patrol those categories. Most of the time they should be empty, so constantly patrolling dozens of empty cats is a waste of time.

{{error}}s are problems of the highest severity level... think DEFCON 1. These generally get prompt attention. They should be easy to fix. There should be a big fat red message on the article making the location of the error easy to spot. The solution to the error should be relatively clear. Errors are often triggered by vandals. Revert the vandalism. Incorrect or omitted template parameters. Fix the parameters. At the other extreme are things like Category:Orphaned articles. Those are DEFCON 5. They take years to fix.

Before we take a look at how the {{error}} transclusions are triggered, let's take a look at the categories. I don't see the random members of these categories that I looked at transcluding {{error}}s. So apparently they are to be treated at lower level of severity/priority. It's not immediately obvious when looking at the members of these categories where the invalid ISBNs are. wbm1058 (talk) 12:13, 29 August 2017 (UTC)

Regarding the categories, Category:Pages with ISBN errors gets populated whenever the template detects an invalid ISBN. At the same time, the template will throw an error message at the location of the template in an article. In most cases, the errors are down to typos and therefore should be easy to fix. In some cases, however, an invalid ISBN turns out to be actually used in print. In these cases, the user can use the |invalid?= parameter (with ? indicating the parameter number) in order to mute the error message and suppress the population of the corresponding category. Instead, this will cause it to be listed in Category:Pages with listed invalid ISBNs semi-permanently (because there is no fix unless the same book gets reissued with a correct ISBN later on). This seems to work fine (and as desired) so far.

After reading your explanation I think that your usage of WhatLinksHere to detect errors quickly is a bit unorthodox (like relying on a sideeffect), but I see that it serves a good purpose and therefore it is desirable to avoid those transclusions showing up for you. Do you have any idea already how we can achieve that? --Matthiaspaul (talk) 12:43, 29 August 2017 (UTC)

So the {{error}}s all have big fat red messages: Great. I want to be able to quickly find these and fix them first; i.e. give them the highest priority. There is no category for these, which is OK.

The 573 members of Category:Pages with listed invalid ISBNs do not generate any error messages in the articles – these are the lowest priority.

The 70 members of Category:Pages with ISBN errors do generate messages, but these don't rise to the level of {{error}}s – these are middle priority.

e.g. {{ISBN|978‑1‑911576‑82‑2}} gives ISBN 978‑1‑911576‑82‑2

This more subtle message (I didn't notice it at first) is in the error_string that Template:ISBN passes to Module:Check isxn.

Now I see a third category: Category:Articles with invalid ISBNs. It's empty. What populates that? wbm1058 (talk) 13:49, 29 August 2017 (UTC)

I believe that Category:Articles with invalid ISBNs is no longer used, since there is no reason to insert {{Please check ISBN}} now that all ISBN-containing templates have error-checking. I think that the category and the "Please check" template can both be deleted. Rich Farmbrough may know something that I do not.

And since this discussion has been opened, my two cents is that the normal red "Invalid ISBN" is much more appropriate than the big fat text generated by {{error}}. An invalid ISBN is not a "house on fire" situation. It's a cleanup task, but not urgent. – Jonesey95 (talk) 14:09, 29 August 2017 (UTC)

I too found it a bit too fat, but since it exactly emulates the format used by the Mediawiki parser, I didn't override the default format of the {{error}} template at this stage.

The smaller style produced by your HTML before is supported by {{error}} as well, we'd just have to add the |tag=span parameter to it. If you ask me, sizewise I would prefer something between those two styles, but I'm happy to adjust to whatever people find more suitable.

Regarding that apparently unused Category:Articles with invalid ISBNs, I was wondering about that as well, but for my enhancements just tried to use whatever category were used before by {{ISBNT}} and {{Listed Invalid ISBN}}. --Matthiaspaul (talk) 14:26, 29 August 2017 (UTC)

For the moment I have marked the category and template as "historical". Please feel free to press them back into service if they become useful once again. All the best: Rich Farmbrough, 14:37, 30 August 2017 (UTC).

OK, now to work on the fix for my issue, I see this code:

{{#invoke:check isxn|check_isbn|{{{1|}}}|error={{error| Parameter error in {{tl|isbnt<!-- ISBNT -->}}: Invalid [[ISBN]].}}

and then that's duplicated eight more times: {{{2|}}}, {{{3|}}}, {{{4|}}}, etc.

OK, I need to look at the syntax for Module:Check isxn and how that works... wbm1058 (talk) 14:04, 29 August 2017 (UTC)

{{ISBN}} uses span class=error to generate the normal-sized red error text. It has worked for a long time. Is there a good reason to use {{error}} instead? In any event, I don't think the fat text is necessary. Perhaps using tag=span would improve the appearance of the error message. – Jonesey95 (talk) 14:14, 29 August 2017 (UTC)

Right, so one way to fix this is as Jonesey95 suggested... downgrade the severity and pass the same or similar argument as {{ISBN}} does. I don't mind this being made top priority if the error is expected to occur infrequently... I don't want frequently occurring errors to be made top priority because then clearing the queue becomes a time-sink, and these can push down the relative priority or time-to-fix for other errors. In any event, to solve my concern, an {{error}} transclusion cannot be passed as an argument to a lower-level template or module. You could pass a severity-code to the module, and then have the transclusion in Module:Check isxn itself... only transcluded when the error actually happens. – wbm1058 (talk) 14:26, 29 August 2017 (UTC)

I suggested to switch back to the manually crafted HTML as well already, however, I'd only see it as a stop-gap-measure because it would be so much more desirable to have some centrally maintained error/warning message framework used by lots (all) templates and if we need to change the format, it can be done in those few error message templates instead of having to go through uncountable templates and fix up some HTML in them.

I see, however, that the best solution would require touching the Lua code - that might be done at a later stage.

If I understood your usage example correctly, another possible workaround could be to introduce a new template for "small errors" like {{error-small}}. It could use more or less the same code as in {{error}}, but consequently it would not show up as transclusions of {{error}} when you perform WhatLinksHere for {{error}}, right?

--Matthiaspaul (talk) 14:50, 29 August 2017 (UTC)

I was also thinking about something like {{minor error}} or {{error message}} as a fix for this problem. I think it's more elegant to use a template for consistency instead of a span tag, but it appears that {{error}} is only for big problems. Perhaps the documentation for {{error}} should reflect that desire more effectively. – Jonesey95 (talk) 16:02, 29 August 2017 (UTC)

The problems don't necessarily need to be "big", but they should be easy to diagnose and fix, without requiring much subjective judgment on how to fix it. For example, common errors are using {{IMDb}}, getting the month, day and year parameters in the wrong order in {{birth date}} and putting {{subst:Requested move}} on an inappropriate page. If you just want to put out a message without tracking its use, then you could just use an existing template like {{strongbad}} sometimes I replace {{error}} with {{strongbad}} to "clear/whitelist the error transclusion". Or you could use {{Red}} for a red message. In general {{error}}s are user errors, not content errors. – wbm1058 (talk) 16:45, 29 August 2017 (UTC)

The philosophy behind this is to proactively help clueless editors who don't understand how to use the correct template syntax. Or to revert vandals who intentionally use bad syntax. – wbm1058 (talk) 16:54, 29 August 2017 (UTC)

ISBN errors do not fit this "easy to fix" frame. Some of them are quite subtle; understanding ISBNs and how to fix them takes some experience and expertise. – Jonesey95 (talk) 17:14, 29 August 2017 (UTC)

There are some {{error}}s that require more expertise/experience than others. As I'm the main guy working this beat, it's OK as long as I can figure it out. Sometimes I let some less-frequently occurring ones that aren't obvious linger for several days, hoping someone else will fix it. Eventually, I give up waiting and do the necessary research to solve the problem. Another common {{error}} is submitting a {{Proposed deletion}} when there is a previous {{Afd}} existing for the title. wbm1058 (talk) 17:24, 29 August 2017 (UTC)

Yes, replacing {{error}} with {{error-small}} solves my problem. Thanks, wbm1058 (talk) 19:00, 29 August 2017 (UTC)

changes to Module:Check isxn

Please see the discussion at Template talk:ISBN § changes to Module:Check isxn.

—Trappist the monk (talk) 16:08, 16 October 2022 (UTC)