Template talk:Authority control

From Wikipedia, the free encyclopedia
Jump to navigation Jump to search

Discussion example of the new look after the RfC[edit]

The RfC on the changed look of this template, to make it more reader-friendly, has been closed as "succesful"[1]: "There's a strong support for an overhaul of the authority control template that uses human-readable names of the resources, in the interest of being recognizable to more editors. There is general support that Fram's proposal is preferable to the current version, but not any consensus on the exact form that an improved version might take. " (there is more, but that's a separate discussion).

For convenience, I have created a "full" version of the template with all currently possible IDs included. Note that not a single article will end up with the template like this; a fair number of the IDs are very specific ones that only end up on a small number of articles, so most articles will have a much more manageable, smaller template than this.

Feel free to improve this example: but if you want to propose something which follows the RfC result but is clearly different from my proposal, please make your own version. Some notes: I have not created a separate "music" section, as the many MusicBrainz links never appear together on one article: usually you get one, at most two of them. In the future, separate sections for e.g. music or sport may of course become necessary. I have tried to find a balance between labels which are short yet clear enough to give a layperson some idea of what to expect, but this wasn't possible in all cases.

Like I said, all comments and improvements welcome, this is not a final version but a starting point. Fram (talk) 15:35, 2 April 2021 (UTC)

Redesign: multiple IDs[edit]

How do we show multiple IDs?   ~ Tom.Reding (talkdgaf)  17:20, 2 April 2021 (UTC)
Is this even necessary? I know that there are some cases where you indeed have multiple IDs for the same thing, but a) this undermines the unique identifier ID of authority control, b) adds little or nothing for our readers and c) makes things a lot more complex. Simply using the first (preferred) ID from Wikidata seems sufficient. Fram (talk) 07:47, 6 April 2021 (UTC)
Category:Wikipedia articles with multiple identifiers (49,142), currently 43,732.   ~ Tom.Reding (talkdgaf)  11:04, 6 April 2021 (UTC)
I don't doubt that it exists, now. I wondered if it was necessary. Random example, Sarah Aaronsohn, has 5 IDs at the National Library of Israel. So this is not actually a real authority control for Aaronsohn, but a group of pages related to her. And frankly, all 5 are useless. So why should we spend effort in providing these 5? Lasse Åberg has two links to the Swedish national library, both are basically empty, but one is for Lars-Erik Åberg. Same person? Related? No idea, and neither won't anyone directed to that second page. Worth the extra effort? No. The Abbasid dynasty has three VIAF codes. This is an error at VIAF side, not here. Show one and be done with it. Fram (talk) 12:08, 6 April 2021 (UTC)
See proposal @ Template:Authority control/testcases#Multiple IDs (proposed).   ~ Tom.Reding (talkdgaf)  11:58, 28 April 2021 (UTC)
Thanks. While I still think this is unnecessary (just showing one link is in most cases better), it seems like a good way to present it if people want this. Fram (talk) 14:00, 28 April 2021 (UTC)
I also agree that this is unncessary, and it seems to have been added on February 14 (Special:Diff/1006784035) with no discussion I can find other than Template talk:Authority control/Archive 11#Multiple IDs from Wikidata now allowed/appended, which recieved no comments by anyone else. This is a contested (by Fram) bold edit that was evidently not uncontroversial. * Pppery * it has begun... 16:11, 28 April 2021 (UTC)
Look harder; I know you can. It's kinda been a known-problem for at least 8 years.   ~ Tom.Reding (talkdgaf)  23:45, 28 April 2021 (UTC)
I've decided to implement multiple IDs anyway in the sandbox, using a slight variation on your proposal, on the grounds that I shouldn't let this dispute hijack the implementation of the original RfC. This should now be ready to sync once the authority control files TfD is closed (and it's overdue for closure by about an hour and a half at the time I write this comment) * Pppery * it has begun... 02:38, 1 May 2021 (UTC)

Redesign: multiple QIDs[edit]

How do we show multiple QIDs from has part (P527) & part of (P361)? Previous solution above @ Template talk:Authority control/Archive 11#Articles which cover more than one thing.   ~ Tom.Reding (talkdgaf)  17:23, 2 April 2021 (UTC)
We don't. The authority control should match the article, not "be a part of" or "has parts". We wouldn't include these two if there is a direct match (I mean, you wouldn't add a "Beatles" id to the article of Paul McCartney, who is also part of Wings and probably a few other things; and you wouldn't add the IDs of John, Paul, George and Ringo to the authority control of The Beatles). In any case, this is separate from the redesign: the proposed solutions of having basically an option to have either an override of the QI, or a default one and an additional one with an extra QID, work equally well in the old and the new design. Fram (talk) 07:53, 6 April 2021 (UTC)
Bonnie and Clyde problem. ~28,000 pages use some combination of has part (P527) and/or part of (P361).   ~ Tom.Reding (talkdgaf)  11:04, 6 April 2021 (UTC)
And? Like I said, any solution for this should work equally well in the old and the new design surely, as this is independent of the labels and groupings proposed? Whether it is even wanted is a separate discussion, but has no relation to the redesign. Fram (talk) 12:10, 6 April 2021 (UTC)
Wouldn't it make more sense to use the template two or more times with a parameter to indicate what subtopic it is authority control for? - Jmabel | Talk 14:25, 24 April 2021 (UTC)
@Jmabel: this opens up a can-o-worms. See above @ Template talk:Authority control/Archive 11#Articles which cover more than one thing.   ~ Tom.Reding (talkdgaf)  12:02, 28 April 2021 (UTC)
I'm not seeing what makes this a can of worms, other than Tom.Reding declaring unilaterally in that section that Jmabel's solution (which was also proposed independently by MSGJ in that section and by at least two other editors in the talk archives) is out of the question and a non-starter. It appears consensus may be in favor of doing just that, despite his objections * Pppery * it has begun... 16:11, 28 April 2021 (UTC)
It's funny how you looked so hard in the archives to find something here, yet failed to find anything above @ #Redesign: multiple IDs. Willful ignorance and/or intellectual bias at its most obvious.
Imagine the consequences of a |QID= parameter, and how much more chaotic it would be than |part= (I've described them above in the same section, which you've "read"). If you cannot, I suggest focusing your efforts elsewhere.   ~ Tom.Reding (talkdgaf)  23:45, 28 April 2021 (UTC)

Redesign: parameter names[edit]

Yet another problem that wasn't even described in the RfC has unintended consequences:
  1. The parameter name is removed from the rendered page, making it much less intuitive/obvious how to either add an ID or suppress the existing.
  2. All links to Wikipedia pages about the institutions are removed (and links to all {{R from identifier}} type pages).
How do we address that?   ~ Tom.Reding (talkdgaf)  11:44, 4 April 2021 (UTC)
This was discussed in the RfC. The template documentation should be improved to indicate how this needs to be done (for the first issue), and for the second, yes, that's a small disadvantage which is (per the consensus at the RfC) outweighed by the benefits of the new design. You are free to create a mockup that respects the outcome of the RfC and adresses your concerns of course. Fram (talk) 07:57, 6 April 2021 (UTC)
This was only discussed in my thread, not voted on by the vast majority of participants. The RfC did not weigh the advantages & disadvantages, and cannot be used as such.   ~ Tom.Reding (talkdgaf)  11:04, 6 April 2021 (UTC)
I think you underestimate the voters in the RfC here. Certainly the second issue you raise was clearly decided by the RfC: the first issue is needs better explanation at the documentation page. Re-litigating the RfC here won't really change the outcome. Fram (talk) 12:12, 6 April 2021 (UTC)
Re: "underestimate": I indeed estimate (as we are forced to) that most voters didn't read through the comments to pick out the nuances that they may or may not have been aware of. The cons & consequences of your redesign weren't described at all. As such, there is no consensus when it comes to broad implementation, because it wasn't actually discussed. Your RFC wasn't pointless, though, as it's a first step towards a second, more thorough, RFC, and/or further discussion here on how to address all these problems above. "There is no problem" is not a solution, though.   ~ Tom.Reding (talkdgaf)  11:56, 8 April 2021 (UTC)
Feel free to raise this with the closer of the RfC or at WP:AN. Until then, the RfC actually closed in favour of this, and the consequences were accepted. If you have an actual proposal that respects the RfC and actually improves the design, feel free to present it. Simply stonewalling though won't change anything. Fram (talk) 12:17, 8 April 2021 (UTC)
Per the close, "but not any consensus on the exact form that an improved version might take", and "the exact form that an improved version might take" is exactly what we're trying to (I think) discuss here. "No solution" will indeed change nothing.   ~ Tom.Reding (talkdgaf)  12:39, 8 April 2021 (UTC)
The exact form, no, that's what we're discussing. But your objections so far seem more like "let's get back to the old format". It would probably help if you presented some example of what you have in mind (doesn't need to be a full one, just a mockup with a few links which incorporates the RfC close and your objections/improvements). Fram (talk) 12:55, 8 April 2021 (UTC)
To be honest here, looking at the wikilinks/pageview stats of the various (identifier) redirects I don't think the second issue is a problem anyway, it seems that these links were basically never getting used. Looking at a few examples
  • RERO (identifier), 17,968 incoming links, Median 210 page views a month. In the average authority control template the link gets clicked once every 7.13 years.
  • NKC (identifier), 166,311 incoming links, Median 1,012 page views a month. n the average authority control template the link gets clicked once every 13.69 years.
  • NLG (identifier), 19,282 incoming links, Median 192.5 page views a month. In the average authority control template the link gets clicked once every 8.35 years.
  • WorldCat Identities (identifier), 844,173 incoming links, Median 3528 page views a month. In the average authority control template the link gets clicked once every 19.93 years.
I really don't think it's worth having all these links to the institutions when the average link gets used once a decade, and with Fram's proposed redesign a lot of the reason for having these links in the first place vanish, as readers will no longer be left wondering "what is NLG, who operates it?", it's immediately obvious that it relates to the national library of Greece. 86.23.109.101 (talk) 21:37, 12 April 2021 (UTC)
Now sure what IP's math is for "once every X years" nonsense, but here is the Pageviews Analysis for all 4 examples aggregated monthly over the last year. Shows significant usage.   ~ Tom.Reding (talkdgaf)  12:08, 28 April 2021 (UTC)
The IP means "one view per article using the identifier per X years". * Pppery * it has begun... 18:12, 28 April 2021 (UTC)

Anyone willing to implement this?[edit]

So, we have had some small improvements to the proposed version, and some comments, but discussion seems to have died down. Anyone here willing to implement this? Fram (talk) 13:50, 21 April 2021 (UTC)

There's been no progress on the above implementation issues, despite your lying/mischaracterization of the situation.   ~ Tom.Reding (talkdgaf)  14:12, 23 April 2021 (UTC)
So? Like I said, 2 isn't an issue at all, 3 is an issue that has been decided by the RfC, and 1 is as far as I can tell not an issue either, but a feature of the new design. I don't expect you to implement this, considering that we are all volunteers and you oppose this (even though you are welcome to implement it anyway of course), but the above issues are no reason to stop this at all. Fram (talk) 14:23, 23 April 2021 (UTC)
I have no problems implementing a solution, when we have one.   ~ Tom.Reding (talkdgaf)  14:27, 23 April 2021 (UTC)
Ah, personal attacks, that will help. Fram (talk) 14:37, 23 April 2021 (UTC)
Indeed, this does seem like an attempt to force your own viewpoint by refusing to implement anything else. It didn't work, though, because someone else was willing to do the implementation. * Pppery * it has begun... 15:32, 23 April 2021 (UTC)
I've made an attempt at implementing this at Module:Authority control/sandbox. There's something screwed up with identifier validation and WorldCat that I can't quite figure out right now, but it mostly works. As for the technical details discussed above, I completely dropped support for multiple instances of the same identifier. Other issues I ran into during implementation are that Fram didn't include autores.uy in the complete table above, so I stuck it in Other with the label "autores.uy" (which can be changed easily), and I wasn't sure what to do if an article had no identifiers in the "General" section, which makes there be no obvious place to put the link and Wikidata pencil. * Pppery * it has begun... 15:39, 23 April 2021 (UTC)
Thanks! Autores.uy was an oversight. Would it be possible and helpful if instead of starting with "Authority control: general", we would move "Authority control" to a "header" position" and used "General" as the label for the first section? Comparable to (random example) Template:Peter Paul Rubens, where "Peter Paul Rubens" at the top would be replaced by "Authority Control" plus the pencil? Fram (talk) 15:45, 23 April 2021 (UTC)
Implemented. * Pppery * it has begun... 15:54, 23 April 2021 (UTC)
Thanks, great! There seems to be an issue in the testcases in the section "Suppression via null params", where the new version generates some errors where the old version doesn't. Otherwise, it seems to work as expected. Takes up some more vertical space (at the bottom of articles), but is much more reader-friendly. It can always be made auto-collapsed if necessary, but that's outside the scope of the RfC change and would need another discussion. Fram (talk) 16:11, 23 April 2021 (UTC)
Yes, that is the There's something screwed up with identifier validation and WorldCat that I can't quite figure out right now, which I've now fixed. Actually, my original implementation autocollapsed like all other navboxes, and then BrandonXLF changed it to always expand for reasons I don't understand, and I reverted him (before seeing your comment) on the grounds that I saw no reason to deviate from the standard navbox behavior. I don't personally have a strong opinion on whether it is expanded or collapsed, and don't mind if someone re-reverts me. * Pppery * it has begun... 16:17, 23 April 2021 (UTC)
I changed it because the current authority control is always "expanded" as in the links are always visible, but the new title row does make it larger than the current template. BrandonXLF (talk) 16:19, 23 April 2021 (UTC)
Fram, maybe it would be better to move "Authority control" to the left of the template? I created an example at User:BrandonXLF/K. The issue with having it at the top is it makes the template significantly taller, it different very different from the current authority control template, and it can cause confusion since it looks too similar to an actual navbox, which this isn't really since it exclusive links to other sites. BrandonXLF (talk) 16:27, 23 April 2021 (UTC)
That looks good as well. Pppery, would this be feasible (and do you like it)? I just wonder if it wouldn't look a bit strange on the (many) instances where we wll only have one "subheader"? Certainly worth a try! Fram (talk) 16:29, 23 April 2021 (UTC)
In terms of feasability, doing that is trivial. It personally looks a little odd to me, but that's probably just because I coded the vertical-header option so am used to it and shouldn't be decisive. As for cases with only one subheader, one idea would be to go back to the originally-proposed format and say Authority control: National libraries as one header if only national libraries are present, for example, thus producing something like for a template with only a BIBSYS identifier (and using Brandon's format as currently implemented for cases with more than one header). * Pppery * it has begun... 16:44, 23 April 2021 (UTC)
Looks good. Specifically for Norway, I guess simply "Norway" is sufficient, the (BIBSYS) part can go, it isn't included for other national libraries. Fram (talk) 12:52, 24 April 2021 (UTC)
Implemented the above format (with the tweak that if the only section is "General" or "Other" it omits the section label as either pointless or redundant). Note that "Norway (BIBSYS)" was what you labelled it as in your table at the top of the section, which is why I included it with that title (I've now changed it to just Norway). * Pppery * it has begun... 13:29, 24 April 2021 (UTC)
Pppery, upon further inspection, it does seem a little odd-looking. I found Template:Taxonbar, and I think the format it uses when it has multiple groups could work well for this, see User:BrandonXLF/K/testcases. BrandonXLF (talk) 07:19, 25 April 2021 (UTC)
That formatting works for me. But, now that you brought up {{taxonbar}}, it may also be due for a redesign to make more reader-friendly in the same way {{authority control}} is. Implementing that would also require finding a solution to #Redesign: multiple QIDs above. Anyway, we should probably stop arguing over what color to paint the bikeshed now. * Pppery * it has begun... 14:51, 25 April 2021 (UTC)
I've now gone ahead and implemented that proposal in Module:Authority control/sandbox * Pppery * it has begun... 13:48, 26 April 2021 (UTC)
So, which section should autores.uy go in, and what should it be titled as? I was implicitly asking that earlier, and the question appears to have gotten lost in the formatting sidetrack above, so I'm restating it explicitly. * Pppery * it has begun... 00:55, 24 April 2021 (UTC)
Under the "biographical dictionaries", title "Uruguay"? It's something halfway between "national library" and "biographical dictionary", could go either way. Fram (talk) 12:50, 24 April 2021 (UTC)
Implemented. I believe the only things left to resolve before this is ready to be synced are #Duplicate Poland national library identifiers and possibly the TfD I started of {{Authority control files}}, which is automatically generated based on the data stored in Module:Authority control in a way that would need rewriting if there is consensus to keep the navbox. * Pppery * it has begun... 13:29, 24 April 2021 (UTC)
Thanks. I think the solution you suggested below for the Polish ones is the correct way to proceed, so that can be implemented as well. So then we only need to wait for the closure of the AC files TfD. Fram (talk) 08:27, 26 April 2021 (UTC)
Well, that and #Documentation table, which should be straightforward but probably should get at least some discussion. * Pppery * it has begun... 13:48, 26 April 2021 (UTC)

Duplicate Poland national library identiifers[edit]

There are currently 33,000 articles that have both NLP and PLWABN identifiers. Under the rewrite (both in Fram's original proposal and in my implementation), both of these display as "Poland" in the national libraries section, which would result in two links with identical labels. That seems undesirable to me. What should be done about this? * Pppery * it has begun... 23:55, 23 April 2021 (UTC)

It appears from reading d:Property:P7293 and d:Property:P1695 that NLP IDs are deprecated by the national library in favor of PLWABN IDs, so maybe don't show NLP at all if PLWABN is present? That would be pretty easy to implement. * Pppery * it has begun... 00:02, 24 April 2021 (UTC)
Done the above per Fram's post in the previous section. * Pppery * it has begun... 13:48, 26 April 2021 (UTC)

Discussion at Wikipedia:Templates for discussion/Log/2021 April 24 § Template:Authority control files[edit]

 You are invited to join the discussion at Wikipedia:Templates for discussion/Log/2021 April 24 § Template:Authority control files. * Pppery * it has begun... 00:55, 24 April 2021 (UTC)

Documentation table[edit]

There is a giant table at Template:Authority control/doc#Wikidata and tracking categories that is currently generated automatically from this module, thus it's necessary to decide how it will look post-redesign before implementation in order to avoid extra edits to high-risk templates. The current sandbox code I wrote produces:

Parameter Section Appears as Wikidata property Tracking categories and page counts
Articles User pages Misc. pages Faulty IDs
AAG Art galleries and museums Auckland P3372: Auckland Art Gallery artist ID 1,801 0 7 0
ACM-DL Scientific databases Association for Computing Machinery P864: ACM Digital Library author ID 1,614 2 9 0
ADB Biographical dictionaries Australia P1907: Australian Dictionary of Biography ID 7,371 0 4 4
AGSA Art galleries and museums South Australia P6804: Art Gallery of South Australia creator ID 2,029 0 4 0
autores.uy Biographical dictionaries Uruguay P2558: autores.uy ID 792 0 4 0
AWR Biographical dictionaries Australian Women's Register P4182: National Natural Landmarks site ID 2,398 0 4 6
BIBSYS National libraries Norway P1015: BIBSYS ID 74,683 0 18 0
Bildindex Art research institutes Bildindex (Germany) P2092: Bildindex der Kunst und Architektur ID 127 0 4 0
BNC National libraries Chile P1890: CCAB ID 1,086 0 4 0
BNE National libraries Spain P950: Biblioteca Nacional de España ID 90,808 1 13 4
BNF National libraries France (data) P268: Bibliothèque nationale de France ID 298,395 2 68 2
Botanist Scientific databases International Plant Names Index P428: botanist author abbreviation 5,714 0 4 0
BPN Biographical dictionaries Netherlands P651: Biografisch Portaal van Nederland ID 7,306 0 4 0
CANTIC National libraries Catalonia P1273: CANTIC ID 29,733 0 5 0
CINII Scientific databases CiNii (Japan) P271: CiNii author ID (books) 29,949 0 13 0
CWGC Other Commonwealth War Graves Commission P1908: CWGC person ID 1,986 0 4 0
DAAO Art research institutes Australian Artists P1707: DAAO ID 986 0 4 9
DBLP Scientific databases DBLP (computer science) P2456: DBLP author ID 6,662 4 7 2
DIB Biographical dictionaries Ireland P6829: Dictionary of Irish Biography ID 5,311 0 4 0
DSI Art research institutes Scientific illustrators P2349: Stuttgart Database of Scientific Illustrators ID 3,423 0 4 0
FAST Other Faceted Application of Subject Terminology P2163: FAST ID 222,457 0 6 1
FNZA Art research institutes New Zealand Artists P6792: Find NZ Artists ID 1,065 0 4 1
GND General Integrated Authority File (Germany) P227: GND ID 400,662 26 403 3
HDS Other Historical Dictionary of Switzerland P902: HDS ID 9,456 0 7 0
IAAF Other World Athletics P1146: World Athletics athlete ID 19,590 0 4 0
ICCU National libraries Italy P396: SBN author ID 16,158 0 8 0
ICIA Art research institutes ICIA (Israel) P1736: Information Center for Israeli Art artist ID 464 0 4 0
IEU Other Internet Encyclopedia of Ukraine P9070: Internet Encyclopedia of Ukraine ID 607 0 4 2
ISNI General ISNI P213: ISNI 517,149 24 158 6
Joconde Art research institutes Joconde (France) P347: Joconde work ID 530 0 4 0
KULTURNAV Art research institutes KulturNav (Norway) P1248: KulturNav-ID 5,009 0 4 2
LCCN National libraries United States P244: Library of Congress authority ID 673,984 26 535 7
LIR Other Lexicon Istoric Retic (Switzerland) P886: Lexicon istoric retic ID 130 0 4 0
LNB National libraries Latvia P1368: LNB ID 20,677 0 4 0
Léonore Other Léonore (France) P640: Léonore ID 5,830 0 8 7
MA Other Microsoft Academic P6366: Microsoft Academic ID 44,898 1 5 3
MBA Other MusicBrainz artist P434: MusicBrainz artist ID 134,552 0 53 0
MBAREA Other MusicBrainz area P982: MusicBrainz area ID 29,351 0 4 0
MBI Other MusicBrainz instrument P1330: MusicBrainz instrument ID 755 0 4 0
MBL Other MusicBrainz label P966: MusicBrainz label ID 4,391 0 5 2
MBP Other MusicBrainz place P1004: MusicBrainz place ID 5,417 0 4 0
MBRG Other MusicBrainz release group P436: MusicBrainz release group ID 116,719 0 4 0
MBS Other MusicBrainz series P1407: MusicBrainz series ID 740 0 4 0
MBW Other MusicBrainz work P435: MusicBrainz work ID 26,148 0 4 0
MGP Scientific databases Mathematics Genealogy Project P549: Mathematics Genealogy Project ID 14,307 1 5 0
NARA Other National Archives (US) P1225: U.S. National Archives Identifier 21,513 0 4 0
NCL National libraries Taiwan P1048: NCL ID 540 0 5 1
NDL National libraries Japan P349: National Diet Library ID 57,593 0 28 0
NGV Art galleries and museums Victoria P2041: National Gallery of Victoria artist ID 2,883 0 4 1
NKC National libraries Czech Republic P691: NKCR AUT ID 168,637 0 19 1
NLA National libraries Australia P409: Libraries Australia ID 40,343 2 15 0
NLG National libraries Greece P3348: National Library of Greece ID 19,873 0 4 0
NLI National libraries Israel P949: National Library of Israel ID 49,364 0 13 0
NLK National libraries Korea P5034: National Library of Korea ID 32,409 0 7 0
NLP National libraries Poland P1695: NLP ID (unique) 2,266 0 2 0
NLR National libraries Romania P1003: National Library of Romania ID 155 0 4 3
NSK National libraries Croatia P1375: NSK ID 10,204 0 4 0
NTA National libraries Netherlands P1006: Nationale Thesaurus voor Auteurs ID 223,310 0 32 0
ORCID General ORCID P496: ORCID iD 12,099 434 76 1
PIC Art research institutes Photographers' Identities P2750: Photographers' Identities Catalog ID 10,197 0 4 1
PLWABN National libraries Poland P7293: PLWABN ID 122,541 0 7 0
Publons Scientific databases Publons (researchers) P3829: Publons author ID 1,890 0 9 1
RID Scientific databases ResearcherID P1053: ResearcherID 2,695 23 18 4
RISM Other RISM (France) P5504: RISM ID 10,377 0 4 0
RERO Other RERO (Switzerland) P3065: RERO ID 22,217 0 10 13
RKDartists Art research institutes RKD Artists (Netherlands) P650: RKDartists ID 34,803 0 9 0
RKDID Art research institutes RKD ID (Netherlands) P350: RKDimages ID 1,010 0 4 0
RSL National libraries Russia P947: RSL ID (person) 880 0 8 0
SELIBR National libraries Sweden P906: SELIBR ID 38,945 0 28 3
SIKART Art research institutes SIKART (Switzerland) P781: SIKART ID 1,166 0 4 0
SNAC-ID Other Social Networks and Archival Context P3430: SNAC ARK ID 130,908 0 4 1
SUDOC Other SUDOC (France) P269: IdRef ID 240,146 7 62 0
S2AuthorId Scientific databases Semantic Scholar P4012: Semantic Scholar author ID 1,516 3 7 0
TA98 Scientific databases Terminologia Anatomica P1323: Terminologia Anatomica 98 ID 3,311 0 4 0
TDVİA Other Encyclopedia of Islam P7314: TDV İslam Ansiklopedisi ID 2,059 0 5 1
TePapa Art galleries and museums Te Papa (New Zealand) P3544: Te Papa agent ID 3,497 0 4 0
TLS Other Theaterlexikon (Switzerland) P1362: Theaterlexikon der Schweiz ID 577 0 4 3
Trove Other Trove (Australia) P1315: NLA Trove ID 64,789 2 7 7
UKPARL Other UK Parliament P6213: UK Parliament identifier 2,546 0 4 6
ULAN Art research institutes Artist Names (Getty) P245: Union List of Artist Names ID 46,326 0 15 0
USCongress Other US Congress P1157: US Congress Bio ID 12,873 0 4 0
VcBA National libraries Vatican P8034: Vatican Library VcBA ID 40,954 0 4 5
VIAF General VIAF P214: VIAF ID 906,734 98 1,142 4
WORLDCATID General WorldCat P7859: WorldCat Identities ID 759,882 1 16 0
General WorldCat (via Library of Congress) 3,700
General WorldCat (via VIAF) 147,600

Does that look good to everyone else? * Pppery * it has begun... 13:48, 26 April 2021 (UTC)

I like the addition of the Section column.   ~ Tom.Reding (talkdgaf)  13:59, 26 April 2021 (UTC)
Could the parameter column be linked like the old label column? — GhostInTheMachine talk to me 15:56, 26 April 2021 (UTC)
Not too hard to do technically, but the same logic that lead to removing the link from the main navbox seems to suggest the link may not be necessary in the table either. * Pppery * it has begun... 16:40, 26 April 2021 (UTC)
Not sure that there is a parallel. The navbox needs to be kept tidy and small, so there is definitely a strong argument for removing all of the labels (and so their links). The table has a lot more space and serves as a central reference for the complete set of IDs that could be shown by the template. Links in the first column are a major source of reference. — GhostInTheMachine talk to me 17:50, 26 April 2021 (UTC)
Makes sense to me. I've now updated my code to add links (which is now reflected in the table) * Pppery * it has begun... 19:53, 26 April 2021 (UTC)
Truly a work of art and beauty. Awesome — GhostInTheMachine talk to me 20:12, 26 April 2021 (UTC)
Indeed, perfetly done! Fram (talk) 06:57, 27 April 2021 (UTC)
A minor correction needs making - FNZA and DIB have typos in their "Section" column. DIB should be "Biographical dictionaries" rather than "Biographical databses", and FNZA is missing an "e" in research. 192.76.8.91 (talk) 11:22, 28 April 2021 (UTC)
Fixed. Thanks for catching these; they would have caused a script error on all uses of the relevant identifier if the code had gone live (and the testcases didn't list them because they were recently added and the testcases page hasn't been updated). * Pppery * it has begun... 15:56, 28 April 2021 (UTC)

Reference works[edit]

Hi All, I have only noticed the discussion and I would like to propose some changes (or rather ask your opinions). I have been working with RexxS on a template to make use of Wikidata's external IDs pointing to reference works (encyclopedias, biographical dictionaries, etc, sources that are not only data and are reliable). This offers the readers sites to continue reading on (especially useful for article stubs) and could be useful during article creation too. It can handle multiple languages (it prioritises local language sources) and multiple IDs too, Also, it already has a large set of sources included. See some tests here.

My proposal would be to remove similar categories from the authority template and use them separately for the following reasons:

  • These sources do not strictly serve as authority control.
  • They are important for readers to easily find and follow up and would get lost in the authority control template.
  • What to include in reference works and how to display them might need more flexibility than this template provides.
  • Some wikipedias already implement reference works in separate templates.

What do you think? Adam Harangozó (talk) 16:52, 28 April 2021 (UTC)

This is orthogonal to the in-progress redesign (if anything, [they] would get lost in the authority control template is made less true by the redesign}}) and should be discussed separately. * Pppery * it has begun... 18:12, 28 April 2021 (UTC)

RfC started[edit]

I have started the RfC at Wikipedia:Village pump (proposals)#RfC: look of Authority Control. I have converted the (Arts) template to the new look, so people can easily look at lots of real articles to see the new look (while there are still a million articles to see the old look as well), without needing to wade through the "testcases". Obviously, I will at the end change the (Arts) template to the agreed upon look. Fram (talk) 07:45, 7 May 2021 (UTC)

I closed the RfC. @Pppery: would you like to implement the new design? I'm not sure if you have other things in there which may not be ready to deploy. — Martin (MSGJ · talk) 10:23, 7 June 2021 (UTC)
 Done * Pppery * it has begun... 13:58, 7 June 2021 (UTC)

The new version takes up too much space[edit]

Looking at Template:Authority control/testcases, the new version seems to *triple* the amount of space that the template takes up in some cases, and always takes up more space than the previous one. That's a serious issue that could lead to people wanting to auto-collapse the template (which would be *bad* since that would make it even less useful). The current version looks better to me, and it shows more info by displaying the IDs too. Maybe keep that, and just write out the acronyms if you want? Thanks. Mike Peel (talk) 14:30, 28 April 2021 (UTC)

This was argument was already presented and rejected at the RfC. * Pppery * it has begun... 15:39, 28 April 2021 (UTC)
I can't spot it in the RfC? Thanks. Mike Peel (talk) 19:28, 28 April 2021 (UTC)

The idea that something like:

is an improvement over the current:

is farcical. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 12:26, 1 May 2021 (UTC)

But it was decided by a committee! Johnuniq (talk) 02:29, 2 May 2021 (UTC)
I see in the testcases page (near the bottom of the page) that a template with only one item still renders in a single line. For items like the example above, where there are only two or three items in separate categories, we could make the template less cumbersome by putting "Authority control" on the left side, then "National libraries" etc. as subheadings to the right, then the IDs to the right of that. – Jonesey95 (talk) 04:15, 2 May 2021 (UTC)
To be more precise, it's only one line if all items are in the same category (and the labels themselves don't take up more than one line of space). The idea of putting "Authority control" on the left was discussed higher up in #Anyone willing to implement this? and, at the time, seemed odd-looking to me, but I don't feel strongly (and would be willing to do the implementation of any design that reaches consensus). I'm getting somewhat annoyed at the extent to which this discussion is going round in circles.* Pppery * it has begun... 15:35, 2 May 2021 (UTC)
Implemented the above suggestion, and Template:Authority control files has now been deleted. @Fram, Tom.Reding, Jmabel, BrandonXLF, GhostInTheMachine, Adam Harangozó, Mike Peel, Pigsonthewing, Johnuniq, and Jonesey95: Any final comments before the redesign goes live? * Pppery * it has begun... 01:35, 4 May 2021 (UTC)
I like the shorter vertical height. One likely bug: It appears that the sandbox adds an extra closing </span> tag after each item. Here's one:
{{Authority control/sandbox|QID=42}} contains:
*<span class="uid">[https://d-nb.info/gnd/119033364 Integrated Authority File][[Category:Miscellaneous pages with GND identifiers]]</span></span>
I haven't looked at the code to see where it is added, but if I am correct, it should be fixed before going live. – Jonesey95 (talk) 01:59, 4 May 2021 (UTC)
Thanks for pointing that out. Fixed * Pppery * it has begun... 02:05, 4 May 2021 (UTC)
Brilliant. No objections to making this update. – Jonesey95 (talk) 02:22, 4 May 2021 (UTC)
Looks good to me too, go for it! Fram (talk) 07:23, 4 May 2021 (UTC)
Just spotted a typo in the sandbox, probably introduced by me: "MusicBranz artist" should be "MusicBrainz artist" (extra "i" in "brainz"). Fram (talk) 07:25, 4 May 2021 (UTC)
A few other ones: "Sweeden" should be "Sweden", "Urugway" should be "Uruguay", and all other Musicbranz should be changed to Musicbrainz. Fram (talk) 07:29, 4 May 2021 (UTC)
Thanks, typos fixed. * Pppery * it has begun... 13:04, 4 May 2021 (UTC)

Any other comments? Yes; the discussion is "going round in circles" because changing:

to:

is stupid. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 08:18, 4 May 2021 (UTC)

Your first example is not from an actual Wikipedia article, and your second one isn't even about one subject but about completely disparate ones (or even non-existent ones). Real examples would be somewhat more convincing perhaps. Even then, it would be stopping the improvement of 95% because it looks somewhat worse for 5%. — Preceding unsigned comment added by Fram (talkcontribs) 09:33, 4 May 2021 (UTC)
There are still examples on the test cases page where it is tripling the amount of space, e.g., search for '4925052'. So the change was a step in the right direction, but didn't solve this problem. Remember that cases with few identifiers are in the long tail, so are actually the most common, you're 'improving' the 5% with many identifiers. Thanks. Mike Peel (talk) 08:58, 4 May 2021 (UTC)
No, most of the "long tail" won't need that much more space as they often only have one or two (general) identifiers anyway (articles like Bülent Evcil). And I gladly spend some space to improve the easy understanding of what readers are looking at (and a list divided over some subsections is taking up more space, but is easier to read than a long list of IDs one after the other). To me, the 4825052 example looks better in the new format than in the old one. Fram (talk) 09:13, 4 May 2021 (UTC)
Both examples are taken from the testcases page, and both are also highly plausible - indeed likely - scenarios. But no doubt the proponents of this asinine change have checked the common usage patterns before invoking it; perhaps, being one of them, you can share that research with us? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 12:14, 4 May 2021 (UTC)
Oh no, we forgot, best negate the RfC and undo all these changes because, unlike the proponents of the status quo, we have not checked the common usage patterns. None of the examples of how the new version of the template will look like seems terrible (or "asinine") to me: they take up a bit more space in some cases, because they are more self-explanatory, much less intentionally obscure than the old versions. It's a trade-off, and one which you and some others don't like, and others do. That's why we had an RfC, where these pros and cons were taken into deliberation. It is impossible to combine the results of the RfC with a requirement to keep the template as compact as it used to be (assuming that is something to aim for), and readability and logical grouping has been chosen over saving one or two lines of space. Allowing people to at a glance see what this is about, and to get to your preferred AC much quicker than in the old format, seem like sufficient benefits to make your concerns less important. You don't need to agree, but perhaps you need to accept it. Fram (talk) 12:27, 4 May 2021 (UTC)
Interesting how 'The above is a very simple mockup of how it could look. This is an example, and not necessarily the end result.' turned into 'It is impossible to combine the results of the RfC with a requirement to keep the template as compact as it used to be'. Also, note that the example given in the RfC was actually as compact as the current version. Mike Peel (talk) 12:37, 4 May 2021 (UTC)
Where was height discussed? The only example given in the RfC was a best-case scenario where the height was essentially unchanged.   ~ Tom.Reding (talkdgaf)  12:50, 4 May 2021 (UTC)

If you have any constructive suggestions on how to make the template take up less space while still respecting the RfC outcome, feel free to provide them and I'd be happy to implement. All of the above comments appear to be non-constructive re-litigation of the RfC. * Pppery * it has begun... 13:04, 4 May 2021 (UTC)

The RfC conclusion was "There's a strong support for an overhaul of the authority control template that uses human-readable names of the resources, in the interest of being recognizable to more editors." You can do that while taking up less vertical space easily if you wanted to. But no, we must have drama!!! Mike Peel (talk) 13:32, 4 May 2021 (UTC)
If you have any constructive suggestions on how to make the template take up less space while still respecting the RfC outcome, feel free to provide them and I'd be happy to implement. I'm not at all wedded to the current format, but I do care that the implementation of the clear consensus at the RfC not be further obstructed. * Pppery * it has begun... 13:38, 4 May 2021 (UTC)
I'm happy with the status quo, so why would I propose something different? But perhaps since you've already reduced the amount of space for cases where there are less than ~4 IDs, you could try just increasing that number a bit, and/or combining lines when they contain few IDs? Mike Peel (talk) 13:48, 4 May 2021 (UTC)
Feel free to make a mock-up of how you visualize this, of which lines can be combined, ...? Many of the labels only make sense when coupled with the groupings (e.g. the national libraries). Concrete improvements to the ready-to-go version are always welcome; general comments of unhappiness, while also welcome, are hardly actionable. Fram (talk) 14:07, 4 May 2021 (UTC)
No, thank you. As I said, I'm happy with the currently live version, if you want to change things then that's down to you. However, I think you would need another RfC to decide whether to make the current version live or not, since you didn't address the increased space consumption in your previous one, and to check that people are generally happy with how the changes have been implemented. Mike Peel (talk) 14:11, 4 May 2021 (UTC)
The new implementation is close enough to what was proposed in the RfC. Fram (talk) 14:16, 4 May 2021 (UTC)
That's your opinion. Feel free to gather others, e.g., through an RfC. Mike Peel (talk) 14:18, 4 May 2021 (UTC)
I agree with Fram here. There's no need for another RfC, and in fact starting one would be unacceptable forum shopping. * Pppery * it has begun... 14:20, 4 May 2021 (UTC)
Because (a) Fram, Jonesey95, and I all are happy with the sandboxed version and (b) the RfC shows clear consensus that the sandbox is preferable to the status quo (this does not mean it is perfect, or that no improvements are possible), notwithstanding your vocal objections. The burden is on you. * Pppery * it has begun... 14:54, 4 May 2021 (UTC)
"the RfC shows clear consensus that the sandbox is preferable to the status quo" - no, it doesn't, most people at that RfC have not seen the sandbox. Mike Peel (talk) 15:01, 4 May 2021 (UTC)
The sandbox version is way, way closer to the one proposed at the RfC (and to the spirit of the RfC) than the status quo. Do you honestly believe that if you asked the people who supported the change at the RfC whether they prefer the sandbox version or the current version, that they would go for the current one? That seems like wishful thinking. Fram (talk) 15:05, 4 May 2021 (UTC)
I think you would get more feedback at an RfC that would say 'this change is good, this change is bad'. I'm not against change, I just don't think you have converged on a good solution yet. Mike Peel (talk) 15:08, 4 May 2021 (UTC)
And other people are far from happy with it. The burden is on you to show consensus for the change you propose to make (and not just for a change). Note also that the RfC did not speak at all about the version currently in the sandbox, which was not presented there; indeed, it explicitly stated that there was "not any consensus on the exact form that an improved version might take." Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 16:10, 5 May 2021 (UTC)
Yes; a post-discussion RfC, prior to implementation is not only prudent, but necessary, and prescribed, given:
  1. the inadequacy of the original RfC to display worst-case results via cherry-picking a height-neutral example,
  2. the original RfC not describing/elucidating that parameter names & links will disappear,
  3. the deviation from the original RfC's example due to multiple IDs, and
  4. per the close "not any consensus on the exact form that an improved version might take".
Also, the new RfC should receive input & approval from participants here, from both sides, prior to posting. Anything less would be explicitely WP:BADFAITH.   ~ Tom.Reding (talkdgaf)  16:41, 5 May 2021 (UTC)
You would perhaps get more positive responses if you didn't keep on projecting the RfC in a bad-faith light. Your argument #1 is wrong and bad faith, yoru argument #2 was what the RfC was all about, #3 is not a deviation, it is incorporating the exception at your request, even though the value of it is very dubious (would be much better to have one "preferred" ID at Wikidata and only include that one, instead of multiple ones which add nothing but confusion and errors), which leaves you only with argument #4. It might have some merit on its own, but after the other three I have very little inclination to bow to the incessant demands of the opposers, way too often expressed in bad faith or aggressiveness. Fram (talk) 07:50, 6 May 2021 (UTC)
The new version is atrocious. What should be a rather innocuous line of text is now a blight. Blind worship of the almighty data and completely ignoring aesthetics and practicality is a folly. --Animalparty! (talk) 17:13, 7 June 2021 (UTC)
@Animalparty: but it has consensus.   ~ Tom.Reding (talkdgaf)  17:29, 7 June 2021 (UTC)
God sometimes I wish for the simplicity of a benevolent dictator (i.e. an editor-in-chief). Wikipedia continues its slide into the mediocrity of the masses, first with content (trivia, anyone?), and now magnified data cruft. Ugh. --Animalparty! (talk) 23:08, 7 June 2021 (UTC)

Taking out all the wikilinks doesn't seem like improving user-friendliness[edit]

To repeat something I said at the RfC (where I liked the idea of making it a bit more user friendly but wasn't sure how it could be done well):

It doesn't make sense to get rid of all the wikilinks if the purpose is to make it more user-friendly. The consensus was to make it more user-friendly, not for this particular version. That's good because while organizing the links in this way is user-friendly, removing the wikilinks is not. We're removing links from acronyms to English language Wikipedia articles explaining what those resources are and replacing them with [newly organized] acronyms linked directly to the resource, which is sometimes in another language. If someone wants to know what they're clicking beforehand, I suppose they can just google it or open up a new Wikipedia tab to search? This does not strike me as making it more user-friendly. The ideal is certainly to have a wikilink to information about the resource before you jump into it, plus the link itself. — Rhododendrites talk \\ 14:52, 4 May 2021 (UTC)

The consensus was to make it more user-friendly, and the example on how to do this was by making the links meaningful. We don't replace the acronyms with new acronyms, but with full words which usually clearly explain (together with the group label) what it is you are linking to. There are a few which are still the same Acronym, but even those have a group label and often a parenthesis with the country name. Any suggestions to improve the few still unclear ones are welcome, but the vast, vast majority are now immediately obvious. Above, we already have complaints that the new template is too big: adding even more links or text to it will only make this worse. The current proposal strikes a reasonable balance between these two demands, but like I said, if you have suggestions how to improve the few remaining acronyms, please post them! Fram (talk) 15:02, 4 May 2021 (UTC)
"the new template is too big" - we're saying it has too much whitespace, adding more text would not increase the whitespace (hopefully!). Mike Peel (talk) 15:04, 4 May 2021 (UTC)
Nope. "We're" saying "The new version takes up too much space", not "has too much whitespace". taking up too much space = being too big. Adding more text would mean that (for an unknown number of articles) the template would take up more lines on the screen (depending on screen widt obviously), which above was considered to be a problem. Your reply here is the very first time anyone here brings up whitespace, actually. Fram (talk) 15:08, 4 May 2021 (UTC)
I thought it was implicit above, with the fact that you have *less* text covering *triple* the number of lines. If it wasn't just displaying more whitespace, I wouldn't be complaining. Mike Peel (talk) 15:10, 4 May 2021 (UTC)
As the RfC close quoted in the section above made clear, there was "not any consensus on the exact form that an improved version might take." To pretend that there is consensus for the currently proposed version is disingenuous at best. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 15:15, 4 May 2021 (UTC)
(edit conflict) I'm mainly looking at the large group under "other". Some of them have acronyms and others are spelled out, but most are not self-explanatory. What is Leonore? What is Musicbrainz? What is Trove? Visit them to find out! My point isn't so much about acronyms. I was looking at SUDOC when I wrote the above, which indeed is "replacing an acronym with a new acronym" in the way I described, but the point is allowing a reader to know what a resource is before they follow it outside of Wikipedia. It's easy enough with a national library to do this by broad groupings, but for most other cases it's hard to tell exactly what it is from a broad categorization. Hence the usefulness of wikilinks. — Rhododendrites talk \\ 15:36, 4 May 2021 (UTC)
Okay. I think it is just as easy for people to click on e.g. "Trove" and find out what it is by visiting it, as it is for them to first read our page on Trove. But I'm interested to hear what others think. Should, for the not so obvious links, a link to the Wikipedia article be reintroduced? This would be for, I guess, at most (in General) ISNI, ORCID and VIAf, and (in others) Léonore, RERO, SUDOC, and Trove? Fram (talk) 15:42, 4 May 2021 (UTC)
My thoughts on the matter: self-explantaory labels don't generally need links, but they would be useful for non-self-explanatory labels like the ones you proposed. However, I'm drawing a blank on what the best way to include them is. For RERO specifically, it would probably be better to expand the acronym to "Library Network of Western Switzerland", thereby obviating the need for a link. Also, for MusicBrainz, you could add a link without taking up any more space, by doing MusicBrainz artist, instead of MusicBrainz artist. * Pppery * it has begun... 17:37, 4 May 2021 (UTC)
Good idea for the Musicbrainz ones! Fram (talk) 07:39, 5 May 2021 (UTC)
Implemented that. Any ideas for how to include links for the other ambiguous identifiers? * Pppery * it has begun... 14:21, 5 May 2021 (UTC)
You could go back to displaying the numbers as the link to the resource, and expanding the acronyms as links to the Wikipedia articles. Thanks. Mike Peel (talk) 14:28, 5 May 2021 (UTC)
I agree; related discussion above @ #Redesign: parameter names.   ~ Tom.Reding (talkdgaf)  15:45, 4 May 2021 (UTC)

At the risk of overcomplicating things, I'm trying to remember what capacity we have to use something like tooltips which provide a couple sentences explanation when mousing over these items. Or, alternatively, something like the mouse-over "previews" enabled by default these days, but displaying a Wikipedia article preview while actually linking to an external resource. That would use less space while still letting people know what they're clicking on. Maybe not possible, though. — Rhododendrites talk \\ 15:48, 4 May 2021 (UTC)

{{tooltip}} exists, so this is technically possible, but see MOS:NOHOVER * Pppery * it has begun... 15:52, 4 May 2021 (UTC)
Hmm yeah. Although we do have link previews with no apparent objections -- what about doing that here? Maybe there's a way to trick the interface into displaying a link preview to a Wikipedia article while linking externally? Maybe that's too deceptive, though. Another consideration is that this wouldn't be much help on mobile, but I have a hard time imagining someone being on mobile, digging into these links... — Rhododendrites talk \\ 16:16, 5 May 2021 (UTC)
See proposal @ Template:Authority control/testcases#Wikilinks (proposed).   ~ Tom.Reding (talkdgaf)  14:54, 5 May 2021 (UTC)
Looks reasonable to me, but I'll wait for opinions from other editors before implementing. @Fram and Rhododendrites: Thoughts on that proposal? * Pppery * it has begun... 15:04, 5 May 2021 (UTC)
(ec)Thanks. Doing this for all links seems like unnecessary overkill to me; doing this for the ones that remain which aren't obvious may be a good compromise though (so doing this for ISNI, ORCID, VIAf, Léonore, RERO, SUDOC, and Trove seems sufficient to me, among the current batch of ACs). I don't think this is e.g. needed for a link to the National Library of any country, it is rather self-explanatory what these are. Fram (talk) 15:07, 5 May 2021 (UTC)
It should be consistently applied, not based on what you think is or isn't obvious.   ~ Tom.Reding (talkdgaf)  15:20, 5 May 2021 (UTC)
Why? It should be applied where it is necessary, not where it adds no value to the understanding at all. The AC already is a sea of bluelinks, maximizing that number only for consistency seems not helpful. The new version of the template explains that BALaT is an art research institute from Belgium, and that's sufficient for people to decide if they may be follow the external link to the BALaT page or not (where they can learn more about BALaT in any case). Adding in another, internal link to BALaT just adds an unnecessary link. (Mind you, BALaT may be a bad example as none of the links to it (a measley 47) give a result!). Fram (talk) 15:33, 5 May 2021 (UTC)
I've implemented Fram's proposed linkings in the sandbox, although for RERO it may be better to expand the acronym to "Library Network of Western Switzerland", rather than linking it. And I, as I've said earlier, don't see the point of linking when the label and section provides enough information by themselves. * Pppery * it has begun... 15:38, 5 May 2021 (UTC)
As Rhododendrites said, "If someone wants to know what they're clicking beforehand, I suppose they can just google it or open up a new Wikipedia tab to search? This does not strike me as making it more user-friendly. The ideal is certainly to have a wikilink to information about the resource before you jump into it, plus the link itself."   ~ Tom.Reding (talkdgaf)  16:05, 5 May 2021 (UTC)
(ec)How could people not know what they are clicking if the link is "national libraries: Croatia" or some such? "If someone wants to know what they're clicking beforehand" is in that case adequately answered by the text in the template surely? Fram (talk) 16:19, 5 May 2021 (UTC)
Could someone help me to understand the way the sandbox is organized? What should I be looking at? There's an awful lot under "compare" but I'm not sure what's relevant and what's not.
In the interest of finding a compromise between user-friendly organization, user-friendly information, and overall size, I think it's reasonable for the national libraries to remain self-explanatory.
Another thought: the more we spell things out and categorize things on separate lines, the larger these will get. The larger these will get, the more calls there will be to collapse them. And if they're collapsed by default, there's not much point to cutting out the wikilinks in the first place... — Rhododendrites talk \\ 16:16, 5 May 2021 (UTC)
@Rhododendrites: I believe for this section you only need to look at Template:Authority control/testcases#All valid test, which shows all identifiers recognized by the template, with the current format first, and the proposed changes below.

On the topic of wikilinks, many of the articles currently wikilinked to don't really provide any explanation of what the external link shows. Taking AAG (the first entry alphabetically) as an arbitrary example, as far as I can tell the article Auckland Art Gallery Toi o Tāmaki focuses entirely on the physical aspects of the gallery and doesn't even mention anything about the website, so reading that article would not provide any more information about the link than "Auckland" + "Art gallies and museums" provides by itself. In fact, that's true for basically the entire "Art gallies and museums" section.

Moving on to the "Art research institutes" section, the wikilink for BaLAT redirects to Royal Institute for Cultural Heritage#Online artworks pages, which provides technical detail about the structure of the website, but doesn't really explain what the content of the website is. I believe it's more user friendly to expand the label to "Royal Institute for Cultural Heritage (Belgium)", whereupon the link would provide no further information. The next link in that section is bildindex, which at least provides some non-redundant information. Next is Dictionary of Australian Artists, where again the link doesn't really discuss the content of the website or provide any more information than "Australian Artists" + "Art research institutes"

I'm not going to look at every single identifier link, but I think you get the idea at this point: blindly wikilinking everything isn't useful, and there's a spectrum between "Clearly useful" and "Clearly useless" for linking each identifier. * Pppery * it has begun... 15:26, 7 May 2021 (UTC)

I suggest not wikilinking unless we have an article which gives some useful information about that identifier. This is a basic principle of linking — Martin (MSGJ · talk) 09:31, 7 June 2021 (UTC)
@MSGJ: That link says nothing about whether the article is useful or not, it just talks about the principle of least astonishment. So if we had a stub on the repository, that would be fine (or even a redlink according to that guidance). Thanks. Mike Peel (talk) 10:05, 7 June 2021 (UTC)
Yes, a stub would be fine. (I can't see any benefit to a redlink here?) Currently some of these are redirects to articles which don't mention the repository, which would be surprising/untuitive/unhelpful for readers following the link. — Martin (MSGJ · talk) 10:08, 7 June 2021 (UTC)

Several potential classical music properties[edit]

From the transclusions of {{Authority control Q}} ({{Authority control (custom)}} would be more accurate & appropriate, but anyway), there are several property IDs that don't exist in WD yet. I've gathered all the unique IDs below:

Of these, RISM ID (P5504) & FAST ID (P2163) already exist in WD, but are not in the module, and should probably be added here if no objections.

The rest I'm leaving here for anyone that might want to start the associated d:Wikidata:Property proposals.   ~ Tom.Reding (talkdgaf)  11:39, 21 May 2021 (UTC)

 RISM & FAST done   ~ Tom.Reding (talkdgaf)  14:06, 5 June 2021 (UTC)
I've added these to the redesign code (which is now back in the sandbox), giving RISM the label "RISM (France)" wikilinked to Répertoire International des Sources Musicales, and FAST "Faceted Application of Subject Terminology" with no wikilink, and placing both in "Other". @Fram: Do you have any better suggestions for labels and sections for these? * Pppery * it has begun... 16:43, 5 June 2021 (UTC)
FAST belongs in "other" indeed (if we need to have it at all, seems to bring little added value). RISM should perhaps go to a section "Music", although we could wait to create this until we have one or two additional music entries (We have Musicbrainz, but although this are a lot of links, most music articles have only one MB ID). Fram (talk) 07:38, 7 June 2021 (UTC)
@Tom.Reding: There is an ISWC Wikidata property, ISWC (P1827), but it isn't an identifier because the ISWC database isn't in a format that allows for linking to IDs directly. Perhaps a third-party site like ASCAP or BMI could be used to form links, but those sites might not have all ISWCs in their databases. Jc86035 (talk) 08:33, 27 June 2021 (UTC)
@Jc86035: thanks! Not sure how I missed that... What is wrong with these directly-linked IDs? Using the 2 examples @ ISWC (P1827), I'm able to link to both T-905.029.737-5 & T-900.214.198-2 using the third-party formatter URL (P3303). We use 3rd party formatters for other properties, and the main drawback I've seen is they might need updating every few years, and not their completeness, at least not for those URLs chosen as the main third-party formatter URL (P3303). I.e. if completeness is a problem, then it should be demoted/removed.   ~ Tom.Reding (talkdgaf)  12:23, 27 June 2021 (UTC)
@Tom.Reding: My understanding is that BMI and ASCAP have the same set of ISWCs, since they share data with each other's sites, but they might not have the full set of ISWCs because other organizations can also assign them. So if a work has 0% BMI control and 0% ASCAP control it won't be available on their sites. In practice the vast majority of contemporary works with enwiki articles will have an ISWC in BMI/ASCAP, though. I don't know if it would be appropriate to link to them here, even if it would be better than nothing. Jc86035 (talk) 12:29, 27 June 2021 (UTC)
@Jc86035: good to know for BMI/ASCAP. The current third-party formatter URL (P3303) for ISWC (P1827) is musicbrainz.org, though.   ~ Tom.Reding (talkdgaf)  12:54, 27 June 2021 (UTC)
@Tom.Reding: Depending on the context MusicBrainz could be worse since all ISWCs it has are added manually, so its dataset is almost certainly much smaller than the BMI/ASCAP dataset. I don't really know how P3303 is used in practice so I'm not sure how relevant the current values of it are to this template. Jc86035 (talk) 13:01, 27 June 2021 (UTC)

Collapsing the template?[edit]

Am bumping into these large authority control templates on many pages, and the concept of navbox stacking of collapsed templates falls on the wayside. Can these things be default collapsed all at once? Thanks. Randy Kryn (talk) 18:18, 7 June 2021 (UTC)

There was no consensus to auto-collapse them (thankfully), nor to keep using the smaller version (sadly), so: nope. Mike Peel (talk) 18:24, 7 June 2021 (UTC)
Maybe after dealing with them the auto-collapse will become the popular option. Too many pages hide three or four templates in navbox cages, and then these things are now sticking out the bottom taking even more attention from well-made templates. I don't understand your 'thankfully', eyesores are eyesores and never Mark Twain shall meet (check out the bottom of Mark Twain's page, for example). Randy Kryn (talk) 18:29, 7 June 2021 (UTC)
I really hope not, auto-collapsing it would make it even worse than it is now. But given the track record here, that probably means it will happen soon. :-( Mike Peel (talk) 18:33, 7 June 2021 (UTC)
Readers who actually use Authority control links (any research on people using them?) would very likely have the smarts to click 'view' to expand them. Randy Kryn (talk) 18:42, 7 June 2021 (UTC)
Maybe existing users who wonder where it's gone on specific articles. But not all articles have it, so it would make it harder to see which articles have it and which don't. And it significantly reduces the chances of it being found by other readers who don't currently use it. Mike Peel (talk) 18:47, 7 June 2021 (UTC)
I agree with the original poster here. Please revert this horribly obtrusive and non-consensus-based expansion or face the likelihood that people will start removing these templates en masse from articles. Authority control should not be such a prominent part of articles. Having it expandable is ok (and was agreed to in the recent RFC). Having it default to the expanded state is not. Most readers have no use for this information. It just makes more distractions from the part they are actually here for, the text of the article. —David Eppstein (talk) 23:15, 7 June 2021 (UTC)
Came here because I also think this looks ridiculous. Authority control means nothing to ~99.9% of people reading an article. AllegedlyHuman (talk) 03:26, 8 June 2021 (UTC)

Anyone is free to go to the Village Pump and start a new RfC to get it collapsed, removed altogether, reverted to the old version, or stripped of most of its entries. But the current version is the result of two RfCs (one for the general principle of changing the cryptic abbreviation + meaningless ID to a more easily understandable text link, and one for the specific layout), so it isn't "non-consensus-based" and can't be reverted based on some complaints. The last RfC gave the choicce between collapsed or uncollapsed, but opinions there were divided. I tried to demonstrate the new look on some 10,000 pages (or 1% of the uses of it) during the RfC, but this was quickly reverted. Perhaps a new RfC on whether it should be autocollapsed or not will get more input or a more clear result now the new version is actually life: but I'll let someone else start it. Just make sure, whoever wtites an RfC, that you get the history right, and don't start with claims of "non-consensus-based" and so on. Fram (talk) 07:34, 8 June 2021 (UTC)

The revert mentioned below (#Errors) has for now restored the old, less obtrusive appearance, so I can't see what it would look like at Mark Twain. As for the "new look" where opinions there were divided: the closer wrote explicitly that there is no consensus on default collapsing behaviour, so it's no surprise that people turn up here to voice concerns about this template. For the record, I agree it should be collapsed by default, at minimum it should allow a parameter |state=collapsed, like any other navbox. -- Michael Bednarek (talk) 13:09, 8 June 2021 (UTC)
I've added support for |state=collapsed in the sandbox. * Pppery * it has begun... 23:46, 11 June 2021 (UTC)
Now turn it on by default. It is horribly obtrusive otherwise. @Michael Bednarek:, re: "Anyone is free to go to the Village Pump and start a new RfC": there was no prior consensus from the RFC for making it expanded, so doing so is a non-consensus move that should be reverted. —David Eppstein (talk) 20:07, 12 June 2021 (UTC)
Support for the suggestion that it be collapsed by default. PamD 22:50, 12 June 2021 (UTC)
Support autocollapse by default. – Muboshgu (talk) 20:19, 13 June 2021 (UTC)

Pinging the participants of the recent RfC for comments, specifically on the collapsing issue: @Francis Schonken, Pigsonthewing, ProcrastinatingReader, Mike Peel, Blueboar, Tom.Reding, JohnFromPinckney, Rhododendrites, Levivich, Guettarda, CaptainEek, Sea Ane, Aza24, Ajpolino, Pbsouthwood, and The wub: sorry to ping you over such a trivial issue, but it not be fair to ping some and not all. — Martin (MSGJ · talk) 20:49, 13 June 2021 (UTC)

  • Thanks for the ping. What happened to the "default" behavior: autocollapse when there are other templates, uncollapse when it's the only template? That still seems to me to be the best approach. Barring that, if I have to choose between autocollapse or autouncollapse, then it's autocollapse, per arguments above. Levivich 21:03, 13 June 2021 (UTC)
  • As I've said all along, the recent change was harmful (as indeed would be collapsing). It should be reverted. As for the RfC, it was not (as I pointed out when it was modified) neutral, as is required Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 21:13, 13 June 2021 (UTC)
  • Old version uncollapsed is better than the new version un/collapsed.   ~ Tom.Reding (talkdgaf)  21:15, 13 June 2021 (UTC)
  • Basically every navbox is collapsed by default, why isn't this?? Especially when it is not the only navbox on a page, it makes no sense for it to be the only one that is expanded. And we shouldn't have to go through and set the collapse perimeter manually on every page that has one. The default should be collapsed, it could be uncollapsed on specific pages if folks think that is useful. But if the default is between "in your face obtrusive big ugly template that most of our readers and editors don't know what it is" and "out of the way template that can be opened by those who know what it is", I think the latter is by far more sensible. CaptainEek Edits Ho Cap'n! 22:16, 13 June 2021 (UTC)
  • I agree with Tom.Reding, the old version uncollapsed is the far better alternative. The new version looks both obtrusive and messy. However, collapsing it would be even worse. --Bjerrebæk (talk) 02:41, 14 June 2021 (UTC)
  • +1 for autocollapse behaviour. -- Michael Bednarek (talk) 03:46, 14 June 2021 (UTC)
  • Autocollapse per Levich's sensible reasoning. Aza24 (talk) 03:56, 14 June 2021 (UTC)
  • Autocollapse by default, per Levivich and CaptainEek, · · · Peter Southwood (talk): 05:29, 14 June 2021 (UTC)
  • Voicing my support for autocollapsing (in all cases, not just if present with other navboxes), if the current version is what we're stuck with. In its present form, {{Authority control}} elevates trivial information to the same—or more prominent—level as actual encyclopedic content in navigation templates. It's akin to spray-painting the warranty information or mechanic's address across the hood of a brand new car: useful to some if needed, but needlessly prominent, distracting, and just plain tacky. --Animalparty! (talk) 05:34, 14 June 2021 (UTC)
  • I've already given my thoughts on this page, but to summarise: the new version is not an improvement over the previous version, particularly for the amount of space it uses, but collapsing it by default would make it even worse as it hides it out of the way of people that would find it useful. Mike Peel (talk) 06:49, 14 June 2021 (UTC)
    • Collapsing it would make it no less visible than the previous form, and would only require one more click for those people to uncollapse. If you think that the readers who want this are incapable of making that one click, I think you need better faith in the technical ability of readers who are technically savvy enough to want to use this at all. —David Eppstein (talk) 07:16, 14 June 2021 (UTC)
      • @David Eppstein: It would make it much less visible than the previous form. No longer would you be able to glance at it and see what content it contains. Nor would you easily know if it exists on the page (many pages still don't have it), particularly as it would blend in with navigation templates. Plus, I keep clicking on the headers of collapsed templates expecting them to expand, and only then remember it's the tiny 'show' link on the right, so it's often not just one click. Mike Peel (talk) 07:27, 14 June 2021 (UTC)
  • Collapse it. ProcrastinatingReader (talk) 07:19, 14 June 2021 (UTC)
Pppery, which sandbox did you add it to? (I don't see here that you've recently edited any sandbox). If you'll point me to it, or just tell me exactly what is needed (and for the autocollapse default also), I'll add it to the page – I'm satisfied that there's sufficient consensus here for both, in the short term at least. Or of course you could do it. Caveat: this is written in a language I don't speak, but that's just nothing compared to the extent to which the page it invokes is beyond me. If there are any Luans reading this, please feel free to step in! Justlettersandnumbers (talk) 16:13, 14 June 2021 (UTC)
@Justlettersandnumbers: I've updated the module to follow standard navbox collapsing rules by default (autocollapse unless it's the only footer template), which seems to be what most people wanted.

For what it's worth, the sandbox edit I was referencing was Special:Diff/1028116858, which didn't show up on the GUC tool since it only shows the latest 20 edits to each wiki, and I've made several hundred edits since then. * Pppery * it has begun... 16:45, 14 June 2021 (UTC)

OK, great, thank you! Seems to be working as expected, many thanks! Justlettersandnumbers (talk) 16:58, 14 June 2021 (UTC)
@Pppery: Why have you made this change without consensus? Mike Peel (talk) 17:08, 14 June 2021 (UTC)
Because I saw a consensus to do it, and it was clear from my reading of Justlettersandnumbers' comments that they would have done it themselves if they were more familiar with Lua coding. The sole reason I got involved in this in the first place was to remedy the situation in which changes were proposed and got consensus but no one had the technical skill to implement them. In this section, there are twelve people (Randy Kryn, David Eppstein, PamD, Michael Bednarek, Muboshgu, Levivich, CaptainEek, Aza24, Peter Southwood, Animalparty, ProcrastinatingReader, and myself) explicitly supporting collapsing, and two (Mike Peel, Bjerrebæk) opposing it. It's rather impressive to claim that's not a consensus. * Pppery * it has begun... 17:15, 14 June 2021 (UTC)
Mike Peel, please see above where I wrote "I'm satisfied that there's sufficient consensus here for both, in the short term at least", and invited Pppery to make the change. I'd have tried to do that myself if the thing hadn't been written in Lua. So any blame for the (mis)reading of the discussion should be directed at me, while any thanks should of course be sent in Ppperys' direction. And by the way, I'm still satisfied that there was consensus for both changes, despite your opposition. Justlettersandnumbers (talk) 17:25, 14 June 2021 (UTC)
@Pppery: Consensus isn't just counting (which apparently you can't do anyway, you missed Tom and Andy at least), and the RfC closed with no consensus for collapsing the template. The template display has been getting worse and worse, as I predicted right from the start of this, sigh. Mike Peel (talk) 18:48, 14 June 2021 (UTC)
Mike Peel, isn't this whole business difficult enough for everyone without adding personal remarks to the mix (you might like to strike that one, perhaps?)? As above, it was I and not Pppery who assessed the consensus in this discussion, and then asked Pppery to make the changes because they were (and are) beyond my embarrassingly limited technical abilities. I didn't take into account the opinions of either Tom.Reding or Andy Mabbett because both expressed a wish to return to the previous version of the template but no preference for collapsing this version or not; I did take account of your opinion and that of Bjerrebæk. If I've made a mistake here please take it up with me and no-one else. Thank you, Justlettersandnumbers (talk) 20:10, 14 June 2021 (UTC)
I've given up. Have fun continuing to trash this template. I'm not watching it any more. Mike Peel (talk) 20:22, 14 June 2021 (UTC)
I wrote the recent change was harmful (as indeed would be collapsing). I'm not clear what part of that is not clear to you, much less why you would see it as anything other than strong opposition to collapsing the template. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 20:53, 14 June 2021 (UTC)
I still think this should autocollapse by default rather than only in the presence of navboxes, as it is not itself a navbox. As it is, I am now looking forward to going through hundreds of recently created articles manually adding |state=collapsed to each one. What fun. —David Eppstein (talk) 17:39, 14 June 2021 (UTC)
Also, the new autocollapse seems to work inconsistently, not hiding the material when there is only one line (example: [2]) and not collapsing the template at all nor providing any "hide" button to collapse it in some cases (example: [3]). —David Eppstein (talk) 17:47, 14 June 2021 (UTC)
Re templates on one line, is there some benefit to collapsing these? The "Authority control: show" line would take up just as much space as the template does currently, so I don't see the point. Using a horizontal rather than a vertical format (and thus no logical place to put a show button) when there are a small number of identifiers was originally Jonesey95's idea in #The new version takes up too much space, but it shouldn't have triggered in your specific example and only was due to another bug I've fixed in the sandbox. Jonesey95, is that suggestion still relevant now that the template autocollapses by default, or should it be removed? (Regardless, I've changed the sandbox so that an explicit |state=collapsed overrides that change and forces the template to the vertical navbox format) * Pppery * it has begun... 18:47, 14 June 2021 (UTC)
David Eppstein, I agree that it would be preferable if the default state were 'collapse' – I've already manually added one collapse parameter (here) and will doubtless spend time adding more. But in this climate I don't see any way to achieve that other than proposing it here and hoping for some support. Regards, Justlettersandnumbers (talk) 20:16, 14 June 2021 (UTC)
Isn't "proposing it here and hoping for some support" exactly what this exact discussion thread already is? And there appears to be plenty of support. I don't see why each successive discussion keeps getting reinterpreted in the most expansive way possible. —David Eppstein (talk) 20:29, 14 June 2021 (UTC)
When I voted for collapse, I meant collapse it (by default). In all circumstances. No qualifiers. I dunno why it's taken 4-5 discussions just to constantly reaffirm the principles expressed in the first RfC but here we are. ProcrastinatingReader (talk) 21:11, 14 June 2021 (UTC)
Responding to Pppery's question above: If the template has a |state= option, it should honor it in all multi-line cases, so my suggestion to remove the header (which also apparently disables collapsibility) for vertically short versions is probably no longer valid. I don't see the benefit of collapsing a single-line version, however. – Jonesey95 (talk) 21:25, 14 June 2021 (UTC)
OK, I've removed that code from the sandbox. The current sandbox logic is, if all identifiers are in one section, to show just that one section on one line (unless the labels are long enough to make it take up more than one line), ignoring |state=, and otherwise to display a header with a show/hide button, currently defaulting to autocollapse (collapse unless it is the only collapsible thing on the page). Re whether it should collapse in all cases (default to |state=collapse), I have no strong opinion. * Pppery * it has begun... 21:43, 14 June 2021 (UTC)
See Template:Authority control/testcases#Compare for comparisons of the live template (top of each pair) with the sandbox (bottom of each pair). – Jonesey95 (talk) 23:53, 14 June 2021 (UTC)
To test this properly we also need to check what they do in their uncollapsed version (if there are no other collapsible things on the page. Is there any way to simulate that on the testcases page? — Martin (MSGJ · talk) 09:53, 15 June 2021 (UTC)
Remove all but one instance of the template and preview the edit? (Nothing very interesting will happen, though, you'll end up in literally the exact same state as if you had clicked the "show" button) * Pppery * it has begun... 18:55, 15 June 2021 (UTC)

Queries[edit]

I would have left this discussion run a little longer. It was implemented less than 24 hours after I pinged the RfC participants and it would not have hurt to wait a few days before making the change.

A couple of queries:

  • On Abacus, the template is collapsed but why, because there are no other navboxes on that article?
  • On Alkane, the template is not collapsed yet it takes up three rows.

There does seem to be some inconsistent behaviour — Martin (MSGJ · talk) 20:12, 14 June 2021 (UTC)

Re Abacus, I have no idea, but it has nothing to do with this template, since if I edit the whole page, and replace {{authority control}} with a different navbox, and preview the change, the replacement navbox also shows collapsed. Re Alkane, see my reply to David Eppstein above, the collapsibility code I wrote only kicks in if the template shows a navbox header, which currently happens when there are four or more identifiers (not counting WorldCat due to a bug I've already fixed in the sandbox). I agree this is weird and nonstandard, and should have realized that when I deployed the change. * Pppery * it has begun... 20:28, 14 June 2021 (UTC)
The AC template on Abacus is autocollapsed because it is one of two elements on the page with the "collapsible" property. The other is {{Infobox Chinese}}. That's how autocollapse works; the same problem happens when {{multiple issues}} is present in an article with just one navbox. As Pppery says, if you swap a random autocollapsible navbox, like {{MTV Movie Award for Best Fight}}, for the AC template, you will see that navbox autocollapsed as well. – Jonesey95 (talk) 21:30, 14 June 2021 (UTC)
It is false that collapsability currently kicks in when there are four or more identifiers. Lori Lamel is still showing an uncollapsed and uncollapsable four-line Big
Authority
Control
Box
. —David Eppstein (talk) 23:47, 14 June 2021 (UTC)
Christ, the box is longer than the longest section on the article. This template is really the case study for why a template should never be deployed to 2 million articles ever again without clear, broad community consensus at VPR in advance. Textbook WP:FAIT. ProcSock (talk) 00:30, 15 June 2021 (UTC)
I've always thought adding this template to bios was mandatory because the template doc says this template should be added to all biographies. I realize now I've probably been taking that too literally. Levivich 00:37, 15 June 2021 (UTC)
@Levivich: I add it to bios I create because otherwise the article will turn up on my watchlist when someone else adds it. PamD 04:45, 15 June 2021 (UTC)
I've now deployed the code from the sandbox, so Lori Lamel's authority control template collapses like it should. * Pppery * it has begun... 20:41, 22 June 2021 (UTC)

Google Scholar author ID (P1960)[edit]

Perhaps it would be a good idea to add Google Scholar author ID (P1960) to the template? We have included it in the corresponding Norwegian template. --Bjerrebæk (talk) 20:57, 7 June 2021 (UTC)

Errors[edit]

There are heaps of errors in articles: Lua error in Module:Authority_control at line 1192: attempt to concatenate field '?' (a function value). Example Irena Swanson. Recent edits to the module need to be reviewed. Johnuniq (talk) 10:54, 8 June 2021 (UTC)

Seems to be all articles in Category:Pages using authority control with parameters. Fram (talk) 11:25, 8 June 2021 (UTC)
I have reverted the change for now — Martin (MSGJ · talk) 12:15, 8 June 2021 (UTC)
Indeed, it was all pages using parameters and a Wikidata item (either implicitly by being in mainspace or explicitly with a |QID= parameter). This wasn't caught by the testcases since there weren't any tests that tested that specific combination. I've now added some tests (which were showing the same Lua error then but now aren't after the fix), and fixed the underlying bug in the sandbox (a straightforward one-character typo), so this should be ready to go live again (but I'd prefer a different template editor or admin, such as MSGJ, actually re-apply the change so I get a second set of eyes) * Pppery * it has begun... 13:13, 8 June 2021 (UTC)
I can't spot any problems in the test cases (but it is not exactly easy to cross-check the links because the format is so different!) If no one else can see any issues I will deploy shortly — Martin (MSGJ · talk) 14:12, 9 June 2021 (UTC)

Why?[edit]

I've just come across this template {{Authority control (arts)}} when @Fram: added it, replacing the previous {{Authority control}}, to Saara Hopea. The effect seems to be that the reader no longer sees the ISNI or SELIBR data, while the other three fields are unchanged. While I'm not sure who, under what circumstances, would use the ISNI and SELIBR, it seems odd and arbitrary to include them for most people but not for visual artists - especially as there are plenty of people who are visual artists but also write or do other activities for which non-visual-artist identifiers might be relevant. (And a visual artist could well write a book a couple of years after her article had been given this visual-arts-specific template had been added...)

Could someone point me to an explanation of why this separate template is needed, and how it benefits the reader? Is it part of a move towards a whole series of different specialised Authority control templates? I'm genuinely puzzled. Thanks. PamD 17:09, 10 June 2021 (UTC)

Amended above when I realised that although the templates have separate pages, the talk page is combined - I hadn't noticed I was being redirected. PamD 17:28, 10 June 2021 (UTC)
Link to relevant TFD. – Jonesey95 (talk) 19:16, 10 June 2021 (UTC)
@Jonesey95: Thanks. A long read, shedding quite a lot of light. I'm not convinced by the argument for the existence of this variant template - it looks to me as if the solution to the problem of "too many ids are displayed in {{Authority control}}" would be to have it collapsed by default, so that only a single line intrudes visually in the article. But the discussion, this time round at least, has been and gone.
Could I ask that something be added to the template documentation page at {{Authority control (arts)}} to explain this history and give a link to that discussion? If the talk page for the template existed, it would have a notice announcing that previous TfD, but the talk page redirects here instead. Should that be the case? I'm sure I won't be the only editor not involved in previous discussion about this who will be puzzled on seeing something on their watchlist being amended to change the template, and wanting to find out more about it.
And it seems surprising that the Art UK identifier doesn't seem to be included, for UK artists - is it considered too lowbrow a database to be of interest, or something like that, or because the unique identifier is based on the actual name? It might not be necessary for JMW Turner but would be useful for a John Smith. It's in Wikidata.
The template name is also misleading: "arts" usually includes music, literature, dance etc, but the template description specifies the much narrower "visual arts". PamD 22:50, 10 June 2021 (UTC)
I don't know why the template wasn't just merged here, with |1=arts or |arts=yes implemented as an option. That would have been much more sustainable. – Jonesey95 (talk) 00:00, 11 June 2021 (UTC)
A few points: the only IDs that can be included in Template:Authority Control (Arts) are IDs which are already included in the main AC template, as the Arts version is a wrapper, wholly dependent on the main template. If Art UK, British Museum, ... IDs are added to the main template, they will automatically also appear on the Arts template. Collapsing wasn't an option at the time the Arts version was created: if and when that happens, it might be useful to re-evaluate the need for separate subtemplates. But even then, it still would mean that on uncollapsing, one would get plenty of IDs which are of very little added value for specific articles (while they may be useful for other ones), and removing clutter while keeping the best bits is usually supported. Finally, it wasn't merged here because this would make the main template even more complicated (certainly if more such subtemplates would be created, e.g. one per country or language or so, or one for sports, one for music, ...), and would make maintaining and finetunnig the subtemplate impossible for anyone but the few people with the TE right here. Fram (talk) 07:27, 11 June 2021 (UTC)

Broken identifiers[edit]

During the process of implementing the RfC, Fram discovered that the following identifiers were broken on many or all uses:

  1. Terminologia Embryologica
  2. Terminologia Histologica
  3. BALaT (Belgium)
  4. WorldCat (via VIAF)

Is there any objection to removing these from the module? * Pppery * it has begun... 14:05, 7 June 2021 (UTC)

For Terminologia Embryologica and Terminologia Histologica, the content is still available and the URL could have been fixed (Template:TerminologiaEmbryologica and Template:TerminologiaHistologica provide working links to the same resource), however I still propose removing them since every article I checked includes the same information in the infobox so I don't see the benefit of repeating them in the authority contol template at the bottom. I've removed those two and BALat from the sandbox, and also implemented Template talk:Authority control/Archive 11#Researcher ID leads to Publons? and fixed an edge case in the implementation of #Duplicate Poland national library identifiers, which wasn't working properly when the |NLP= ID was passed as a parameter rather than via Wikidata. I plan to copy this code to the live module in a week (since there is a standard one-week delay for adding identifiers, there should be one for removing them as well).
WorldCat (via VIAF) was previously removed for the same reason in Special:Diff/949779734, and then re-added in Special:Diff/959383148, so I am choosing not to re-remove it in this proposal to avoid it getting caught up in unnecessary drama. * Pppery * it has begun... 23:46, 11 June 2021 (UTC)
Strong objection to removing WorldCat. WorldCat is one of the most practical links in what is otherwise mostly a wastebin of data of use to a handful of librarians in the world, and robots. Worldcat can actually help people find sources by and about the subject, and locate copies of the work in libraries. Using George Washington as an example, why should we remove WorldCat with all of its value but keep links to BIBSYS or FAST or Vatican? Yes sometimes the WorldCat link for a particular subject doesn't work. Oh well, that's what happens when data is automatically sucked from Wikidata. It's bad enough this wastebin of data is taking up 3-5 times the page space as before, why make it less practical for users? --Animalparty! (talk) 03:00, 12 June 2021 (UTC)
I was not proposing removing WorldCat, only the other 3 broken identifiers. Also, George Washington uses a "WorldCat" link, which is a separate thing from the "WorldCat (via VIAF)" link I initially considered removing then decided against, so wouldn't have been impacted anyway. * Pppery * it has begun... 03:04, 12 June 2021 (UTC)
WorldCat (via VIAF) has been having some problems for ~the past 2 months, at least from what editors have reported on my talkpage (1, 2). WorldCat itself is online, but via-VIAF is not, and it's not obvious to me why. There's nothing on worldcat.org explaining it, and I've tried a few incrementally-different URL variants to see if it was/n't a small/guessable URL update at fault, to no avail. It would be nice to know if this is a permanent or temporary issue. At first it appeared transient, but after weeks of 404s (I check a random article every few days), it seems to be becoming more permanent. Given its long tenure though, I think it's worth giving them the benefit of the doubt, and a little extra time before removal, say, by July.   ~ Tom.Reding (talkdgaf)  11:35, 13 June 2021 (UTC)
Makes sense to me. * Pppery * it has begun... 13:17, 13 June 2021 (UTC)
@Pppery: Something has happened to Module:Pages with authority control identifiers to put a whole bunch (technical term meaning "almost 90") of cats (such as Category:Miscellaneous pages with VIAF identifiers) inside themselves, they are listed at Wikipedia:Database reports/Self-categorized categories. --Redrose64 🌹 (talk) 09:09, 16 June 2021 (UTC)
Fixed Oops, I should have realized that would happen when I wrote that code. * Pppery * it has begun... 13:46, 16 June 2021 (UTC)

ISNI (and others) shows as a linked 1, instead of the full number. Not sure what's going on.--Auric talk 14:58, 21 June 2021 (UTC)

Not a bug, a deliberate way of including a wikilink to ISNI while including the URL somwewhere and consistently showing the redesign. This specific layout was discussed at #Taking out all the wikilinks doesn't seem like improving user-friendliness * Pppery * it has begun... 15:36, 21 June 2021 (UTC)

 Removed TE, TH, and BALAT, since no one objected to removing any of them. I didn't end up doing the Publons thing, since it only affects one page so I decided it wasn't worth adding. * Pppery * it has begun... 20:41, 22 June 2021 (UTC)

@Tom (LT): notifying the TE & TH proposer, as should be the norm. I couldn't find who proposed BALaT (I searched the archives for "P3293", "BALaT", & "Belgian Art").   ~ Tom.Reding (talkdgaf)  11:57, 23 June 2021 (UTC)
Sorry, I should have thought to do that, but it didn't occur to me. * Pppery * it has begun... 13:28, 23 June 2021 (UTC)

DNB or GND or German National Library[edit]

I missed the discussions to change the display of authority control. Looking now, I couldn't find the information for the German National Library which formerly appeared with label DNB. I saw France etc. but no Germany. Nikkimaria told me it's hidden under "Integrated Authority File". How is anybody supposed to know that? Do you expect users to look at the template documentation? Would it be hard to - perhaps also - provide the link under "Germany" where it would be self-explanatory? --Gerda Arendt (talk) 15:27, 21 June 2021 (UTC)

I have no objection to changing the label and/or moving it to a different section, and doing both of those would be fairly straightforward. Listing it twice seems confusing to me, and would also be a little bit harder to implement. * Pppery * it has begun... 15:36, 21 June 2021 (UTC)
A simple solution could be: "Integrated Authority File (Germany)" or "Integrated Authority File (DNB)". Grimes2 (talk) 15:58, 21 June 2021 (UTC)
Added (Germany) to the sandbox. I decided that was better since one of the goals of the redesign was to avoid cryptic acronyms. If someone else prefers a different solution, that's fine with me as well. * Pppery * it has begun... 21:29, 21 June 2021 (UTC)
And deployed (noting for context that Gerda thanked me for my previous comment, which I took to mean that she agreed with the (Germany) addition. * Pppery * it has begun... 20:41, 22 June 2021 (UTC)

Add support for P4613 Encyclopedia of Modern Ukraine ID[edit]

Online national encyclopedia of modern Ukraine. The ID is linked to 4,394 articles in en.Wikipedia.

 —Michael Z. 15:58, 22 June 2021 (UTC)

Disabling {{TPER}} since there's nothing for a Template Editor to do right now; there's a standard one-week delay for adding identifiers (per the header), so someone will get to this in a week. * Pppery * it has begun... 20:41, 22 June 2021 (UTC)
Re-enabling TPER since there were no objections in a week. ネイ (talk) 14:02, 5 July 2021 (UTC)
 Not done: According to the page's protection level you should be able to edit the page yourself. If you seem to be unable to, please reopen the request with further details. Elli (talk | contribs) 22:40, 8 July 2021 (UTC)
I will leave it to Michael Z then, since I do not have template editor rights. ネイ (talk) 08:37, 9 July 2021 (UTC)
Thanks. I will report back if I encounter any issues. —Michael Z. 13:49, 9 July 2021 (UTC)

External links to library resources: RfC[edit]

A Request for Comment on external links to library resources, which relates to this template, has started: Wikipedia talk:External links#RfC: External links to library resources. Opinions, knowledge, and suggestions are sought. Please join in. SilkTork (talk) 10:29, 3 July 2021 (UTC)

Invalid containsVIAFID link[edit]

At Warberg IC, the "Authority control" section has "WorldCat (via VIAF)" link https://www.worldcat.org/identities/containsVIAFID/316392146, which is not valid. It results in "404: Document not found". While the Warberg IC wikidata:Q3486392 VIAF ID entry 316392146 links to valid https://viaf.org/viaf/316392146/. Shouldn't the links be the same? (both to viaf.org) --Prikryl (talk) 06:55, 4 July 2021 (UTC)

No |nocat parameter or similair[edit]

Hi, I was just looking at this templates documentation and there doesn't appear to be a nocat or equivalent parameter (specifically I was looking at Wikipedia talk:External links#RfC: External links to library resources, which currently is added in 89 different categories by my quick count)? If there is could someone point me to it, if not could a technical editor comment on the feasibility of adding one? -- Asartea Talk | Contribs 10:46, 8 July 2021 (UTC)

Why? Nikkimaria (talk) 12:05, 8 July 2021 (UTC)

Microsoft Academic[edit]

Microsoft Academic is (unfortunately!) shutting down at the end of this year. Do we have a suitable replacement we can add to this template? Perhaps Scopus? ProcrastinatingReader (talk) 09:47, 13 July 2021 (UTC)

Regex of ADB and MA identifiers need a fix[edit]

Two valid cases detected as faulty identifiers:

  • The number at the end of ADB identifiers can now exceed 30000, e.g. Lawrence Bragg.
  • It is possible for MA identifier to have 4 digits only, e.g. Sangji University.

I have fixed Wikidata but could not change the module here. ネイ (talk) 14:59, 20 July 2021 (UTC)

Fixed. – Jonesey95 (talk) 16:18, 20 July 2021 (UTC)
Thank you! Looks good now. ネイ (talk) 14:25, 24 July 2021 (UTC)

Is there a known issue related to Authority Control template, and the Navboxes Top / Bottom format?[edit]

Evening all. Per an issue raised on Lionel Messi, and when checking this also occurs on Cristiano Ronaldo, it seems that when these players have Navboxes that nest inside others the Authority Control wont render and just gives the Template link. The only solution appears to be to place Authority Control above the Navbox dialogue? Koncorde (talk) 18:42, 23 July 2021 (UTC)

The Ronaldo page is in Category:Pages where post-expand include size is exceeded, which means that not all templates in the page will be rendered properly. The size of the page needs to be reduced. – Jonesey95 (talk) 19:23, 23 July 2021 (UTC)
That isn't the issue. I can move Authority Control to before the existing Navboxes, and I can add 3 such templates, and all continue rendering correctly. On the 4th it begins to create issues. But if I put Authority Control AFTER the Navboxes it wont work at all. Koncorde (talk) 21:59, 23 July 2021 (UTC)
I'm pretty sure that it is the issue. The limit report in the article's source currently says "Post‐expand include size: 2097107/2097152 bytes". It's 45 bytes under the limit, which means that a tiny change will put it over. It could be that the reordering of the templates changes the rendered page just enough that it gets under the limit. The solution is still the same. – Jonesey95 (talk) 22:42, 23 July 2021 (UTC)
I will try trimming some content down as testing removing a section entirely did enable the template at the end. Cheers Koncorde (talk) 00:08, 24 July 2021 (UTC)
Looking at the Special:ExpandTemplates for {{Authority control}} on Lionel Messi, there are some minor improvements that can be made, that together may shave ~500 B off the post-expand size.
  1. The {{EditAtWikidata}} module seems to be adding a large & possibly repetitive preamble (search for "edit" in the expand). The whole 1st line is ~1200 B long, but I don't know how much of it is un/necessary; like, do we really need the URLs in

    1.1 <div id="Authority_control_frameless_&#124;text-top_&#124;10px_&#124;alt=Edit_this_at_Wikidata_&#124;link=https&#58;//www.wikidata.org/wiki/Q615#identifiers&#124;Edit_this_at_Wikidata",
    and
    1.2 aria-labelledby="Authority_control_frameless_&#124;text-top_&#124;10px_&#124;alt=Edit_this_at_Wikidata_&#124;link=https&#58;//www.wikidata.org/wiki/Q615#identifiers&#124;Edit_this_at_Wikidata"?

  2. All "Wikipedia articles with ..." categories have always bothered me since the wording seems redundant. Surely they can all be shortened to "Articles with ..."? (10 B x 23 cats = 230 B)
  3. There is a useless comment produced by Template:Authority control that can probably be omitted from the expand by moving around the <includeonly></includeonly> tags. (~45 B)
I haven't looked at any other template, but there is probably at least a little bit of fat that can be trimmed elsewhere.   ~ Tom.Reding (talkdgaf)  01:26, 24 July 2021 (UTC)

Displaying the IDs & making it easy to copy and paste[edit]

Sometimes I copy IDs from Wikipedia in lieu of searching on various sites, so being able to see the number and just copy it is useful. I toggle between Wikipedia and Wikidata as sources for finding multiple IDs. The additional supporting information in Wikipedia articles often helps with confirming that it is in fact a match. BooleanColors (talk) 02:28, 27 July 2021 (UTC)BooleanColors

When you follow the link, you can easily copy the ID from the target website (or alternatively, you can find the ID at Wikidata, which often has two or three times as much IDs as Wikipedia anyway, while Wikipedia only has IDs from Wikidata and no additional ones). Displaying the IDs here as well has been removed after an RfC where most participants found it unnecessary or distracting and preferred the new format or something like it. To find out if the person at Wikipedia and the person at the ID target website are a match, you need to follow the link to that site anyway. Fram (talk) 08:17, 27 July 2021 (UTC)