Template talk:LCCN

Manipulating single parameter.

I saw your request on the Wikipedia:Help desk. Unfortunately Wikipedia does not have string manipulation capabilities currently. So the only way to convert '89-456' to '89000456' would be a massive switch containing every possible input combination of digits and the resulting output digits. The most efficient way would be to have the numbers before and after the dash as separate parameters (i.e. |89|456) and then logic to convert the 'after dash' number into the 'leading zeros' form, but even that would require a switch with one-hundred thousand conditions (0 to 99999)... which is probably not computationally feasible. Finally, you could do it as three parameters (i.e. |89|000|456) and then combine different elements for the link and display. I made the second parameter optional, but I'm not sure if it is precisely what you wanted. {{LCCN|89000456}} now produces: LCCN 89-456... Wikipedia automatically numbers external links if no text is included. Is that what you wanted? I don't think so because that's what a blank second parameter would produce also. --CBDunkerson 12:18, 4 April 2006 (UTC)[reply]

Thanks for explaining, I'll change it back to having p2 required. -- Jeandré, 2006-04-08t19:16z

I made a change to use three parameters because it should actually be shorter than two. That is; '|89|000|456' vs '|89000456|89-456'. Only problem would be items where the section after the '-' is six characters long. Those should be input as '|99||123456'... using a blank second parameter. Let me know what you think. --CBDunkerson 00:06, 12 April 2006 (UTC)[reply]

Excellent, thanks. -- Jeandré, 2006-04-12t17:32z

Feature request

I've asked that a function be written to handle the number conversion automatically. This implementation is far too klunky for regular people to use. A simple function built into the software should solve the problem, and it's not without precedent. We already have things like ISBN 0-123-4567-89 and urlencode: ({{urlencode: ≠/ab ?c 132}} outputs %E2%89%A0%2Fab+%3Fc+132, for instance).

See Bugzilla: 8160: ParserFunction for Library of Congress Control Numbers (LCCN)

Vote for it if you like the idea. — Omegatron 16:10, 5 December 2006 (UTC)[reply]

Letter prefix.

Hi, I tried and failed to use the template to access this resource: [1]. The "sa " prefix on the LCCN confuses the template. Anyone know the fix for this? John Vandenberg 22:46, 24 February 2007 (UTC)[reply]

Add "%20" between the letters and first numbers: {{LCCN|sa%2065|00|3567}} LCCN sa%2-65 – 00. It's not pretty, but works. Hopefully we can fix the template to handle it better. -- Jeandré, 2007-02-25t18:14z

Using a "+" sign instead of "%20" works as well and looks slightly better. The proper solution is using urlencode. This is very easy to implement in the template. However, it would require someone to remove the "%20" thingies from all the articles where they have been added. --217.232.144.201 20:43, 30 November 2007 (UTC)[reply]

LCCN permalinks

Could this template be updated to use the LCCN Permalink (LCCN Permalink FAQ) instead of performing a search at http://catalog.loc.gov? It may be that the permalink feature wasn't available when this template was created, or perhaps there's another reason that permalinks wouldn't be suitable. Quale (talk) 10:05, 17 February 2008 (UTC)[reply]

Done - thanks for suggesting this improvement. I've tested the new version with the 3 /doc examples and the first "What links here" implementation at Asteraceae#References, and they all work, but if it broke something else please revert the edit. -- Jeandré, 2008-02-17t10:28z, -- Jeandré, 2008-02-17t10:30z, -- Jeandré, 2008-02-17t10:39z

single-parameter template

Instead of dealing with all of the stupid parameters in this template, why not just make a single-parameter template to handle 6, 8, 10, and however many digits? It's lame having to do {{lccn|12||345678}} instead of just {{lccn|1234567}}; thus, {{lccn8}}. And, better yet, why not just code this template to detect the # of digits and adjust the output accordingly (if it's even necessary)? LCCN 1234567890 and LCCN 123456 work fine anyway so it should probably be moved to {{lccn1}} or whatever. —Eekerz ^(t) 09:04, 20 April 2010 (UTC)[reply]

Bad gateway

Hi. The instructions say "number after the dash is not 6 digits long, enough zeroes to make it so". I tried that with LCCN 83-0 – 051 (the zero is added) but get no link. Any help? Thanks. -SusanLesch (talk) 18:56, 4 May 2010 (UTC)[reply]

Best I could do is work around it: LCCN 83-51331 which at least reads. You can reach my on my talk page if there's a reply. Thanks. -SusanLesch (talk) 19:04, 4 May 2010 (UTC)[reply]

Template with 1 parameter

You can use padleft to fill the missing zeros. {{padleft:{{{3}}}|6|0}}. When using #expr you can convert a given number 89-456 to 89000456: {{#expr:{{{1|0}}}*0}}{{padleft:{{#expr:0*{{{1|0}}}*-1}}|6|0}}: 80.143.88.200 (talk) 19:24, 29 October 2010 (UTC)[reply]

Legacy cleanup?

What exactly would be needed to cleanup that backlog? This seems to be very bot-friendly. Headbomb {talk / contribs / physics / books} 01:19, 22 March 2012 (UTC)[reply]

Is it even necessary? The links still seem to work. But I agree it seems to be a bot-friendly task. -- Alan Liefting (talk - contribs) 01:48, 28 May 2012 (UTC)[reply]

RFC: Should we display LCCNs according to new-style rules, or old-style rules?

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Since 2003, the Library of Congress started normalizing LCCNs according to these rules, with the motivation that having half a million standard for controls numbers was a bit silly. So if you find some old source with an old-style LCCN on it (i.e. LCCN 85-2), when you follow the link you are presented with the normalized (modern) LCCN (i.e. LCCN 85000002). I think this is a bit confusing for those who aren't intimately familiar with LCCNs. But worse if you take a source with a new-style LCCN, such as LCCN 85000002, it will be erroneously be displayed as LCCN 85-2 on Wikipedia, and you will be taken to a page that says LCCN 85000002, which will lead to great puzzlement as to why Wikipedia displays things as LCCN 85-2. Therefore I think we should just bite the bullet and embrace the modern LoC's standard for our own articles. Headbomb {talk / contribs / physics / books} 01:56, 22 March 2012 (UTC)[reply]

Support for new-style

Support, as proposer. Headbomb {talk / contribs / physics / books} 03:51, 22 March 2012 (UTC)[reply]
/ƒETCH COMMS / 14:57, 22 March 2012 (UTC)[reply]
Support per nom. – Allen4names 16:53, 22 March 2012 (UTC)[reply]
Support: No reason not to. Whenaxis (contribs) 00:49, 23 March 2012 (UTC)[reply]
Support. Common sense. Jafeluv (talk) 10:14, 23 March 2012 (UTC)[reply]
Support. It's a no-brainer (so, zombies won't like it >;-). — SMcCandlish Talk⇒ ɖ∘¿¤þ Contrib. 09:28, 26 March 2012 (UTC)[reply]
Support - Whatever will make the LOC's online lookup the easiest to use. The new format seems best. EdJohnston (talk) 00:01, 29 March 2012 (UTC)[reply]
Support as perfectly rational. Imzadi 1979 → 09:32, 29 March 2012 (UTC)[reply]

Support for old-style

Discussion

These numbers add nothing but clutter and should not be used at all. Same with ISBNs, OCLC numbers. None of that information is of the slightest functionality to Wikipedia users. Real life book searches are done by Author + Title, sometimes incorporating Publisher and Date. Never LCCN, never OCLC, never ISBN. All of these manifestations of number worship and empty linkage based thereon is obsessive-compulsive behavior at its worst, in my opinion. Of course, there is no RFC option to negate this entire discussion. Inertia and clique decision-making rules at WP. Carrite (talk) 20:19, 22 March 2012 (UTC)[reply]

For my money, I can say I do use ISBN's, usually if I have one reference to a book and want to find out about it somewhere else, ie, I have a book want to look it up on Amazon to see reviews. I'd say I do that about once every couple months for some reason or other. Of course, title-based searches are the norm, but I don't think I have ever seen anyone search using Publisher and Date. Usually if the author+title are too ambiguous, people give up Jztinfinity (talk) 04:51, 23 March 2012 (UTC)[reply]

I for one always use ISBNs when available, and know very little who would rather search things Author+Year+Title+Publisher instead of searching things via ISBN (or similar). Plus, this is the age of the internet, if you insist on doing manual searches on Amazon for something like Harrisson, MA (2007), Light, Spectra, ISBN 978-0553587333 using Author+Year+Title+Publisher (which is a very error-prone method, especially if someone makes a mistake), rather than just click on the ISBN and select Amazon option, they really are masochists. Even if you are reading a printed version of Wikipedia, searching via ISBN is still way easier than searching for Author+Year+Title+Publisher. Anyway, like it or not, ISBNs and LCCNs are used, and they won't go away anytime soon. Headbomb {talk / contribs / physics / books} 14:55, 23 March 2012 (UTC)[reply]

I too use ISBNs all the time, especially when looking for specific editions (this is usually necessary when doing source verification; different editions usually have different pagination). I know academic types like to use OCLCs, LCCNs and various other more "geeky" source identifiers for various useful purposes. That said, the fact that they are seen as annoying clutter by some editors suggests we should have a span class, perhaps source_ext_id that can be applied to all such things so that editors who detest them can make them invisible with their own CSS. PS: Because this template is an LCCN template, it has to do one LCCN format or the other. The third option that Carrite wants cannot be an RfC option, since this template can't do nothing. The way to pursue that option is to take the template to WP:TFD for deletion. (I predict a "keep" result.) — SMcCandlish Talk⇒ ɖ∘¿¤þ Contrib. 09:26, 26 March 2012 (UTC)[reply]
To everything there is a season... and ISBNs/ISSNs/OCLCs, etc all have a useful purpose. Since this RfC is related to a specific template with a specifyic function, the option requested is not possible since the template has to do something. Imzadi 1979 → 09:33, 29 March 2012 (UTC)[reply]

End

Alright, normally I wouldn't close this myself, since I initiated the discussion, but since it's been open for over a week and no one objected, I'm going to close this and get the various templates updated to use the new style. Headbomb {talk / contribs / physics / books} 16:03, 31 March 2012 (UTC)[reply]

The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Citation/identifier

{{Citation/identifier}} duplicates this and other templates. Why not just use it as a core so we only do updates in one place? ---— Gadget850 (Ed) ^talk 12:42, 30 April 2012 (UTC)[reply]

I suppose it could be done that way. There still needs to be a way to implement the behaviour mentioned in the RFC though.... Headbomb {talk / contribs / physics / books} 18:45, 30 April 2012 (UTC)[reply]

Some do not work

{{LCCN|unk81||031593}}LCCN unk8-1 works, but {{LCCN|unk81031593}}LCCN unk8-103159 does not work. Template gets confused and removes last number.

I fixed the pages like this by using {{lccn8}} instead. AManWithNoPlan (talk) 01:04, 15 June 2012 (UTC)[reply]

Remove legacy support and fix new support

Nothing seems to be using legacy mode anymore, I suggest we delete it to clean up the template. Secondly, newer LCCN's do not work with this template, but they do with {{lccn8}}. Time to fix this template to work with new ones too? AManWithNoPlan (talk) 23:36, 19 January 2015 (UTC)[reply]

Something

Done this week.

Does this revision break every inline use of the template? --or inline use within a bullet point? For instance there are two in biography section Laura Ingalls Wilder#Other works, one in "(Publisher, year, {LCCN})" context and one other.

--P64 (talk) 21:49, 14 November 2015 (UTC)[reply]

Fixed. Awesome catch. AManWithNoPlan (talk) 22:45, 14 November 2015 (UTC)[reply]

I also added a test to the test cases AManWithNoPlan (talk) 23:05, 14 November 2015 (UTC)[reply]

RFCs on citations templates and the flagging free-to-read sources

See

Headbomb {talk / contribs / physics / books} 17:06, 29 October 2016 (UTC)[reply]

Chronicling America

The Library of Congress's Chronicling America project uses LCCNs, but many of these LCCNs are not recognized by lccn.loc.gov. This seems to be because the LCCN server only serves up results for LoC holdings, and LCCNs starting with "sn" are part of CONSER and "may or may not be in LC". As a result, even though there is a responsive LoC page for these LCCNs, this template frequently points to an empty search results page instead.

Example 1 (not in LoC, in Chronicling America): LCCN sn90-51192 ("Your search found no results") - Chronicling America page
Example 2 (in LoC, also in Chronicling America): LCCN sn82-14988 - Chronicling America page

Would it be feasible for this template to take parameter to specify that it should link out to chroniclingamerica.loc.gov rather than lccn.loc.gov? -- Visviva (talk) 18:00, 23 December 2019 (UTC)[reply]

Update: as {{LCCN8}} is a better fit for my current use case (lists of newspapers), I've posted on Template talk:LCCN8#Adding_option_for_Chronicling_America and prepared a possible solution here. However, I would imagine I'm not the only one to get tripped up by this issue, so it might be good if there was a fix for {{LCCN}} as well. -- Visviva (talk) 19:05, 23 December 2019 (UTC)[reply]

@Visviva: This is an extremely late response but a probably better solution would be to link with the prefix https://www.loc.gov/item/ instead of the current https://lccn.loc.gov/, in much the same way as Library of Congress Control Number (LCCN) (bibliographic) (P1144) at Wikidata does. This would mean your examples would link as: LCCN sn90-51192 and LCCN sn82-14988. I shall try to look at this in the not too distant future but I notice there is code in there for some sort of non-ID lookup so not sure how to handle that just yet (I should probably add some tracking for such usage and see if anything is using that to begin with). —Uzume (talk) 22:46, 11 May 2024 (UTC)[reply]

@Visviva: I fixed your examples from above and added some tracking for the strange (and hopefully unused) case I am investigating. —Uzume (talk) 18:42, 12 May 2024 (UTC)[reply]