Template talk:Authority control/Archive 11

This is an archive of past discussions about Template:Authority control. Do not edit the contents of this page. If you wish to start a new discussion or revive an old one, please do so on the current talk page.

Archive 5

←

Archive 9

→

"The RID id AAS-5150-2020 is not valid" (?!) - http://en.wiki.x.io/wiki/Alexei_Eryomin

Dear Alexei, Thanks for getting back to me. I have just checked this and have tried to fix this for you but it looks like the issue is the change in the ResearcherID sequence. We have recently changed to from a one letter ResearcherID sequence to a three letter ResearcherID sequence. This is due to the high volume of ResearcherIDs being generated over the year, and there are only so many possible unique combinations. It looks like Wikipedia/Wikidata is not yet be aware of this change in the ResearcherID sequence and therefore may have not updated their forms to accept the new ResearcherID. We advise you forward this email to the Wikipedia/Wikidata to advise them of this change. If you have any further questions, please feel free to keep in touch. Kind regards, Monisha Tailor | Publons | Wellington, New Zealand

Publons is part of Clarivate, the global leader in trusted insights and analytics that accelerate the pace of innovation. On Fri, 17 Jul at 8:41 PM , Aeremin < > wrote:

screenshot where my ResearcherID is mentioned as not being valid

MMonisha Tailor<info@publons.com>17 июл. в 07:15 Dear Alexei,

Monisha from Publons here. Thanks for your message and apologies for the delayed response. Could you please provide a screenshot where your ResearcherID is mentioned as not being valid? Looking forward to hearing from you.

Monisha Tailor | Publons | Wellington, New Zealand

Publons is part of Clarivate, the global leader in trusted insights and analytics that accelerate the pace of innovation. On Sat, 4 Jul at 6:49 AM , Aeremin < > wrote: Feedback for: What is happening to ResearcherID? • Difficult to understand

I don't understand, why: "The RID id AAS-5150-2020 is not valid" (?!) - http://en.wiki.x.io/wiki/Alexei_Eryomin 262510:183422 Aeremin (talk) 06:50, 21 July 2020 (UTC)

ridLink in Module:Authority control needs an update to also accept three initial letters instead of one. A L Eryomin (Q87055226) has the working link https://researcherid.com/rid/AAS-5150-2020 which isn't currently accepted here. wikidata:Property:P1053#P1793 currently says [A-Z]{1,3}-\d{4}-(19|20)\d\d. It has a reference [1] but it's from 2014 with one letter. I haven't found a reference for the current format. PrimeHunter (talk) 07:24, 21 July 2020 (UTC)

Fixed. Monisha (Aeremin), can you please provide a link to the ResearcherID specification that explains the permissible format of ResearcherID values? For example, how many letters can be in the initial string? Followed by how many numbers, in what format, and with what constraints? Do the letters and numbers represent anything? (also, there is an auto-reply on info@publons.com saying that the mailbox is not monitored, so you might want to check that.) – Jonesey95 (talk) 14:00, 21 July 2020 (UTC)

UK Parliament identifier

I propose that we add UK Parliament ID (P6213) to this template. there are currently 2,574 uses on Wikidata, almost every one of which corresponds to an article on this project, and a number of which have no other identifier via this template. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 13:20, 6 February 2020 (UTC)

Can someone check my attempt at adding this to the sandbox, please? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 23:20, 16 February 2020 (UTC)

I've restored this from the archive, as it went unanswered. @Jonesey95, Tom.Reding, Matthiaspaul, and Paine Ellsworth: as recent editors of the module, who may kindly be able to help. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 14:06, 22 July 2020 (UTC)

Added as requested. --Matthiaspaul (talk) 14:19, 25 August 2020 (UTC)

Tracking "Category:AC with 0 elements"

Some page has {{Authority control}} with 0 elements. How about to add tracking these pages? It can be helpful for tracking wikidata backlogs and wikidata vandals. -- ChongDae (talk) 08:25, 1 July 2020 (UTC)

Added as requested: Category:AC with 0 elements

At present, this still includes invocations of the template in other namespaces as well.

I guess, they should better be masked off, or do you see any purpose in tracking them as well?

--Matthiaspaul (talk) 14:16, 27 August 2020 (UTC)

This template and the Bonnie & Clyde problem

Consider articles such as Del Martin and Phyllis Lyon, where authority control info for the individuals are on their discrete items, but the article is linked to a third item. Authority control is unable to retrieve any info.

Were authority control to take an optional |QId= parameter, it would be possible to place two authority control templates on the Del Martin and Phyllis Lyon, one pointed at Del's item and one pointing at Pyllis's item.

Any possibility this, or some other solution might be put in place? --Tagishsimon (talk) 18:37, 1 September 2020 (UTC)

Tagishsimon I was able to add two formatted authority control templates on the article. Looks messy, but may have to do. WomenArtistUpdates (talk) 19:28, 1 September 2020 (UTC)

Actually, since July 2018 the template takes an optional |qid= parameter, but it is deliberately ignored for invocations of the template from mainspace. The reasons for this are discussed in archived talk threads, but may need some review:

Example (this works because we are not in mainspace):

{{Authority control|qid=Q445893}}

{{Authority control|qid=Q15056022}}

Uzume already mentioned the possible use of the Wikidata property "has part" P527. The logic could be to automatically display ACs for all parts, if a new parameter |part= would be provided without arguments. So, something like

{{Authority control|part=}}

on the Del Martin and Phyllis Lyon page would not list one but both ACs.

However, I think, we should not create any hard dependencies from Wikidata. Therefore, there should always be ways to override the structure at Wikidata using local parameters. Something like |part=Q445893 could display the AC for Q445893 only (like |qid=, but also in mainspace), and only if this node is part of the set in Wikidata's "has part" list of the node associated with either the article (or the node given as argument to |qid=). Example:

{{Authority control|part=Q445893}}

{{Authority control|part=Q15056022}}

If the goal is only to get some kind of confirmation of the hierarchy before allowing the |qid= parameter in mainspace, it might be easier to work the other way around using the "is part" property P361.

--Matthiaspaul (talk) 20:26, 1 September 2020 (UTC)

If we're going to use multiple templates, then it would be better if they displayed a name, within the template (something like "Authority control for Phyllis Lyon", in the left-hand cell), rather than the hacky not-headings used in this edit. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 22:16, 1 September 2020 (UTC)

Good suggestion.

--Matthiaspaul (talk) 10:14, 2 September 2020 (UTC)

What to do if there are multiple VIAF numbers for the same topic?

Sometimes VIAF has a problem, and has different numbers for the same topic, e.g.:

294040572, same topic as 7915155832952633490005
182256910, same topic as 213965472 and 598154381059230292653
179456031, same topic as 212884075 and 8328148209318800460002

Wikidata items should only contain one VIAF ID, and choosing one (hoping that VIAF at some point in time would merge the others) seems a logical choice at Wikidata. For Wikipedia, making such choice seems less evident: if VIAF has multiple numbers for the same topic it is almost a POV to choose one and omit another. For example: the first example in the list above: the first VIAF number connects to the BnF authority file on the item (in French), while the second connects to the DNB authority file on the same (in German). So which one to choose?

Wikipedia should not be in the business of sorting VIAF's problems (Wikidata may do so, Wikipedia should not), but must report content with equal weight in the case variants of such content occur with equal weight in reliable sources. In other words, Wikipedia should not choose between a "France"-inclined information bit and a "Germany"-inclined one, if both occur with equal weight in reliable sources: either both are mentioned, or both omitted from Wikipedia's pages.

So, the question is: which route to follow to get out of such conundrum. I don't know whether this has been discussed before, and whether then appropriate approaches were suggested? Tx. --Francis Schonken (talk) 10:19, 15 May 2020 (UTC)

One could avoid that conundrum by adding {{VIAF}} templates for each number to articles that need them. -- Michael Bednarek (talk) 12:01, 15 May 2020 (UTC)

Both numbers consecutively in the {{VIAF}} template also works:

VIAF 294040572, 7915155832952633490005

This, however, is the talk page of {{Authority control}} template – my question above implying: how does one approach this for the {{Authority control}} box, which only takes one |viaf= parameter, and uploads the one from Wikidata if none is specified. --Francis Schonken (talk) 12:18, 15 May 2020 (UTC)

If the topics are the same the nodes will eventually be merged, in which case it is only a matter of time before the duplication is resolved. I don't see a need to change the module to handle this scenario. --Izno (talk) 21:50, 15 May 2020 (UTC)

WP:NOTCRYSTALBALL, so no, that's just denial, and not an answer on the issue. --Francis Schonken (talk) 02:34, 16 May 2020 (UTC)

Probably the easiest is to use {{VIAF}} in the External links section and add |VIAF= parameter to this template. By the way, Wikidata should contain all IDs (although this template won’t display more than one) so that VIAF can query problematic items and merge them. As far as I know, they do follow Wikidata duplicates and merge them, but this process can take several months, so this “matter of time” is a bit too long to just keep the suboptimal situation for the time being. —Tacsipacsi (talk) 00:26, 22 May 2020 (UTC)

@Rich Farmbrough: I think this is throwing the baby out with the bathwater. The baby being all the pages on which their unique worldcat-via-viaf link is validly produced. Tacsipacsi's solution is to suppress AC's VIAF output, which ~~can~~ should be done via a blank parameter or a parameter with only a comment as shown above. This isn't working for some reason, so if I have time I'll check it out then reverse this change. ~ Tom.Reding (talk ⋅dgaf) 14:03, 27 May 2020 (UTC)

If you can improve this situation, please do! The best solution is probably to get Wikidata up to date, failing that to add the correct and only correct items to the template calls. All the best: Rich Farmbrough 17:43, 27 May 2020 (UTC).

If we just used the ISNI number, that is intended to be a link to all the others AIUI. All the best: Rich Farmbrough 17:45, 27 May 2020 (UTC).

Thus far only unhelpful replies to my OP, and/or replies that have no recognisable relation to the OP question. In WP articles we either take authority control as reflecting reality (which any WP content should do per core content policies), not "choosing" VIAF identifiers we like & omitting others for POV reasons, or we delegate authority control to Wikidata (in which case there's only one possibility afaics, that is removing the POV/OR {{authority control}} template, which is based on a WP:USERGENERATED source with questionable content, wherever we encounter it). I'd say, if Wikipedia articles do authority control, we should do it with our own means, not based on Wikidata's flawed content. I hope to get some reasonable replies to my OP still, if not, so be it, but then, as far as I'm concerned, that's the end of the template wherever I encounter it. --Francis Schonken (talk) 13:55, 28 May 2020 (UTC)

In response to earlier comments, I don't think it's right to assume that multiple VIAF records for the same entity are simply errors waiting to be merged. For many libraries that contribute to VIAF, things like pseudonyms will result in multiple records for the same person; it is part of the structure of those libraries' databases. For instance, the Library of Congress Name Authority File has distinct records (and identifiers) for Mark Twain,Samuel Clemens, Louis de Conte, and Quintus Curtius Snodgrass, all the same person writing under different names. This isn't an error; it is an intentional Library of Congress policy for its authority file. Accordingly, VIAF also has four identifiers: Mark Twain,Samuel Clemens, Louis de Conte, and Quintus Curtius Snodgrass, and each of these VIAF records links to numerous other authority files that structure their databases similarly (i.e., intentionally splitting the single person "Mark Twain" among four different identifiers). Similar things happen with names of corporations: A single company that has changed its name might result, intentionally, in two different LC/VIAF records for an entity that Wikipedia covers in a single article, or that Wikidata covers in a single item.

Why shouldn't this template accurately reflect the structures of the databases to which it refers? If VIAF, or the Library of Congress, or any other database, intentionally uses multiple identifiers for a topic that Wikipedia intentionally covers in a single article, why not just display them all? Thanks-- TimK MSI (talk) 15:18, 28 May 2020 (UTC)

Since there is not always a 1:1 relationship, I think there are two possibly ways to go forward:

If, for us, it is important to keep those "splitted identities" separate as well, then we would have to add the AC template either to the corresponding redirects or add multiple instances to the Mark Twain article, the first one for the "Mark Twain" identity, the others for the other related identities.

If it is not important to keep them separated in Wikipedia and all we want to achieve is establishing links between an article and the corresponding Wikidata nodes, we could simply lump all identifiers into a single AC template by enhancing the template's functionality to accept not only a single entry, but optionally a comma-separated list of entries for all identifiers which could exist in multiple instances by design or error, f.e. |VIAF=294040572,7915155832952633490005, and display&link them all as well. This is easily machine-readable, so if some of the given IDs are merged later on at Wikidata or elsewhere, it is possible for bots to parse and update the lists accordingly. Also, bots coming around to see if there are new identifiers to move to Wikidata, will detect that there is a potential conflict to be solved and could alert people at Wikidata (or elsewhere) to see if something can be merged, if a new meta-level will have to be established (like "all personalities of Samuel Langhorne Clemens") and linked to instead, or if the status quo is just fine and should be kept long-term. This is definitely better than leaving a HTML comment, which is not machine-readable and thus requires ongoing human interaction to be maintained.

--Matthiaspaul (talk) 15:46, 29 May 2020 (UTC)

Would rather favour the second of these approaches: can it be implemented? --Francis Schonken (talk) 05:09, 1 June 2020 (UTC)

This help page (Wikipedia:Authority_control#Non-1:1_and_non-exact_matches) asks us to put non-exact matching IDs on redirects to an article by adding the {{authority control}} template to the exactly matching redirect (positioned after the actual #redirect[[]] and corresponding rcats, and before optional categories). If such a redirect does not exist yet, it should be created.

However, this does not rule out the case that multiple exact matches exist that need to be resolved at Wikidata or elsewhere. The knowledge about such cases is valuable information, that should ideally be used to resolve the problem rather than left unutilized. However, we can't expect Wikipedia editors to become active at Wikidata or start corresponding with other external institutions to resolve such cases on an individual basis. Instead, we need an easy to use method to document such identifiers in a machine-readable fashion. HTML comments just won't do it. Therefore, I still think that we should improve the template to let it accept comma-separated lists of identifiers of the same type, so that bots can pick up this info and relate it to those who can solve the problem. --Matthiaspaul (talk) 19:31, 5 June 2020 (UTC)

Yes, all of that was more or less clear after your previous comment. Hence my question whether your preferred solution can be implemented. Can it? --Francis Schonken (talk) 07:58, 17 June 2020 (UTC)

It was clear to you and me, but not necessarily to others, that's why I discussed the idea a bit more for others to check - after all, I could have overlooked something... Also, I found that remark in the help. However, as nobody responded, I assume that nobody saw any shortcomings in the argumentation. So, yes, I think it can and should be implemented this way.

I almost did it myself, but there are some special cases in the code regarding VIAF codes. It would take some time to research why they were implemented this way, as I don't want to break existing functionality, so this is best done by one of the former editors.

--Matthiaspaul (talk) 11:48, 16 July 2020 (UTC)

@Matthiaspaul: who do you think would then best take the job? I'd try to avoid another three or four back and forths (and wouldn't really know who to ask) – I mean, just ping them, or whatever is the best way to contact these editors who you think to be more qualified. --Francis Schonken (talk) 16:20, 26 August 2020 (UTC)

From a look at the history, I think, Tom Reding is closely familiar with these special cases regarding VIAF/LCCN/WORDCATIDs and the background why they were implemented the way they are.

--Matthiaspaul (talk) 10:00, 2 September 2020 (UTC)

If there are multiple IDs - and multiple Wikidata items - because of pseudonyms, then the solution to use is that described in '#This template and the Bonnie & Clyde problem', further down this page. If there are more than one ID for the same concept, then that is an error at VIAF, and the best ID should be marked as preferred, on Wikidata, and displayed template here; the other IDs should be marked as deprecated on Wikidata, with a qualifier noting the reason why (they can also be listed at Wikipedia:VIAF/errors). In such cases, the OP's claim "Wikidata items should only contain one VIAF ID" is false, as is their claim that we should treat all such IDs equally. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 12:48, 2 September 2020 (UTC)

This is mostly about the second case. However, Wikidata is not Wikipedia, and while both projects can take advantage of each other, some Wikipedians do not edit in Wikidata for various reaons -- out of a principle, because they oppose the WMF's pushing of it, because of its sub-standard user-interface, its unreliability, or simply because they cannot (f.e., for many years I was listed there as being logged out and was not able to log in for technical reasons although page moves in Wikipedia were still reflected there under my global account's name, so that my other edits there were limited to edits that could be carried out as an IP). So, while what you write is correct, it is not a solution suiting everyone.

The idea of this proposal, as I understood it, is to make it as easy as possible for those of us who become aware of such a situation to provide the info about the IDs and thereby (implicitly) also about the existence of the problem "as is" (because this is something that is important to learn about) without having to resolve it themselves. The idea is to let them just provide a list of VIAF codes in an intuitive and easy machine-readable form (and even mostly backwards-compatible fashion) so that bots (or other editors) can pick it up and carry it over to Wikidata or VIAF and initiate the necessary actions there. Until then, our template would populate a maintenance category like "multiple VIAF codes given" and just list them all in the navbox (or, if we give them priorities, only the first one in the row). The template could even check if the given VIAF codes are present and already invalidated at Wikidata and then mute (or specially mark) the display of the code in the Navbox, and possibly also populate another maintenance category indicating that the VIAF codes in the parameter's list need to be cleaned up (if this has not been done by a bot already). The system would also work without the categories, but then it would take longer for the situation to be seen and picked up.

This would give our users easy means to provide the info if they know about such duplicates, and help solving it without ever having to touch Wikidata. At the same time it would allow us to take advantage of Wikidata but stay independent of whatever data is present there. And users who want to initiate the necessary corrections themselves at Wikidata or VIAF, can do so as well.

--Matthiaspaul (talk) 10:29, 3 September 2020 (UTC)

Lowercase parameter aliases

Hi, at present the identifier parameters are using mixed-case (which, for most identifiers, is effectively the same as upper-case). This is fine in itself; we are doing this as well in the CS1/CS2 citation templates. Still, it looks a bit odd as most templates meanwhile use lowercase parameters. Therefore, I propose to add lower-case parameter aliases for all identifiers (as we do with citation templates as well).

Of course, to keep the code small and easy to maintain, we should do this not by manually extending the alias list but by lower-casing the strings before comparison. As before, the identifiers should still be displayed in mixed-case in the navbox.

--Matthiaspaul (talk) 10:33, 2 September 2020 (UTC)

Done. The template now supports lower-case alias names of all parameters (except for deprecated aliases). --Matthiaspaul (talk) 18:29, 8 September 2020 (UTC)

BAV Vatican Library - P8034

Can you please add the new Vatican Library VcBA ID (P8034) for the Vatican library? Thanks --Accurimbono (talk) 07:41, 26 August 2020 (UTC)

Worldcat identifiers

Why does the chart on the Module page list zero articles with a WorldcatID, when, right below it, there is a link listing 626,671 articles with worldcat IDs

Category:Wikipedia articles with WorldCat identifiers

--Bellerophon5685 (talk) 17:28, 2 September 2020 (UTC)

Because these are different categories:

Category:Wikipedia articles with WORLDCATID identifiers

The latter one is about the WORLDCATID parameter, the former about the WorldCat Identifier (which is an identifier somehow derived from VIAF or LCCN identifiers). I can't answer the background of why that is, but it was discussed at least tangential in archived talk threads.

--Matthiaspaul (talk) 18:05, 2 September 2020 (UTC)

I'm also seeing the Category:Wikipedia articles with WorldCat identifiers link listed in the article text rather than the categories section (example). No obvious errors in the code. Any ideas on a fix? T.Shafee(Evo&Evo)^talk 04:05, 18 September 2020 (UTC)

This is because you are using AC on a user page. ACs main use is for mainspace, usage in other namespaces is considered for debug / illustration / documentation purposes only and we don't want these invocations to pullute the categories. As a debug help, the category names are instead listed as text.

--Matthiaspaul (talk) 08:44, 19 September 2020 (UTC)

Cleaning up unused cats being leftovers from coding errors, parameter renames and naming scheme changes

Hi, going through the authority control maintenance category tree I identified a number of old and abandoned categories still lingering around as leftovers from coding errors, general category naming scheme changes and a few parameter renames years ago.

As the existing maintenance category structure is not exactly straight-forward to understand, these unused and empty categories can potentially cause confusion. Therefore, I think, we should delete them to ease future maintenance. Nothing will be lost by this.

Nevertheless, I'd like to give you a chance to comment on this cleanup effort.

Here's the list:

This one was apparently caused by a coding error or to catch a coding error. Even the creator cannot remember its purpose any more:

Category:Miscellaneous pages with ' .. id .. ' identifiers

These are all leftovers after a general change of the tracking category naming scheme in 2018:

Leftovers from a rename of a parameter for an identifier from RLS to RSL fixing a typo:

Leftovers after the rename of an identifier from NLA-person to Trove in 2019:

--Matthiaspaul (talk) 12:01, 1 September 2020 (UTC)

For completeness, we also have one more bunch of abandoned categories after a recent parameter name change from SBN to ICCU:

The last one still has some entries at present - it may take some more time (days? weeks?) until the name change has completely trickled-through and the category will finally be empty as well. Therefore, this is just listed for completeness here - this set is still to fresh to delete at this point in time.

--Matthiaspaul (talk) 12:53, 2 September 2020 (UTC)

The SBN categories listed immediately above are empty at this time. – Jonesey95 (talk) 18:31, 2 September 2020 (UTC)

Great, a couple of hours ago the last one of them still contained several thousand entries. So, they could be deleted now as well.

--Matthiaspaul (talk) 22:02, 2 September 2020 (UTC)

Matthiaspaul, it is standard practice to inform the page creator when you tag their page for deletion, even with empty categories. If you use Twinkle, this is done automatically if you have set up your preferences to do so for ALL CSD categories. Thanks so much for addressing the situation with these categories. Liz ^{Read! Talk!} 18:26, 8 September 2020 (UTC)

Although this is optional per our documentation, this is good advise in general. However, these are not normal content categories, but only tracking categories previously used for our internal maintenance purposes, and, with one exception, they are all leftovers from renames following changes in the templates/modules to no longer use them. That's why they are empty. Also, they don't carry any important edit history. In the exceptional case, the creator was informed and the issue discussed even before this thread was started (see above). For the other cases, this thread was meant as a courtesy to inform anyone who might care (including their creator Tom Reding, who is a regular here), but we really should avoid unnecessary bureaucracy for trivial cleanups to have more time left for useful work. --Matthiaspaul (talk) 07:25, 9 September 2020 (UTC)

Link for NLR ID is broken

The link for NLR ID (National Library of Romania ID) appears to be broken. This could be fixed if the URL is updated to use the formatter URL as stated in d:Property:P1003. — Preceding unsigned comment added by ネイ (talk • contribs) 11:10, 13 October 2020 (UTC)

Done ~ Tom.Reding (talk ⋅dgaf) 11:46, 13 October 2020 (UTC)

Commonwealth War Graves Commission IDs

I suggest that we display CWGC person ID (P1908) in this template. For example, on Walter Kimberley (which currently has no AC identifies), that would display as 75228351. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 22:23, 11 September 2020 (UTC)

Done ~ Tom.Reding (talk ⋅dgaf) 19:16, 20 October 2020 (UTC)

I went through all ~2000 pages containing CWGC person ID (P1908), which reduced Category:AC with 0 elements (0) by 115 (from 462,757 to 462,642). ~ Tom.Reding (talk ⋅dgaf) 20:27, 20 October 2020 (UTC)

When should this be not used?

The documentation says this should be used for all biography articles, and I normally see it for many other articles, too. Are there limits to where it should be added, or is it basically everywhere that's not a list? {{u|Sdkb}} ^talk 07:18, 18 October 2020 (UTC)

Hmm, it seems like no one has an answer to this; we may want to develop more of a standard. {{u|Sdkb}} ^talk 02:18, 24 October 2020 (UTC)

Category:Wikipedia articles with WORLDCATID identifiers

Category:Wikipedia articles with WORLDCATID identifiers and Category:Wikipedia articles with WorldCat identifiers seem to refer to the same thing, and the former one is empty. I think we should change this:

{ 'WORLDCATID', '[[WorldCat Identities (identifier)|WorldCat Identities]]', 7859, nil },

To this:

{ 'WORLDCATID', '[[WorldCat Identities (identifier)|WorldCat Identities]]', 7859, nil, category = 'WorldCat' },

And delete the "WORLDCATID" category. ネイ (talk) 16:36, 21 October 2020 (UTC)

These tracking categories, which may or may not be empty, track different implementations of WorldCat, which may or may not be suppressed, and should not be changed. ~ Tom.Reding (talk ⋅dgaf) 17:03, 21 October 2020 (UTC)

Are there any possible cases for a page to be included in Category:Wikipedia articles with WORLDCATID identifiers? From the code, I can find Category:Wikipedia articles with WorldCat identifiers but not this one. ネイ (talk) 12:49, 23 October 2020 (UTC)

@ネイ: you're right; in testing I could not get {{Authority control}} to populate Category:Wikipedia articles with WORLDCATID identifiers. I see now that this & related categories were created by Matthiaspaul & Uzume (I thought these were cats I created and/or inspected, thus my response above), and I believe I see why. Since |WORLDCATID= is a valid parameter, its associated, logically named tracking categories were missing. I endorse using the relatively-recently-created Category:Pages with WORLDCATID identifiers category tree for the parameter, and Category:Wikipedia articles with WorldCat-LCCN identifiers & Category:Wikipedia articles with WorldCat-VIAF identifiers separately for the automatically created links. ~ Tom.Reding (talk ⋅dgaf) 14:39, 23 October 2020 (UTC)

Sure, I am fine as long as the duplication is resolved. ネイ (talk) 14:55, 23 October 2020 (UTC)

Just another thing I still hadn't gotten around to fixing. Thanks. —Uzume (talk) 02:12, 24 October 2020 (UTC)

Done, in the module. When Category:Wikipedia articles with WorldCat identifiers (0) gets zeroed out (it started @ 630,576), we can nominate it for deletion or redirect it. ~ Tom.Reding (talk ⋅dgaf) 19:31, 24 October 2020 (UTC)

Incorrect ISNI

I'm new here, I came to mention that page Stamen_Grigorov has statements about incorrect ISNI authority control which are very unfriendly (and seem to blame the reader), but there's no clear statement of how to fix such an issue. Even the talk page where I am writing this is not clear about it. It would help if a user knowledgeable about the Authority Control template could clearly state how to fix such errors when encountered. (Apologies if I missed it.) Thanks! 2601:240:4700:9610:E09F:A7D6:8ABB:95F5 (talk) 19:15, 27 October 2020 (UTC)

IAAF ID new name

I've replaced the link to the IAAF ID with the new name (World Athletics) on two occasions but has been overwritten twice. Can anyone update this link so it doesn't get overwritten again? I'm not sure if people are promoting from sandbox or something? SFB 17:10, 28 November 2020 (UTC)

@Sillyfolkboy: because there are so many identifiers, changes come along relatively frequently, which is why most of the links used are redirects, so that template editors don't need to get involved to make routine updates such as this. ~ Tom.Reding (talk ⋅dgaf) 17:48, 28 November 2020 (UTC)

Entry in "Pages with red-linked authority control categories"

Hi. I just observed that Category:Pages with red-linked authority control categories is populated with (only) "Karen Lee (politician)". The identifier UKPARL was recently added, but all the corresponding tracking categories seem to exist, thus are not red. Strangely enough, the category is not listed among the hidden categories when viewing the page directly, however, it shows up in edit preview. This "stealth-nature" suggests some glitch in the code to me, possibly related to the recent addition of "Category:AC with 0 elements", which may need further tweaking to mask off non-mainspace entries, anyway. So, if someone has an idea... ;-) --Matthiaspaul (talk) 19:55, 29 August 2020 (UTC)

@Matthiaspaul: I don’t know what happened, but the category is now empty. —Tacsipacsi (talk) 21:39, 29 August 2020 (UTC)

Strange, it's gone for me as well now. Since neither the template, module, article, nor the corresponding Wikidata entry has been edited today, this must have been down to some caching issue. Thanks for checking.

--Matthiaspaul (talk) 23:35, 29 August 2020 (UTC)

The category is again populated, this time with hundreds of pages containing AC templates with the new VcBA identifier (Template talk:Authority control/Archive 11#BAV Vatican Library - P8034). So, apparently this is "normal" for a transitional period of time after adding new identifiers even though all necessary maintenance categories have been created. --Matthiaspaul (talk) 18:56, 8 September 2020 (UTC)

And empty again. --Matthiaspaul (talk) 06:58, 9 September 2020 (UTC)

Replace NLP with PLWABN

This edit request to Module:Authority control has been answered. Set the |answered= or |ans= parameter to no to reactivate your request.

Could I request a replacement of NLP ID (old) (P1695) with PLWABN ID (P7293)? NLP ID (old) (P1695) is still maintained, but PLWABN ID (P7293) is preferred (292,755 uses at Wikidata), even by VIAF.

PLWABN ID (P7293): suggested parameter |PLWABN =

Jklamo (talk) 20:08, 27 December 2020 (UTC)

Please can you make the required change to Module:Authority control/sandbox? — Martin (MSGJ · talk) 20:52, 27 December 2020 (UTC)

I would advocate for using both, unless/until it can be shown that all QIDs using NLP ID (old) (P1695) have an associated PLWABN ID (P7293) (I haven't checked). ~ Tom.Reding (talk ⋅dgaf) 21:32, 27 December 2020 (UTC)

There are ~18.4k en QIDs using NLP ID (old) (P1695), and, unless my search syntax is way off, only 3 QIDs using both NLP ID (old) (P1695) & PLWABN ID (P7293). I'll add PLWABN ID (P7293) soon if no objections. ~ Tom.Reding (talk ⋅dgaf) 18:51, 28 December 2020 (UTC)

Done ~ Tom.Reding (talk ⋅dgaf) 22:52, 1 January 2021 (UTC)

Features of "authority control" and how to improve its correct reflection

Can you explain or just correct it?

Why does the page of Alexei Eryomin not reflect all 9 parameters of "authority control" reflected here [2]?

Even on ptWiki and esWiki - 5 parameters are reflected [3], and on enWiki only 2? Noophelia 2.0 (talk) 10:52, 5 February 2021 (UTC)

@Noophelia 2.0: those wikis' versions of Module:Authority control have code to use Google Scholar author ID (P1960), Scopus author ID (P1153), OCLC control number (P243), while en.wiki's version does not, either because no one has requested them to be added, or they have been rejected. The remaining IDs not used by any wiki you mentioned are Google Books ID (P675), Google Knowledge Graph ID (P2671), Publons author ID (P3829).

A L Eryomin (Q87055226) currently has 8 authority types (not 9), and 2 of them (OCLC control number (P243) & Scopus author ID (P1153)) have multiple IDs, which {{Authority control}} is not prepared to handle (yet). ~ Tom.Reding (talk ⋅dgaf) 12:34, 5 February 2021 (UTC)

On further investigation of the talk archives, Google Scholar author ID (P1960), Scopus author ID (P1153), & OCLC control number (P243) were all proposed & rejected, but I could not find any requests for Google Books ID (P675), Google Knowledge Graph ID (P2671), & Publons author ID (P3829). ~ Tom.Reding (talk ⋅dgaf) 16:30, 5 February 2021 (UTC)

@Tom.Reding: A big heartfelt thank You for trying to help. To make it easier to handle , I removed the double IDs from (OCLC control number (P243) & Scopus author ID (P1153)), but this does not help. It is not clear why the Google Scholar author ID (P1960), Scopus author ID (P1153), and OCLC control number (P243) are rejected. Publons author ID (P3829) - 3458251. And I don't know how to improve this situation - on ptWiki and esWiki - 5 parameters are reflected, and on enWiki only 2. Noophelia 2.0 (talk) 10:36, 8 February 2021 (UTC)

@Noophelia 2.0: it's all there in the archives. ~ Tom.Reding (talk ⋅dgaf) 12:05, 8 February 2021 (UTC)

Add support for P9070 (Internet Encyclopedia of Ukraine ID)

This edit request has been answered. Set the |answered= or |ans= parameter to no to reactivate your request.

Internet Encyclopedia of Ukraine ID (P9070) is the identifier for entries in the Internet Encyclopedia of Ukraine, a professional English-language authority based on the 6-volume English translation of the 14-volume Ukrainian-language source. It has around 8,000 entries and is actively updated. It is cited over 200 times in Google Scholar results. English-language Wikipedia currently has over 1,600 links to the Internet Encyclopedia of Ukraine.

The identifier is present on about 140 Wikidata items, and I will be actively adding more. Please add support for this identifier to this template and module. Thanks. —Michael Z. 00:28, 8 February 2021 (UTC)

Will do, pending a week or so grace period for discussion/objections. ~ Tom.Reding (talk ⋅dgaf) 01:47, 8 February 2021 (UTC)

Done ~ Tom.Reding (talk ⋅dgaf) 19:52, 14 February 2021 (UTC)

Thank you, @Tom.Reding:. Sorry I hadn’t thought through all the steps: would you change the abbreviation to IEUkr to make it more easily identifiable? Thanks. —Michael Z. 20:14, 14 February 2021 (UTC)

@Mzajac: there are many national-level IDs, and I conformed the parameter to the current standard. |IEUkr= would be a strong departure. ~ Tom.Reding (talk ⋅dgaf) 20:40, 14 February 2021 (UTC)

Is there a standard you can link to, or do you mean prevailing usage? Thanks, anyway. —Michael Z. 20:54, 14 February 2021 (UTC)

Template:Authority control#Wikidata and tracking categories. ~ Tom.Reding (talk ⋅dgaf) 21:01, 14 February 2021 (UTC)

Add support for P3829 (Publons author ID)

Publons author ID (P3829) replaces (P1365) ResearcherID (P1053), which {{Authority control}} currently usees. Wikidata currently has ~54,000 entries using Publons author ID (P3829), ~1700 of which point to an en.wiki article. Only 15 items share both IDs. ~ Tom.Reding (talk ⋅dgaf) 10:30, 8 February 2021 (UTC)

Done ~ Tom.Reding (talk ⋅dgaf) 19:53, 14 February 2021 (UTC)

Multiple IDs from Wikidata now allowed/appended

All IDs from Wikidata for all allowed parameters are now displayed in comma-separated fashion; example @ Mark Twain#Libraries via BNE & several other parameters. ~ Tom.Reding (talk ⋅dgaf) 20:00, 14 February 2021 (UTC)

When should this be not used? - redux

This question was raised earlier, but I didn't see any discussion about it. It's now been raised on my talkpage again by 1234qwer1234qwer4, with the comment that template documentation indicates that authority control should be used only on biographical articles.

Is this still the standard? My own sense (and the one from which I've been proceeding over the past year or two) is that at some point authority control became useful in many non-biographical fields - geographical, musical, business, etc. Is this correct, or should its use on non-biographical articles be curtailed? I think it's likely time to revisit the issue. --Ser Amantio di Nicolao^{Che dicono a Signa?}_{Lo dicono a Signa.} 17:15, 14 December 2020 (UTC)

I did not say the template should not be used outside of biographies, instead, I noted that its use seems to be officially sanctioned only for biographies yet. In fact, I do think it can be useful on other articles, like ones about places or organisations, too, but consensus is required on such a large scale, and that was the point I raised. The questions is exactly, as you stated, where it should not be used. If identifiers from Wikidata are welcome to be displayed on all articles where such information exists, we could as well get rid of the template and integrate authority control into Wikipedia's GUI in some way, like interwikis are already. 𝟙𝟤𝟯𝟺𝐪𝑤𝒆𝓇𝟷𝟮𝟥𝟜𝓺𝔴𝕖𝖗𝟰 (𝗍𝗮𝘭𝙠) 17:29, 14 December 2020 (UTC)

To add: It would definitely do no harm either if it is decided that the template should be used in all articles from some more topic areas, as that would make a more extensive bot run possible. Currently, the addition of the template to biographical articles is approved for Tom.Bot, see Wikipedia:Bots/Requests for approval/Tom.Bot 6. 𝟙𝟤𝟯𝟺𝐪𝑤𝒆𝓇𝟷𝟮𝟥𝟜𝓺𝔴𝕖𝖗𝟰 (𝗍𝗮𝘭𝙠) 17:39, 14 December 2020 (UTC)

I think the question you're trying to ask is "when should a dormant AC not be used?", because I don't see why/where AC shouldn't be used on a page on which it displays a valid ID.

The answer basically depends on the available databases' prevalence in/penetration into a particular subject area. For example, going with the geographical queue, if there's 1 AC database for mountains (in Wikidata and voted on inclusion in {{Authority control}}), and it covers only 10% of all mountains (setting aside what a universal definition of mountain actually is...but you get the idea), then putting AC on all mountains is disruptive. If that database (or those databases) covers 60%+ of all mountains, adding a dormant {{Authority control}} probably makes sense. For reference, ~40% of AC transclusions have 0 elements, for which there is consensus to add a dormant AC, either via approved bot or manually only. The grey-area in between 0% & 60% is where some research (the burden of proof) needs to be done to determine what the current database penetration is for other subject areas, and/or advocate for a lower penetration %. To my knowledge, no one seems both willing & able to do that (I'm certainly not). But, if a valid-enough argument is made for some category (i.e. 60%+ mountain penetration), and consensus is established, I'd definitely re-WP:BRFA it. ~ Tom.Reding (talk ⋅dgaf) 19:50, 14 December 2020 (UTC)

Correction: as of 2 years ago, there was no consensus for automatically adding dormant templates. My recollection of that issue years ago is a bit dull. There may or may not have been intervening discussions regarding this issue that I'm not aware of due to breaks and/or lack of pings. ~ Tom.Reding (talk ⋅dgaf) 22:45, 14 December 2020 (UTC)

Right; the contributions of your bot from two years ago show that through the presence of "\d+ IDs from Wikidata" in all edit summaries, and that might be the reason for why the bot found so many articles yet to tag. 𝟙𝟤𝟯𝟺𝐪𝑤𝒆𝓇𝟷𝟮𝟥𝟜𝓺𝔴𝕖𝖗𝟰 (𝗍𝗮𝘭𝙠) 22:50, 14 December 2020 (UTC)

@Tom.Reding: So what you're describing is basically what I've been doing over the years before doing AWB runs, except that I haven't really codified much of my process. Basically what I'll do is test out AWB on a few pages and see what the prevalence is. So, for instance, with songs, which I've been doing with AWB lately, I tested out the template on five or six articles. The fact that it populated on all of them, or nearly all, told me that it's a valid thing to pursue. Same as I did earlier with high schools/colleges, and before that with localities. Trouble is, it's a lot more difficult to come up with the standard when one is doing it on one's own; if there's any way to develop a better list for future bot/AWB runs, I'm in. --Ser Amantio di Nicolao^{Che dicono a Signa?}_{Lo dicono a Signa.} 20:10, 14 December 2020 (UTC)

"Five or six" seems a bit too little to decide whether a big set with tens of thousands of articles should bear the template, especially given that songs can have very different popularity/coverage. When I've taken ten from your recent batch, only six had the template. 𝟙𝟤𝟯𝟺𝐪𝑤𝒆𝓇𝟷𝟮𝟥𝟜𝓺𝔴𝕖𝖗𝟰 (𝗍𝗮𝘭𝙠) 20:17, 14 December 2020 (UTC)

@Tom.Reding: Could you point to where your bot was approved to add dormant ACs? Wikipedia:Bots/Requests_for_approval/Tom.Bot_6 specifies approval only where there is something displayed, not all biographical articles. Nikkimaria (talk) 22:12, 14 December 2020 (UTC)

If the template should always be displayed when there are external identifiers, why use a template at all? To use my example from before, it's like using a template to transclude interwiki onto the page: The argument that editors connecting pages through Wikidata will not always check if all the linked pages have the interwiki template would make the placement of the template on all pages legitimate, but what the template would be supposed to do could much better be realised using a different mechanism, the one we are using now. 𝟙𝟤𝟯𝟺𝐪𝑤𝒆𝓇𝟷𝟮𝟥𝟜𝓺𝔴𝕖𝖗𝟰 (𝗍𝗮𝘭𝙠) 20:17, 14 December 2020 (UTC)

@1234qwer1234qwer4: See, that's very interesting. Because when I spot check the articles I've tagged, nearly all (let's say 85-90%) have shown the template. And I can assure you I'm not cherry-picking articles I think are going to be likely. I'm sure the actual rate is somewhat lower than that, certainly...but on the whole I'm seeing the template show more than I had expected it would. --Ser Amantio di Nicolao^{Che dicono a Signa?}_{Lo dicono a Signa.} 20:26, 14 December 2020 (UTC)

@Ser Amantio di Nicolao: So, do you continue adding the template in spite of this discussion not having any formal consensus? If you think adding it to all pages of a specific topic is appropriate, expanding Tom.Bot's scope would be much more efficient than doing the changes by hand. 𝟙𝟤𝟯𝟺𝐪𝑤𝒆𝓇𝟷𝟮𝟥𝟜𝓺𝔴𝕖𝖗𝟰 (𝗍𝗮𝘭𝙠) 14:41, 16 January 2021 (UTC)

@𝟙𝟤𝟯𝟺𝐪𝑤𝒆𝓇𝟷𝟮𝟥𝟜𝓺𝔴𝕖𝖗𝟰: As I've had no complaint from anyone, yes - I see no harm in continuing to add the template for right now. It may not be the most ideal solution, but it does seem to work most of the time. --Ser Amantio di Nicolao^{Che dicono a Signa?}_{Lo dicono a Signa.} 16:17, 16 January 2021 (UTC)

I put {{authority control}} at the foot of every article I start. It may just sit there doing nothing, but doing no harm. Often it picks up values from Wikidata, or I add values. I can't see why I would omit it. Almost anything that qualifies for a Wikipedia article could also be included in specialized indexes or catalogs, either now or in the future, and links to those external entries will often be useful. Authors, butterflies, cars, dogs ... yachts, zoos.

The question of whether a template is needed at all is valid. I would support extending the underlying software so that the list of identifiers is automatically displayed if any of them are found in Wikidata, whether or not the template is present. But the template is still a convenient and familiar way to add identifiers, which can then be migrated to Wikidata by a bot. Aymatth2 (talk) 15:08, 3 March 2021 (UTC)

Add support for P6829 (Dictionary of Irish Biography ID)

The Dictionary of Irish Biography (DIB) removed its paywall in December 2020. There are 7614 wikidata entries. jnestorius^(talk) 22:42, 28 February 2021 (UTC)

Support. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 21:18, 3 March 2021 (UTC)

Done ~ Tom.Reding (talk ⋅dgaf) 19:23, 9 March 2021 (UTC)

Microsoft Academic IDs

I propose that we add Microsoft Academic ID (P6366) to the template; the site has rich data about people and their papers, and includes data which is not easily found in other online resources; not least where they have been cited. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 21:27, 3 March 2021 (UTC)

@Pigsonthewing: there are 2 formatter URL (P1630)s - which one, if any, can be used in all cases? ~ Tom.Reding (talk ⋅dgaf) 15:01, 7 March 2021 (UTC)

@Tom.Reding: https://academic.microsoft.com/v2/detail/$1 seems to work in all cases; note also that it's marked as"preferred" on Wikidata. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 17:30, 7 March 2021 (UTC)

Done ~ Tom.Reding (talk ⋅dgaf) 19:24, 9 March 2021 (UTC)

RfC about the look of the template

I've started Wikipedia:Village pump (proposals)#RfC: make Template:Authority control more reader-friendly. Fram (talk) 10:18, 18 March 2021 (UTC)

Word wrap for comma-separated values

I've noticed an issue on the page A–Z Series where there are multiple entities under the MBRG category, separated by commas. There are so many that they go outside the page limits, instead of wrapping within the box. I've had no experience with this template myself, so I don't know whether this is an issue with the data (i.e. there "shouldn't" be this many entities within one category) or whether there's a way to allow word wrapping within the template, since it's something that is possibly occurring elsewhere under legitimate circumstances. Thought I'd bring it to the attention of folks associated with the template though :-) Fattonyni (talk) 10:04, 18 March 2021 (UTC)

@Fattonyni: good lord... I'll add a clause to wrap if ~~more than 3 IDs~~ total ID length >= 80. Ideally, but I'm not sure how, if I knew the width of the box and character width of the IDs, a more intelligent conditional wrap could be performed. ~ Tom.Reding (talk ⋅dgaf) 10:23, 18 March 2021 (UTC)

Done ~ Tom.Reding (talk ⋅dgaf) 11:29, 18 March 2021 (UTC)

@Tom.Reding: brilliant, thanks! Fattonyni (talk) 15:21, 18 March 2021 (UTC)

Articles which cover more than one thing

How does this template get used for articles which cover more than one concept/person/object? Is it possible to apply it more than once with different QID parameters, and if so, how could the scope of each be clearly indicated? — Martin (MSGJ · talk) 08:51, 11 March 2021 (UTC)

@MSGJ: to your first question, I would like to see some examples as well (the Bonnie and Clyde page unfortunately has a null AC template).

{{Taxonbar}} is an {{Authority control}}-style template which has been made to accept any number of QIDs. However, the WP:Tree of Life/taxonomy space suffers from large-scale translational issues between WP & WD that I don't think exist for AC (taxon names change, get updated, split, merge, have un/official variants, etc.), so {{Taxonbar}} can be used for ideas on how to improve AC, but not as any sort of idyllic goal.

I'd suggest a parameter which is able to add a secondary QID to the template like, say, |also=. {{Taxonbar}} is, and has to be, more aggressive in its WP-WD linkage by soft-requiring its |from= parameter on all pages. I don't think this is/will be necessary for AC, so I'd prefer a parameter name that won't hint at/suggest that.

As far as visualization goes, the [[Help:Authority control|Authority control]] link can be moved from the left column to the header, similar to {{Taxonbar}} with multiple QIDs (Template:Taxonbar#Multiple Wikidata entries). Multiple QID labels can be enumerated in the left column, also similar to {{Taxonbar}} with multiple QIDs, but with the pen icon & "Edit this at Wikidata" link immediately next to each QID label (just as the pen icon exists now next to "Authority control"). ~ Tom.Reding (talk ⋅dgaf) 12:50, 11 March 2021 (UTC)

Thanks for your answer. It is exactly analogous to Bonnie and Clyde, where an article covers an overview of more than one topic. In the case of lighthouses, it is quite common that a lighthouse is replaced by a new lighthouse in the same location or nearby. The Wikipedia article would generally cover multiple lighthouses in the same location. There are also lots of pairs of lights (used to provide leading lights) and an article would usually cover both of them.

I like your suggestions, and the ability to add |also=. May I suggest a naming scheme like |qid1= (used to override the current page's qid) and |qid2=, |qid3=, etc. to provide supplementary ones?

I made a mock up of what it could look like below, broadly in line with your own ideas. — Martin (MSGJ · talk) 12:18, 12 March 2021 (UTC)

That looks good.

"used to override the current page's qid" - that is out of the question. The solution instead is to move the WP site link to the appropriate QID in WD, NOT simply masking over the problem in AC. The current QID should always be shown in AC, and we can discuss whether or not to:

force the current QID to the top of AC (I'd say force), or
allow the user to change the order of all QIDs (I'd say don't), or
allow the user to only change the order of QIDs below the current (no problems),

but overwriting the current QID is a non-starter.

This is why I suggest |also=, or something equally evocative/non-neutral. |qid= is too neutral and begets the reasoning/tenancies towards #2. ~ Tom.Reding (talk ⋅dgaf) 14:16, 12 March 2021 (UTC)

The only reason I was suggesting the qid could be overridden was in examples like Kinnaird Head lighthouses (Q105519325) which is an overview item for two different lighthouses, and has no useful data. But I guess if there is no data, then that row would not be displayed anyway, so no problem. — Martin (MSGJ · talk) 16:05, 12 March 2021 (UTC)

I quite like Matthiaspaul's suggestion of using a |part= parameter which is dependent on has part(s) (P527) — Martin (MSGJ · talk) 16:07, 12 March 2021 (UTC)

Something similar was done in {{Taxonbar}} to automatically pull basionym (P566) & original combination (P1403) into the template. I think this is a very good starting point. |part= may be used locally for those unfamiliar with WD, with a followup tracking cat to move that QID to WD.

For some preliminary statistics & usage examples, I chose Library of Congress authority ID (P244), which has ~592,000 WP articles:

~19,000 use part of (P361),

~11,000 use has part(s) (P527), and

~1,800 use both.

I spot-checked a few they seem reasonable to include at the end of the article. I'll start with the automatic addition first, see how that goes, then incorporate the parameter with any community feedback. ~ Tom.Reding (talk ⋅dgaf) 11:39, 13 March 2021 (UTC)

Holding off on this until after #RfC about the look of the template. If passed, I don't think this is doable due to the additional left-column, making room for IDs even more scarce. ~ Tom.Reding (talk ⋅dgaf) 21:26, 23 March 2021 (UTC)

Please see Template talk:Authority control/Archive 11#This template and the Bonnie & Clyde problem (not least my post there timestamped "22:16, 1 September 2020 (UTC)", and the example article linked to from that). Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 15:10, 12 March 2021 (UTC)

Yes, I am in agreement with all points made in that thread. So it seems there is a real need for this functionality — Martin (MSGJ · talk) 16:05, 12 March 2021 (UTC)

Allowing multiple ACs is just a sloppier version of my #2 concern above. ~ Tom.Reding (talk ⋅dgaf) 11:39, 13 March 2021 (UTC)

Generalizing Category:VIAF not on Wikidata & Category:VIAF different on Wikidata

Currently, these 2 categories are emitted by the template, and not by a/the module as all other {{AC}} tracking categories are.

Category:VIAF not on Wikidata (0) contents (currently @ 568 pages) are duplicated in Category:Pages using authority control with parameters (0) (currently @ 2411 pages), which tracks all properties, not just |VIAF=.
Category:VIAF different on Wikidata (0) (currently @ 132 pages) does not yet have an analog, Category:Pages using authority control with parameters different on Wikidata (0), which I plan to create & populate.

After the new cat is created, I plan on discontinuing Category:VIAF not on Wikidata & Category:VIAF different on Wikidata for the new, general categories. I'll wait some time before CfD'ing them, but I thought I'd let any interested people know, in case they want to clear out the category in the meantime.

The alternative, having 2 cats for each parameter, would require 168 new categories, which is prohibitive to display, and I think not necessary due to the 1843 pages (2411 – 568=1843) that would be dispersed among them. To carry forward some of that functionality, though, I plan on making the 2 general categories sorted by the first/last-alphabetically-discovered absent/different parameter. For example, Cyriak will appear in Category:Pages using authority control with parameters under V for |VIAF=, and not C. However, there will be some ambiguity, as there is another parameter starting with V, |VcBA=, but I don't see this as a big issue, as it still vastly narrows down the scope of potential suspects/parameters, for a very small percentage of problematic {{AC}} pages (~0.14% for pages-absent, and an estimated < ~0.1% for pages-different^†). ~ Tom.Reding (talk ⋅dgaf) 12:09, 28 March 2021 (UTC)

It turned out that Category:VIAF different on Wikidata (0) is & was entirely duplicated in Category:Wikipedia articles with multiple identifiers (0), meaning the WP-ID might be present as a secondary/tertiary/etc. ID in WD. After refreshing all 132 pages, 97 of them showed up in Category:Pages using authority control with parameters different on Wikidata (0), a 27% reduction. ~ Tom.Reding (talk ⋅dgaf) 15:22, 28 March 2021 (UTC)

^†0.02% for pages-different ~ Tom.Reding (talk ⋅dgaf) 07:41, 2 April 2021 (UTC)

Researcher ID leads to Publons?

No idea since when this happens, but the ResearcherID links simply lead to Publons. Having both is then not necessary. I guess ResearcherID is the one that should go? Fram (talk) 08:36, 2 April 2021 (UTC)

See ResearcherID, they are merging. Probably an if statement is needed, so that ResearcherID is still shown if Publons is not present. Thanks. Mike Peel (talk) 09:45, 2 April 2021 (UTC)

Thanks. Terminologia Embryologica (Category:Wikipedia articles with TE identifiers) links no longer seem to work, all lead to the homepage of TE (tested 3 at random). Fram (talk) 13:33, 2 April 2021 (UTC)

Same problem for Terminologia Histologica (Category:Wikipedia articles with TH identifiers). Fram (talk) 13:37, 2 April 2021 (UTC)

Template:ACArt name

Please can we move this template so that it makes more sense when read by humans in the wikitext? Perhaps something like Template:Authority control (arts) would be better. — Martin (MSGJ · talk) 20:36, 9 February 2021 (UTC)

Well, for most humans it will make just as much sense as ACArt. I know that authority control is the right term for people who actually are into authority control, but for most people it gives a completely wrong impression of what are basically "reliable identifiers". Template:Art IDs perhaps? Fram (talk) 21:09, 9 February 2021 (UTC)

Support {{Authority control (arts)}}, or similar — wrapper/extension templates like {{Cite IUCN}}, {{Navseasoncats with decades below year}}, {{Infobox <anything>}}, {{Authority control files}}, etc., follow their parent's naming convention, namely {{Cite journal}}, {{Navseasoncats}}, {{Infobox}}, {{Authority control}}, etc., and I see no reason to stray from it. ~ Tom.Reding (talk ⋅dgaf) 01:20, 10 February 2021 (UTC)

Support. per User:Tom.Reding. --Robert.Allen (talk) 14:45, 6 March 2021 (UTC)

Done ~ Tom.Reding (talk ⋅dgaf) 12:35, 17 April 2021 (UTC)

Reference works in the new auth control template

Hi All, I have only noticed the discussion about the redesigned authority template 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 at the bottom of the article.
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) 08:51, 29 April 2021 (UTC)

VPP discussion

Just to note that @ProcrastinatingReader: has started a discussion at Wikipedia:Village_pump_(proposals)#Authority_control. Mike Peel (talk) 12:24, 4 May 2021 (UTC)

New RfC

Fram seems to have started one at Wikipedia:Village_pump_(proposals)#Discussion_(look_of_Authority_Control). Pinging @Pppery and Tom.Reding:. Thanks. Mike Peel (talk) 10:37, 7 May 2021 (UTC)

Thousands of WorldCat links don't work

Above, I already listed two AC links which never work, Category:Wikipedia articles with TE identifiers (160 instances) and Category:Wikipedia articles with TH identifiers (301 instances).

A much more common problem though is Worldcat links which don't work. Category:Wikipedia articles with WorldCat-VIAF identifiers has 141,000 instances. Looking at the first ones, I get:

.NET Framework: "404: Document not found"
+/- (band): "404: Document not found"
Florida State Road A1A: "404: Document not found"
One World Trade Center: OK
M1 motorway (Northern Ireland): "404: Document not found"
1. April 2000: "404: Document not found"
1a Palace Gate: "404: Document not found"
1&1 Drillisch: OK
1er Bataillon de Fusiliers Marins Commandos: "404: Document not found"
1Punch: "404: Document not found"

That's 8 out of the first 10 where this gives an error. Now, this is not a random selection, and biographies may give better results: but it still is a way too high error percentage (and number). A further batch of 10 consecutive articles, including this time some biographies, gives the error for Aarlanderveen; Aaron Buchanan & The Cult Classics, Aarón Castellanos, Santa Fe, Aaron Copland School of Music, Aaron Scotus, Aaron's Rod (novel), and Årstad Church. Worldcat is found for Chloe Aaron, Jesse Aaron and Aarong. So again 7 out of 10 with this problem.

Can this be corrected, or else WorldCat removed from authority control until this is solved? Fram (talk) 08:02, 25 May 2021 (UTC)

Discussion example of the new look after the RfC

The RfC on the changed look of this template, to make it more reader-friendly, has been closed as "succesful"[4]: "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

How do we show multiple IDs? ~ Tom.Reding (talk ⋅dgaf) 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 (0), currently 43,732. ~ Tom.Reding (talk ⋅dgaf) 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 (talk ⋅dgaf) 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 (talk ⋅dgaf) 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

How do we show multiple QIDs from has part(s) (P527) & part of (P361)? Previous solution above @ Template talk:Authority control/Archive 11#Articles which cover more than one thing. ~ Tom.Reding (talk ⋅dgaf) 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(s) (P527) and/or part of (P361). ~ Tom.Reding (talk ⋅dgaf) 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 (talk ⋅dgaf) 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 (talk ⋅dgaf) 23:45, 28 April 2021 (UTC)

Redesign: parameter names

Yet another problem that wasn't even described in the RfC has unintended consequences:

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.
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 (talk ⋅dgaf) 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 (talk ⋅dgaf) 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 (talk ⋅dgaf) 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 (talk ⋅dgaf) 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 (talk ⋅dgaf) 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?

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 (talk ⋅dgaf) 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 (talk ⋅dgaf) 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

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

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

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: Script error: The function "docConfTable" does not exist. 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 (talk ⋅dgaf) 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

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

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

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 (talk • contribs) 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 (talk ⋅dgaf) 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:

the inadequacy of the original RfC to display worst-case results via cherry-picking a height-neutral example,
the original RfC not describing/elucidating that parameter names & links will disappear,
the deviation from the original RfC's example due to multiple IDs, and
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 (talk ⋅dgaf) 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 (talk ⋅dgaf) 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

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 (talk ⋅dgaf) 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 (talk ⋅dgaf) 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 (talk ⋅dgaf) 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 (talk ⋅dgaf) 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)

Google Scholar author ID (P1960)

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)

Authority control databases – Del Martin
International	ISNI VIAF FAST WorldCat
National	Germany United States Netherlands Norway Korea Israel
Other	IdRef 2

Authority control databases – Phyllis Lyon
International	ISNI VIAF FAST WorldCat
National	Germany United States Israel
Other	IdRef

Authority control
Kinnaird Head Lighthouse	Admiralty: J4438 NGA: 110-15704 ARLHS: MEX-014
New Kinnaird Head Lighthouse	Admiralty: J4437 NGA: 110-15705 ARLHS: MEX-012

Authority control: general	Integrated Authority File ISNI ORCID VIAF WorldCat WorldCat-Library of Congress WorldCat-VIAF
National libraries	Australia Catalonia Chile Croatia Czech Republic France (data) Greece Israel Italy Korea Japan Latvia Netherlands Norway (BIBSYS) Poland Poland Romania Russia Spain Sweden Taiwan United States Vatican
Art galleries and museums	Auckland South Australia Te Papa (New Zealand) Victoria
Art research institutes	Artist Names (Getty) Australian Artists BALaT (Belgium) Bildindex (Germany) ICIA (Israel) Joconde (France) KulturNav (Norway New Zealand Artists Photographers' Identities RKD Artists (Netherlands) RKD ID (Netherlands) Scientific illustrators SIKART (Switzerland)
Biographical dictionaries	Australia Australian Women's Register Ireland Netherlands
Scientific databases	Association for Computing Machinery CiNii (Japan) DBLP (computer science) International Plant Names Index Mathematics Genealogy Project Publons (researchers) ResearcherID Semantic Scholar Terminologia Anatomica Terminologia Embryologica Terminologia Histologica
Other	Commonwealth War Graves Commission Encyclopedia of Islam Historical Dictionary of Switzerland Léonore (France) Lexicon Istoric Retic (Switzerland) Microsoft Academic Musicbrainz artist Musicbrainz area Musicbrainz instrument Musicbrainz label Musicbrainz place Musicbrainz release Musicbrainz series Musicbrainz work National Archives (US) RERO (Switzerland), RERO Social Networks and Archival Context SUDOC (France) Theaterlexikon (Switzerland) Trove (Australia) UK Parliament Internet Encyclopedia of Ukraine US Congress World Athletics

Authority control
General	ORCID Category:Miscellaneous pages with ORCID identifiers
Scientific databases	ResearcherID Category:Miscellaneous pages with RID identifiers