Template talk:Wikidata Infobox/Archive 4

Problem with employer data

See Commons:Village pump#Sea of blue links in the infobox. Kaldari (talk) 17:26, 14 November 2019 (UTC)

Thanks for the pointer. I've replied there. There's now a tweak in {{Wikidata Infobox/sandbox}} to add a little bit of whitespace between lines so that they are more clearly separated. Thanks. Mike Peel (talk) 05:48, 15 November 2019 (UTC)

This section is resolved and can be archived. If you disagree, replace this template with your comment. Mike Peel (talk) 17:12, 12 June 2020 (UTC)

trouble with Category:Recipients of the Copley Medal

Category:Recipients of the Copley Medal runs out of time and causes an error. I am sure it is caused by data on Wikidata. Can we put a limit on number of "winners" a page is allowed to display? --Jarekt (talk) 03:56, 26 April 2020 (UTC)

Q28003 should be cleaned-up (awards should be on items for persons). I added a temporary fix. Jura1 (talk) 10:42, 26 April 2020 (UTC)

@Jarekt and Jura1: I've added a limit now - it auto-hides if it's over 5, and cuts off at a maximum of 20. Thanks. Mike Peel (talk) 15:10, 10 May 2020 (UTC)

This section is resolved and can be archived. If you disagree, replace this template with your comment. Mike Peel (talk) 17:03, 12 June 2020 (UTC)

Translator

Hi, could you add translator to this template? Code:

translator -->{{#invoke:Wikidata Infobox|formatLine | P655 | {{#invoke:WikidataIB | getValue | rank=best | P655 | name=translator | linkprefix=":"
| qlinkprefix=":" | list={{{liststyle|ubl}}} | qid={{#invoke:WikidataIB |getQid |qid={{{qid|}}} }} | spf={{{spf|}}} | fwd={{{fwd|ALL}}} | osd={{{os
d|no}}} | noicon={{{noicon|yes}}} | qual=ALL}} }}<!--

This code need to be after author section.

Tested on https://commons.wikimedia.org/w/index.php?title=Template:Wikidata_Infobox/core/sandbox&oldid=416502029

It will help to add crucial information for book editions which are translated. Skim (talk) 15:25, 2 May 2020 (UTC)

CC: @Mike Peel:

@Skim: The change is now live. Thanks. Mike Peel (talk) 15:09, 10 May 2020 (UTC)

This section is resolved and can be archived. If you disagree, replace this template with your comment. Mike Peel (talk) 17:01, 12 June 2020 (UTC)

Location, continent, hemisphere, error

Hi. At some point, when continents were added, something went wrong, since the location chain of Madrid is Madrid, Community of Madrid, Spain, Africa, Southern Hemisphere. Definitely not in Africa, neither in the Southern Hemisphere. The item Spain has two values in the P30 property, but Africa is not even the first of them (wrt hemisphere, Africa is both in the Southern and Northern Hemisphere. The infobox apparently chooses the second value again, in this case P706's). Strakhov (talk) 05:34, 6 May 2020 (UTC)

@Strakhov: Traced down to this edit that removed instance of (P31)=country (Q6256). There's a chance that might get reverted on the basis that instance of (P31) is also set to Mediterranean country (Q51576574) for some reason there - @RexxS: this might need a coding tweak to handle. Also, I'm not sure why the retrieved value of continent (P30) fetched both the 'preferred' and 'normal' rank values from Spain (Q29), which may also be worth fixing. Thanks. Mike Peel (talk) 07:47, 6 May 2020 (UTC)::

@Mike Peel and Strakhov: The algorithm doesn't follow continent, just P276 (location), or P131 (located in the administrative territorial entity), or P706 (located on terrain feature). When Spain was not an instance of country, the code would find P706 and use it for the next level up the chain (no P276 or P131 for Spain). Best values are: {{wdib |ps=1 |P706 |qid=Q29 |lp=:}} → Iberian Peninsula. So the code checks the previous link in the chain to see whether "Community of Madrid" is located in "Africa" or the "Iberian Peninsula". It turns out that the answer is no, it's just in "Spain", not in "peninsular Spain". So the algorithm has no way of telling which of the higher levels to use. In that case, it just picks the second one. If you wanted to set Iberian Peninsula as preferred value of P706 for Spain, that would solve it for every location with mainland Spain. Similar considerations apply when trying to determine the hemisphere (via P706) that African Spain belongs to. The information isn't there, so it picks the second one. Nevertheless, the function was designed to terminate at the country level, so it's best to set the country as a country.

The problem with excluding classes such as countries when subclasses exist is that a coder has to anticipate all possible values of the subclass. At line 1550, I already test for the location being a country within the United Kingdom (Q3336843) as a condition to terminate the chain, now it's being suggested that I have to test for 'Mediterranean country" as well. Do I also have to test for 'Baltic country'? What about banana producing countries (Q66903706) or any of the other 32 items that are subclasses of country? https://w.wiki/Q6d refers.

Currently, {{#invoke:WikidataIB |location |Q2807 |first=y}} → Madrid, Community of Madrid, Spain -- Thanks Mike.

@Mike: it never looks at P30. It got "Africa" or the "Iberian Peninsula" from P706, where they have equal rank. So are there really any tweaks you want me to make? --RexxS (talk) 17:49, 6 May 2020 (UTC)

@RexxS: Thanks for the background info, I've modified located in/on physical feature (P706) accordingly, [1]. My preference would actually be to remove located in/on physical feature (P706) support completely, as I'm not sure it's useful. With the subclasses, @Roberpl: replied to my revert saying that sovereign state (Q3624078) is a subclass of the country, but given that this only affects a few countries and would involve a lot of checks, my preference is to keep things simpler here and keep P31=country - but I don't know what will happen in the long term here. Thanks. Mike Peel (talk) 18:01, 6 May 2020 (UTC)

@Mike Peel: I think there were originally some terrain features that had P706, but no P131. I would have thought that normally having the fallback to P706 would only be beneficial, because they may show up missing data in entries. Or how about {{#invoke:WikidataIB |location |Q320936 |first=y}} → Mare Tranquillitatis, LQ12 (needs support for P376). --RexxS (talk) 18:28, 6 May 2020 (UTC)

Thanks, now it displays correctly except for a few anormalities which have apparently been tracked. I do not have a strong opinion on the rest, since I don't know much about these modules' functioning. Strakhov (talk) 02:56, 7 May 2020 (UTC)

This section is resolved and can be archived. If you disagree, replace this template with your comment. Mike Peel (talk) 17:01, 12 June 2020 (UTC)

ex-libris (P8195)

There is a new property for a person's ex libris. I added it to the sandbox. It can be tested at Category:Andrée Béarn. Please check and add to the live version Jura1 (talk) 17:36, 6 May 2020 (UTC)

I think an ex-libris is a rather niche, trivial aspect of most people who have them, and I'm not a fan of image cramming for the sake of mere show-and-tell. When will it stop? Image, grave, coat of arms, commemorative plaque, 'related image', signature, ex libris, etc, why not images of house, spouse, hometown, and left toe? Less is best, in my opinion. Does the infobox have a limit to the number of images/radio buttons it displays? --Animalparty (talk) 20:06, 6 May 2020 (UTC)

Only one image is displayed by default: image (P18) if present. It might be rare that we have all of the above for an individual.

The property is there to simplify retrieving the image. Jura1 (talk) 21:09, 6 May 2020 (UTC)

@Jura1: The change is now live. Thanks. Mike Peel (talk) 15:08, 10 May 2020 (UTC)

This section is resolved and can be archived. If you disagree, replace this template with your comment. Mike Peel (talk) 17:00, 12 June 2020 (UTC)

Duplicate defaultsort warning displayed although defaultsort=no is set

Hi! Although I have set defaultsort=no in Category:Buildings by Elissa Aalto, the duplicate defaultsort warning is still displayed. ––Apalsola ^{t • c} 12:33, 10 May 2020 (UTC)

And Category:Buildings by Elissa Aalto is also categorised under family name, given name, births by year etc. categories derived from Q2628666.

These problems may be related to the feature that displays data from the items set in P971 parameter in Q93864507. ––Apalsola ^{t • c} 12:56, 10 May 2020 (UTC)

@Apalsola: Good catch, I forgot to turn off auto-categorisation for the embedded infoboxes. I've now modified {{Wikidata Infobox/sandbox}} to do that, please check it. I'll make that live shortly as it's a significant issue. Thanks. Mike Peel (talk) 13:38, 10 May 2020 (UTC)

@Mike Peel: Thanks for your prompt response. The fix in the sandbox template seems to work OK. ––Apalsola ^{t • c} 13:53, 10 May 2020 (UTC)

@Apalsola: Thanks for checking it, the change is now live. Thanks. Mike Peel (talk) 15:08, 10 May 2020 (UTC)

This section is resolved and can be archived. If you disagree, replace this template with your comment. Mike Peel (talk) 15:21, 12 June 2020 (UTC)

Links to English Wikipedia in media legend

Some wikidata items’ images has interwiki links to wikipedia articles in the "media legend" description to the image. Those link correctly in Commons to non-English Wikipedias (if you change Common’s interface to respective language). But links to English Wikipedia attempt to link to Commons instead. Example: LASIK. Links to English Wikipedia work in other places in Commons, but not in Wikidata Infobox. Where should I ask for fixing it?— Роман Рябенко (talk) 21:50, 23 May 2020 (UTC)

Someone fixed it. Now it works for English too.--Роман Рябенко (talk) 06:16, 24 May 2020 (UTC)

@Роман Рябенко: I think you fixed it through your edits at LASIK (Q278846). Due to caching, changes can take a while to show up here - you can do a null edit (edit and save the page without making changes) or purge the cache (add ?action=purge at the end of the URL) to check if it is a caching issue. Also, technically the media legends aren't supposed to include wikitext, so this is an unsupported feature, but it does seem to work... Thanks. Mike Peel (talk) 11:36, 24 May 2020 (UTC)

This section is resolved and can be archived. If you disagree, replace this template with your comment. Mike Peel (talk) 15:21, 12 June 2020 (UTC)

Vandalism

{{Edit request}} A template somewhere has been vandalised to display "amor Miguel Falabella" twice under the authority control section of the Wikidata Infobox. I'm trying to track down where this was done but if anyone with more expertise in this template can find it more quickly, please do! --Canley (talk) 03:22, 31 May 2020 (UTC)

Indeed, this problem is also polluting Wikidata and some Wikipedias that are pro-Commons category (P373). --Liuxinyu970226 (talk) 03:53, 31 May 2020 (UTC)

@Canley and Liuxinyu970226: Thanks for reporting. I think the issue is fixed now, since I can not find any pages with that message. Anybody knows anything about it? --Jarekt (talk) 04:36, 31 May 2020 (UTC)

Yes, seems to have been fixed, I purged the cache and no longer see it. --Canley (talk) 04:38, 31 May 2020 (UTC)

This section is resolved and can be archived. If you disagree, replace this template with your comment. Mike Peel (talk) 15:17, 12 June 2020 (UTC)

GMC registration number

Please add GMC registration number (P8273) to the Authority control section; it is an idenitifer for UK physicians, and in many cases will be the only identfier we have for such individuals. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 21:13, 5 June 2020 (UTC)

Moin Moin Andy Mabbett, I added it to the sandbox of Wikidata Infobox, please check it, if everything looks good. Regards --Crazy1880 (talk) 13:27, 6 June 2020 (UTC)

@Crazy1880: Thank you. That's working, but I think the label could be just "GMC", rather than "GMC registration number". Or is it pulled from the Wikidata label? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 14:29, 6 June 2020 (UTC)

@Andy Mabbett, yes, it's the label from Wikidata. Perhaps you could do there the label to "GCM" and the alias to "GMC registration number"? Regards --Crazy1880 (talk) 16:53, 6 June 2020 (UTC)

Thank you, but no, I don't think that appropriate. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 17:46, 6 June 2020 (UTC)

@Pigsonthewing: It's now live. Thanks. Mike Peel (talk) 16:40, 12 June 2020 (UTC)

This section is resolved and can be archived. If you disagree, replace this template with your comment. Crazy1880 (talk) 12:03, 14 June 2020 (UTC)

Drobné památky ID

Please add Drobné památky ID (P6736) to the Authority control section. It is an identifier for Czech small-scale public artwork. At the moment 3000+ items with both Drobné památky ID (P6736) and Commons category (P373). Jklamo (talk) 13:05, 7 June 2020 (UTC)

@Jklamo: It's now in {{Wikidata Infobox/sandbox}}, I'll deploy that shortly. Does it look OK? Thanks. Mike Peel (talk) 15:15, 12 June 2020 (UTC)

@Jklamo: It's now live. Thanks. Mike Peel (talk) 16:39, 12 June 2020 (UTC)

@Mike Peel: Looks great, thanks! Jklamo (talk) 19:55, 13 June 2020 (UTC)

This section is resolved and can be archived. If you disagree, replace this template with your comment. Mike Peel (talk) 20:04, 13 June 2020 (UTC)

mysterious errors

Last few months there is a lot of strange errors in Category:Pages_with_script_errors, most are category pages and all are not showing any issues when inspected and disappear from the category when the page is purged. It is not a big deal, if it happens once but it happens every day and each time I check there are 50-500 categories there without any issues. All of them look like [something] in/at/of [something-else]. Checking rendering time for those pages show that they are all very slow loaders, maybe the issue is that at some point they do take longer to load and trip some error but next time you check they are loading in less then 10 sec and do not show any issues maybe we could add some flag to the template to sacrifice some content in favor of speed so we could add it to the most problematic ones. --Jarekt (talk) 23:53, 8 June 2020 (UTC)

@Jarekt: The version in the sandbox should fix this issue (it runs faster, so shouldn't hit the 10 second limit as much), but it needs some more tweaking and testing before it's ready to deploy. Thanks. Mike Peel (talk) 09:37, 9 June 2020 (UTC)

That is good to hear. I can be purging Category:Pages with script errors for a bit longer (80 categories today), but I like to monitor Category:Pages with script errors carefully as most cases are doe to my edits. --Jarekt (talk) 11:30, 9 June 2020 (UTC)

@Jarekt: The new version is live, hopefully Category:Pages with script errors will be a bit emptier now. Thanks. Mike Peel (talk) 16:38, 12 June 2020 (UTC)

Mike, There were again 2k categories in Category:Pages_with_script_errors. A lot of "date in place" categories and people categories. Very slow purging clears them all up, so it is unclear whatever the error was ... --Jarekt (talk) 18:28, 17 June 2020 (UTC)

This section is resolved and can be archived. If you disagree, replace this template with your comment. Mike Peel (talk) 18:56, 12 June 2020 (UTC)

Template gone crazy

See Category:Venues_of_the_2002_FIFA_World_Cup – numerous timeout errors and a raft of bizarrely inappropriate categories. --R'n'B (talk) 14:50, 10 June 2020 (UTC)

Seems to have gone away, although previewing the category page in edit mode (without actually editing anything) still shows timeouts. --R'n'B (talk) 17:32, 10 June 2020 (UTC)

@R'n'B: Should be better now. Thanks. Mike Peel (talk) 16:37, 12 June 2020 (UTC)

This section is resolved and can be archived. If you disagree, replace this template with your comment. Mike Peel (talk) 20:05, 13 June 2020 (UTC)

No documentation

{{Edit request}} Documentation exists for this template, but isn't being displayed. I think it's just missing <noinclude>{{Documentation}}</noinclude> at the end. --Lord Belbury (talk) 12:01, 6 July 2020 (UTC)

@Lord Belbury:  Done. Thanks. Mike Peel (talk) 16:28, 6 July 2020 (UTC)

This section is resolved and can be archived. If you disagree, replace this template with your comment. Mike Peel (talk) 17:43, 24 July 2020 (UTC)

For religious buildings

It would be nice to also display religion or worldview (P140) in categories such as Category:Mt. Moriah Lutheran Church. Would someone take time to add this to the current features? Thierry Caro (talk) 08:13, 23 April 2020 (UTC)

@Thierry Caro: Given that this property is controversial in a lot of cases, I'd prefer to not include it in the infoboxes, if that's OK. Thanks. Mike Peel (talk) 17:09, 12 June 2020 (UTC)

@Mike Peel: It honestly does not matter that much as an Infobox feature. But I'm disappointed by the reason provided. Controversies? Which controversies? Fuck them! There's none we should care about, honestly. Come on, my friend. We are serious people here and we should be able to deal in a resonable manner with possible problems if there are any that appear. There is no real reason to be afraid of anything. Thierry Caro (talk) 17:24, 12 June 2020 (UTC)

@Thierry Caro: See en:Wikipedia:Village_pump_(policy)/Archive_126#RfC:_Religion_in_biographical_infoboxes. But actually, you said "buildings" in the title, so maybe I can add it just for non-people items, [2], try that? Thanks. Mike Peel (talk) 17:32, 12 June 2020 (UTC)

@Mike Peel: You really caught me off-guard with your line on controversy. Whatever, I guess that if we cannot have the property used for everything, I'll take the buildings alone. If you can do that, thank you. This is, I suppose, the least 'controversial' part. Thierry Caro (talk) 17:36, 12 June 2020 (UTC)

@Thierry Caro: This is now live. Thanks. Mike Peel (talk) 18:32, 7 August 2020 (UTC)

Thank you. Thierry Caro (talk) 18:50, 7 August 2020 (UTC)

This section is resolved and can be archived. If you disagree, replace this template with your comment. Mike Peel (talk) 18:32, 7 August 2020 (UTC)

(1900, 2000) vs. (1900-2000)

See for example: Category:Cory Booker where his dates for the various positions he held are separated by a comma instead of a dash. (1900, 2000) instead of (1900-2000). This usage is wrong, the comma indicates holding the position two times, once in each of the two years, indicating there is no continuity in office. The dash, like we use in birth and death dates indicate continuity. --RAN (talk) 16:30, 16 June 2020 (UTC)

@Richard Arthur Norton (1958- ): The latest version of WikidataIB (just updated here) improves the display of qualifiers, they are now displayed with a dash. Thanks. Mike Peel (talk) 18:21, 7 August 2020 (UTC)

This section is resolved and can be archived. If you disagree, replace this template with your comment. Mike Peel (talk) 18:21, 7 August 2020 (UTC)

Gramophone composer ID

Please consider adding Gramophone composer ID (P8386). Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 10:55, 28 June 2020 (UTC)

@Pigsonthewing: Added to {{Wikidata Infobox/sandbox}}, please check it. Thanks. Mike Peel (talk) 18:19, 1 July 2020 (UTC)

Seems to work well. Thank you. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 22:13, 1 July 2020 (UTC)

@Pigsonthewing: This is now live. Thanks. Mike Peel (talk) 18:15, 7 August 2020 (UTC)

This section is resolved and can be archived. If you disagree, replace this template with your comment. Mike Peel (talk) 18:15, 7 August 2020 (UTC)

Box loosing connection

Tracked in Phabricator
Task T257266

Hi, its weird, but currenty the box is loosing its connexction to WD, as soon some cats are beeing added or removed. I found that on Category:Aurelio Craffonara (d:Q16063928), Category:Suzanne Ferrand (d:Q23618709) and Category:Nakia Burrise (d:Q3303302). After that I did some test edits on Category:Angela Merkel (d:Q567) with the same effect. There is someting broken, which should be urgently fixed. Thx. --JuTa 01:04, 7 July 2020 (UTC)

@User:Mike Peel please have a look --JuTa 01:06, 7 July 2020 (UTC)

I noticed a few cases of this too. I just edited Østbirk Church (Q12011908) and then noticed that the Wikidata & Wikipedia links disappeared from Category:Østbirk Kirke. --Hjart (talk) 02:46, 7 July 2020 (UTC)

Same here. --Arnd (talk) 05:45, 7 July 2020 (UTC)

PS: when you add a perameter qid=XXXX the box is working fine again, i.e. here. --JuTa 05:49, 7 July 2020 (UTC)

I can confirm, mo more box anymore, new songtitle from the stranglers ;)--Derzno (talk) 05:50, 7 July 2020 (UTC)

@JuTa: It looks to be working now? Perhaps there was a server glitch that's now been fixed. If not, try "?action=purge" to clear the cache, and see if that resolves the issue? Thanks. Mike Peel (talk) 08:20, 7 July 2020 (UTC)

Ah, I see, it's phab:T257266. Also discussed at Commons:Village_pump#Interproject_connection_fails and elsewhere. Thanks. Mike Peel (talk) 08:26, 7 July 2020 (UTC)

Just tested it and didn't work so far. --46.244.175.209 14:07, 7 July 2020 (UTC)

Probably you got a stale version. Pages are more aggressively cached for logged-out users than for logged-in ones (caching generally improves user experience, and you get a less customizable interface than a logged-in user, which is easier to cache). This cache can be cleared by appending ?action=purge to the URL (and then pressing the big blue confirm button), after which the category should be OK. All the above examples are good for me when opening them logged out, by the way. —Tacsipacsi (talk) 19:52, 7 July 2020 (UTC)

This section is resolved and can be archived. If you disagree, replace this template with your comment. Mike Peel (talk) 18:14, 7 August 2020 (UTC)

Categorize missing items separately

When trying to find out if any bad cached categories left after the above-mentioned bug, I was surprised that categories without a Wikidata item aren’t categorized separately. The nearest tracking category is Category:Uses of Wikidata Infobox with no instance of, however that contains a lot of categories where there’s an item, but that doesn’t have a P31 statement. Not having an item at all is a far larger issue than having a P31-less item, and I think it should warrant for an own tracking category. Is there a reason not to create it? —Tacsipacsi (talk) 23:01, 7 July 2020 (UTC)

@Tacsipacsi: I think you're looking for Category:Uses of Wikidata Infobox with problems. It contains a lot of unmatched categories that aren't the result of the bug, though, otherwise I'd have bot-purged them. Thanks. Mike Peel (talk) 07:50, 8 July 2020 (UTC)

@Mike Peel: So Category:Uses of Wikidata Infobox with problems only contains pages that have no Wikidata connection? Its name is quite general (“problems” can mean pretty much anything from missing item to missing P31 statement to missing English label of an item used in some statement), and it has no description at all, just a bunch of templates which don’t clarify what it’s for (apart from having some connection to {{Wikidata Infobox}}). Tacsipacsi (talk) 22:21, 8 July 2020 (UTC)

@Tacsipacsi: Yes, if the infobox works then it appears in Category:Uses of Wikidata Infobox, otherwise it says says "NO WIKIDATA ID FOUND!" and it will be in Category:Uses of Wikidata Infobox with problems. I think these were the original pair of tracking categories for the template... Happy for it to be renamed/have a proper description added if you want. Thanks. Mike Peel (talk) 06:47, 9 July 2020 (UTC)

@Mike Peel: I went ahead and added a description (and removed {{Autocat}} to reduce the visual clutter, as the template is now mentioned in the description, and I don’t think anyone would really add a maintenance category manually). I think it should be renamed to something like “Uses of Wikidata Infobox with no item”, but I don’t want to be too bold in renaming a such big category without prior consensus. —Tacsipacsi (talk) 13:54, 9 July 2020 (UTC)

@Tacsipacsi: OK, I've created Category:Uses of Wikidata Infobox with no item and updated {{Wikidata Infobox/sandbox}} to use it, will deploy the change with other edits soon. It'll then take a while for the transition to happen, but I may speed it up with a null edit bot. Thanks. Mike Peel (talk) 17:42, 24 July 2020 (UTC)

@Mike Peel: Thanks! I think the category should have been moved, not recreated, so that edit history is preserved (for example, my category description was released under CC, not placed in the public domain), and it remains on watchers’ watchlists (some people might want to get notified on watchlist when the infobox is added inappropriately). After you created the category under the new name, I don’t think I can move the old one over it without admin right. (I can give it a try after the template change will have gone live, of course, if you’d like.) Thanks in advance, —Tacsipacsi (talk) 00:44, 25 July 2020 (UTC)

@Tacsipacsi: I deleted the new category and moved the old one to the new name, so the edit history is still there. It's also now being populated as the infobox code has been updated, it'll take a while for all the categories to move over. Thanks. Mike Peel (talk) 18:12, 7 August 2020 (UTC)

This section is resolved and can be archived. If you disagree, replace this template with your comment. Mike Peel (talk) 18:12, 7 August 2020 (UTC)

supressing Category:Unisex names from Category:Uses of Wikidata Infobox with no image

Hi, can Category:Unisex names supressed from Category:Uses of Wikidata Infobox with no image like i.e. Category:Male names? Thx. --JuTa 14:57, 11 July 2020 (UTC)

@JuTa: It's now in {{Wikidata Infobox/sandbox}}, please test it. Thanks. Mike Peel (talk) 17:23, 24 July 2020 (UTC)

Looks fine in Category:Burçin (given name), thx a lot. PS: did you see my other request at #Roman names? --JuTa 17:31, 24 July 2020 (UTC)

I saw your other request, but am not sure how to implement it yet. Thanks. Mike Peel (talk) 17:52, 24 July 2020 (UTC)

@JuTa: This is now live. It'll take a while for the category includes to update. Thanks. Mike Peel (talk) 18:07, 7 August 2020 (UTC)

This section is resolved and can be archived. If you disagree, replace this template with your comment. Mike Peel (talk) 18:07, 7 August 2020 (UTC)

published in (P1433)

Hello, I don't know if it have been already discussed but is it possible to display the value stored by published in (P1433)? it will be displayed in a lot of categories in the same kind of this one, and also this is a quite relevant info. Christian Ferrer ^(talk) 19:23, 17 July 2020 (UTC)

@Christian Ferrer: It's now in {{Wikidata Infobox/sandbox}}, please test it. Thanks. Mike Peel (talk) 17:23, 24 July 2020 (UTC)

@Mike Peel: It's perfect, thank you. You can make the effective change as soon as you wish. Christian Ferrer ^(talk) 18:15, 24 July 2020 (UTC)

@Christian Ferrer: It's now live. Thanks. Mike Peel (talk) 18:06, 7 August 2020 (UTC)

This section is resolved and can be archived. If you disagree, replace this template with your comment. Mike Peel (talk) 18:06, 7 August 2020 (UTC)

Update Toolforge URL

{{Edit protected}} Hi, can you update the URLs to Toolforge in Template:Wikidata Infobox/core as they have changed due to phab:T234617 I've already made the changes in the sandbox Thank you --Nintendofan885^{T&Cs apply} 21:06, 28 July 2020 (UTC)

@Nintendofan885: Is there any actual issue with the old URLs, apart from the additional redirect not being nice? If there isn’t, I’d let Mike Peel deploy it when other changes are deployed anyway (to reduce the load on the servers), and the edit request could be disabled. —Tacsipacsi (talk) 00:21, 30 July 2020 (UTC)

@Tacsipacsi: No. That's fine, you can close this edit request --Nintendofan885^{T&Cs apply} 10:56, 31 July 2020 (UTC)

@Nintendofan885 and Tacsipacsi: The changes are now live. Thanks for directly editing the sandbox! For background, I try to limit the number of edits to the live version to around 1 per month, queuing things up here until there's a batch of changes to be made in one go. Thanks. Mike Peel (talk) 18:05, 7 August 2020 (UTC)

This section is resolved and can be archived. If you disagree, replace this template with your comment. Mike Peel (talk) 18:05, 7 August 2020 (UTC)

Maps: zoom level and borders

I do not understand in detail how the display of the maps is controlled in the infobox. I very much reckon it takes the geocoordinates from P625 to display the pin on that loacation of the map, but how is the zoom level determinedß Does this depend on the accuracy level of the coordinates? Or is there some other magic? Second thing is that for an item that is an area, it sometimes displays the borders / boundaries of that area, sometimes it doesn't. E.g. in Category:Lac de Carcans-Hourtin you see a thick grey line around the lake. The same happens to Category:Ratingen - however with a high zoom level so that you have to zoom out to see the entire area. And for other items, e.g. Category:Payangan, there is no outline at all. Where does the infobox get the boundaries from? I would understand this if the item is linked to an OSM id, but the case of Lac de Carcan-Hourtin shows it cannot be the source, as there is no such link. -- H005 15:12, 5 August 2020 (UTC)

@H005: The link is made the other way, from OSM to Wikidata. For example, see https://www.openstreetmap.org/relation/1450359 for Hourtin-Carcans Lake (Q1535929). OSM relations should be linked in both directions, but for other OSM objects it's not possible – but it is possible to add their Wikidata ID on the OSM side, and so get boundaries in the infobox on Commons. — Sam Wilson ( Talk • Contribs ) … 03:30, 6 August 2020 (UTC)

@Samwilson: Thanks. Does it take a while until this takes effect? I tested adding it to an OSM item yesterday morning, but can't see any effect until now. (Also, if anyone has an answer to the zoom level question, I'd still be very much interested.) -- H005 06:51, 7 August 2020 (UTC)

@H005: Yep, it can take a few days I think (although maybe it's paused at the moment). — Sam Wilson ( Talk • Contribs ) … 06:56, 7 August 2020 (UTC)

@H005: The map zoom is automatically chosen based on the value of area (P2046) (it works best if this is in km^2). It looks like Ratingen (Q3791) has two areas, which has shown up a bug in the infobox code that I've fixed in {{Wikidata Infobox/sandbox}}, will update the main version soon. Thanks. Mike Peel (talk) 13:16, 7 August 2020 (UTC)

This is now live. Thanks. Mike Peel (talk) 19:16, 7 August 2020 (UTC)

Thanks a lot! Seems to work pretty well! -- H005 02:06, 8 August 2020 (UTC)

This section is resolved and can be archived. If you disagree, replace this template with your comment. Mike Peel (talk) 19:16, 7 August 2020 (UTC)

Errors

There are a lot of categories related to Gambia in Category:Pages with script errors, like Category:2016 in Gambia. Any idea how to fix it? --Jarekt (talk) 02:22, 6 August 2020 (UTC)

{{Gambiayear}} was transcluding {{Wikidata Infobox}}, resulting in two such infoboxes in the categories. I've removed the transclusion, which fixes the errors. However, even the single use of Wikidata Infobox consumes a lot of time to load on those pages, which suggests there's a second problem afoot. Pi.1415926535 (talk) 03:38, 6 August 2020 (UTC)

I've modified {{Wikidata Infobox/sandbox}} so it will also skip instance of (P31)=sovereign state (Q3624078) when deciding which items to show in 'category combines' cases. That should help speed things up. Thanks. Mike Peel (talk) 17:37, 7 August 2020 (UTC)

Now live. Thanks. Mike Peel (talk) 17:50, 7 August 2020 (UTC)

This section is resolved and can be archived. If you disagree, replace this template with your comment. Mike Peel (talk) 17:50, 7 August 2020 (UTC)

Template miscategorizes people based on incorrect (non-best rank) gender

This template places, for instance, Category:Kae Tempest in Category:Women by name rather than Category:LGBT people by name (or Category:Non-binary people by name or Category:Non-binary people), and Category:Stephanie Burt in Category:Men by name (and also Category:LGBT people by name, but not Category:Women by name). On Wikidata, the sex or gender (P21) information is correct; I believe the issue is with how Template:Wikidata Infobox/core uses Module:WikidataIB’s checkvalue function. I think there are two separate problems:

1. The function should only take best-rank statements into account: preferred-rank statements if any exist, otherwise normal-rank statements, never deprecated-rank statements even if they’re the only ones.
2. The template should categorize people slightly differently: trans woman (Q1052281) and trans man (Q2449503) should not only produce Category:LGBT people by name, but also Category:Women by name and Category:Men by name respectively; more values should also be recognized, such as non-binary (Q48270), intersex (Q1097630), genderfluid (Q18116794), agender (Q505371), genderqueer (Q12964198), either by handling them explicitly in the template code and mapping them to appropriate categories, or by mapping any unrecognized value to Category:LGBT people by name (though I’m not sure if this is correct for values like two-spirit (Q301702)).

--Lucas Werkmeister (talk) 21:23, 6 August 2020 (UTC)

@Lucas Werkmeister: I've updated the code in {{Wikidata Infobox/sandbox}}, please can you check it? With the new version, it only uses best-ranked values (I think - pinging @RexxS: to check that "checkvalue|rank=best" will work?), and the following categories are added, in this order:

sex or gender (P21)	Category
intersex (Q1097630)	Category:LGBT people by name
genderfluid (Q18116794)	Category:LGBT people by name
agender (Q505371)	Category:LGBT people by name
genderqueer (Q12964198)	Category:LGBT people by name
non-binary (Q48270)	Category:Non-binary people by name
trans woman (Q1052281)	Category:LGBT people by name Category:Women by name
trans man (Q2449503)	Category:LGBT people by name Category:Men by name
male (Q6581097)	Category:Men by name
female (Q6581072)	Category:Women by name

Any other QID values for P21 do not add categories here. Does this seem OK, or are there other changes that should be made at the same time? Thanks. Mike Peel (talk) 19:08, 7 August 2020 (UTC)

@Mike Peel: Thanks! Testing Kae Tempest (Q6375824) (by previewing {{Wikidata Infobox/sandbox|qid=Q6375824}} on a random category page), Category:Non-binary people by name is added now, but Category:Women by name is still there. Looking at the source code of checkvalue, I don’t think it supports a rank parameter (only getValue does, if I’m not mistaken). --Lucas Werkmeister (talk) 20:50, 7 August 2020 (UTC)

Apologies, Mike, I hadn't considered the case of unwanted ranks in checkvalue(). I've now updated the code in Module:WikidataIB/sandbox to fully implement ranks:

• {{#invoke:WikidataIB/sandbox |checkvalue |val=Q5 |qid=Q42}} → Q5
• {{#invoke:WikidataIB/sandbox |checkvalue |val=Q5 |qid=Q42 |rank=b}} → Q5
• {{#invoke:WikidataIB/sandbox |checkvalue |val=Q5 |qid=Q42 |rank=p}} →
• {{#invoke:WikidataIB/sandbox |checkvalue |val=Q5 |qid=Q42 |rank=n}} → Q5
• {{#invoke:WikidataIB/sandbox |checkvalue |val=Q5 |qid=Q42 |rank=d}} →
• {{#invoke:WikidataIB/sandbox |checkvalue |val=Q5 |qid=Q42 |rank=p n d}} → Q5

You might want to check it before updating the main module. Cheers --RexxS (talk) 20:58, 7 August 2020 (UTC)

Thanks RexxS. @Lucas Werkmeister: the infobox sandbox now uses the WikidataIB sandbox for these calls, can you confirm that's now working OK? Thanks. Mike Peel (talk) 14:22, 8 August 2020 (UTC)

@Mike Peel and RexxS: looks good to me now, thanks! --Lucas Werkmeister (talk) 16:38, 8 August 2020 (UTC)

@Lucas Werkmeister and RexxS: The updated WikidataIB and infobox code are now live, let's see how that goes. Thanks. Mike Peel (talk) 17:51, 20 August 2020 (UTC)

This section is resolved and can be archived. If you disagree, replace this template with your comment. Mike Peel (talk) 17:51, 20 August 2020 (UTC)

Wishlist: locator tool -link

Commons:Locator-tool could be added to wikidata infobox as tool link (example link) --Zache (talk) 09:34, 11 August 2020 (UTC)

@Zache: It's in {{Wikidata Infobox/sandbox}}, just below the coordinates, does that look/work OK? Thanks. Mike Peel (talk) 11:15, 15 August 2020 (UTC)

@Mike Peel: Place is ok, It seems to work with this change. (ie. without category -prefix and urlencode)--Zache (talk) 20:22, 18 August 2020 (UTC)

@Zache: It's now live. I'm a bit worried that the absence of 'urlencode' might cause problems with spaces in category names, but let's see how it goes. Thanks. Mike Peel (talk) 17:50, 20 August 2020 (UTC)

This section is resolved and can be archived. If you disagree, replace this template with your comment. Mike Peel (talk) 17:50, 20 August 2020 (UTC)

Category:Individual painting categories

Mike can you add {{#ifeq:{{#{{#property:P31}}|Q3305213|[[Category:Individual painting categories]]}} somewhere to Wikidata Infobox? I am trying to populate a new category I just created Category:Individual painting categories, which will be used for adding more digital representation of (P6243) to paintings. --Jarekt (talk) 02:29, 14 August 2020 (UTC)

@Jarekt: It's added to {{Wikidata Infobox/sandbox}}, and seems to work OK at Category:Mona Lisa. I used different code (using WikidataIB for the check), can you test it some more please? Thanks. Mike Peel (talk) 11:14, 15 August 2020 (UTC)

@Mike Peel: I found the change in Template:Wikidata Infobox/core/sandbox and it looks fine. It would be great if you could add it to the next release. --Jarekt (talk) 03:10, 16 August 2020 (UTC)

@Jarekt: It's now live. Thanks. Mike Peel (talk) 17:48, 20 August 2020 (UTC)

This section is resolved and can be archived. If you disagree, replace this template with your comment. Mike Peel (talk) 17:48, 20 August 2020 (UTC)

Wrong coordinates

Sometimes there are wrong coordinates. Example: Category:Trzebiel. In infobox 51°36'N and 14°48'E (wrong, even on map), in wikidata (right coordinates) 51°40'N and 14°46'E. --PaulT (talk) 16:06, 14 August 2020 (UTC)

@PaulT: Normally the problem is with the 'precision' of the coordinates on Wikidata, you can resolve this by changing the precision or removing and re-adding the coordinates from Wikidata. Thanks. Mike Peel (talk) 18:42, 14 August 2020 (UTC)

Changed the precision, but doesn't work. Any other idea? --PaulT (talk) 10:37, 18 August 2020 (UTC)

@PaulT: It seems to have worked, try visiting [3] to purge the cache. Thanks. Mike Peel (talk) 11:06, 18 August 2020 (UTC)

Didn't think to have it in the cache for so a long time. Sorry and thank you very much. --PaulT (talk) 15:26, 18 August 2020 (UTC)

This section is resolved and can be archived. If you disagree, replace this template with your comment. Mike Peel (talk) 17:18, 3 September 2020 (UTC)

DEFAULTSORT & non-existing categories

as far as I understand, for a person to be sorted correctly on commons by this template, the following preconditions must be fulfilled:

• family name (P734) has to be set (e.g. Pinki)
• given name (P735) has to be set (e.g. Herzi)
  • both must exist / must be created for unusual names
• Category:Pinki (surname) has to exist
• Category:Herzi (given name) has to exist

then and only then a DEFAULTSORT statement like

{{DEFAULTSORT:Pinki, Herzi}}

will be created (don't blame me if details are not quite correct, I didn't look into the implementation). It is a burden to create family name (P734) & given name (P735), if not existing. But why is there a need to create categories too for just creating a text like the above DEFAULTSORT statement. If there is no obvious reason, maybe you can release this constraint and create the DEFAULTSORT statement anyway. best --Herzi Pinki (talk) 21:52, 17 August 2020 (UTC)

The DEFAULTSORT template entirely independent of the Wikidata Infobox template. It's especially useful for people who go by pseudonyms that differ from their actual first or last names. You may notice the Wikidata Infobox freaks the hell out whenever it encounters a category with a {{DEFAULTSORT}} text string that doesn't match exactly with the Wikidata values for given and family names (e.g. {{DEFAULTSORT:Shmoe, Joe P.}} for, given name (P735) = Joe (Q17862013) }} and family name (P734) = Schmoe), and screams a bright red "Warning: Default sort key "_____" overrides earlier default sort key "_____", as seen in Category:Pages with DEFAULTSORT conflicts. The {{Wikidata Infobox}} does add corresponding categories for given and surnames, whether they exist or not, and whenever you see a red category, that's just Wikidata nudging you to create one. You are under no obligation to create said category. --Animalparty (talk) 03:04, 18 August 2020 (UTC)

I observed that whenever one of the above categories is red, sorting goes by category name and not by family name, given name. --Herzi Pinki (talk) 05:43, 18 August 2020 (UTC)

@Herzi Pinki: Can you give an example, please? Looking at the code, it should not depend on the existence of the category, just the values of family name (P734) and given name (P735) on Wikidata. Possibly there could be caching errors if you have just added one of those values on Wikidata. @Animalparty: The infobox doesn't scream when it encounters that issue, the error message is in lower case, it's more of a yelp. Pi bot will disable the automatic DEFAULTSORT in those cases after a day or so. Thanks. Mike Peel (talk) 07:37, 18 August 2020 (UTC)

Category:Heinrich Reisenbauer is listed in Category:Male sculptors from Austria under H (like Heinrich), instead of R (like Reisenbauer). --Herzi Pinki (talk) 07:44, 18 August 2020 (UTC)

@Herzi Pinki: Ah, I see. Reisenbauer (Q98446767) needs to have a label in English for it to work. Thanks. Mike Peel (talk) 08:50, 18 August 2020 (UTC)

tricky, thanks --Herzi Pinki (talk) 08:54, 18 August 2020 (UTC)

This section is resolved and can be archived. If you disagree, replace this template with your comment. Mike Peel (talk) 17:17, 3 September 2020 (UTC)

Traditionelle Lebensmittel in Österreich

Ist es möglich in der Infobox die Beschreibung de:Register der Traditionellen Lebensmittel unterzubringen, derzeit im Aufbau siehe Abgeleitete Aussagen im wikidata:Q15841993 --danke -- K@rl (talk) Mid Abstond hoidn xund bleibn 10:40, 29 September 2020 (UTC)

Die Anforderung verstehe ich nicht. Man bringt dort keine einzelnen Items unter, nur Aussagen. -- H005 16:36, 29 September 2020 (UTC)

Als Beispiel wäre die Indexnummer wie in wikidata:Q266540

@Karl Gruber and H005: I don't speak German, but I can use Google Translate. Bitte google übersetze meine Antwort. I'm not sure what is wanted here, but I think it's one of two options. Either you're after an infobox in a category for the register, in which case you need to point out which Commons category connects to Register of traditional Austrian food (Q15841993). Or you're trying to create an authority control property for the registry, in which case you need to propose it at wikidata:Wikidata:Property proposal/Authority control. Thanks. Mike Peel (talk) 19:05, 29 September 2020 (UTC)

@Mike Peel: I think it’s the second case, see Kaiserschmarrn (Q266540) described by source (P1343) Register of traditional Austrian food (Q15841993) / URL (P2699) https://www.bmlrt.gv.at/land/lebensmittel/trad-lebensmittel/speisen/kaiserschmarren.html. It’s theoretically not impossible to process this, although quite tricky indeed.

@Karl Gruber: Diese Infobox zeigt nur Eigenschaften, sie „versteht“ Qualifikatoren nicht (einige Qualifikatoren werden in Klammern gezeigt, aber das ist alles, sie werden nicht weiter verarbeitet). Es ist theoretisch möglich, Qualifikatoren mehr zu unterstützen, aber sehr kompliziert, wahrscheinlich wird es solche Unterstützung nicht bald (oder nie) geben. Du kannst eine neue Eigenschaft (mit Datentyp „Externer Identifikator“) vorschlagen. – Tacsipacsi (talk) 22:34, 29 September 2020 (UTC)

Alles klar, thx werden wir machen. ---- K@rl (talk) Mid Abstond hoidn xund bleibn 08:37, 30 September 2020 (UTC)

This section is resolved and can be archived. If you disagree, replace this template with your comment. Mike Peel (talk) 16:51, 5 December 2020 (UTC)

image inconsistency

Hi @Mike Peel: , there seems to be a flaw in the Infobox template, see e.g. Category:State coats of arms of Vienna: Some image seems to be missing, because of the [[File: | 95px]]. --Herzi Pinki (talk) 07:09, 10 July 2020 (UTC)

@Herzi Pinki: The problem was on Wikidata, the image had been marked as deprecated. Fixed. Although probably the same image shouldn't be in both image (P18) and coat of arms image (P94). Thanks. Mike Peel (talk) 07:26, 10 July 2020 (UTC)

A situation, where an image is deprecated, is a standard situation. Although it might get fixed on Wikidata (thanks), it should not cause flaws in the infobox. Maybe you can add a proper check? best --Herzi Pinki (talk) 07:30, 10 July 2020 (UTC)

@Herzi Pinki:  Done, this should now be fixed by the addition of a check in the template. Thanks. Mike Peel (talk) 15:42, 6 December 2020 (UTC)

This section is resolved and can be archived. If you disagree, replace this template with your comment. Mike Peel (talk) 15:42, 6 December 2020 (UTC)

visitor center (P2872)

Hello. Can someone have this property displayed in the Infobox? It would be great for categories such as Category:Fossil Butte National Monument. Thierry Caro (talk) 16:50, 15 September 2020 (UTC)

@Thierry Caro: It's in {{Wikidata Infobox/sandbox}}, please test it. Thanks. Mike Peel (talk) 18:51, 29 September 2020 (UTC)

@Mike Peel: Tested. It works perfectly fine! It is ready. Thierry Caro (talk) 05:26, 30 September 2020 (UTC)

@Thierry Caro:  Done, this is now live. Thanks. Mike Peel (talk) 15:39, 6 December 2020 (UTC)

This section is resolved and can be archived. If you disagree, replace this template with your comment. Mike Peel (talk) 15:39, 6 December 2020 (UTC)

Error with deprecated rank P18

If P18 entry/entries are set with deprecated rank, the infobox shows some unwanted code. Exampleː ̈https://www.wikidata.org/wiki/Q348036 / https://commons.wikimedia.org/wiki/Category:Adalberto_Libera --Arch2all (talk) 17:38, 22 September 2020 (UTC)

@Arch2all: Thanks for the bug report. Ideally there wouldn't be deprecated P18 values, but anyway I think I've fixed this in {{Wikidata Infobox/sandbox}}, please can you check it? Thanks. Mike Peel (talk) 18:54, 29 September 2020 (UTC)

@Mike Peel: Sorry, but I don't know how to check the sandbox version. The production infobox still has the error. Reason for deprecated P18 values are some bots, which automatically extract images from Wikipedia articles for person entries. Sometimes they extract images, that are not really well suited (for example architect's work instead of a portrait). Deletion is not a solution in this case, because bots recreating these entries sooner or later. Arch2all (talk)

@Arch2all:  Done, this is now live. Thanks. Mike Peel (talk) 15:34, 6 December 2020 (UTC)

This section is resolved and can be archived. If you disagree, replace this template with your comment. Mike Peel (talk) 15:34, 6 December 2020 (UTC)

LoC HABS/HAER/HALS place ID (P8655)

Hello again. We have uploaded a lot of pictures here coming from the Historic American Buildings Survey, the Historic American Engineering Record or the Historic American Landscapes Survey. So I believe we should display the new LoC HABS/HAER/HALS place ID (P8655) in the Infobox, just like we do for NRHP reference number (P649). The Library of Congress is such an authrity, I believe it makes total sense. Thierry Caro (talk) 05:30, 30 September 2020 (UTC)

@Thierry Caro: It's now in {{Wikidata Infobox/sandbox}}, please test it. Thanks. Mike Peel (talk) 16:49, 5 December 2020 (UTC)

@Thierry Caro:  Done, this is now live. Thanks. Mike Peel (talk) 15:34, 6 December 2020 (UTC)

This section is resolved and can be archived. If you disagree, replace this template with your comment. Mike Peel (talk) 15:34, 6 December 2020 (UTC)

OpenStreetMap link doesn't seem to work?!

You could use WikiMap instead:

https://osm4wiki.toolforge.org/cgi-bin/wiki/wiki-osm.pl?project=Commons&article={{anchorencode:{{FULLPAGENAME}}}}&l=1

->

https://wikimap.toolforge.org/?cat={{anchorencode:{{PAGENAME}}}}&subcats=true&subcatdepth=1

--DB111 (talk) 22:41, 30 September 2020 (UTC)

It seems to work fine with me. Where exactly do you encounter problems? -- H005 06:52, 1 October 2020 (UTC)

I often see an empty world map and the message ""sorry, no data to show". Furthermore the "old" tool doesn't show subcategories any more. Additionally there is some kind of problem or lag in display, e.g. the current tool shows 1 pic, WikiMap 10 of them. --DB111 (talk) 14:47, 1 October 2020 (UTC)

@DB111: I've tried changing this in {{Wikidata Infobox/sandbox}}, but I'm encountering problems. For Category:Jodrell Bank Observatory, the current link in the infobox goes to [4], which works. The new code gives [5], which seems to find some images but doesn't zoom in on the appropriate country/location. Am I missing something? Thanks. Mike Peel (talk) 16:07, 5 December 2020 (UTC)

@Mike Peel: It's just a visualization issue in two ways: The old tool ignores the l parameter, that's why you don't get the Japanese "Mark II" subcategory pics and the zoom is different. The main issue is the unfortunate display, a lot of markers overlap. So you can zoom in the UK or just enable clustering of markers (defaults to off when subcategories are enabled, switch button is also in the upper right corner) to better see this heaps: https://wikimap.toolforge.org/?cat=Jodrell_Bank_Observatory&subcats=true&subcatdepth=1&cluster=true --DB111 (talk) 17:17, 5 December 2020 (UTC)

@DB111: OK, cluster=true seems to help, but it's still displaying Kazakhstan in the centre of the map rather than zooming in on the areas where there are photos? Thanks. Mike Peel (talk) 17:25, 5 December 2020 (UTC)

Some images in the UK plus some in Japan, how to zoom better to fit them all? If you omit the subcategories, you only see UK pics. --DB111 (talk) 17:33, 5 December 2020 (UTC)

Bye the way: Is the japanese flower miscategorized to "Mark II"? So just remove it and zoom should be fine! --DB111 (talk) 17:40, 5 December 2020 i(UTC)

@DB111: Ah, thanks! The flower was miscategorised, and I didn't realise it was trying to include Japan in the map. I've removed that and it seems to work OK. So this change should be ready to go live with the next release (either today or tomorrow). Thanks. Mike Peel (talk) 17:42, 5 December 2020 (UTC)

P.S., this link is moving to the bottom of the infobox in the next version, per the Geogroup discussion below. Thanks. Mike Peel (talk) 18:02, 5 December 2020 (UTC)

@DB111:  Done, this is now live. Thanks. Mike Peel (talk) 15:33, 6 December 2020 (UTC)

This section is resolved and can be archived. If you disagree, replace this template with your comment. Mike Peel (talk) 15:33, 6 December 2020 (UTC)

Please hide relative position within image (P2677)

Please hide the value of relative position within image (P2677) qualifiers, visible e.g. at Category:Markgrafentafel (Hans Baldung) in brackets after the values of depicts (P180). It's not human-readable or at least not useful for humans in this way. Thanks in advance, --Marsupium (talk) 12:34, 4 October 2020 (UTC)

I second this. It's just noise. Keep Commons for humans. Robots and tinkerers can amuse themselves ad nauseum in Wikidata, let's not treat the humble Wikidata Infobox as being a portal to all possible data. --Animalparty (talk) 15:23, 4 October 2020 (UTC)

@Mike Peel: can you please you hide this data that has no use in Commons infoboxes? --Animalparty (talk) 21:59, 2 December 2020 (UTC)

@Marsupium and Animalparty: Looking at depicts (P180), the main qualifiers used (>1k uses on Wikidata) are quantity (P1114), relative position within image (P2677), color (P462), shown with features (P1354) and applies to part, aspect, or form (P518). I'm not sure it makes sense to display those here, and depicts often gets quite long anyway, so I've modified {{Wikidata Infobox/sandbox}} to not display any qualifiers, and to display the depicts statements as prose rather than a bulleted list (which will make it shorter where there are many depicts values). How does that look now? Thanks. Mike Peel (talk) 16:40, 5 December 2020 (UTC)

@Marsupium and Animalparty:  Done, this is now live. Thanks. Mike Peel (talk) 15:21, 6 December 2020 (UTC)

This section is resolved and can be archived. If you disagree, replace this template with your comment. Mike Peel (talk) 15:21, 6 December 2020 (UTC)

IPHAN bug

@Mike Peel: See Category:Francisco Antônio de Almeida Júnior. [[Category:IPHAN with known IDs|]] appears out of nowhere. ~★ nmaia ^d 22:11, 14 October 2020 (UTC)

@NMaia: Thanks, there was a typo of chivalric order (P550) instead of IPHAN ID (P5500), fixed in {{Wikidata Infobox/sandbox}}. Thanks. Mike Peel (talk) 11:53, 5 December 2020 (UTC)

@NMaia:  Done, this is now live. Thanks. Mike Peel (talk) 15:20, 6 December 2020 (UTC)

This section is resolved and can be archived. If you disagree, replace this template with your comment. Mike Peel (talk) 15:20, 6 December 2020 (UTC)

Request for maintenance-Category for Year of birth missing

Moin Moin together, I have a question, if you could or wanted to do something like this. We have maintenance categories, but we have nothing for P31:Human, and the category Year of birth missing or Year of birth missing (living people). My question now would be, would such a category be interesting and who could create it? Many thanks in advance and thanks for comments --Crazy1880 (talk) 18:33, 18 October 2020 (UTC)

@User:Mike Peel: Sounds realistic as a wish? Regards --Crazy1880 (talk) 11:42, 4 November 2020 (UTC)

@Crazy1880: I could add Category:Uses of Wikidata Infobox with no year of birth for cases of instance of (P31)=human (Q5) with no date of birth (P569) value, would that work for you? I'm not sure how to identify living people here, though. Thanks. Mike Peel (talk) 11:47, 5 December 2020 (UTC)

Moin Mike Peel, yes, you could start with it, just to see how many become so. Many thanks for the realization. Reagards --Crazy1880 (talk) 20:13, 5 December 2020 (UTC)

@Crazy1880: OK, it's added to {{Wikidata Infobox/sandbox}}, and I've set up Category:Uses of Wikidata Infobox with no year of birth. Does that look OK? Thanks. Mike Peel (talk) 20:29, 5 December 2020 (UTC)

Moin Mike Peel, look at Category:Martine Ambert, seems to work. Regards --Crazy1880 (talk) 21:29, 5 December 2020 (UTC)

@Crazy1880:  Done, this is now live. Thanks. Mike Peel (talk) 15:19, 6 December 2020 (UTC)

This section is resolved and can be archived. If you disagree, replace this template with your comment. Mike Peel (talk) 15:19, 6 December 2020 (UTC)

Two boxes on one page, coordinates

I have two Wikidata Infoboxes on Category:Rheindelta (Bodensee) because the category covers both (nearly identical) protected areas. The second box complains that "{{#coordinates:}}: cannot have more than one primary tag per page". Is there any way to suppress this error message? Thanks --Reinhard Müller (talk) 14:40, 4 November 2020 (UTC)

@Reinhard Müller: No, the infobox is not designed to be used multiple times in one category. Probably you want to create separate categories or to merge the Wikidata items. Thanks. Mike Peel (talk) 11:30, 5 December 2020 (UTC)

@Mike Peel: I think that neither of those options make much sense in cases like the one I meantioned above. Since both Wikidata items cover the same area, I don't think it's reasonable to create two separate Commons categories with identical content, but on the other hand the Wikidata items cannot be merged, because parameters like date of creation or some IDs are different. --Reinhard Müller (talk) 11:55, 5 December 2020 (UTC)

@Reinhard Müller: Looking more closely, I think this is a Wikidata modelling issue, particularly since these items seem to be about the same thing just with different protection types. I'd suggest doing something like has part(s) of the class (P2670)=Special Protection Area (Q2463705) in Rhine delta (Q1517075), adding the different values as qualifiers to that value, and then merging Rheindelta (Q101135539) in. Thanks. Mike Peel (talk) 12:30, 5 December 2020 (UTC)

This section is resolved and can be archived. If you disagree, replace this template with your comment. Mike Peel (talk) 15:19, 6 December 2020 (UTC)

Incubator sitelink appears as inline interwiki link

On Category:The arts, a seemingly stray incubator:Wp/mnw/ပါန်ကွတ် appears, which comes from d:Q2018526 (added a year ago). Apart from the fact that Incubator projects should not have Wikidata sitelinks and the link is broken anyway, I think the template should not attempt to show Incubator links, since incubator: is not an interlanguage link prefix and so it doesn’t appear in the sidebar. I don’t remove the sitelink from Wikidata yet in order to help testing, but please do revert this incorrect edit after fixing the template. (Or I can also do the revert, of course.) —Tacsipacsi (talk) 22:18, 25 November 2020 (UTC)

@Tacsipacsi: This is added by Module:Interwiki, which @Jarekt: maintains, the infobox just auto-includes that module. So I suggest raising it at the module talk page. Thanks. Mike Peel (talk) 11:28, 5 December 2020 (UTC)

{Fixed}} Tacsipacsi thank you for debugging this on. Mike thanks for heads up. --Jarekt (talk) 02:45, 6 December 2020 (UTC)

This section is resolved and can be archived. If you disagree, replace this template with your comment. Mike Peel (talk) 15:18, 6 December 2020 (UTC)

Replacing P1447 by P8286

@Mike Peel: I would strongly suggest that a replacing of Sports-Reference.com Olympic athlete ID (archived) (P1447) by Olympedia people ID (P8286) would be a good move, since the Sports-reference.com ID were earlier hosted on an external database with other databases but now it is no longer active, it is only available through archive-links. See the english wikipedia-article en:Sports_Reference#Olympics. The same olympics database are now in the hands of the owners own database on their own domain-name. The Olympedia does also have a larger and wider database since it also include other Olympic-related persons as referees and organisational sports-leaders. Best regards Migrant (talk) 21:29, 2 December 2020 (UTC) updating and hopefully more clarifying text. Best regards Migrant (talk) 01:34, 5 December 2020 (UTC)

@Migrant: Do you know if there is a plan to deprecate Sports-Reference.com Olympic athlete ID (archived) (P1447)/migrate all uses to the new property? It's easy enough to remove if so, but for now, I've added Olympedia people ID (P8286) alongside it in {{Wikidata Infobox/sandbox}}. Thanks. Mike Peel (talk) 10:35, 5 December 2020 (UTC)

Think I will ping @MisterSynergy, RonaldH, and Pamputt: since they have been involved with these 2 properties heavily. Other useful pages for information around these are of course the proposal pages:

• Wikidata:Wikidata:Property proposal/Archive/25#P1447 (from August 2014, but not very big discussion)
• Wikidata:Property talk:P1447 (contains speculationshistory of the closing database at Sports-reference.com and a possible new site)
• Wikidata:Wikidata:Property proposal/Olympedia ID (from May 2020, bit more discussed and more voters for)
• Wikidata:Property talk:P8286 (contains more about the import of values from the same database which was held at Sports-reference.com)

Since I know there are many more ID's at Olympedia database and that one will be updated on regular bases and the other archived base which will not be updated at Sports-reference since it doesn't exist anymore on live servers connected to Internet and that all these data are actually coming from the same group OlyMADMed, prior to Sports-reference.com/olympics but now at their own site at Olympedia.com. But let here some words from the users I mentioned above. Best regards Migrant (talk) 04:08, 6 December 2020 (UTC)

Thanks for the ping. The above is correct, and you can indeed immediately replace P1447 with P8286. Wikidata will keep P1447 values as they technically still provide some limited use, but they are nothing else than partial past snapshots of what was originally copied there from a non-public Olympedia, and is now served from public Olympedia directly. User:RonaldH and me had email contact with the Olympedia team in March, which provided an excellent mapping table of corresponding Sports-Reference.com and Olympedia profiles. I was thus able to add an Olympedia ID to all items which had a Sports-Reference-ID at that time (around 130.000 items). Sports-Reference identifiers thus do not need to be shown any longer at all. —MisterSynergy (talk) 09:49, 6 December 2020 (UTC)

I fully agree with MisterSynergy. Due to other obligations I wasn't able to follow up with the replacement activities that were still required in order to introduce Olympedia and get rid of all SportsReference links, except for the ones referring to overview pages that may not have counterparts on Olympedia. Would this also automatically fix the SportsReference template occurrences in de.wp articles? --RonaldH (talk) 11:01, 6 December 2020 (UTC)

@Migrant, MisterSynergy, and RonaldH:  Done, I've removed P1447 and added P8286. This is now live. Thanks. Mike Peel (talk) 15:18, 6 December 2020 (UTC)

This section is resolved and can be archived. If you disagree, replace this template with your comment. Mike Peel (talk) 15:18, 6 December 2020 (UTC)

P5326 (P5326)

Hello,

1/ Is it possible to integrate P5326 (P5326), just below taxon author (P405) in the infobox?

2/Is it possible for both P5326 (P5326) and taxon author (P405) to have by default the links to the Wikimedia Commons categories when they exist (I think it is already the case), but in addition, and as a replacement for when there is no category available, to have the link to the Wikidata item. Indeed the items displayed via those properties can have very useful infos (and links). (note for me : to be tested there and there)

Regards, Christian Ferrer ^(talk) 12:11, 5 November 2018 (UTC)

@Christian Ferrer: Currently, for Allostichaster palmula (Q2858131), Aporocidaris incerta (Q2343200):

{{wdib |qid=Q2858131 |P5326 |fwd=ALL |osd=n |lp=:}} →

{{wdib |qid=Q2343200 |P5326 |fwd=ALL |osd=n |lp=:}} →

I'm not keen to have piped links to Wikidata because of the criticism I've had in the past that external links should be obvious, rather than potentially surprising the reader who isn't expecting to be taken to another site. However, if |noicon=false, then each publication's Wikidata entry can be reached via a click on the pen icon. Would that be an acceptable compromise? --RexxS (talk) 00:10, 6 November 2018 (UTC)

• Yes, of course it is. Although 1/the text "Edit this in Wikidata" may be a little repulsive for outside visitors who do not particularly want to edit anything. And 2/ I wanted to have the possibility for a link to the publication item (when the category don't exist) e.g. A new fissiparous micro-asteriid from southern Australia (Echinodermata: Asteroidea: Asteriidae) (Q56035104). But well ok, thanks you, this is an acceptable compromise, I take. Christian Ferrer ^(talk) 06:09, 6 November 2018 (UTC)

  @Christian Ferrer: P5326 (P5326) is now in the sandbox, how does that look? BTW, I think we're getting to the point where the infobox is displaying more than {{Taxonavigation}}, perhaps it would be worth thinking about adding it to all taxon categories now? (technically easy using pi bot, but there's been opposition to it in the past). Thanks. Mike Peel (talk) 21:41, 30 November 2018 (UTC)

@Mike Peel: Great, thanks you, tested and approved in Aporocidaris incerta. As far as I am concerned, I put the infobox as soon as I create or modify a category, but not to disturb the historical way I always left {{Taxonavigation}} and {{VN}}. I can talk only for me, but yes, I am very much in favor of the infobox being added in all taxon categories, but below all content please, see previous example. Another good point for the infobox can be seen in Ophiura scomba, where Ophiura scomba is in fact an alternate accepted name (a habit taken for the sake of simplification by almost the entire community, I presume) and whose official name is Ophiura (Ophiura) scomba displayed in the Infobox. Christian Ferrer ^(talk) 05:16, 1 December 2018 (UTC)

@Christian Ferrer: OK, this is now live. The existing pi bot code adds the template below all other templates, and it's easy enough to run it through taxons. I've already suggested this a few times at Commons_talk:WikiProject_Tree_of_Life#Wikidata_Infobox_and_taxons without getting consensus, feel like having a go at re-suggesting it there? ;-) Thanks. Mike Peel (talk) 21:36, 3 December 2018 (UTC)

@Mike Peel: thanks you, I'd suggect that we wait the outcome of the property proposal that I made on Wikidata, and then, if successful, we will have to work a bit to retrieve the author citations in the Infobox, which is in the eyes of the specialists, very important. After that, and with all the effort and progress we have made since the creation of the taxontree, I think it will be more easy to get consensus. Christian Ferrer ^(talk) 05:53, 4 December 2018 (UTC)

Ugh, more clutter. I personally remove the wikidata template from taxon articles, if they lack {{Taxonavigation}}: It's more unwanted data dumpage imposed from Wikidata, and the essential links are redundant to {{Taxonavigation}}. But I suspect I'm fighting losing battle, and that the "small" Wikidata-enabled infoboxes initially proposed will soon rival short novels on every category in length and level of intricate detail. --Animalparty (talk) 01:32, 25 January 2019 (UTC)

This section is resolved and can be archived. If you disagree, replace this template with your comment. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 11:46, 26 December 2020 (UTC)

Problem with various people.

Hi, I got a dispute with a wikidata user about how to use family anf given names on wiidata. See reverted several of my edits. He the deiscusion under wikidata:User talk:JuTa#Given names. His current conclusion: the Commons infobox should not be using Wikidata to produce these categories.. This would break a very lot of cats und prior work. Any other idea how to solve this problem? --JuTa 02:12, 17 January 2019 (UTC)

I've replied there - basically it needs some way to store diminutive (Q108709) as a property/qualifier, and then we (probably RexxS) could modify the infobox to use that where available. Thanks. Mike Peel (talk) 10:54, 17 January 2019 (UTC)

I suggest that it should be possible to override the Wikidata value with a locally supplied value. There's just no sensible way to programmatically decide which of a number of possible aliases to use for a particular field. If template code such as:

• {{#invoke:WikidataIB |getValue |rank=best |P735 |qid={{#invoke:WikidataIB |getQid |qid={{{qid|}}} }} | name=givenname | |fwd=ALL |osd=no |noicon=yes | linked=n | spf={{{suppressfields|}}} | lang=en | sep=" "}}

were to be replaced by:

• {{#invoke:WikidataIB |getValue |rank=best |P735 |qid={{#invoke:WikidataIB |getQid |qid={{{qid|}}} }} | name=givenname | |fwd=ALL |osd=no |noicon=yes | linked=n | spf={{{suppressfields|}}} | lang=en | sep=" " |{{{given-name|}}}}}

then the parameter |given-name= could be used in a particular article to take precedence over what is on Wikidata. --RexxS (talk) 00:22, 18 January 2019 (UTC)

It could be an idea similar to the |defaultsort=no doing the same with |givenname=no and |surname=no. In these cases these wikidata values will be ignored by the infobox and the persons categories they have to be set manually like in old times. That could be easier to get implemented as the suggestion above. regards. --JuTa 18:13, 24 January 2019 (UTC)

Now I have a current example where this would be usefull: Category:Anthony of Sourozh. It is because of wikidata and the infobox in Category:Bloom (surname) and Category:Andrei (given name). This leaves most readers clueless why. I tried to fix this by editing the wikidata item and got reverted. Then I tried t fix it by moving the commons category to the names set in wikidata and got reverted again by another user. To fix at least something I added Category:Sourozh (surname) and Category:Anthony (given name) nmanualy now. But it would be realy helpfull if there is any possibility to surpress the name categories coming out of the infobox in such cases. regards. --JuTa 17:39, 4 March 2019 (UTC)

@JuTa: I think this needs to be recorded better on Wikidata. I can't see how having a local override in the infobox here would help resolve this issue in the long run. Thanks. Mike Peel (talk) 00:27, 5 March 2019 (UTC)

Hmm, If you look i.e. to my wikidata talk page people wikidata seems to be the opinion that this is a commons problem. :( --JuTa 07:52, 5 March 2019 (UTC)

This section is resolved and can be archived. If you disagree, replace this template with your comment. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 11:48, 26 December 2020 (UTC)

Links to BHL pages

Hello, I remember very well that you want to be careful with external links. Howether I ask if by chance you can integrate a link to a BHL page. Example in Category:Ophioplocus bispinosus, in the field "Publication in which this taxon name was established" you can read "Brittle-Stars, New and Old (30093893)", the number 30093893 is in fact a BHL page ID, retrieved as qualifier of P5326 (P5326), as you can see in the wikidata item Ophioplocus bispinosus (Q61443488). I wonder, in the extend that we already have the number, if you can make the link available in the infobox. This kind of link can be used to lead to the exact page where the taxon name was published.

Otherwise, in case that is not possible to give us the link, you could try to prevent the appearance of this number...that few people, except me and you now, know what this is.

Thanks you, regards, Christian Ferrer ^(talk) 19:05, 3 February 2019 (UTC)

There are two options:

1. @RexxS: would you be able to modify the qualifier function so that it uses formatter URL (P1630) (if available) to link the qualifier value if it is for an identifier?
2. @Christian Ferrer: we could stop displaying qualifiers for that property, or to only display the qualifier if it is volume (P478) or page(s) (P304).

Thoughts? Thanks. Mike Peel (talk) 20:52, 4 February 2019 (UTC)

@Mike Peel: First thoughts: You can easily separate the value and the qualifier, but I can't guarantee that it will always work with multiple values if one of them doesn't have a qualifier:

• {{wdib |ps=1 |P5326 |qid=Q61443488}} →
• {{wdib |ps=1 |P5326 |qid=Q61443488 |qual=P687 |qualsonly=y}} →

I could write another bespoke function, but for now, we could fabricate it using hard-coded values like this:

• {{wdib |ps=1 |P5326 |qid=Q61443488 |qual=P687 |qualsonly=y |qprefix=[http://biodiversitylibrary.org/page/ |qpostfix=]}} →

To generalise that, we could use the fact that WikidataIB can read property entities just like Wikidata entities:

• {{wdib |ps=1 |P1630 |qid=P687}} → https://biodiversitylibrary.org/page/$1

Then use Module:String to replace the $1:

• {{#invoke:String|replace|{{wdib |ps=1 |P1630 |qid=P687}}|$1|{{wdib |ps=1 |P5326 |qid=Q61443488 |qual=P687 |qualsonly=y}}|1|true}} → https://biodiversitylibrary.org/page/

However, as I don't know what sort of display you want, I can't be more specific. Given a little time, I'll write the general function to handle qualifiers that are identifiers by looking for a formatter URL (P1630), but that will have to go on the "to-do" list for now. Cheers --RexxS (talk) 23:43, 4 February 2019 (UTC)

I would have like something a bit more friendly, such as BHL page, or something similar, but I take the proposition above, thanks you very much. If it's possible go ahead, integrate that link in the infobox please. Christian Ferrer ^(talk) 05:54, 5 February 2019 (UTC)

@Mike Peel: I can't edit the infobox. --RexxS (talk) 22:41, 7 February 2019 (UTC)

@RexxS: Template:Wikidata Infobox/sandbox and Template:Wikidata Infobox/core/sandbox should be editable and up-to-date. Thanks. Mike Peel (talk) 22:46, 7 February 2019 (UTC)

@Mike Peel: I don't do templates :P --RexxS (talk) 22:48, 7 February 2019 (UTC)

@Christian Ferrer: Sorry, I only just spotted that:

• [{{#invoke:String|replace|{{wdib |ps=1 |P1630 |qid=P687}}|$1|{{wdib |ps=1 |P5326 |qid=Q61443488 |qual=P687 |qualsonly=y}}|1|true}} BHL page] → BHL page

Is that what you want? --RexxS (talk) 23:20, 7 February 2019 (UTC)

@RexxS: yes exactly, very great, thanks you. Christian Ferrer ^(talk) 05:28, 8 February 2019 (UTC)

• @RexxS: , @Mike Peel: , The ideal would be that the Wikidata Infobox/line can integrate two things, the publication name and the link :

{{wdib |ps=1 |P5326 |qid=Q61443488}} [{{#invoke:String|replace|{{wdib |ps=1 |P1630 |qid=P687}}|$1|{{wdib |ps=1 |P5326 |qid=Q61443488 |qual=P687 |qualsonly=y}}|1|true}} (BHL page)] → (BHL page)

Regards, Christian Ferrer ^(talk) 17:37, 16 February 2019 (UTC)

•  Done I managed to do it. Christian Ferrer ^(talk) 22:37, 17 February 2019 (UTC)
• With this code I manage to have the BHL link I wanted (example) :

{{#if:{{#property:P5326| from={{#invoke:WikidataIB |getQid |qid={{{qid|}}} }}}}|<tr {{#ifeq:{{{mobile|n}}}|y||class="wdinfo_nomobile"}}><th class="wikidatainfobox-lcell">{{ucfirst:{{#invoke:WikidataIB |getLabel |Q55155646}} }}</th><td {{#ifeq:{{{wrap|n}}}|y| style="white-space: nowrap"}}><div class="mw-collapsible mw-collapsed">{{#invoke:WikidataIB | getValue | rank=best |qid={{#invoke:WikidataIB |getQid |qid={{{qid|}}} }} |P5326 |fwd={{{fwd|ALL}}} |osd={{{osd|no}}} |linkprefix=":"|qlinkprefix=":"}} [{{#invoke:String|replace|{{wdib |ps=1 |P1630 |qid=P687}}|$1|{{wdib |ps=1 |P5326 |qid={{#invoke:WikidataIB |getQid |qid={{{qid|}}} }} |qual=P687 |qualsonly=y}}|1|true}} (BHL page)]</div></td></tr>}}<!--

However, with that code, a BHL link is given even when it is not given in the item, logic, (example). How to write a condition for that...

[{{#invoke:String|replace|{{wdib |ps=1 |P1630 |qid=P687}}|$1|{{wdib |ps=1 |P5326 |qid={{#invoke:WikidataIB |getQid |qid={{{qid|}}} }} |qual=P687 |qualsonly=y}}|1|true}} (BHL page)]

... to be displayed only if :

the property P5326 (P5326) has BHL page ID (P687) as qualifier, inside the concerned item?

@RexxS: and @Mike Peel: ? Christian Ferrer ^(talk) 12:08, 18 February 2019 (UTC)

@Christian Ferrer: You can test the difference like this:

• For Ophioplocus bispinosus (Q61443488) {{wdib |fwd=ALL |osd=n |noicon=true |P5326 |qid=Q61443488 |qual=P687 |qualsonly=y}} →
• For Holothuria austrinabassa (Q2480364) {{wdib |fwd=ALL |osd=n |noicon=true |P5326 |qid=Q2480364 |qual=P687 |qualsonly=y}} →

Is that enough for you to write the #if: test? --RexxS (talk) 17:50, 18 February 2019 (UTC)

@RexxS: No I don't manage to write it, however I managed to have the result with : {{wdib |ps=1 |P5326 |qid={{#invoke:WikidataIB |getQid |qid={{{qid|}}} }} |qual=P687 |qualsonly=y |qprefix=[http://biodiversitylibrary.org/page/ |qpostfix=" (BHL page)"]}} from what you wrote a bit abobe. Christian Ferrer ^(talk) 19:28, 18 February 2019 (UTC)

@Christian Ferrer: For reference, the test for having the property P5326 (P5326) with BHL page ID (P687) as qualifier would be:

• {{#if:{{wdib |fwd=ALL |osd=n |noicon=true |P5326 |qid={{#invoke:WikidataIB |getQid |qid={{{qid|}}} }} |qual=P687 |qualsonly=y}} | put the code here for when it has the property with the qualifier | put the code here for when it doesn't (if needed) }}

But what you've done is fine. You just have to remember to change the hard-coded url if the site ever changes its structure (not likely, I guess). --RexxS (talk) 23:23, 18 February 2019 (UTC)

Ok thanks you Christian Ferrer ^(talk) 05:30, 19 February 2019 (UTC)

This section is resolved and can be archived. If you disagree, replace this template with your comment. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 12:09, 26 December 2020 (UTC)

Linking

@RexxS and Animalparty: Following up on d:Wikidata:Project_chat#Question_regarding_Commons_Categories, it might be better to use getCommonsLink instead of the P373/sitelink value when making the link. That way, we also get the commons category if it's on a category item, and we're less dependent on P373 values (ideally we'd drop support for P373 at some point, but we're not quite there yet). Do you think that would be feasible? Thanks. Mike Peel (talk) 09:38, 12 February 2019 (UTC)

Sorry, Mike, that's too abstract for me. Can you give a concrete example of where the result would be improved? The _getCommonslink function returns the Commons sitelink, if it's a category and |onlycat=true; otherwise the Commons sitelink of the first best topic's main category (P910), if it exists; otherwise the first best Commons category (P373), if |fallback=false; otherwise nothing. --RexxS (talk) 16:00, 12 February 2019 (UTC)

@RexxS: I can't find an example offhand, I'll let you know if I find one. The basic idea is that instead of using P373 you use _getCommonslink. Thanks. Mike Peel (talk) 21:03, 12 February 2019 (UTC)

This section is resolved and can be archived. If you disagree, replace this template with your comment. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 12:10, 26 December 2020 (UTC)

original combination (P1403)

Hello, I would want the original combination of a taxon, but not the label of the value stored within this property statment, but the value of a property of the element which is itself the value of this property. Example:

for Ophioderma teres (Q2245699) the value of original combination (P1403) is Ophiura teres (Q61818290)

The issue is I dont want to have as value in the infobox the label of Ophiura teres (Q61818290), because a signifiant number of species have for label another thing that the species name, such as a common name. And original combination (P1403) is specifically about the taxon name.

What would be ideal would be to display in the infobox:

for Ophioderma teres (Q2245699)

the value of original combination (P1403) is Ophiura teres (Q61818290)

what to display is the taxon name (P225) of Ophiura teres (Q61818290) written in italic, a space, followed the taxon author citation (P6507) of Ophiura teres (Q61818290) written in normal

in summary → Original combination : Ophiura teres Lyman, 1860

Regards, Christian Ferrer ^(talk) 10:29, 25 February 2019 (UTC)

@Christian Ferrer: For Ophioderma teres (Q2245699) the label is returned like this:

• {{#invoke:WikidataIB |getValue |fwd=ALL |osd=n |lp=: |noicon=y |P1403 |qid=Q2245699}} → Ophiura teres (the label)

I think we can build your request from two calls. For Ophioderma teres (Q2245699):

• {{#invoke:WikidataIB |getPropOfProp |fwd=ALL |osd=n |lp=: |noicon=y |prop1=P1403 |prop2=P225 |qid=Q2245699}} → Ophiura teres (the taxon name of the original combination)
• {{#invoke:WikidataIB |getPropOfProp |fwd=ALL |osd=n |lp=: |noicon=y |prop1=P1403 |prop2=P6507 |qid=Q2245699}} → Lyman, 1860 (the taxon author citation of the original combination)

Here's the result. For Ophioderma teres (Q2245699):

• ''{{#invoke:WikidataIB |getPropOfProp |fwd=ALL |osd=n |lp=: |noicon=y |prop1=P1403 |prop2=P225 |qid=Q2245699}}'' {{#invoke:WikidataIB |getPropOfProp |fwd=ALL |osd=n |lp=: |noicon=y |prop1=P1403 |prop2=P6507 |qid=Q2245699}} → Ophiura teres Lyman, 1860

Is that what you need? --RexxS (talk) 00:50, 27 February 2019 (UTC)

@RexxS: Yes exactly, the issue is that in the infobox we can't call directly "Q2245699", as it comes itself from a value taken from a property of the first item. Christian Ferrer ^(talk) 04:31, 27 February 2019 (UTC)

And that, of course, is the reason I wrote the function getPropOfProp which allows you to fetch a property from second entity where that entity is a property of a first entity. --RexxS (talk) 17:37, 27 February 2019 (UTC)

@RexxS: Oh sorry. I do not really have any skills. I hack a bit sometimes by copying, but many things are beyond my comprehension. In fact I missed that the qid you used was Q2245699 and not Q61818290! → my fault. That's great, it's exactly that, thanks you very much. I will try to integrate that to the sandbox! Christian Ferrer ^(talk) 17:54, 27 February 2019 (UTC)

• Ok done, in test in Ophioderma teres, Erichsonella filiformis and Cosmasterias lurida (→ taxon name is provided but without the autority in Wikidata) Christian Ferrer ^(talk) 15:35, 28 February 2019 (UTC)

 Done copied to the infobox Christian Ferrer ^(talk) 13:36, 2 March 2019 (UTC)

Original publication of original combination (P1403)

• @RexxS: When you have time, can you check the code below, please? it don't work and I'm not able to go further.
  

{{#if:{{#property:P5326| from={{#invoke:WikidataIB |getPropOfProp |fwd=ALL |osd=n |lp=: |noicon=y |prop1=P1403 |prop2=P5326 |qid={{#invoke:WikidataIB |getQid |qid={{{qid|}}} }} }} }}|<tr {{#ifeq:{{{mobile|n}}}|y||class="wdinfo_nomobile"}}><th class="wikidatainfobox-lcell">{{ucfirst:{{#invoke:WikidataIB |getLabel |Q55155646}} }} (of ''{{#invoke:WikidataIB |getPropOfProp |fwd=ALL |osd=n |lp=: |noicon=y |prop1=P1403 |prop2=P225 |qid={{#invoke:WikidataIB |getQid |qid={{{qid|}}} }} }}'')</th><td {{#ifeq:{{{wrap|n}}}|y| style="white-space: nowrap"}}><div class="mw-collapsible mw-collapsed">{{#invoke:WikidataIB |getPropOfProp |fwd=ALL |osd=n |lp=: |noicon=y |prop1=P1403 |prop2=P5326 |qid={{#invoke:WikidataIB |getQid |qid={{{qid|}}} }} }}</div></td></tr>}}

I want to retrieve P5326 (P5326) from the item quoted in original combination (P1403), same principle as above

Example:for Ophiactis savignyi (Q2766693)

the value of original combination (P1403) is Ophiolepis savignyi (Q61792100)

in Ophiolepis savignyi (Q61792100) the value of P5326 (P5326) is System der Asteriden (Q51393288)

Of what I want to have at the end is:

Original publication (of Ophiolepis savignyi) = System der Asteriden (BHL page)

In summamy I would want to have the same thing,which work well, than:
{{#if:{{#property:P5326| from={{#invoke:WikidataIB |getQid |qid={{{qid|}}} }}}}|<tr {{#ifeq:{{{mobile|n}}}|y||class="wdinfo_nomobile"}}><th class="wikidatainfobox-lcell">{{ucfirst:{{#invoke:WikidataIB |getLabel |Q55155646}} }}</th><td {{#ifeq:{{{wrap|n}}}|y| style="white-space: nowrap"}}><div class="mw-collapsible mw-collapsed">{{#invoke:WikidataIB | getValue | rank=best |qid={{#invoke:WikidataIB |getQid |qid={{{qid|}}} }} |P5326 |fwd={{{fwd|ALL}}} |osd={{{osd|no}}} |linkprefix=":"|qlinkprefix=":"}} {{wdib |ps=1 |P5326 |qid={{#invoke:WikidataIB |getQid |qid={{{qid|}}} }} |qual=P687 |qualsonly=y |qprefix=[http://biodiversitylibrary.org/page/ |qpostfix=" (BHL page)"]}}</div></td></tr>}}

but where P5326 (P5326) is from another item, as we did just above. Christian Ferrer ^(talk) 13:36, 2 March 2019 (UTC)

This section is resolved and can be archived. If you disagree, replace this template with your comment. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 12:11, 26 December 2020 (UTC)

Incorrect award category

Category:Best Actress German Film Award winners contains lots of people who may have won a German Film award, but I'm quite sure that none of the men listed there have received the Best Actress award. It should be Category:German Film Award winners instead. --Sitacuisses (talk) 20:26, 5 March 2019 (UTC)

Category:Gerd Baumann is associated with Gerd Baumann (Q1510407), which has the property award received (P166). The value of that is German Film Award (Q708731), which has the property category for recipients of this award (P2517). That has two values: Category:Best Actress German Film Award winners (Q8298321) and Category:German Film Award winners (Q7818235). The logic in the infobox is only doing what it is supposed to. I've deprecated the value Category:Best Actress German Film Award winners (Q8298321) on Wikidata, and commented on the talkpage, but I doubt that the locals will see the problem in the way that we have. --RexxS (talk) 22:08, 5 March 2019 (UTC)

I've made some more changes [6] [7] to German Film Award (Q708731) and Category:Best Actress German Film Award winners (Q8298321). I don't actually know how subcategories are modelled in Wikidata, but the current situation seems more logical to me. The effects are soaking through very slowly: Half a day later, less than 10% of the affected categories have moved.

Also, in Category:German Film Award winners the subcategory Best Actress German Film Award winners‎ should be separated from the individual names. --Sitacuisses (talk) 12:42, 6 March 2019 (UTC)

Corrected the latter here. Laddo (talk) 13:44, 6 March 2019 (UTC)

@Sitacuisses and Laddo: Thanks both of you. I think the Wikidata structure is much clearer now, and it looks like we will soon be back to normal with the categories. --RexxS (talk) 22:19, 6 March 2019 (UTC)

@Sitacuisses, Laddo, and RexxS: I've run through those categories making null edits, Category:Best Actress German Film Award winners is now empty, and Category:German Film Award winners has 140 subcategories that should be up-to-date. Is that the expected outcome? Thanks. Mike Peel (talk) 22:38, 8 March 2019 (UTC)

@Mike Peel, Sitacuisses, and Laddo: thanks Mike. Comparing Category:German Film Award winners with en:Category:German Film Award winners (which is manually maintained) gives me the impression that all is well now. Cheers --RexxS (talk) 23:09, 8 March 2019 (UTC)

Thanks, but not all is well. Now we have a category tree with the top level defined in Wikidata, but the subcategories still need to be added at Commons. This is confusing at least and could lead to overcategorization. And Cat-a-lot won't move actresses from "German Film Award winners" to "Best Actress German Film Award winners‎". --Sitacuisses (talk) 13:29, 9 March 2019 (UTC)

@Sitacuisses: I think this needs better modeling on Wikidata. Ideally each type of award would have its own Wikidata entry, rather than just one, and those then use category for recipients of this award (P2517) to link to the appropriate commons category item. @GerardM: is this something you might be interested in helping sort out? Thanks. Mike Peel (talk) 17:00, 9 March 2019 (UTC)

This section is resolved and can be archived. If you disagree, replace this template with your comment. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 12:12, 26 December 2020 (UTC)

Display title?

Would it be possible to implement control over the infobox top caption or title so as to be able to properly display ships' names in italics, for example? Jay D. Easy (talk) 18:28, 15 March 2019 (UTC)

@Jay D. Easy: are you looking for a parameter that would control the display manually, or do you want to have it done automatically? Could you give me any actual examples of infoboxes where you want a different styling for the caption, please? --RexxS (talk) 00:23, 16 March 2019 (UTC)

@RexxS: manually seems most feasible to me. Maybe with a parameter that takes "y" or "1". Category:USS Polaris (ship, 1871) is one example. Jay D. Easy (talk) 00:28, 16 March 2019 (UTC)

@Jay D. Easy: I don't think it's easy to ascertain which part of the title is to be italicised, as I assume books, etc. will have a similar requirement, but with different rules, so a yes/no parameter seems insufficient. I've implemented instead a title parameter that allows you to manually specify the title, and I've replaced

• {{Wikidata Infobox}}

with

• {{Wikidata Infobox/sandbox|title=USS ''Polaris'' (ship, 1871)}}

in Category:USS Polaris (ship, 1871) as a demonstration. See what you think. --RexxS (talk) 11:05, 16 March 2019 (UTC)

@RexxS: yours is a better idea, I have to admit. Simple but effective. And it looks good. So, thank you for you effort! You have my vote (in case we're looking for consensus). Jay D. Easy (talk) 18:34, 16 March 2019 (UTC)

Yes, seems quite robust, and mimics the familiar idiom of piped links (except for the parameter ID). Parsing such names to identify non-italicized parts would seem pretty unfeasible in many cases unless the naming system at the source allowed for various ‘prefix’, ‘disambiguator’, &c. fields as separate components of a title.—Odysseus1479 (talk) 20:00, 16 March 2019 (UTC)

@RexxS: and all: this isn't going to work as currently coded, as it is not multilingual. E.g., see 1871)?uselang=ja compared with 1871)&oldid=342819691&uselang=ja. I think it's more important to keep the multilingual support than it is to tweak the English label formatting. Thanks. Mike Peel (talk) 10:53, 17 March 2019 (UTC)

This section is resolved and can be archived. If you disagree, replace this template with your comment. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 12:37, 26 December 2020 (UTC)

Small favour

I use this template a lot and I'm tired of writing every time "Wikidata Infobox" between the double {} signs. Is there any special aid to do that more easily? I mean when we are editing a cat, at the bottom of the page where I took the { sign, where it says "Standard" etc, could we not have a full written form of this to copy into the cat? Or at least make it possible to write WI instead of the whole two words? BTW at that area I refer to there is no "cat see also" thingy either, every time I need to use it I employ the "cat redirect" thing and change the letters. Am I too lazy to ask for these gadgets? Or in fact they all exist somewhere and I'm too stupid to find and enjoy them? Quedo atento a sus comentarios. --E4024 (talk) 00:35, 16 March 2019 (UTC)

@E4024: I've created Template:WI as a redirect to Template:Wikidata Infobox, as the simplest solution. Changes to the toolbars, etc. are a hassle to get consensus for, but redirects are cheap and easy. See if that helps. Cheers --RexxS (talk) 10:36, 16 March 2019 (UTC)

P.S. Don't use {{Wi}} or {{Wi}} as they already exist as shortcuts for the interlanguage links to the Italian Wikipedia. --RexxS (talk) 11:11, 16 March 2019 (UTC)

@E4024: Yes; see: Using AutoHotKey macros to make typing – and life – easier. I add the template by typing just three characters: "\wx". Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 22:15, 9 April 2019 (UTC)

This section is resolved and can be archived. If you disagree, replace this template with your comment. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 12:37, 26 December 2020 (UTC)

"upload media" in WD Infobox--really annoying

When/how did "upload media" appear in the Infobox? It's really annoying when:

• a) the WD infobox is providing data to the user, which is a different user function than a request for images, and
• b) "upload media" it appears right below an exiting image, and
• c) "upload media" appears in conjunction with numerous images already on the commons page.
• Thanks. Prburley (talk)

I agree. Simpler is better. --Animalparty (talk) 13:44, 3 April 2019 (UTC)

That was Special:Diff/343385140. Jean-Fred (talk) 15:13, 3 April 2019 (UTC)

@Prburley, Animalparty, and Jean-Frédéric: The link is there to let you upload an image directly to the category, rather than having to upload and then find a category to add the uploaded file to. I'd rather not lose the functionality if possible, but I'd be happy to move it to a less prominent position in the infobox, or do you have other suggestions for improving it apart from just removing it? Thanks. Mike Peel (talk) 17:40, 3 April 2019 (UTC)

@Mike Peel: I'd vote to remove it completely in order to not mix user functions. Otherwise, I'd put it in a tiny font next to the "edit infobox" pencil at the bottom of the box. Thanks! Prburley (talk)

I had experimented a while ago with something a bit similar at {{Upload picture from category}} (which I just updated to the latest Wikimedia style guide design).

I think if we want something like that, then it should be on all categories, not just the ones with the infobox (although, granted, that’s a pretty good start for coverage ;-))

Alternatively, it could be added by the infobox, but not made part of it − could be moved in a similar fashion to {{Top icon}} − just made {{Upload picture from category icon}} and added it to Category:Foreground flowers as an example.

Some thoughts :) Jean-Fred (talk) 08:28, 4 April 2019 (UTC)

Including {{Upload picture from category icon}} sounds good. I've demo'd that in {{Wikidata Infobox/sandbox}} at Category:Andromeda Galaxy - @Prburley and Animalparty: what do you think? @Jean-Frédéric: the aim is to have the infobox in all categories, so hopefully a separate roll-out of the upload template wouldn't be needed (unless it can be added in a non-template way). Thanks. Mike Peel (talk) 17:15, 4 April 2019 (UTC)

@Mike Peel: Oh, I would definitely get that rolled-out in a non-template way − what I have in mind would be something akin to the auto-banner we have on all article talk pages on French-language Wikipedia (eg fr:Discussion:Victor Hugo, make sure your interface is in French), where it’s included via system messages. Jean-Fred (talk) 18:03, 4 April 2019 (UTC)

@Jean-Frédéric: I just discovered an issue with this: the box does not appear on mobile. Can you fix that somehow please, as that's one of the elements that should be shown in the mobile view? Thanks. Mike Peel (talk) 06:31, 16 April 2019 (UTC)

Ah, indicators are not supported on mobile >_> (per phab:T75299). Geez, what’s the point of using such built-in syntax… Anyone knows of a If mobile syntax ? :-þ Jean-Fred (talk) 08:16, 16 April 2019 (UTC)

@Jean-Frédéric: You can set separate css for mobile devices, see "wdinfo_nomobile" in Template:Wikidata Infobox/styles.css. Perhaps something can be done with that? Also, for a specific skin, see [8]. Thanks. Mike Peel (talk) 08:28, 16 April 2019 (UTC)

@Prburley and Mike Peel: I don't see the difference at the sandbox or Andromeda page. My suggestion is to put "Upload media" in a tiny font on the line below "Reasonator Scholia Statistics" at the bottom of the infobox. Better yet, I like Jean-Frédéric's suggestion of placing the Upload media at the top of the page and removing it from the infobox--which you may have done with that blue "upload a file" button. Thanks! Prburley (talk)

This section is resolved and can be archived. If you disagree, replace this template with your comment. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 12:38, 26 December 2020 (UTC)

Commemorative plaque

If there is no image of a tombstone can we have the template display any commemorative plaque instead? I added the plaque image as if it were a tombstone here to show what it would look like: Category:Annemarie_Loepert. RAN (talk) 05:53, 24 April 2019 (UTC)

Personally I'm in favor of keeping the infobox simpler, rather than overloaded. If a plaque image is added, then a tombstone image later, we'd have at least three images (and really, why do we need to show a grave image at all)? Where does it stop? Why not a flag of the nationality? Why not a photo of a person's house? Why not a link to where I can buy tickets to a movie about the subject? The more bloated the infobox becomes, the poorer the overall quality across Commons: for every nicely composed plaque or gravestone image there are handfuls of clunky photographs of crumbling stone with little to no information value. This is Commons, not Wikipedia, the infobox doesn't have to do and be everything. And since there's still no way of locally customizing or overriding the raw data from the almighty but unthinking Wikidata, we can't pick and choose. --Animalparty (talk) 17:47, 24 April 2019 (UTC)

I partially agrees with Animalparty: including several images probably clutters too much this thing. Nevertheless I consider interesting knowing "from Commons" when a Wikidata property to link to Commons (Q18610173) is filled in wikidata and when not (tomb image, night image, winter image, location map image, indoor image, collage imagen, plan view image...) but maybe that could be better achieved through others means (more indirect ones) than in fact "showing" these images in the infobox when they are linked in wikidata. Cheers. Strakhov (talk) 18:18, 24 April 2019 (UTC)

This section is resolved and can be archived. If you disagree, replace this template with your comment. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 12:39, 26 December 2020 (UTC)

main subject (P921)

...and main subject (P921)? Despite of being already included, it isn't transcluded in the infobox :) Strakhov (talk) 15:30, 8 May 2019 (UTC)

@Strakhov: Are you looking at categories about people or things? It's currently not included for people. Thanks. Mike Peel (talk) 18:36, 8 May 2019 (UTC)

@Mike Peel: I'm thinking about works/editions mostly. I don't know if it's just me, but I don't see "main subject".. here nor here, despite each of them having this property filled with several wikidata values. Strakhov (talk) 18:43, 8 May 2019 (UTC)

@Strakhov: Aah, I see, there's a bug. It should show in {{Wikidata Infobox/sandbox}} now, I'll roll that out soon. Thanks. Mike Peel (talk) 18:52, 8 May 2019 (UTC)

Yes now main subject (P921) works in the sandbox. Christian Ferrer ^(talk) 20:08, 8 May 2019 (UTC)

Yep, now it's OK (sandbox-wise). Thanks. Strakhov (talk) 15:38, 9 May 2019 (UTC)

Why? --Animalparty (talk) 17:11, 8 May 2019 (UTC)

This section is resolved and can be archived. If you disagree, replace this template with your comment. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 12:40, 26 December 2020 (UTC)

Non-administrative entity in multiple administrative entities

Category:Víziváros Office Center (Budapest) shows Víziváros, Budapest I. District etc. This is wrong: the building is in the 2nd district of Budapest. The Víziváros is split between the two districts, but it’s obvious from Wikidata which one applies: Víziváros Office Center (Q63952979) has both location (P276): Víziváros (Q1415725) and located in the administrative territorial entity (P131): Budapest District II (Q1068701). In this case, the infobox should choose the administrative entity that is also listed on the item as P131. —Tacsipacsi (talk) 14:53, 19 May 2019 (UTC)

@RexxS: Perhaps you could modify the location code to handle this? Although I'm not sure how standard this approach is on Wikidata. Alternatively, @Tacsipacsi: , would it make sense to have two Wikidata items, one for the part of Víziváros in the 1st district, the other for the part that's in the second district? Thanks. Mike Peel (talk) 06:58, 20 May 2019 (UTC)

@Mike Peel and Tacsipacsi: If both location (P276) and located in the administrative territorial entity (P131) are present in a given entity, the algorithm has to decide on whether to follow the chain on one or the other. Please see Template talk:Wikidata Infobox/Archive 2 #Displaying of non-administrative locations, where I was asked to restore precedence to location (P276), which I did. I don't think I can alter that logic. So in the case of Víziváros Office Center (Q63952979), the code will ignore located in the administrative territorial entity (P131)=Budapest District II (Q1068701) and follow location (P276)=Víziváros (Q1415725). The entity Víziváros (Q1415725) then has two alternatives for its property located in the administrative territorial entity (P131) and the problem is how to decide on which one to choose. At present, the code searches each alternate for a qualifier applies to part, aspect, or form (P518) and scans those for a match to the previous location. So now, you want the code to also check if that previous location had a located in the administrative territorial entity (P131) that matches one of the alternatives. Is this a common case? Anyway I've sandboxed a possible solution:

• {{#invoke:WikidataIB |location |qid=Q63952979 |first=y}} → Víziváros Office Center, Víziváros, Budapest District II, Budapest, Hungary
• {{#invoke:WikidataIB/sandbox |location |qid=Q63952979 |first=y}} → Víziváros Office Center, Víziváros, Budapest District II, Budapest, Hungary

You may want to test it further. Cheers --RexxS (talk) 18:38, 20 May 2019 (UTC)

Thanks! I hope it’s not too common, but I don’t think it’s the only such situation on Earth. Creating multiple entities is not an option, as the Víziváros is one single entity (as defined in the relevant decree 94/2012 (XII.27.) Főv. Kgy. rendelet). This approach (remembering previous P131) is exactly what I imagined, thanks! —Tacsipacsi (talk) 19:30, 21 May 2019 (UTC)

This section is resolved and can be archived. If you disagree, replace this template with your comment. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 12:41, 26 December 2020 (UTC)

Health infobox for countries

Is there a way to display

• life expectancy (P2250)
• total fertility rate (P4841)

on categories for "health in <country>" (see Special:EntityUsage/Q64027457)?

At d:Wikidata:WikiProject Medicine/health by country, I listed current categories/values. The idea is to eventually add more indicators (only a few currently have data at Wikidata).

These categories should have a category's main topic (P301) with a value that has instance of (P31)=health by country or region (Q64027457).

The P2250/P4841 would be in the item with linked from location (P276) (or, if not present, country (P17)). I could add P276 everywhere if that simplifies it.

Eventually, something similar could be done for healthcare by country or region (Q64027602) (Special:EntityUsage/Q64027602). Jura1 (talk) 13:53, 17 June 2019 (UTC)

• I added the first two properties in the sandbox. Seems to work. --Jura1 (talk) 10:37, 24 June 2019 (UTC)

{{Edit request}} Please add these changes from the sandbox. Note also Template_talk:Wikidata_Infobox#Health_infobox_for_countries.

@Jarekt: may I ask you here too? Jura1 (talk) 23:06, 1 July 2019 (UTC)

Jura1, I do not know much about ((tl|Wikidata Infobox}}, so I would prefer to leave edits to that template to User:Mike Peel. --Jarekt (talk) 02:27, 2 July 2019 (UTC)

@Jura1: I've been on vacation, I'll try to have a look at this later this evening. Thanks. Mike Peel (talk) 06:18, 2 July 2019 (UTC)

• I also added check for economy and education, but with the most recent sandbox edit all three appear in all three. The idea is to display health indicators in health by country, economic ones in economy by country, etc. --Jura1 (talk) 16:52, 2 July 2019 (UTC)

  @Jura1: This is interesting! I thought you were just including the properties only in given cases, but you're actually fetching them via qid={{#invoke:wd | property | raw | P276 |eid={{#invoke:wd | property | raw | P301}} }}. At the least we should do that using WikidataIB (@RexxS: is that possible?). But in general, I'm hoping that we can follow category combines topics (P971) to add information like this, and I wonder if there's a more general solution. Mind if I think about this for a few days? Thanks. Mike Peel (talk) 17:02, 2 July 2019 (UTC)

  @Mike Peel: I think it would be nice if it already displayed. I don't particularly care how it's coded. I suppose as long as nothing breaks, it should be fine.Jura1 (talk) 17:15, 2 July 2019 (UTC)

  @Mike Peel: Does this depend on the behaviour of |eid= in Module:Wd? That is, the function returns nothing if the parameter exists but is blank? I've implemented a |eid= that should mimic that behaviour in Module:WikidataIB/sandbox if you want to test it when you have time. --RexxS (talk) 20:17, 2 July 2019 (UTC)

  BTW, that part is only loaded if check for health by region -->{{#if:{{#invoke:WikidataIB|checkvalue | val=Q64027457 | P31 | qid={{#invoke:WikidataIB |getQid |qid={{{qid|}}} }}}} | <!-- is true. Checking for P971 might work too. The economy one might need some work, as currently there isn't much consistency. Jura1 (talk) 05:27, 3 July 2019 (UTC)

• @Mike Peel: as the suggested version works, would you mind adding it for now and optimizing the code later? Jura1 (talk) 16:25, 4 July 2019 (UTC)

  @Jura1: That sounds reasonable - done. Thanks. Mike Peel (talk) 17:19, 4 July 2019 (UTC)

@Jura1: Heads up that there's going to be a major change to display category combines topics (P971) information shortly, see {{Wikidata Infobox/sandbox}}. Can you check that this doesn't cause any problems for your use cases, please, and let me know if the code that was added before should be removed or if it's still useful? Thanks. Mike Peel (talk) 17:17, 19 April 2020 (UTC)

• @Mike Peel: Thanks. The testcase for health looks good and I (re-)added one for education/economics: works too. Jura1 (talk) 08:35, 20 April 2020 (UTC)

This section was archived on a request by: Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 12:42, 26 December 2020 (UTC)

following redirects on wikidata

Tracked in Phabricator
Task T157868

Hi, it seems that if name items on wikidata are links through redirects the box does not follow them. There is i.e. the red category Category:Q28053272 (given name). The content is because all the cats, like Category:Auguste Pattberg, within it are using d:Q28053272 (Auguste) which is a redirect to d:Q18010311 (Auguste) (I merged male and female names to unisex names some days ago). This is a bug in my eyes and should be fixed. Thx. --JuTa 16:32, 7 July 2019 (UTC)

The same applies for Category:Q18220903 (given name) for unisex given name Category:Jan (given name). --JuTa 17:12, 7 July 2019 (UTC)

• If you would avoid merging items on Wikidata, this wouldn't happen. Jura1 (talk) 18:22, 7 July 2019 (UTC)

Yes, but isnt that sensefull? These are unisex names and should be handeled together, shouldnt they? --JuTa 18:45, 7 July 2019 (UTC)

• Currently, you seem to be merging merely for a category problem at Commons. Please avoid doing that.

The first is similar to "Jean": it's a male given name in French and female one in English, but that doesn't make it a unisex given name. Jura1 (talk) 20:29, 7 July 2019 (UTC)

So the unisex commons category on commons should be connected to the male item on wikidata, but not the the female one. Hmmmm --JuTa 20:31, 7 July 2019 (UTC)

I have no opinion on this. Maybe you need to link manually or with different code. Jura1 (talk) 16:41, 10 July 2019 (UTC)

PS: Even in case my merges on wd are incorrect, the box should follow redirects on wikidata anyhow. There are and will be correct merges on wikidata. --JuTa 20:35, 7 July 2019 (UTC)

@JuTa and Jura1: Shouldn't links to Wikidata redirects be shortlived? They should really be automatically moved over to the new destination, as they can cause a variety of issues if they aren't. I'm not even sure that the Wikidata interface follows them automatically. But @RexxS: perhaps this could be handled by WikidataIB anyway? Thanks. Mike Peel (talk) 19:01, 9 July 2019 (UTC)

@Mike Peel: I don't understand how you expect WikidataIB to "follow" a redirect. The code reads the contents of the database for a given entity-ID. How would it know that is a redirect? Can you give me some examples to work from? --RexxS (talk) 23:31, 9 July 2019 (UTC)

@RexxS: The original example seems to have been reverted, so here's an alternative: Category:Culture in Pescara (Q65098513) redirects to Category:Culture in Pescara (Q26204988), so if WikidataIB found a property value that's Q65098513, then it should 'follow' that and display information, such as the label, from Q26204988 instead. Thanks. Mike Peel (talk) 07:03, 10 July 2019 (UTC)

@Mike Peel: for Category:Culture in Pescara (Q65098513) and Category:Culture in Pescara (Q26204988), reading property Commons category (P373):

• {{wdib|ps=1|qid=Q65098513|P373}} → Culture of Pescara
• {{wdib|ps=1|qid=Q26204988|P373}} → Culture of Pescara

So it looks like WikidataIB already "follows" the redirect for properties. However the underlying code doesn't do the same for the label:

• {{#invoke:WikidataIB|getLabel|qid=Q65098513}} → Category:Culture in Pescara
• {{#invoke:WikidataIB|getLabel|qid=Q26204988}} → Category:Culture in Pescara

That's an issue for the mw.wikibase.getLabel call in the Wikibase Client Scribunto interface. Only thing I can suggest is to file a Phabricator ticket, sorry. I simply don't have any means of recognising when a page is a Wikidata redirect, in order to create a work-around. --RexxS (talk) 14:12, 10 July 2019 (UTC)

At Wikidata, eventually redirects get replaced by the new value by bot. An odd thing I encountered at Category:Twr_Mawr_Llanddwyn_Lighthouse is that "different from" points to the category that had been linked previously to that item. I tried various edits on Wikidata, but that didn't help. Jura1 (talk) 16:41, 10 July 2019 (UTC)

Aah, this is phab:T157868. It looks like an issue that's been around for quite a while. I've changed it to high priority on phabricator. Thanks. Mike Peel (talk) 17:57, 10 July 2019 (UTC)

Query Server doesn't either. The bot takes care of it. Category:Twr_Mawr_Llanddwyn_Lighthouse is a more complex problem. Somehow the new sitelink doesn't get loaded. Jura1 (talk) 18:46, 10 July 2019 (UTC)

@Jura1: That was a different issue, you had updated the sitelink but not Commons category (P373). removing the P373 value has fixed it. Thanks. Mike Peel (talk) 19:16, 10 July 2019 (UTC)

This section was archived on a request by: Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 12:46, 26 December 2020 (UTC)

Edit request - cleanup

{{Edit request}}

Hi. Can I request that

.taxontree-rcell {
	
}

.taxontree-row {
	
}

be changed to

.taxontree-rcell,
.taxontree-row {
	
}

or removed entirely, since the rules are empty? Also, can

.wdinfobox_hide {
	display: none;
}

#wdcreator {
	display: none;
}

be combined to

.wdinfobox_hide,
#wdcreator {
	display: none;
}

which has the same result but removes the extra lines? Thanks, --DannyS712 (talk) 17:12, 12 July 2019 (UTC)

@DannyS712: I've moved your question here from the style talk page, I hope that's OK. I'd prefer to keep the formatting as it is, as it's more human-friendly, unless there's a reason why making these changes is good? Thanks. Mike Peel (talk) 08:37, 28 July 2019 (UTC)

This section was archived on a request by: Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 12:47, 26 December 2020 (UTC)

Has pet

I want "Has pet" has pet (P1429) to display at my user:ssr, how do I make it? --ssr (talk) 15:40, 16 August 2019 (UTC)

@Ssr: It's now in the sandbox, although I'm not sure the items meet Wikidata's notability requirements... Thanks. Mike Peel (talk) 16:33, 21 August 2019 (UTC)

As this infobox is displayed Commons, it is up to the Commons community to decide which Wikidata info to include. I say no to "has pet", as it would push human biographical infoboxes (many already very crowded) ever further into trivial, arbitrary and indiscriminate territory. A person's pet is almost never a significant aspect. If we're including pets on, say, Barack Obama, why not height, weight, hair color, Twitter account, net worth, number of appearances on C-Span, earlobe shape, and favorite flavor of ice cream? But I am less opposed to displaying the inverse ("owned by") on pet infoboxes, as for example Bo the dog is often defined and described as "the Obama family dog". --Animalparty (talk) 23:42, 6 September 2019 (UTC)

This section was archived on a request by: Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 12:49, 26 December 2020 (UTC)

Some UK geographical identifiers

In this time of WLM, would it be possible to add some more UK buildings/geographical identifiers to the template, viz.:

GSS code (2011) (P836); OpenDomesday settlement ID (P3118); TOID (P3120); Vision of Britain unit ID (P3615); Vision of Britain place ID (P3616); British History Online VCH ID (P3628); KEPN ID (P3639); Atlas of Hillforts ID (P4102); Highland Historic Environment Record ID (P7304); Gazetteer for Scotland place ID (P7350); GENUKI ID (P7352); UK Lakes Portal ID (P7548); Dictionary of Scottish Architects building ID (P7630); POWiS ID (P7659); Aberdeenshire HER ID (P7694);

Thanks! Jheald (talk) 18:44, 2 September 2020 (UTC)

Some categories that would display a number of these include

• Category:Compton Verney or Category:West Wycombe (GSS code (2011) / OpenDomesday settlement ID / TOID / Vision of Britain unit ID / Vision of Britain place ID / British History Online VCH ID / KEPN ID)
• Category:Gladhouse Reservoir (Gazetteer for Scotland place ID / UK Lakes Portal ID / Dictionary of Scottish Architects building ID)
• Category:Culross_Abbey (Dictionary of Scottish Architects building ID / POWiS ID)
• Category:Creich,_Highland_(civil_parish) (TOID / Vision of Britain unit ID / Gazetteer for Scotland place ID / GENUKI ID)
• Category:Kinloch_Castle (Highland Historic Environment Record ID / Dictionary of Scottish Architects building ID)
• Category:Dunadd (Atlas of Hillforts ID / Gazetteer for Scotland place ID)

-- Jheald (talk) 19:59, 2 September 2020 (UTC)

@Jheald: They are now in {{Wikidata Infobox/sandbox}}, please test it. Thanks. Mike Peel (talk) 16:03, 3 September 2020 (UTC)

@Mike Peel: Thanks, Mike. That's looking good. I tried moving TOID (P3120) up slightly compared to its numerical position - it's a rather generic resource, and a very long number, and just seemed to sit better on the page a little higher. But I see that got reverted; no big deal, either way.

Both Gazetteer for Scotland place ID (P7350) and Atlas of Hillforts ID (P4102) seem to be having some issues today. But per the Wayback Machine, the Gazetteer was up at least as recently as August 21st, and the Hillforts looks like a certificate issue; so could we let both go forward for the time being? They both should be back soon, with luck.

The only other comment I'd make - more as a vague aspiration going forward, than anything concrete - but would it be possible to do any more to distinguish the property names from the identifier values in the infobox? Looking at eg Category:West Wycombe now, the mixture of identifier values and long, rather texty identifier names makes it, for me, a bit hard to pick out either. Not sure what might help. Identifier names in italic? Or values in bold, or fixed-width teletype? Unsure, but perhaps worth a thought. Thanks! Jheald (talk) 16:57, 3 September 2020 (UTC)

@Jheald: The revert was accidental, I was trying to figure out the problem above. Add it back if you want, I've just been keeping things in numerical order to make it easier to maintain. I've changed the text size for the IDs so it's smaller, does that look reasonable? It means the infobox takes up less space, which is important where we are displaying a lot of IDs, but makes it a bit harder to read. Thanks. Mike Peel (talk) 17:15, 3 September 2020 (UTC)

@Mike Peel: Interesting. I would never have thought of it, but the smaller text size *really* works for me. It really does seem to reduce the 'busyness' of the page - it makes the page feel more organised, with that bit set apart, rather than everything blurring together as a sea of text all the same size. And it makes the individual lines *much* more readable, also with more chance of white space around them, which helps to distinguish one line from the next. So a big thumbs up for this from me!

Also, because it's now easier to see the TOID for what it is, I am now not so bothered to move it up to get it out of the way. All in all, IMO a really good step forward. Thanks! Jheald (talk) 17:27, 3 September 2020 (UTC)

OK, let's see if anyone has any comments on it, otherwise I'll make it live at some point soon. Thanks. Mike Peel (talk) 17:29, 3 September 2020 (UTC)

@Mike Peel: Did anything happen with these (and the reduced font size)? They never seem to have been moved into the main template, but don't seem to be in the sandbox any more either -- looks like they were collateral damage from this diff Jheald (talk) 23:46, 14 October 2020 (UTC)

@Jheald: Sorry, I've been working on other things, and have just come back to the infobox. I've restored the changes in the sandbox, I plan to make it live this weekend. Thanks. Mike Peel (talk) 17:12, 5 December 2020 (UTC)

@Jheald: (belatedly) this is live. Thanks. Mike Peel (talk) 18:11, 29 December 2020 (UTC)

This section is resolved and can be archived. If you disagree, replace this template with your comment. Mike Peel (talk) 18:11, 29 December 2020 (UTC)

Category:Doctor of Philosophy

The template is applying Category:People who hold PhDs (was a red link until I just created it), which seems to duplicate Category:Doctor of Philosophy; though perhaps that should be Category:Doctors of Philosophy (plural; c/f/ Category:Doctors of Divinity and others). Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 19:52, 4 December 2020 (UTC)

@Pigsonthewing: That's coming through the chain award received (P166) = Doctor of Philosophy (Q752297) -> category for recipients of this award (P2517) = Category:People who hold PhDs (Q9517628). You'll know better than I whether or not P166 is the right property to use to indicate this. I think there's a difference between content about PhDs in general and a category for people with PhDs, but it's easy enough to rename Category:People who hold PhDs if you want? Thanks. Mike Peel (talk) 10:31, 5 December 2020 (UTC)

Please keep trivial cruft like this away from Commons. What's next, Category:People who hold bachelor's degrees? Category:People who have graduated high school? Category:People who have had sex, Category:People who have farted? --Animalparty (talk) 02:53, 6 December 2020 (UTC)

Category:People who have farted: can you get an award for that? Cool; cool, cool, cool. --RexxS (talk) 21:01, 25 December 2020 (UTC)

This section is resolved and can be archived. If you disagree, replace this template with your comment. Mike Peel (talk) 18:09, 29 December 2020 (UTC)

Highlighting objects using OSM data

OpenStreetMap's Edgbaston Pool polygon, seen in Wikidata

OpenStreetMap's River Sherbourne relation, seen in Wikidata

Objects (ways, polygons and relations) in OpenStreetMap can be tagged with a Wikidata ID.

Wikidata's excellent 'Abbe98/osm.js' user script can be used to display a zoomable, slippy map on the Wikidata page, like those in the screenshots above. Where no OSM object is found, a blank is displayed.

This infobox does that for Category:Edgbaston Pool, but not for Category:River Sherbourne. Can it? Perhaps User:Abbe98's code is reusable? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 19:23, 16 December 2020 (UTC)

@Pigsonthewing: The infobox uses mw:Extension:Kartographer to generate the maps. The automatic highlighting of the area relies on the link to the Wikidata item being stored in the OSM entity, if you can add it there then after a short delay (depending on when WMF updates the cached OSM data, and when the server cache for the category expires) then it should automatically display here. I'm not sure that anything in the Javascript code can be used here, sorry. Thanks. Mike Peel (talk) 19:47, 25 December 2020 (UTC)

This section is resolved and can be archived. If you disagree, replace this template with your comment. Mike Peel (talk) 18:08, 29 December 2020 (UTC)

float right lost today

Tracked in Phabricator
Task T279008

Hi, today the "float right" got anyhow lost, which results a lot of white space on any page using this template. Can this get fixed? --JuTa 19:52, 31 March 2021 (UTC)

There was a change in the CSS today that causes this problem. It will get fixed soon, see the linked ticket at Phabricator. -- Discostu (talk) 20:42, 31 March 2021 (UTC)

Fixed -- Discostu (talk) 20:49, 31 March 2021 (UTC)

This section is resolved and can be archived. If you disagree, replace this template with your comment. Discostu (talk) 20:49, 31 March 2021 (UTC)

Recent change(?) adds massive white space

Tracked in Phabricator
Task T279008

Look at any category with an infobox (Category:Joe Biden, Category:Romania, etc.). The content is now shunted down to a line BELOW the entire infobox. This is unacceptably ugly and a waste of screen space, making content even harder to view. Please fix. Thanx. --Animalparty (talk) 19:52, 31 March 2021 (UTC)

See above -- Discostu (talk) 20:42, 31 March 2021 (UTC)

Fixed -- Discostu (talk) 20:49, 31 March 2021 (UTC)

This section is resolved and can be archived. If you disagree, replace this template with your comment. Discostu (talk) 20:49, 31 March 2021 (UTC)

Link to en.wikipedia

Dear all, it seems to me that the infobox prefers linking to en.wikipedia. I saw this at Category:Synagogue in Lučenec. I do not think it is just or very correct. Perhaps there does not need to be a link to any Wikipedia since those are already on the left and easily accessible through the link to the Wikidata item. Thanks!--Jetam2 (talk) 17:43, 2 February 2021 (UTC)

User:Jetam2: I think the Wikipedia link displayed in the infobox is related to the language selected by the user in the interface. I mean, you get a en.wikipedia link probably because you have selected English language in Commons. It is true, though, I get the en.wiki link when unlogged, but, after all, English is the default language when accessing Commons without an account... Strakhov (talk) 21:10, 2 February 2021 (UTC)

Hi Jetam2, I tried with slovakian in the references an the correct slovak article in the box was appearing - not the english. regards -- K@rl (talk) Mid Abstond hoidn xund bleibn 10:50, 3 February 2021 (UTC)

Thank you, both, for letting some light on this. It is true that English is set as my language on Commons. The issue seems less weird now though the one link still seems to suggest that there is only one article available while there might be more.--Jetam2 (talk) 16:24, 3 February 2021 (UTC)

The links also appear in the sidebar. Thanks. Mike Peel (talk) 13:24, 25 April 2021 (UTC)

This section is resolved and can be archived. If you disagree, replace this template with your comment. Mike Peel (talk) 13:24, 25 April 2021 (UTC)

errors

This template times out at Category:Stolpersteine in Germany. I am not sure how to diagnose the issue. --Jarekt (talk) 13:22, 5 February 2021 (UTC)

Seems fine now... Thanks. Mike Peel (talk) 13:23, 25 April 2021 (UTC)

This section is resolved and can be archived. If you disagree, replace this template with your comment. Mike Peel (talk) 13:23, 25 April 2021 (UTC)

Wikidata ID not found

Does anyone know why the Wikidata ID is not found for Category:UKCA marking? In UKCA marking (Q101220997), a Commons-Link has been added to other sites and there's also a Commons category (P373) entry that links to the category. -- H005 12:24, 9 February 2021 (UTC)

H005, it is working normally for me. You may need to purge the page to get it to show up properly. — Huntster (t @ c) 13:18, 9 February 2021 (UTC)

Thanks, what do you mean by "purge"? -- H005 14:58, 9 February 2021 (UTC)

H005, sorry for the delay, busy at work. There are several ways. You can simply append "&action=purge" to the end of any Wikimedia page to fetch a fresh copy. You can also go into your Gadgets page and enable any number of tools which provide a purge functionality (just search "purge" there) to make it easier on yourself in the future. It's worthwhile. — Huntster (t @ c) 20:58, 9 February 2021 (UTC)

Thanks, I'm on a different computer today, and here it works, even without purging. I will look into those gadgets though, thanks for the hint! -- H005 08:02, 10 February 2021 (UTC)

This section is resolved and can be archived. If you disagree, replace this template with your comment. Mike Peel (talk) 13:18, 25 April 2021 (UTC)

Coordinates error

On Category:Higher Town, Isles of Scilly, at the time of writing this, the coordinate location is showing as 50° 00′ 00″ N, 6° 18′ 00″ W, but on Higher Town (Q20065114) the coordinates are defined as 49°59'N, 6°17'W. Any idea why? MSGJ (talk) 20:29, 10 February 2021 (UTC)

MSGJ, on Wikidata, the coordinate precision was set to...something very odd (see diff of correction). I set a normal precision which seems to have fixed the issue. I think the module was trying to interpret the precision as the next most-broad setting, which resulted in the 50 00, 6 18 figure. — Huntster (t @ c) 20:54, 10 February 2021 (UTC)

I'm seeing a similar issue on Category:Hastings station (MBTA) / Hastings station (Q14715522), where the coordinates in the infobox don't match the wikidata item. Confusingly, that wikidata item has no precision set. Pi.1415926535 (talk) 21:01, 10 February 2021 (UTC)

I set precision to 0.01. Has that fixed it? There is something not right here though. The position on the map should match the position in Wikidata, regardless of the precision. MSGJ (talk) 22:33, 10 February 2021 (UTC)

There is something similar on New Grimsby (Q7007859) where the precision was set to 0.13962240550751 by BotMultichill. I don't know how to fix it because when I change the precision the coordinates go wrong. MSGJ (talk) 22:31, 10 February 2021 (UTC)

Given some ambiguity, I updated the coordinates to match what Ordnance Survey gives, and left the default precision. — Huntster (t @ c) 03:07, 11 February 2021 (UTC)

@Huntster: now you can see the problem at Category:New Grimsby, which is what I meant by "when I change the precision the coordinates go wrong"! MSGJ (talk) 08:38, 11 February 2021 (UTC)

MSGJ, the reason you are seeing "wrong coordinates" in Wikidata is because it is all based on decimal coordinates, but displayed as degree,minute,second coords. When the decimal coordinates are "49.95728, -6.33740" with a precision of 0.00001, it displays as "49°57'26.21"N, 6°20'14.64"W". If you change precision to 0.01, aka "49.95, -6.33", it now displays as "49°57'0"N, 6°19'48"W". Same basic decimal coordinates, just less precise. — Huntster (t @ c) 13:26, 11 February 2021 (UTC)

This section is resolved and can be archived. If you disagree, replace this template with your comment. Mike Peel (talk) 13:19, 25 April 2021 (UTC)

Outreachy project

Hi all. I'm proposing an Outreachy project (see Outreachy (Q15894890)), jointly with @RexxS: , with the ultimate aim of having an intern that rewrites the infobox entirely in Lua during this summer. You can find the details at phab:T273109. Hopefully this will lead to new users coming to this talk page to look for starter tasks, and it would be great if you could welcome and help them, and continue posting requests here in dedicated sections (bearing in mind that they will need more background info and help to implement the changes). Questions are welcome here or on the Phabricator task. Thanks. Mike Peel (talk) 19:19, 1 March 2021 (UTC)

Unfortunately, this won't go ahead, at least in this round, as it needs a co-mentor that knows Lua. If anyone could help mentor, please let me know. Thanks. Mike Peel (talk) 11:19, 2 March 2021 (UTC)

This section is resolved and can be archived. If you disagree, replace this template with your comment. Mike Peel (talk) 13:17, 25 April 2021 (UTC)

Location chain issues

Category:Foz de Lumbier: -> "Navarra, Euskal Herria, Navarra, Euskal Herria, Navarra, Euskal Herria, Navarra, Euskal Herria, Navarra": not mention of the country ("Spain") and repetition of this "Navarra, Euskal Herria" several times. I guess it's related to this ethnolinguistic region ("Euskal Herria") being located in the administrative territorial entities 'Navarre', 'Basque Country' and 'Pyrénées-Atlantiques' (in fact parts of this region, well, the first two at least, the third one only partially) according to its Wikidata item but maybe the template could follow the P131 chain from the beginning, instead of relying on P276 from Navarre onwards. I don't know, I guess it's complex module... Strakhov (talk) 09:58, 13 March 2021 (UTC)

Strakhov, yeah, that was a weird one. I've reworked things a little bit, moving Basque Country, Southern Basque, and French Basque out of located in the administrative territorial entity (P131), removing location (P276) entirely in some cases, and using part of (P361) for various Basque regions since (afaik) they aren't actually administrative entities. It's a messy solution, but the real world arrangements are just as messy. How the infobox handles chaining should still be re-examined. — Huntster (t @ c) 20:33, 19 March 2021 (UTC)

This section is resolved and can be archived. If you disagree, replace this template with your comment. Mike Peel (talk) 13:16, 25 April 2021 (UTC)

Deprecated use in gallery pages

It should be mentioned that this template should be avoided in gallery pages to avoid an over-categorization with the main category, and considering there's already other templates such as Template:Infobox gallery pages about people. See this discussion for more details. Synthwave.94 (talk) 14:00, 26 April 2021 (UTC)

@Synthwave.94: Use in gallery pages is fine, it's designed to cope with that. Set autocat=no if you don't want it to add the categories. The manual infoboxes should be deprecated. Thanks. Mike Peel (talk) 09:16, 27 April 2021 (UTC)

@Mike Peel: Thanks for your answer. Synthwave.94 (talk) 13:19, 27 April 2021 (UTC)

This section is resolved and can be archived. If you disagree, replace this template with your comment. Mike Peel (talk) 19:19, 16 July 2021 (UTC)

New Lua error

Noticed in Category:Keraudren (surname):

Lua error in Module:Interwiki at line 49: bad argument #1 to 'ipairs' (table expected, got nil).

Possibly related to the fact that the Wikidata item linking to that Category was recently changed from Kéraudren (Q24706827) to Keraudren (Q25114160) - but the Commons Category still displays the Qid of the original WD item.

Laddo (talk) 22:26, 30 April 2021 (UTC)

@Laddo: You need to report this at Module talk:Interwiki, not here, since it's a module that the infobox transcludes. Hopefully @Jarekt: could help there. Thanks. Mike Peel (talk) 09:14, 1 May 2021 (UTC)

@Laddo: Fixed I hope. I have not touched that part of code for a while, so something must have changed with the wikibase data model. Strange. --Jarekt (talk) 02:50, 2 May 2021 (UTC)

This section is resolved and can be archived. If you disagree, replace this template with your comment. Mike Peel (talk) 19:18, 16 July 2021 (UTC)

Request for properties

Please can replaces (P1365) and replaced by (P1366) be shown in the infobox? MSGJ (talk) 22:35, 15 February 2021 (UTC)

@MSGJ: Added to {{Wikidata Infobox/sandbox}}, please test. Thanks. Mike Peel (talk) 13:22, 25 April 2021 (UTC)

@MSGJ: This is now live. Thanks. Mike Peel (talk) 15:37, 18 July 2021 (UTC)

This section is resolved and can be archived. If you disagree, replace this template with your comment. Mike Peel (talk) 15:37, 18 July 2021 (UTC)

school district (P5353)

This property could be displayed, couldn't it? It would be useful on pages such as Category:C. K. McClatchy High School, where it would generate a link to Category:Sacramento City Unified School District. Thierry Caro (talk) 14:23, 20 March 2021 (UTC)

@Thierry Caro: Added to {{Wikidata Infobox/sandbox}}, how does that look? Thanks. Mike Peel (talk) 13:15, 25 April 2021 (UTC)

@Thierry Caro: This is now live. Thanks. Mike Peel (talk) 15:35, 18 July 2021 (UTC)

This section is resolved and can be archived. If you disagree, replace this template with your comment. Mike Peel (talk) 15:35, 18 July 2021 (UTC)

request for change of property

Now, seen for the first time, the Infobox also shows Cultural heritage database in Austria ObjektID (P2951). This property is legacy and deprecated. It was replaced by the data provider in 2021 by the new Heritage Information System ID in the database of cultural heritage in Austria (P9154). P9154 Ids have been already added to Wikidata. Can you please replace P2951 by P9154 in the Infobox. You can link directly to the corresponding line in the german WP using:

[[{{#invoke:Wikidata |sitelinkOf|Q{{#invoke:Wikidata|claim|P2817|id=Q38180651|parameter=numeric-id }}}}#Q38180651]] → [[{{#invoke:Wikidata |sitelinkOf|Q{{#invoke:Wikidata|claim|P2817|id=Q38180651|parameter=numeric-id }}}}#Q38180651|Link]] (please replace sitelinkOf by whatever is working here on commons)

https://denkmalliste.toolforge.org seems not to be maintained actively (see de:Wikipedia_Diskussion:WikiProjekt_Österreichische_Denkmallisten#https://denkmalliste.toolforge.org this German talk).

best --Herzi Pinki (talk) 08:59, 25 June 2021 (UTC)

this template is central infrastructure. How to improve maintenance? @Mike Peel: --Herzi Pinki (talk) 22:31, 14 July 2021 (UTC)

@Herzi Pinki: Pinging me helps. ;-) I've swapped the ID in the sandbox, please test {{Wikidata Infobox/sandbox}}. Thanks. Mike Peel (talk) 19:15, 16 July 2021 (UTC)

@Mike Peel: tested and ok. Can you please make it productive. --Herzi Pinki (talk) 19:51, 16 July 2021 (UTC)

@Herzi Pinki: This is now live. Thanks. Mike Peel (talk) 15:34, 18 July 2021 (UTC)

This section is resolved and can be archived. If you disagree, replace this template with your comment. Mike Peel (talk) 15:34, 18 July 2021 (UTC)

Image of interior, view and winter view

Hi together,

I think it would be nice, if images from the following properties would be displayed in the infobox in a similar manner as nighttime view (P3451) is:

• image of interior (P5775)
• view (P8517)
• winter view (P5252)

Or are there any reasons against this? There are probably some more similar properties, but those are the ones I've noticed so far.

Cheers --DavidJRasp (talk) 13:20, 13 July 2021 (UTC)

I think this results in needless clutter. More is not better. Why not just make a gallery instead? The infobox was never intended to be a mini encyclopedia article itself. --Animalparty (talk) 15:17, 13 July 2021 (UTC)

@DavidJRasp and Animalparty: I think these make sense - it's good to show more images, since that's one of the main things we do, and it also makes it obvious where images are missing on Wikidata and could be added. It's also simple to include them, without taking up much extra space (since we have the radio button to select them). I've added these to {{Wikidata Infobox/sandbox}}, please test the changes! Thanks. Mike Peel (talk) 19:11, 16 July 2021 (UTC)

to make it obvious where images are missing on wikidata, I prefer something like Query for Austrian commons-categories without images. This is a more targeted proceeding. best --Herzi Pinki (talk) 18:45, 17 July 2021 (UTC)

@Mike Peel: I tested it for Category:Frauenkirche (Munich) in preview. The image of the interior is displayed as "image of grave".

@Animalparty: I understand this concern, that those images could clutter the infobox, but then again... Why do we already have the nighttime image and others there? Why is the nighttime image more important than the interior or view from a given site e.g.? --DavidJRasp (talk) 11:25, 18 July 2021 (UTC)

@DavidJRasp: That should be fixed now in the sandbox, can you try again please? Thanks. Mike Peel (talk) 12:52, 18 July 2021 (UTC)

@Mike Peel: , Yep. Now that is fixed! Thanks you! --DavidJRasp (talk) 15:10, 18 July 2021 (UTC)

@DavidJRasp: OK, this is now live, please let me know if you spot any issue! Thanks. Mike Peel (talk) 15:34, 18 July 2021 (UTC)

This is a very neat addition. Thank you all. Thierry Caro (talk) 16:26, 18 July 2021 (UTC)

This section is resolved and can be archived. If you disagree, replace this template with your comment. Mike Peel (talk) 15:34, 18 July 2021 (UTC)

Wikidata infobox not updating after switching Wikidata item that a Commons category is connected to

I recently noticed that the Wikidata Infobox at Category:Talin, which contains images of a protein called talin, was displaying content related to the town Talin, Armenia. This is apparently because the Wikidata item about the town, Talin (Q608156), had the "Commons category" property set to the Commons category Category:Talin, rather than Category:Talin, Armenia. So I corrected the item (diff) and also added the Commons category to Talin protein (Q7679528) diff. However, the Wikidata Infobox at Category:Talin is still showing data for the wrong Wikidata item. Did I do something wrong? Marbletan (talk) 20:38, 9 August 2021 (UTC)

@Marbletan: the link was actually established through Category:Talin, Armenia (Q32401684). You can get there by clicking the [Wikidata item] link in the lefthand sidebar menu in a given category (or other wikipage where applicable). Fixed it. --HyperGaruda (talk) 03:57, 10 August 2021 (UTC)

I see, I should have realized that. Thank you! Marbletan (talk) 13:02, 10 August 2021 (UTC)

This section is resolved and can be archived. If you disagree, replace this template with your comment. Mike Peel (talk) 17:47, 20 August 2021 (UTC)

Automatic categorisation into a language

In Category:English language, I stumbled across a bunch of subcategories that look rather out of place there, like Category:Atari Portfolio‎. This seems caused by the P407 qualifier (language of work or name) in property P2078 (user manual URL), but the manual's language should not be mirrored in the category structure of Commons. --HyperGaruda (talk) 07:08, 8 August 2021 (UTC)

@HyperGaruda: Thanks for spotting this! I think [9] should fix it, I'll deploy that soon and double-check the category contents after that. Thanks. Mike Peel (talk) 17:52, 20 August 2021 (UTC)

This section is resolved and can be archived. If you disagree, replace this template with your comment. Crazy1880 (talk) 19:14, 8 December 2021 (UTC)

Bug?

I've been adding Commons category (P373) to a bunch of new cats lately and this template isn't pulling Wikidata entries even after I purge the page cache. See Category:William Hodgins Biggar and William Hodgins Biggar (Q8012376) for one recent example. Am I doing something wrong? Adding Commons category (P373) has worked for me in the past. AleatoryPonderings (talk) 19:23, 2 September 2021 (UTC)

@AleatoryPonderings: {{Wikidata Infobox}} needs sitelinks (or the |qid= parameter) in order to find the Wikidata item, see d:Special:Diff/1491741303. — ExE Boss (talk) 11:00, 3 September 2021 (UTC)

This section is resolved and can be archived. If you disagree, replace this template with your comment. Crazy1880 (talk) 19:10, 8 December 2021 (UTC)

Drop coordinates rounding

I propose the following change: Special:Diff/593256463. As commented above (#Odd coordinates), there doesn't seem to be any good reason to round coordinates the way it's currently done. For instance page Category:Aarhus Universitetshospital currently uses sandbox template and given change moved map marker about 300 m to the southwest, matching the marker location displayed on Wikidata (d:Q12300343#P625). 2001:7D0:81DA:F780:E9D6:D1E1:24D2:AF21 16:58, 24 September 2021 (UTC)

I moved my comment to talk page of actual page where change is proposed: Module talk:WikidataIB#Drop coordinates rounding. 2001:7D0:81DA:F780:D52:CBA1:A8AF:806A 07:06, 29 September 2021 (UTC)

This section is resolved and can be archived. If you disagree, replace this template with your comment. Crazy1880 (talk) 19:05, 8 December 2021 (UTC)

climbing route (P7309)

Hello. Can this be added to the Infobox? It would be useful for mountains and hills. Thierry Caro (talk) 18:20, 20 September 2019 (UTC)

species kept (P1990) would also be useful, this time for zoos and stuff. I would limit the number of values displayed to five, just in case. Thierry Caro (talk) 11:41, 22 September 2019 (UTC)

@Thierry Caro: Both are now in {{Wikidata Infobox/sandbox}}, please test them. I've set the second one to auto-collapse at 5, and maxvals=30, for now. Thanks. Mike Peel (talk) 13:37, 28 September 2019 (UTC)

@Mike Peel: Thank you. Both are working perfectly. You may add them to the actual template now. Thierry Caro (talk) 20:09, 28 September 2019 (UTC)

Listing five (or any limited number of) species kept for a zoo seems pointless. Which five? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 14:18, 3 October 2019 (UTC)

@Mike Peel: Maybe we can get climbing route (P7309) only for the moment. Thierry Caro (talk) 12:03, 13 October 2019 (UTC)

@Mike Peel: Thanks. Thierry Caro (talk) 07:06, 9 February 2020 (UTC)

This section is resolved and can be archived. If you disagree, replace this template with your comment. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 12:59, 8 December 2021 (UTC)

Display P366 (Use)

Can we add a line to display P366 (Use)? It is valuable to display the use/purpose/mission of an aircraft type. Thanks! Josh (talk) 16:41, 22 September 2019 (UTC)

@Joshbaumgartner: It's now in {{Wikidata Infobox/sandbox}}, please could you test it? Thanks. Mike Peel (talk) 13:31, 28 September 2019 (UTC)

@Mike Peel: I tested it on a few categories, it looks perfect. Thanks! Josh (talk) 16:15, 28 September 2019 (UTC)

Thanks for checking it. I'll deploy it in the next week or so, when other changes are also ready. Thanks. Mike Peel (talk) 16:23, 28 September 2019 (UTC)

This section is resolved and can be archived. If you disagree, replace this template with your comment. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 13:00, 8 December 2021 (UTC)

Birth not displayed

Hello, why for this category the birth is not displayed? --Arnd (talk) 17:53, 8 October 2019 (UTC)

Moin Moin Arnd, in dem zugehörigen Wikidata-Objekt ist das Geburtsdatum als "misbilligter Rank" eingestuft, deswegen wir er nicht dargestellt. Wenn du vorn auf die drei Punkte im Wikidata-Objekt klickst, siehst du das. Für Rückfragen stehe ich dir gerne zur Verfügung. mfg --Crazy1880 (talk) 18:12, 8 October 2019 (UTC)

This section is resolved and can be archived. If you disagree, replace this template with your comment. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 13:04, 8 December 2021 (UTC)

Danish urban area code (P1894)

This is an official identifier for urban areas in Denmark. Can we have it displayed, please? --Hjart (talk) 12:55, 13 October 2019 (UTC)

• I added it to Template:Wikidata_Infobox/core/sandbox visible on Category:Roskilde. Jura1 (talk) 12:50, 14 October 2019 (UTC)

This section is resolved and can be archived. If you disagree, replace this template with your comment. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 13:03, 8 December 2021 (UTC)

No data, although there should be

I've been having trouble updating Wikidata Infoboxes that for categories that claim to have no data, even though they should have it. My most recent troublesome infobox is with Category:Wassaic, New York, and though I've seen others, I forgot what they were right now. Is there any way to fix this and the others? ----DanTD (talk) 21:15, 17 October 2019 (UTC)

Have you tried purging? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 21:42, 17 October 2019 (UTC)

I've done that in the past, and it hasn't worked so well. ----DanTD (talk) 21:58, 17 October 2019 (UTC)

For sure, doing it in the past won't fix a problem in the present. If you haven't first tried to resolve the issue yourself by taking this simple step on the category page in question, and not doing so deliberately, you are wasting the time of fellow volunteers by asking for help here. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 10:10, 18 October 2019 (UTC)

@DanTD: My checklist to solve this kind of issue tends to be:

1. "?action=purge" at the end of the Commons category URL to purge the Commons cache
2. Open the edit window of the commons category, and save it without making any changes (a "null edit"). Possibly re-run (1)
3. Go to Wikidata. Double-check the commons category sitelink is there, and is correct (not pointing to a redirect, or to a gallery)
4. If the item on Wikidata is a category item, make sure that topic's main category (P910)/category's main topic (P301) values are correctly set, and aren't duplicated
5. If everything looks correct on Wikidata, then make an edit to the Wikidata item (e.g., adding a property, or removing Commons category (P373), or adding then removing 'test' from the aliases). Then try (1) and (2) again. This step has been important recently when items have been merged on Wikidata, as for some reason that has been breaking the sitelinks until the Wikidata item has been edited again.

I tend to find that steps (1) or (2) solve it 80% of the time, (3)/(4) 18%, and (5) 2% of the time. Hope that helps. Thanks. Mike Peel (talk) 01:37, 18 October 2019 (UTC)

This section is resolved and can be archived. If you disagree, replace this template with your comment. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 12:58, 8 December 2021 (UTC)

Errors in Category:Pages with script errors

@Mike Peel: Hi please look at Category:Ice cream cones. --Jarekt (talk) 12:16, 18 October 2019 (UTC)

Also Category:Russians, Category:SNCF, Category:English language --Jarekt (talk) 12:27, 18 October 2019 (UTC)

The location values on d:Q44248 are problematic. Jura1 (talk) 13:56, 18 October 2019 (UTC)

I meant ice cream cone (Q1156634). Jura1 (talk) 14:45, 18 October 2019 (UTC)

@Jarekt and Jura1: I've raised this at d:Wikidata:Project_chat#Unusually_long_lists_in_some_items, I think these need sorting out on Wikidata, but I'm not sure how. Also @RexxS: in case you can spot ways of avoiding timeouts here - some of them seem to be coming in through country (P17), which is different from usual. Thanks. Mike Peel (talk) 14:12, 18 October 2019 (UTC)

I am fixing ice cream cone (Q1156634). --Jarekt (talk) 14:22, 18 October 2019 (UTC)  Done --Jarekt (talk) 14:58, 18 October 2019 (UTC)

@Jarekt: Thanks for fixing ice cream cone (Q1156634). What kind of mentality thinks it's a good idea to add a list of every country that has ice cream cones?

@Mike Peel: I can see some point in having a list of the main countries where Russians live, but 300 Russians living in Monaco - who cares, is it accurate, and where do these figures come from? Also population (P1082) isn't a valid qualifier for country (P17).

Anyway, there's no way I know of to anticipate server timeouts; it just depends on what's running. My only suggestion is to get into the habit of setting |maxvalues=6 or something like that for any field where you suspect fuckwittery can happen on Wikidata. Sorry, --RexxS (talk) 15:15, 18 October 2019 (UTC)

This section is resolved and can be archived. If you disagree, replace this template with your comment. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 13:05, 8 December 2021 (UTC)

image with frame (P7420)

Not sure if and how to include this in the infobox (mainly on items for paintings). Normally, there should be a value in P18, but I suppose it could serve as backup if there isn't.

A way to include this for other infoboxes could be a zoom(-out)-icon. Where could we place this? Jura1 (talk) 14:07, 18 October 2019 (UTC)

@Jura1: A while back I was looking into adding switchable images into the infobox, see User:Mike Peel/Sandbox2 when you have this javascript running. I think that would work here, but it needs someone that knows Javascript to implement it more cleanly, and an interface admin to add it to Commons' built-in javascript - plus then there are portability issues so there would need to be a fallback when the Javascript isn't present. Thanks. Mike Peel (talk) 14:24, 18 October 2019 (UTC)

I'm not really good with js .. Maybe an icon-sized version can do? I added one at the bottom (test here). Jura1 (talk) 15:06, 18 October 2019 (UTC)

@Mike Peel: I like the javascript idea. It would probably be interesting for Wikipedias as well. Once it's available, we could replace it in the template here.

In the meantime, would you kindly update the template from the sandbox? I also added creator's signature (P7457) (test here) and image of backside (P7417) (will be visible here). Jura1 (talk) 07:25, 22 October 2019 (UTC)

{{Edit request}}

diff (only the parts about P7420, P7457, P7417) Jura1 (talk) 14:45, 23 October 2019 (UTC)

I don't think this works well, it's better to keep the images together at the top, rather than mixing text and images. Let's keep thinking about this. Thanks. Mike Peel (talk) 15:04, 23 October 2019 (UTC)

If there are working suggestions, I'm obviously open to them.

Signatures (on persons) are already at the bottom, e.g. at Category:Douglas_Adams. Adding the signature of the creator next to the name of the creator seems a good topical arrangement.

I think it's good to be able to check if the backside is available, but I don't think it should be above most of the other statements .. Jura1 (talk) 15:11, 23 October 2019 (UTC)

In the absence of a better suggestion. I restore the edit request. Jura1 (talk) 18:37, 30 October 2019 (UTC)

Sorry, I've been working on other things. If it's OK I'll circle back to this at the weekend. Thanks. Mike Peel (talk) 20:49, 30 October 2019 (UTC)

@Jura1: I've now coded up the image switcher in {{Wikidata Infobox/sandbox}} - if you install the Javascript from User:Mike Peel/common.js then you can try it out at Category:Presumed portrait of Guillaume Filastre. I've submitted a request to install the javascript site-wide, currently at Commons:Administrators'_noticeboard#Interface_admin_request (as I don't exactly know where I should submit this!), after that's done then I can make the new change live. Does everything look OK to you? Thanks. Mike Peel (talk) 18:04, 2 November 2019 (UTC)

• Thanks, looks good. I activated the js. Let me think it over. Notably the view without javascript might need some work. Jura1 (talk) 21:31, 2 November 2019 (UTC)
• A few tweaks would be nice:

• If js is disabled, I'd favor a more compact view in the way this was initially presented (having an icon rather than the regular sized image). This can also work for the mobile view.
• I'd place creator's signature just below the creator row, not as a person's signature.

BTW, without the script you wrote, in the earlier test version, some other gallery function kicked in, allow to view the three images in sequence. Jura1 (talk) 06:28, 3 November 2019 (UTC)

Note that there's now a proposal to turn on the Javascript by default, please see Commons:Village_pump/Proposals#Displaying_multiple_images_in_the_Wikidata_Infobox_using_Javascript. Thanks. Mike Peel (talk) 15:52, 10 November 2019 (UTC)

• In the meantime, can use the version I first did? Jura1 (talk) 08:00, 11 December 2019 (UTC)

  @Jura1: The Javascript is now live, so I'll update the infobox with the new code shortly, unless any issues appear. Thanks. Mike Peel (talk) 11:31, 15 December 2019 (UTC)

This section is resolved and can be archived. If you disagree, replace this template with your comment. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 13:13, 8 December 2021 (UTC)

Parameter to optionally switch off categorization?

Assume a wikidata, category etc. and infobox of Frank Lloyd Wright (or anyone else). We're likely to also have a "Works by" category and this could be improved by an infobox on Lloyd Wright giving the basic biog, and of course the link to WP etc.

For Lloyd Wright, there's already such an infobox and it's driven by its own Wikidata item. However in many lesser cases we don't need that, but there's still use in being able to replicate the infobox onto such categories. This works pretty easily, but it also places the category page inappropriately into the biographical categories as well.

A simple parameter could switch off this categorization. Could such a thing be provided? Andy Dingley (talk) 21:36, 26 October 2019 (UTC)

@Andy Dingley: In this case there is already an infobox at Category:Buildings by Frank Lloyd Wright, which links to the appropriate category on enwp, and it's easy enough to create similar Wikidata items for other artists. Perhaps a different solution here would be for the infobox to show more information from the category combines topics (P971) items? Thanks. Mike Peel (talk) 06:49, 27 October 2019 (UTC)

• It's hardly "easy to create Wikidata items" (this is a perennial problem!).

Also in such a case it would be wrong to create one: the notable subject is the author, their corpus of work is probably voluminous but not (unlike Lloyd Wright's) enough to pass independent notability all on its own. The goal here is to replicate an easy self-populating infobox onto a different location (wasn't this some of the original pitch for Wikidata?). It's still relevant to the new page, but it's not the same page as a definition, so to impose the categorization would be wrong. Andy Dingley (talk) 10:03, 27 October 2019 (UTC)

@Andy Dingley: My view is that Wikidata items are easy to create (having created quite a few!), and notability is met by the existence of the Commons category. I think it's better to describe the category on Wikidata using its own item rather than reusing an infobox from another category. But if you prefer otherwise, then the parameter you're looking for is "autocat=no". Thanks. Mike Peel (talk) 17:46, 28 October 2019 (UTC)

This section is resolved and can be archived. If you disagree, replace this template with your comment. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 13:14, 8 December 2021 (UTC)

Please suppress "located at street address (DEPRECATED)" (and maybe all deprecated properties)

Is there a valid reason we need to see P969 (P969) (or any deprecated properties)? See Bay View Cemetery for senseless redundancy in action. Perhaps all deprecated properties should be suppressed. --Animalparty (talk) 02:01, 31 October 2019 (UTC)

I think there are still too many items with P969 (P969), but no street address (P6375). Maybe you can get an ETA from the proponents of P6375? @Jc86035, VIGNERON, and Gzen92: Jura1 (talk) 09:00, 31 October 2019 (UTC)

I will look where is the transfer from P969 to P6375 on Wikidata.

Meanwhile, it doesn't matter for Commons as there is no reason for the infobox to show the two values. There should be a test "if P6375 exists, then don't get P969". Ping @Mike Peel: would you look into it?

Cheers, VIGNERON (talk) 09:23, 31 October 2019 (UTC)

@Animalparty, Jura1, and VIGNERON: Hmm, I thought that a) the infobox did that already, and b) that when street address (P6375) is added then P969 (P969) is removed. Apparently not though! I've tweaked the display as suggested, please test that to see if it works. I'll update the main version this weekend. Thanks. Mike Peel (talk) 19:06, 31 October 2019 (UTC)

@Animalparty, Jura1, and VIGNERON: The change is now live. Thanks. Mike Peel (talk) 15:47, 9 November 2019 (UTC)

• Thanks. @Jc86035, VIGNERON, and Gzen92: what's the progress on your side? Having both properties isn't really helpful. Jura1 (talk) 11:39, 10 November 2019 (UTC)

Hello, I work on this request. But it's complicated when there is already street address (P6375) or/and located on street (P669) or weird address. I will start with simple cases, it will probably end manually. Gzen92 ^[discuter] 17:04, 11 November 2019 (UTC)

I will start with the addresses in France (country (P17) and France (Q142)), Gzen92 ^[discuter] 07:28, 12 November 2019 (UTC)

This section is resolved and can be archived. If you disagree, replace this template with your comment. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 13:14, 8 December 2021 (UTC)

Auto-categorization for names

Currently given name (P735) and family name (P734) adds categorization based on an item's label followed by "(given name)" or "(surname)". Generally, this works fine, but sometimes the category linked from the P735/P734-value isn't the same as that category or the category doesn't exists.

• It happens notably when Wikidata has several items with the same Latin script label (e.g. for different genders),
• or the item is for a name that isn't originally written in Latin script (e.g. Chinese names).
• It also happens when Wikidata has two items for a name depending on uppercase/lowercase initial (e.g. van-Van).

The result is that the infobox displayed on the Commons category doesn't match the name item actually used for a person. Sometimes this leads to people doing odd edits on Wikidata trying to "fix" it. The question is if we should try to correct auto-categorization or just accept that the categories aren't exactly as the items defined on Wikidata. @E4024: who brought this up on Wikidata. @JuTa: who edits frequently on Commons. Jura1 (talk) 17:55, 10 November 2019 (UTC)

I want to switch this at some point to use the Commons sitelinks rather than the label to find the category. That wasn't done originally as there weren't many sitelinks then, but there are rather more now. It ideally needs someone to do some quantification of the % of names that have commons sitelinks now - or we run both systems in parallel for a bit along with tracking categories. Thanks. Mike Peel (talk) 18:36, 10 November 2019 (UTC)

• Sounds good. Maybe this can help: [10]. 963 of the top 1000 given name have a sitelink to Commons. The top 1000 cover ca. 70% of all given name (P735) values. Jura1 (talk) 20:00, 10 November 2019 (UTC)

Hi, Sounds not too bad in first glance, but this could lead to other problems. There are different items on wd for the same names here on commons like latin script and cyrillic script variants. I.e. d:Q830350 (Ivan latin) and d:Q21104340 (Ivan cyrillic). Only one wd item can have a sitelink to Category:Ivan (given name). Would that leave all cyrillic Ivans uncategorized? Another (strange) example is d:Q31362405 (Konstantin/Constantin/Constantine/Kostyantyn cyrillic) compared with d:Q7111053 (Konstantin latin), d:Q5163687 (Constanin latin), d:Q19327451 (Constanine latin) and d:Q23308390 (Kontantyn but also cyrillic). I have currently a discussion witha user who insists on the multi-labels on wikidata at d:User talk:Infovarius#Konstantin/Constantin/Constantine/Kostyantyn. PS: d:Q31362405 is currently filling up Category:Konstantin/Constantin/Constantine/Kostyantyn (given name) with several hundred entries. --JuTa 14:26, 12 February 2020 (UTC) (pinging:Mike Peel)

WikiProject Names/lists/given names/Vasily can given an idea of item you would generally find at Wikidata for similar names.

I think you probably have three options for categorization:

• (1) create categories for all of them,
• (2) add English transliteration to all of them and modify the infobox to display values from several items,
• (3) not categorize names that aren't in English.

As I'm not that active here at Commons, I don't want to recommend one option over another.

To overwrite values at Wikidata to "make it work" for English categories isn't really a good idea (at least from a Wikidata perspective). @Mike Peel, Infovarius, and JuTa: Jura1 (talk) 09:46, 13 February 2020 (UTC)

Let's make Commons finally international interlanguage! (if to have such name categories at all) I propose to create categories with correct names like Category:Иван (given name) (Category:Иван (личное имя)?), Category:Константин (given name) (for d:Q31362405) and so on. --Infovarius (talk) 19:37, 13 February 2020 (UTC)

Improvements for given name/family name categories/infobox

It might be worth re-doing the infobox for name items:

display native label (P1705)

If it isn't done yet, it should appear on top of the infobox. It's different from English for non-Latin script names.

change the display of said to be the same as (P460)

Reasonator uses the "see also"-statements and language statements on items to display a table of name variants, see https://tools.wmflabs.org/reasonator/?&q=1495413 for Category:Emilia (given name).

Something that is currently missing at Reasonator is that it should include the "native label" statement from these items

sample: Emilia → Эми́лия (Russian), based on d:Q67630193#P1705

display pronunciation

Other statements that might be worth displaying are the one for pronunciation: IPA transcription (P898) (and others), pronunciation audio (P443) (grouped by language qualifier), maybe directly combined with the language of work or name (P407) statements on the item. Not sure about including Soundex (P3878) or similar though.

sample: Emilia → Polish:

index transliteration

some items include some of the many properties for transliterations. Maybe their values could be made available for search.

display nickname (P1449)

could be interesting

sample: Emilia → Mimi

display given name version for other gender (P1560)

with language from qualifier or language statement on value,

sample: Emilia → Emilio (Spanish, Portuguese)

display name day (P1750)

with qualifiers

sample: Emilia → November 14 (Sweden)

remove display "different from"

see discussion #suggestion_to_ignore_disambiguation-related_statements above

additional sitelinks from "different from" values

similar to what is being done for taxons/species, one could use the "different from" statements to include additional sitelinks to disambiguation pages in other wikis. This is something that users at Wikipedias sometimes miss.

sample: Category:Emilia (given name) would link to es:Emilia (desambiguación).

display rankings

d:Q1495413#P5323 could be interesting to be displayed if made in a compact form,

sample: Emilia → #935 on "frequency of first names in the Netherlands, 2010"

As I'm currently not able to contribute to Wikidata, I leave this to you @Mike Peel: Jura1 (talk) 09:27, 11 December 2019 (UTC)

• For the record, "Emilio" is not proper Portuguese: Correct post-1911 orthography is "Emílio". -- Tuválkin ✉ ✇ 04:15, 11 February 2020 (UTC)
  • So both spellings can be found in Portuguese? Jura1 (talk) 09:46, 13 February 2020 (UTC)
    • Good idea @Jura1: . I think different from (P1889) is interresting in different domains. Maybe we can wrap when there is much values. Jérémy-Günther-Heinz Jähnick (talk) 13:28, 13 February 2020 (UTC)

Would you also be interested in displaying Digital Dictionary of Surnames in Germany ID (P6597) as external identifier in the infobox for family names? Julian Jarosch (digicademy) (talk) 14:45, 8 April 2020 (UTC)

This section is resolved and can be archived. If you disagree, replace this template with your comment. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 13:17, 8 December 2021 (UTC)

translations of unknown value

The Category Schloss Bergedorf connected to Schloss Bergedorf (Q2240259) displays inception (P571). There I found out that the wikibase unknown value gets translated with Unknown – at least for German, Latin, Spanish and English. Is there a way to translate those values? CamelCaseNick (talk) 21:41, 11 January 2020 (UTC)

@CamelCaseNick: I don't know, but there must be a way of translating it. @RexxS: does WikidataIB hard-code this, or use an existing translation? Either way, I would recommend asking this at wikidata:Wikidata:Project chat. Thanks. Mike Peel (talk) 22:39, 12 January 2020 (UTC)

@Mike Peel and CamelCaseNick: The value you see is supplied in the current line 898 as val = i18n["Unknown"]. That variable is defined in the internationalisation section (currently lines 30–81) as ["Unknown"] = "Unknown" at line 64. Other languages can directly edit that line (and remember to re-do that when they update to the latest version of the code), or they can create their own Module:WikidataIB/i18n containing all of their localisations. That module will then automatically override the English versions, and will not require further action when updating the main module. --RexxS (talk) 01:20, 13 January 2020 (UTC)

@RexxS: Could that be changed to use the translated versions that Wikidata displays, please? Those seem to be available here via MediaWiki:Wikibase-snakview-variations-somevalue-label. Thanks. Mike Peel (talk) 16:27, 13 January 2020 (UTC)

@Mike Peel: It could be changed, but I see no reason to change "Unknown" to "unknown value". Why would we want Fred Bloggs' infobox to display "Spouse: unknown value" instead of "Spouse: Unknown"? The entries at Wikidata serve a different audience and purpose from those in infoboxes, and we should beware of attempting to impose a "foolish consistency". Cheers --RexxS (talk) 16:58, 13 January 2020 (UTC)

@RexxS: The reason is multilingual support. I agree that just saying 'Unknown' is nicer than 'Unknown value', but in Spanish, 'Valor desconocido' is better than 'Unknown'. Thanks. Mike Peel (talk) 17:10, 13 January 2020 (UTC)

Then all that's needed is a line in es:Module:WikidataIB/i18n: i18n["Unknown"] = "Valor desconocido" and that's what they get on es-wiki. It's not so simple on multilingual wikis, but until we can optimise values on MediaWiki for all our applications, I don't see why we should use their sub-par English descriptions, when we can make use of the i18n mechanisms on 99% of wikis to get the best one for each language. --RexxS (talk) 18:06, 13 January 2020 (UTC)

@RexxS: We're talking about Commons here, which is a multilingual wiki, so the i18n option won't work as it currently stands. Perhaps if there is no i18n value set here, then the default could be to use the (translated) mediawiki text? Thanks. Mike Peel (talk) 11:04, 19 January 2020 (UTC)

Sure Mike, I'd spotted that this is a multilingual wiki, but the content language is set to English, which is what 99% of readers will see (as opposed to editors, who can set language prefs). Anyone could create Module:WikidataIB/i18n here with the line i18n["Unknown"] = {{MediaWiki:Wikibase-snakview-variations-somevalue-label}}, but I still maintain that seeing "unknown value" worsens the experience for 99% of readers, for whom "Unknown" would look better. Nevertheless, feel free to create the sub-module and try it out. Let me know if you run into any problems. --RexxS (talk) 21:21, 19 January 2020 (UTC)

I don’t know what percentage of Commons readers use an interface language other than English, but I suppose more than 1%, as all desktop users are able to do so if they configure their browser properly—for example, my browser’s preferred language is Hungarian, so MediaWiki:AnonymousI18N.js suggests me to use Hungarian interface when browsing logged out (and stores this choice in a cookie and applies it from then on). Commons is a truly multilingual wiki that tries to give anyone the chance to use languages other than English, but it’s possible only if templates and modules are made multilingual. —Tacsipacsi (talk) 23:12, 19 January 2020 (UTC)

This section is resolved and can be archived. If you disagree, replace this template with your comment. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 13:32, 8 December 2021 (UTC)

Multiple date of births in wikidata with the same year.

Hi there! It's not uncommon for a person on wikidata to have two dates of birth listed: one the full date and one just the year of birth. This is the result of the latter being published in more sources than the former. This shouldn't matter for the "xxxx births" category added by the infobox but at the moment at Category:Peter Kwint the category gets omitted. Vera ^(talk) 08:31, 9 February 2020 (UTC)

I think in this case the more accurate date should be given a preferred rank in Wikidata. --ghouston (talk) 06:44, 10 February 2020 (UTC)

This section is resolved and can be archived. If you disagree, replace this template with your comment. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 13:34, 8 December 2021 (UTC)

Sourcing circumstances not displayed

In case of Category:Heisterbacher Straße 210 (Königswinter) and the corresponding Wikidata item wikidata:Q86458053 the sourcing circumstances of the construction time are not displayed. If a building was constructed "circa 1900", it could have also been constructed in 1898 or in 1902. In such cases, "circa" or other sourcing circumstances should certainly be displayed.--Leit (talk) 18:48, 26 February 2020 (UTC)

@Leit: @RexxS: I think this also needs a tweak in WikidataIB somehow. {{wdib|ps=2|P793|qid=Q86458053 | qual=ALL}} -> construction (circa, 1900) - should return "construction (c. 1900)" or "construction (1900, circa)". Thanks. Mike Peel (talk) 10:08, 19 April 2020 (UTC)

@Mike: The problem is that sourcing circumstances (P1480) is actually stored as a qualifier for construction (Q385378), not as a qualifier for the value of point in time (P585) (1900) as it should be. Wikidata doesn't allow qualifiers to have qualifiers.

Normally, when the code finds a property value that has a qualifier of sourcing circumstances (P1480) equal to circa, it applies the 'circa' to the property value even when qualifiers are not requested, so {{wdib|ps=2|P569|qid=Q1817}} → 204 (date of birth of Philip the Arab). Consequently it catches sourcing circumstances (P1480) equal to circa when processing qualifiers and drops it from the qualifiers (because it's applied to the value already), so you never get 'circa' shown as a qualifier value.

In the present case, the code would apply 'circa' to the value 'construction'; except that isn't a date, so isn't processed by Complex date, which is necessarily where the 'circa' is added.

So, either we disable the automatic rendition of 'circa' to simple statements with a date value (not desirable), or we lobby Wikidata to create a property 'date of construction' that can have the value 1900 and a proper qualifier 'sourcing circumstances: circa' which would immediately render as "circa 1900". This is the "birds coming home to roost" for all those examples of misusing significant event (P793) to make pseudo properties that can't have real qualifiers. --RexxS (talk) 16:27, 19 April 2020 (UTC)

@RexxS: Any chance of a check that sees whether the property value is a date, and only drops it from the qualifiers if that was the case? Replacing significant event (P793) is a rabbit hole I'd prefer not to go down... Thanks. Mike Peel (talk) 16:38, 19 April 2020 (UTC)

@Mike Peel: Not without a substantial re-write of the code (and that really is a grade-A mega-rabbit hole you don't want to go down). The circa is dropped from the assembled list of qualifiers at line 1300 and at that point the code has no idea that the value is not a date. Why should it? It is sheer stupidity to apply 'circa' to something that isn't a date.

Let me have a think about it. I might be able to re-purpose a boolean flag that's passed so that it can carry the datatype as well. --RexxS (talk) 17:00, 19 April 2020 (UTC)

@Mike Peel: Meh - it turned out to be trivial. I already had the datatype stored so that I could deal with the language if it was monolingual text. Oh well, just chalk that down to senility:

• {{wdib |ps=1|P569|qid=Q1817}} → c. 204
• {{wdib/sandbox |ps=1|P569|qid=Q1817}} → c. 204
• {{wdib |ps=2|P793|qid=Q86458053 | qual=ALL}} -> construction (circa, 1900)
• {{wdib/sandbox |ps=2|P793|qid=Q86458053 | qual=ALL}} -> construction (circa, 1900)

Philip the Arab stays the same for his birthday, but Heisterbacher Straße 210 (Königswinter) gains the 'circa' qualifier for its significant event. I can't guarantee the order. That will only happen, of course, if the significant event's value isn't a date (which it can't be with the current definition). --RexxS (talk) 18:17, 19 April 2020 (UTC)

@RexxS: That looks good, thanks! @Leit: what do you think? I have a pending update to the infobox that I'll post shortly, I can update WikidataIB at the same time. Thanks. Mike Peel (talk) 18:20, 19 April 2020 (UTC)

@Mike Peel: @RexxS: Thanks for your efforts. Of course I agree with every change that makes circa being displayed. I have to say that I would never have used significant event (P793) for the construction time if inception (P571) did have the ability to define start time (P580) and end time (P582) (point in time (P585) should probably only be used when only one date is known). By the way, I guess it is still impossible to display circa 1900 [start time]–1903 [end time] as construction or any other item related time. On the other hand, for architectural structures significant event (P793) is anyway still necessary for renovation (Q2144402), facadism (Q56603425), roof extensions (Q760072) etc. --Leit (talk) 19:49, 19 April 2020 (UTC)

This section is resolved and can be archived. If you disagree, replace this template with your comment. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 13:36, 8 December 2021 (UTC)

Name of this template?

@Mike Peel: why it the name of this template {{Wikidata Infobox}} and not {{Wikidata infobox}}? I'm quite sure that "infobox" is not a given name so it shouldn't have a capital. I only noticed because of this edit. Multichill (talk) 19:28, 22 April 2020 (UTC)

@Multichill: It's been a few years so I can't remember exactly, but I suspect that I started at Template:Infobox, found it was already in use, so added 'Wikidata' in front of it. I don't think I paid much attention to the capitalisation. It's easier to bot-maintain uses if we don't use redirects, hence the bot tidying, but I'm not sure it's worth the edits to move it to the lower case version now. Thanks. Mike Peel (talk) 19:46, 22 April 2020 (UTC)

We have these wonderful things called redirects for that. No need to resolve these so no edits needed. Can you adjust your bot to no longer do the redirect resolving before we move this template to the correct name? Multichill (talk) 19:53, 22 April 2020 (UTC)

@Multichill: You're trolling me, right? I'd rather not make ~3 million more bot edits because of capitalisation. Mike Peel (talk) 20:29, 22 April 2020 (UTC)

I'm not trolling you. Renaming a template doesn't mean you have to resolve redirects. Those are useless edits (and I recall bots getting blocked for that, but that was probably on Wikipedia). So can you please adjust your bot to not resolve the redirect and not explode when the template gets moved to the correct name? Multichill (talk) 18:12, 23 April 2020 (UTC)

@Multichill: If this is really necessary, then I can try to work through the bot and infobox code changes that would be needed this weekend, but I'd still prefer not to waste my time doing so. I'm not sure that this is the only template that capitalises the second word (e.g., Template:Art Photo), and I'd like to hear from a few other editors before spending time on this. Thanks. Mike Peel (talk) 20:20, 23 April 2020 (UTC)

No, not really, but usually these kind of things just hurt more if you wait longer.

Might get renamed some day in the future or not. We'll see. Not worth wasting time over (this weekend). Multichill (talk) 19:19, 24 April 2020 (UTC)

I'm also not seeing any real value in renaming it at this point. I could point out that most infoboxes follow the format "Infobox xxx", but since we have redirects from both {{Infobox Wikidata}} and {{Infobox wikidata}}, there's simply no point in going through the effort of a rename. — Huntster (t @ c) 19:49, 24 April 2020 (UTC)

This section is resolved and can be archived. If you disagree, replace this template with your comment. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 13:37, 8 December 2021 (UTC)

Performance in ship categories

Editing ship category pages has recently gotten a lot more annoying, and it seems it's due to the Wikidata Infobox template. For example, clicking edit on Category:Atlas Strength (ship, 2006) just took a very long time to come back, and the performance summary says it used 7.096 seconds of CPU time and 7.813 seconds of real time to render. The Lua profile says 3080 ms is in recursiveClone, 1360 ms is in an unknown function, and various other calls like Scribunto_LuaSandboxCallback::getAllExpandedArguments take a smaller but still noticeable amount of time. The Lua time overall is measured at 6.205 seconds (limit of 10), which seems uncomfortably close. If I remove the infobox, then "preview" edits occur very quickly. The IMO category pages seem a bit faster, say about half that amount of time, but are still slow. This can happen on simply viewing a ship category page which hasn't been recently rendered, too. Is there any way to improve that performance? Carl Lindberg (talk) 14:55, 28 April 2020 (UTC)

@Clindberg: The websites have generally been running slowly for the last few days, but they seem to be faster today. Let's see how it goes. Most of the time, it shouldn't be necessary to edit the category pages now, as you can add the info on Wikidata. Thanks. Mike Peel (talk) 18:33, 29 April 2020 (UTC)

@Mike Peel: Nope, don't think it's a general slowness. Remove the infobox template, and the pages render instantly. The one above someone had changed to point to a specific QID which made it much better, maybe half or a third the time (though still not fast), but all the others are very consistent. The same penalty is there simply *viewing* a ship category which hasn't been rendered in a while -- you wait 7-8 seconds for the page to come up. I am also getting occasional database errors when trying to save (even just adding categories) due to timeouts; unsure if that is related or not but might be. Never seen those before. Carl Lindberg (talk) 12:06, 30 April 2020 (UTC)

Yes, there is a definite penalty to having the infoboxes; I've been noticing it wit the spaceflight categories I've been working on. In the case of Atlas Strength, I added the specific QID because it was originally calling a combined three Wikidata items (Q83968658, Q56351075, and Q83649667). When I made it specific to one of them, the time required for the page to load indeed dropped by about half. — Huntster (t @ c) 13:59, 30 April 2020 (UTC)

@RexxS: Any thoughts about this - in particular, can you think of any ways we could speed up the infobox code while still displaying the same information? I'm not sure how to debug the performance here to identify what is taking up the most processing time. Thanks. Mike Peel (talk) 20:40, 30 April 2020 (UTC)

Sorry, Mike it's not something I'm familiar with. Between ArbCom, AE and trying to keep misinformation out of COVID-19 articles, I'm editing up to 16 hours a day, so I just don't have time to take on another investigation right now. Maybe when things get less crazy. --RexxS (talk) 21:08, 30 April 2020 (UTC)

• If it persists (explicit QID rendering much faster than QID from page property), I think it's something WMDE devs should look into. Jura1 (talk) 07:30, 1 May 2020 (UTC)

• Jura1, the method of the call isn't relevant, I gather. The slowdown seems intrinsic to simply calling WikiData objects; it was just especially noticeable in the above example because three separate WD objects were being called all at once. Still something that needs looking into, of course. That the infobox is designed to import irrelevant meta-data for display is another issue entirely. — Huntster (t @ c) 13:33, 1 May 2020 (UTC)
• The ship category infoboxes do seem to render multiple different Wikidata items. By making that render a single Wikidata item, it seems as though the time was reduced correspondingly -- but it still seems to be roughly 2.5 seconds per item, which is still quite slow compared to pages without them. I don't recall this type of penalty with the Wikidata stuff in the past, though it's possible that it was there. Maybe it was a change to the infobox to render all related Wikidata items (which could multiply the items rendered) made it especially noticeable. Or maybe there is some other recent change which is the cause. Carl Lindberg (talk) 15:00, 1 May 2020 (UTC)

I've tweaked {{Wikidata Infobox/sandbox}} to not show information from ship name (Q56351075), which cuts the processing time in Category:Atlas_Strength_(ship,_2006) from 8.1s to 5.3s, compared to 3.4s for the manual QID. Running faster would definitely be good, but the infobox does quite a lot of work, and I'm not sure how to optimise it (any volunteers to look into this?). Using manual QIDs will add to maintenance debt in the long run, so I'd prefer to avoid those as much as possible. I'll continue thinking about it. Thanks. Mike Peel (talk) 20:02, 2 May 2020 (UTC)

This section is resolved and can be archived. If you disagree, replace this template with your comment. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 13:39, 8 December 2021 (UTC)

Errors

There are new errors at Category:Matches of the 2014 FIFA World Cup and Category:Venues of the 2006 FIFA World Cup. Ithought they might be due to {{FIFA World Cups}} but it is due to {{Wikidata Infobox}}. --Jarekt (talk) 14:13, 23 May 2020 (UTC)

I've seen also that (these are NOT new errors, they occurs since days, at least since the addition of subinfoboxes). The Infobox is once again crashing with inefficient and costly loading of data (here because of recursive infoboxes added recently that the author insists to keep even if they are completely unneeded when the subject of the infobox is ALREADY linked at top of the main infobox in the "related subjects": the link is compeltely enough and does not need to be detailed locally, given that it goes to another category that already shows everything). We almost never need these subinfoboxes (except transitionally when one of the "related subjects" has no relevant link to a category or gallery on Commons, so that these subjects are shown as plain text without link: this is only transitional before a relevant category is created in Commons, but for these cases where infobox explodes, this never happens has the complex subinfoboxes are for subjects that should ALL have a target category to link to).

These subinfoboxes areresponsible of the constant and very heavy load of the server now, with time to render all pages now exceeding several seconds, and the memory usage being very near or exceeding the maximum: when the memory is exhausted, or when there has been too many queries to more than 15 entities, we always have an error, and the subinfoboxes or all other template parts further down in the page come to errors: the scripts are even aborted, false categorizations occurs everywhere because the error thrown in Lua is not caught by the Wiki templates).

why can't we just remove these damn'd subinfoboxes that break so many things and were never needed, but were just a personal initiative taken by a single user with an incorrect analysis and no evaluation of the global cost ??? I've ABSOLUTELY NEVER seen any page needing these subinfoboxes!

As well the Wikidata module has severe deficiencies as it collects too much data from the server (e.g. "getEntityObject()" retrieves ALL languages even when they are not needed, we should have "getEntityObjectWithLang(lang)" to remove many labels, aliases, and descriptions; and in fact we never need any alias but only a single label in a relevant language, so getEntityObjectWithLang(lang) should implement language fallbacks on the Wikidata server side, not in the client side on this wiki, and not even in the PHP client, these unneeded data should not reach the local Lua VM, except if a label is explicitly requested for a specific language). And the Wikidata module should use a much more efficient API that use a much more compact JSON format (there are lot of redundancy, this stresses a lot the PHP engine as well as the Lua engine in their respective garbage collectors, and this can explain the huge memory cost and the very huge CPU usage, in addition to the severe performance bugs in Lua's implementation of tables, that do not behave as hashed tables but as unordered arrays with fullscans for lookups; Lua tables are also costly in term of meory allocation: it uses three pointers per node when 2 pointers are clearly enough; and the table size uses exponential growth by an excessive factor of 2, as it is limited to table sizes that are exact powers of 2: to allocate a hash table with just 33 nodes, Lua allocates 64 nodes, each with three 64-bit pointers, i.e. 192 pointers or nearly 1.6KB (some Wikidata entities require more than 800 tables for one entity, i.e. nearly 2MB, and in fact much more if we also include all strings for description texts and aliases as well as all sitelinks on all wikiprojects in all their linguistic editions)! And note that the current JSON interface uses really too many tables and subtables: property values are objects that contain a snak object that contains a datavalue object containing the actual value and internal representation type; and almost all strings returned from JSON are NOT interned at all; a single query requires about 1MB only for the result; and the caches of entities also takes about 5-7MB; each new query requires 2MB, we rapidly explode the 50MB memory limit for running all Lua scripts for rendering a single page!).

Developers of Wikidata, Lua, Mediawiki, Scribunto, and template-admins of this wiki (like you Jarekt because you've blocked many templates without fixing them and using very inefficient algorithms) MUST ABSOLUTELY rework these five parts (which can be done independantly):

• (1.) a new JSON data model (removing excessive duplication of keys inside their associated values such as language codes in objects already mapped by language code; compaction of snaks; removal of unnecessary "type" subfields which cluters all Lua scripts trying to use Wikidata and requires additional table lookups; adding the necessary server API and a new API for the client side, compatible with this newer compact format).
• (2.) fixing Lua's tables (the broken "fast-hashing" function for strings, the broken collision lists (where multiple colision lists collide and merge into a single one, transforming a hash lookup into a very slow full table scan via a single long linked list), removing next points in all collision chains, and changing the allocation strategy (not using the exponential growth!).
• (3.) adding the "getEntityObjectWithLang(lang)" interface to the "mw.wikidata" module (which also includes filters like BestRank, but avoids using separate additional requests to Wikidata); add a way to request only a subset of properties and a subset of qualifiers, not all of them by default, implement a filter on sitelinks (which are not exactly scoped by language but by interwiki code grouping several languages under sometimes different codes). Possibly even allow requesting Wikidata by SPARQL queries, with more customized filters. Note that "Module:WikidataIB" does NOT optimize anything as it depends on "Module:Wikidata" with all its existing deficiencies.
• (4) if Scribunto uses the 64-bit version of Lua, replace it by the 32-bit version: we will never need the 64-bit version before long, at least not before the server allows many instances of Scribunto for visitors where each instance is allowed to use several gigabytes of memory (the current limit is 50MB for rendering a single wiki page, we are EXTREMELY far from this threshold: this can significantly reduce the memory footprint of the many objects used for Lua tables needed to represent Wikidata JSON results by saving about 40% to 50%!)
• (5.) And also independantly the Infobox/core template MUST remove the subinfoboxes (this is now urgent and it is the easiest thing to revert this recent addition that causes severe troubles to this wiki). [And once again I request the removal of unnecessary autocategorization of years by dominical letter from this infobox, it is breaks often and is NEVER needed].

verdy_p (talk) 21:08, 23 May 2020 (UTC)

@Jarekt: I've changed both categories to use {{Wikidata Infobox/sandbox}} for now, and the error is no longer present. I'm still trying to improve the performance of the infobox.

@Verdy p: I think the embedded content about the competitions is useful in these cases (the description of what a match or a venue is was less useful, but it's now removed by excluding items with subclass of (P279) values). I also still think they are useful elsewhere (e.g., in ship name categories). Most of what you are complaining about here is out of scope (no-one here can fix how Lua works, or what Scribunto does). Other points are useful, but the main issue we're encountering here is with CPU time, not memory. The infobox shouldn't use getEntityObject at all - getBestStatements is generally better and more efficient - but there are some calls to it in Module:Wikidata Infobox, I've asked @Jura1: to look into those as he wrote those parts of the code. I have added a call to getEntity and getProperties to fetch a list of all properties in a wikidata item, so that the rest of the code can check against that list, which seems to improve performance a bit (@RexxS: this was what I was thinking about above, I found a way to do it that didn't require WikidataIB changes). I'll keep looking for other improvements that can be made, before deploying a new version next weekend (probably). Your help is appreciated - if you can spot specific performance issues that can be fixed without removing features or making the code harder to maintain, please point them out, and of course you can edit the sandboxes directly if you want. Thanks. Mike Peel (talk) 18:24, 24 May 2020 (UTC)

@Mike Peel: Once you call getEntity, you load the entire Wikidata entity, whether you need all of it or not. It's okay if you're only ever calling it for the associated page as you're looking at the cached version and it's not expensive. You're trading increased memory use for increased speed, so remember that as Wikidata expands, every language will add content in their own language to each entity and the memory required for getEntity will increase with time.

@Verdy p: I don't know where you got the idea that Module:WikidataIB depends on Module:Wikidata. That's pure nonsense, and WikidataIB contains a number of optimisations over the earlier module, although the principal difference is in increased functionality not previously available. --RexxS (talk) 19:07, 24 May 2020 (UTC)

That's not "non-sense": there's an evidence dependency (Module:Wikidata is loaded first, then the PHP interface is hidden and no longer accessible. And I looked at the code of WikidataIB, it really contains a dependance in Module:Wikidata, notably for getEntity which it still needs and is memory intensive)

Lua can be fixed (but separately). Lua 5.4 will come soon that will fix some problems with its incorrect string hashing and will improve the collision lists to avoid worst cases (but this is still a work in progress).

And the JSON model can be improved by Mediawiki developers to be much less verbose (using much less memory). I have already made a test showing that the memory required for a full entity can be largely decreased using 3 times less tables and removing all superfluous redundancy of language codes and value types: this should benefit to the size of full entities kept in the cache, so that we could cache more entities with no more memory cost, and so with less external queries to Wikidata for complex infoboxes. For now the cache is not even sufficient for infoboxes, it uses too much memory for large entities with lot of properties, translated labels, translated descriptions, and translated aliases, and sitelinks (and we never need any alias in infoboxes, and most sitelinks have no use at all, except for a few ones at top of the main infobox for a single entity i.e. the entity linked from the current page only!)

Loading a full entity in all languages should never be needed in infoboxes: the Wikidata API should really add getEntityByLang to purge the unneeded languages (it should then implement the language fallbacks, directly in the PHP code so that the extra data si not even loaded in the Lua VM and not even exposed in the JSON data returned and converted to Lua tables). The conversion of JSON to Lua tables should really compress the current redundancy of types and langauge codes and avoid breaking up each property statement into a separate snak table and datavalue table: these two tables can become just one and we never need the 3 fields "snaktype", "type" and "datatype", only one "type" field is enough for all, the "value" and "datavalue" are superfluous, we can just keep a single"value" field; all the rest is "internal cooking" from the legacy JSON model!).

verdy_p (talk) 08:38, 25 May 2020 (UTC)

@RexxS: Understood. I've started phab:T253485 to see if the process of fetching a list of defined properties can be made simpler. Thanks. Mike Peel (talk) 19:29, 24 May 2020 (UTC)

I will have a look. Essentially, what my part of the code does it checks if the associated item has a p31 of education, etc. by region. If that is so, it looks for the country/region item and loads a series of properties from that. So, at least, it would need to load the category item, the main topic item and the region item. Jura1 (talk) 23:12, 24 May 2020 (UTC)

The sandbox version no longer does all that. Shall I re-add it or what's the plan? Jura1 (talk) 00:28, 26 May 2020 (UTC)

@Jura1: It should all still be there? I removed it briefly to check performance, but added it back. I also wrapped the code in some additional checks, to make sure the corresponding properties were present, and that the infobox isn't in 'embed' mode. If it's not working, then I might have done something wrong - remind me of an example category please? Thanks. Mike Peel (talk) 08:25, 26 May 2020 (UTC)

@Mike Peel: There is one for each: health, education, economy. Jura1 (talk) 18:35, 26 May 2020 (UTC)

@Jura1: I found the problem - it was with the check of which properties exist in the article item, not the category item. Now fixed in the sandbox. Thanks. Mike Peel (talk) 18:56, 26 May 2020 (UTC)

Thanks. It seems to work. Maybe I should try to develop more of these. Jura1 (talk) 20:19, 26 May 2020 (UTC)

This section is resolved and can be archived. If you disagree, replace this template with your comment. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 13:42, 8 December 2021 (UTC)

Present in work

I've noticed that the Wikidata infobox in Category:San Francisco has a section titled "Present in work". This doesn't seem like a useful thing to include in these infoboxes, except for possibly fictional characters or places. Pi.1415926535 (talk) 09:04, 21 June 2020 (UTC)

I have removed all present in work (P1441) values from San Francisco (Q62), as the property is for fictional subjects, and San Francisco is quite real. Unfortunately, Wikidata (and the Wikidata Infobox, to a lesser extent) is often a magnet for trivial data cruft that even if verifiable and true doe not warrant widespread display. If any Wikidata Infoboxes on Commons display P1441 values, it should be restricted to fictional entities, and perhaps a limit imposed to avoid unwieldy laundry lists. --Animalparty (talk) 20:38, 23 June 2020 (UTC)

This section is resolved and can be archived. If you disagree, replace this template with your comment. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 13:43, 8 December 2021 (UTC)

Odd coordinates

This infobox seems to truncate decimal part of degrees to two digits. For instance, d:Q17354801 has coordinates "59.43444444, 24.75722222", while Commons category linked to this item displays coordinates at "59.43, 24.76". The latter is about 500 m off compared to original coordinates on Wikidata. I'd expect decimal part to be at least five digits for a building location. 2001:7D0:81F7:B580:2CCA:E25D:975E:1D39 12:34, 29 June 2020 (UTC)

The problem is the "precision" of coordinate location (P625) here. Replace the coords with a set with no precision and the problem is solved. I have no idea why those bots introduces coords with "precision" which in most cases needs to be replaced in order to not be quite a bit off.--Hjart (talk) 07:46, 1 July 2020 (UTC)

 Done. Thanks Hjart for finding the issue. — Huntster (t @ c) 08:10, 1 July 2020 (UTC)

"To an arcminute" precision for coordinates display on Wikidata indeed was too inaccurate for a building, but map marker on Wikidata regardless was displayed at accurate location, unlike coordinates on Commons that were placed 500 m off. Truncating decimal part of degrees based on this precision still makes little sense to me. I occasionally see misplaced coordinates on Commons due to this. If anything, then this infobox might instead use this precision only for displaying coordinates, without losing accuracy for map marker and coordinates link, as on Wikidata. Though, I think it would be better if Wikidata Infobox ignored Wikidata precision altogether. Wikidata coordinates are often added by bots and bots generally don't choose meaningful precision (depends on object type/size). 2001:7D0:81F7:B580:9C91:DA75:C3C9:51C 08:55, 1 July 2020 (UTC)

This is something that needs to be fixed on Wikidata, as it is a data issue. It could easily affect other users of the data beyond this template. I suggest raising it with the bot operators on Wikidata. Thanks. Mike Peel (talk) 18:17, 1 July 2020 (UTC)

Mike Peel, but what is the purpose of truncating the decimal part on Commons then? Accurate coordinates are/were available on Wikidata, regardless of poorly chosen precision. Note that regardless of "to an arcminute" precision given on Wikidata, this template still displayed seconds as well, except that for a different location (at truncated coordinates value). How bots handle prcision on Wikidata seems to be a separate issue. 2001:7D0:81F7:B580:FCAC:CB4D:6BA9:C14E 07:24, 2 July 2020 (UTC)

I suspect that wikidata could be reporting truncated data to the template. In that case Mike really can't do much. I guess the best we can do is fix the bots (I'm not a coder myself so can unfortunately only hope that someone with the right set of talent will do it) and reimport millions of bad coord sets.--Hjart (talk) 13:12, 3 July 2020 (UTC)

Not really, raw data from Wikidata are latitude, longitude and precision value (those you see e.g. in diff view). Then on Commons latitude and longitude value get manipulated based on precision value, i.e. accurate coordinates are rounded into inaccurate coordinates (see "decimalPrecision" function in Module:WikidataIB). 2001:7D0:81F7:B580:5C72:7C3D:20C1:7732 14:15, 4 July 2020 (UTC)

That sort of rounding seems to be due to misinterpretating precision. Selecting different precisions on Wikidata easily demonstrates it only sets if location of the very same spot is displayed using degrees or degrees and minutes or degrees and minutes and seconds. While on Commons the higher the precision value, the more coordinates potentially get shifted. 2001:7D0:81F7:B580:5C72:7C3D:20C1:7732 14:46, 4 July 2020 (UTC)

Not just Commons is affected by this. Just a few minutes ago I was asked to fix the position in en:Zinn House. Problem here too was the "precision" in wikidata. this makes me wonder where the rounding really happens --Hjart (talk) 22:41, 5 July 2020 (UTC)

This case on en.wikipedia appears to be unrelated to precision since latitude and longitude value were (also) wrong (Wikidata diff, coordinates entered in Wikipedia still are wrong) and en:Module:Mapframe ignores precision. 2001:7D0:81F7:B580:994B:48AF:1542:1353 13:15, 6 July 2020 (UTC)

Hah. The guy told me he had checked his coords, so I didn't bother checking them as well and just replaced the wikidata version. --Hjart (talk) 15:38, 6 July 2020 (UTC)

I tested this a little on another page, where coordinates are currently about 270 m off due to rounding. Generally coordinates and map look fine if "decimalPrecision" is omitted in Module:WikidataIB. Omitting this also affects coordinates' display (decimal part of seconds is added on given page, which is fine). On some pages the latter may be a little downside of ignoring precision, but I think this matters a little compared to wrong coordinates on other pages. It seems that this template doesn't make good use of precision for coordinates' display either anyway (e.g. despite d:Q183 having ±1° (to degrees) precision set, Category:Germany still displays minutes and seconds as well). Ideally precision could be taken into account only for coordinates' display, the way it works on Wikidata, without messing up latitude and longitude values that are used for external links and for map marker placement, but it seems that current code doesn't allow separating these uses easily here. 2001:7D0:81F7:B580:201C:8A2B:C985:E03 20:00, 6 July 2020 (UTC)

Not sure if it is related, but coors at Category:Moria from WD item are misinterpreted. User map script wikidata:User:Aude/MapView.js at WD is able to interpret the same coors correctly. Jklamo (talk) 09:23, 10 September 2020 (UTC)

I proposed a fix below: Module talk:WikidataIB#Drop coordinates rounding. 2001:7D0:81DA:F780:E9D6:D1E1:24D2:AF21 16:58, 24 September 2021 (UTC)

This section is resolved and can be archived. If you disagree, replace this template with your comment. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 13:44, 8 December 2021 (UTC)

Suggestion to support for in an external property novalue

Example Category:Ragnar_Ling-Vannerus we have KulturNav-ID (P1248) no value telling that we have no value but that we would like to see that this museum database creates an authority for that person.

Suggested function instead of a link add a text as missing value - Salgo60 (talk) 08:09, 31 July 2020 (UTC)

• Oppose. If there is no value, it's better to display nothing at all rather than empty links or true but uninformative statements. I don't think passively stating "no value" or "missing value" on Commons is the best way to inspire some museum curator to update their internal database. We shouldn't clog infoboxes with unhelpful links or commentary just to flag the attention of 1 hypothetical person. From a practical standpoint it's almost as useless as adding/displaying "no value" to death dates of all living people. --Animalparty (talk) 19:32, 7 August 2020 (UTC)
• @Salgo60: I agree with @Animalparty here, it's not useful to have an authority ID that is "no value". I don't think that such values are normally accepted on Wikidata, they seem to be reported as constraint violations at d:Wikidata:Database_reports/Constraint_violations/P1248#"Format"_violations. Thanks. Mike Peel (talk) 20:33, 7 August 2020 (UTC)
• @Mike Peel and Animalparty: Comment thanks for the feedback its a minor thing but in this case with KulturNav-ID (P1248) they lack a lot of identifiers for people and has opened up that you can suggest that an identifier is created IF this object also is part of the VIAF dataset --> you suggest and then it takes some days and they approve it.... a slow process but I feel they are faster now so maybe its now a non issue - Salgo60 (talk) 01:14, 8 August 2020 (UTC)

This section was archived on a request by: Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 13:46, 8 December 2021 (UTC)

Using HTTPS for the PetScan link

From what it appears, the {{Wikidata Infobox}} template can generate a link to the PetScan tool. In the {{Wikidata Infobox/core}} template, there is an HTTP URL for the PetScan tool. Testing a number of PetScan links from infoboxes seems to indicate that HTTP PetScan links generate an HTTP 301 redirect (indicating that the resource has been permanently moved) to an HTTPS URL.

It would seem that having the {{Wikidata Infobox}} template use HTTPS when generating a PetScan link could reduce the number of HTTP redirects and also could provide increased privacy and security for users. Thoughts? --Gazebo (talk) 08:30, 27 December 2020 (UTC)

@Gazebo: Good spot, I've changed it in {{Wikidata Infobox/sandbox}} for testing. Thanks. Mike Peel (talk) 18:07, 29 December 2020 (UTC)

The {{Wikidata Infobox/core}} and {{Wikidata Infobox/core/sandbox}} templates bring to mind a possibly subtle copyright issue. Firstly, I am not accusing others of knowingly violating copyrights. It should be possible to copy content from the {{Wikidata Infobox/core}} template to the {{Wikidata Infobox/core/sandbox}} template and vice versa. From what I understand, a lot of the textual content on Wikimedia Commons is licensed under the Creative Commons Attribution-ShareAlike 3.0 Unported License. In addition, this license has requirements for reusing licensed content that include attribution and identifying the license. In the Wikimedia Foundation Terms of Use, section 7b talks about providing attribution when reusing content on the Wikimedia projects. The question comes up as to how many times has content been copied from the {{Wikidata Infobox/core}} template to the {{Wikidata Infobox/core/sandbox}} template and was the copying done in compliance with any copyrights? If content was copied from the {{Wikidata Infobox/core}} template to the {{Wikidata Infobox/core/sandbox}} template in a way that did not comply with copyright, does that mean that {{Wikidata Infobox/core/sandbox}} is an unauthorized derivative work that cannot be worked with? I may have considered adjusting the {{Wikidata Infobox/core/sandbox}} template to use HTTPS for the PetScan link but I am concerned about working with the {{Wikidata Infobox/core/sandbox}} template due to the previously mentioned copyright concerns...Sometimes, it is hard to know when something is or is not a concern when it comes to copyrights... :( --Gazebo (talk) 10:30, 30 December 2020 (UTC)

This section was archived on a request by: Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 13:51, 8 December 2021 (UTC)

Errors 2021 Jan

Category:Taco Bell shows errors and I can not figure why. Same with Category:Waalse kerk and Category:Nesyt (pond). --Jarekt (talk) 03:37, 3 January 2021 (UTC)

Moin Moin Jarekt, I've fixed it for Taco Bell. In Wikidata country (P17) and country of origin (P495) where set. But you need only one of them. Regards --Crazy1880 (talk) 10:04, 3 January 2021 (UTC)

Crazy1880, thank you for figuring this out. Fixing Wikidata is important but having country (P17) and country of origin (P495) set should not create Lua errors here. @Mike Peel: Is that an issue with {{Wikidata Infobox}} or with Module:WikidataIB and we should seek help from User:RexxS? --Jarekt (talk) 17:53, 3 January 2021 (UTC)

@Jarekt and Crazy1880: The problem is simply that Walloon church (Q2244918) has its instance of (P31) set to "no value". Somebody over at Wikidata thinks that a Walloon Church isn't an instance of anything, and emphatically not a church building (Q16970). Similarly Nesyt (Q12040774) (a pond in South Moravia) isn't an instance of anything either, not even a artificial pond (Q3253281). It's this sort of nonsense that leads to avoidable errors. Nevertheless, if we want to skip the idiocy of a type of church not being an instance of a church, etc., then the code in Module:WikidataIB needs line 1571 amending to:

local instid = v.mainsnak.datavalue and v.mainsnak.datavalue.value.id

I don't have the permissions to fix it myself. --RexxS (talk) 18:46, 3 January 2021 (UTC)

RexxS, I did not realize you did not have edit permissions for your own code here. I elevated you to "template editor". I also modified the line you suggested. Thanks for looking into it. Yes there is a lot of nonsense data properties on Wikidata. My Artwork template deals with a lot of them too. --Jarekt (talk) 19:27, 3 January 2021 (UTC)

@Jarekt: thank you – I hope I won't have to use the permission too often, but it's useful when we need a rapid fix. The Wikidata problem arises because there will always be Wikidatans who insist on maintaining a strict distinction between instance of (P31) and subclass of (P279), which may often be technically correct, but is sometimes a distinction without a real difference. Once the page cache is purged, Category:Waalse kerk and Category:Nesyt (pond) don't show errors any more. Cheers --RexxS (talk) 20:26, 3 January 2021 (UTC)

This section was archived on a request by: Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 13:54, 8 December 2021 (UTC)

Yet another request for property

Please consider to add conscription number (P4856). May be beneficial for 6000+ categories.Jklamo (talk) 18:53, 16 February 2021 (UTC)

@Jklamo: Added to {{Wikidata Infobox/sandbox}}, please test. Thanks. Mike Peel (talk) 13:21, 25 April 2021 (UTC)

This section was archived on a request by: Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 14:22, 8 December 2021 (UTC)

Need min-width

{{Editprotected}} As one can see in Category:Complex_Numbers (musical_group): 2032, without min-width left column of infobox may become too small, exploding the height of this template. Please, add min-width: 70px; in Template:Wikidata_Infobox/styles.css in .taxontree-lcell, .wikidatainfobox-lcell section. --Lockal (talk) 16:05, 19 March 2021 (UTC)

@Lockal: It's set up in {{Wikidata Infobox/sandbox}}, but with 60 since 70 was a bit too wide. How is that? Thanks. Mike Peel (talk) 13:11, 25 April 2021 (UTC)

This section was archived on a request by: Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 15:11, 8 December 2021 (UTC)

Wishlist

• Link to create a new Wikidata item is English-only, is there a translated text that could be used instead? Mike Peel (talk) 20:55, 9 February 2018 (UTC)
• What's the best zoom level to use for the map? How should it depend on the type of object that the category is about? Mike Peel (talk) 21:15, 9 February 2018 (UTC)
• How to handle long strings for IDs, e.g., Category:Monumento Pedro Álvares Cabral (Parque do Ibirapuera). Mike Peel (talk) 23:19, 13 February 2018 (UTC)
  • Is not a good solution to shorten (xxx...) names longer than x signs (keeping - or not, last word entirely)? Whole names could be visible as a tooltip. --Jasc PL (talk) 17:13, 15 April 2018 (UTC)
  • Could we have the Title in the smaller font size, but in bold - as in the Wikipedia infoboxes? This way we will have more place for long titles and better look. --Jasc PL (talk) 22:08, 18 April 2018 (UTC)
• If we really need the Authority control in Commons - OK, but must it be always visible with our tools also? Why not to keeping it hidden by default, having the only [linked WD icon] [Authority control title] [Show/Hide swith] on one bar, or - clickable [Authority control title] as a show/hide switch? --Jasc PL (talk) 22:08, 18 April 2018 (UTC)
• Could we add a link to Crotos for artworks? (see http://zone47.com/crotos/). Sadads (talk) 13:28, 23 May 2018 (UTC)
• Auto-categorisation should handle multiple possible dates, e.g. at Category:Mary Somerville. Mike Peel (talk) 23:36, 1 June 2018 (UTC)
• A field for "Former name" with qualifiers: "Start time", "end time" and "named after".-- Darwin ^Ahoy! 23:37, 20 June 2018 (UTC)
• Check BC birth categories, e.g. Category:Galba. Mike Peel (talk) 17:53, 24 July 2019 (UTC)
• Danmarks Kirker (edited by Nationalmuseet, Denmarks National Museum, in print versions as a long time project, started in 1919). Note, mostly there is an entrance page such as http://danmarkskirker.natmus.dk/vejle/oester-nykirke/ that can be linked, from where one or more PDFs can be downloaded. Only in a few cases (or only with tricks), direct links to the PDF can be detected, such as http://danmarkskirker.natmus.dk/uploads/tx_tcchurchsearch/Holbaek_3345-3416.pdf --Ulamm (talk) 08:36, 8 October 2019 (UTC)

This section is resolved and can be archived. If you disagree, replace this template with your comment. Yann (talk) 23:23, 18 December 2021 (UTC)

location: country missing

At Category:Acaray Dam the only visible location info is "Acaray River", set by located in/on physical feature (P706). The item Acaray Dam (Q3433454) also provides "Paraguay" for country (P17). I expect the country to be displayed in the infobox. Is the missing country bit in this case related to changes discussed at #Improvement to "location" field with hierarchical information perhaps? --Te750iv (talk) 12:25, 10 November 2018 (UTC)

@Te750iv: I've added located in the administrative territorial entity (P131) to the Wikidata item, which is what is used to show the location string. Ideally I guess P706 should be shown at the start as well, if @RexxS: wants to look into that. Thanks. Mike Peel (talk) 12:45, 10 November 2018 (UTC)

@Mike Peel: This is what the location function can return:

• {{#invoke: WikidataIB |location |qid=Q3433454 |first=y |skip=n}} → Acaray Dam, Hernandarias District, Alto Paraná Department, Paraguay
• {{#invoke: WikidataIB |location |qid=Q3433454 |first=y |skip=y}} → Acaray Dam, Paraguay

I can't understand what you want me to do. The function repeatedly looks first for located in the administrative territorial entity (P131), next for location (P276), then for located in/on physical feature (P706), following the first one that exists at each step. I'm not sure I can offer a sensible alternative algorithm. The reason why nothing else was showing before is that Acaray River (Q4672121) has no link to any of those three possible higher level geographical entities. We don't look for country (P17) because it's often found at very low level entities and would short-circuit the location chain. --RexxS (talk) 13:38, 10 November 2018 (UTC)

Aah, I assumed there was more location info in Acaray River (Q4672121) that wasn't being picked up, sorry RexxS! Thanks. Mike Peel (talk) 13:45, 10 November 2018 (UTC)

Actually, having thought about it for a bit, would it be preferable to look for country (P17) as fourth choice? so that if none of the three usual upwards links in the chain exist, we could at least get the country (which would then terminate the chain). The disadvantage is that we would lose the ability to spot broken chains and fix them on Wikidata. What do folks think? --RexxS (talk) 23:10, 10 November 2018 (UTC)

This section is resolved and can be archived. If you disagree, replace this template with your comment. Yann (talk) 23:23, 18 December 2021 (UTC)

Replacing P969 by P6375

The property P969 (located at street address (DEPRECATED)) is deprecated and is to substituted by the property P6375 (located at street address). Main cause is the change of the property type from string to multilingual text. --RolandUnger (talk) 09:31, 20 January 2019 (UTC)

At the moment the usage street address (P6375) is 597 and usage of P969 (P969) is 849,422 and there is no even proposed migration plan, so it is a bit premature to reflect this in template.--Jklamo (talk) 11:57, 20 January 2019 (UTC)

@RolandUnger and Jklamo: Is this being discussed somewhere? (was there a property proposal for it?) Thanks. Mike Peel (talk) 13:14, 20 January 2019 (UTC)

I am afraid all we have (850,000 usage, 50+ templates in various languages) is this Wikidata:Wikidata:Properties_for_deletion#located_at_street_address_(DEPRECATED)_(P969).--Jklamo (talk) 18:03, 20 January 2019 (UTC)

@RolandUnger and Jklamo: OK, thanks for the background. {{Wikidata Infobox/sandbox}} should now support both properties depending on what's available. Please test that to make sure it's working OK, I'll probably make it live this weekend. Once the migration's complete I can tidy it up to just use the new property. Thanks. Mike Peel (talk) 21:52, 22 January 2019 (UTC)

Please have a look at Category:Redemptoristenkloster Bonn. Why is located on street (P669) (not P969 (P969)) supposed to be deprecated?--Leit (talk) 21:48, 21 January 2019 (UTC)

@Leit: That's because the P969 (P969) label was being used for the label for the line, but the line combines the different address properties. I've updated the label to street address (P6375) now, so the deprecated label should stop showing. Thanks. Mike Peel (talk) 21:45, 22 January 2019 (UTC)

The discussion to delete the property P969 (P969) and to migrate it to a new monolingual property can be found in the archives. We know that we have to migrate about 800.000 items which will take time. The change was discussed several times in the past because in several countries addresses are (sometimes only regionally) used/accepted in several languages. But I think the migration can be done by a bot copying the property data and taking the language property from P407 or from P37. Meanwhile we analyze at the German Wikivoyage both properties favoring street address (P6375).

We are also comparing the given languages with the wiki language by analyzing writing system and direction to select an optimal variant. For instance, in case of Egypt we are giving the English address (at the German Wikivoyage) for readability and the Arabic one in parenthesis to show it to the inhabitants. At least in Cairo both addresses are shown at the street signs. --RolandUnger (talk) 05:55, 23 January 2019 (UTC)

This section is resolved and can be archived. If you disagree, replace this template with your comment. Yann (talk) 23:24, 18 December 2021 (UTC)

Uncertain dates and overly specific locations

I have some comments/requests regarding the less-than-ideal format that some dates are displayed. First, see Category:Lawrence S. Harris: there are redundant reminders of what "circa" means (c. 1873 (circa)). Personally, I think linking to circa is pointless as a mere dictionary definition (we should not assume all readers are children who have never seen the word "circa" before, abbreviated or not)." Approximate dates should be rendered simply as "c. 1873" or "circa 1873". Second, see Category:Fred W. Wright: the year of death is uncertain (should read as after 1933), yet the infobox awkwardly displays "1933 (1933)" (the corresponding creator template correctly displays "after 1933").

The last falls into the category of "technically true but missing the point" category: see Category:William Ely Hill. When birth or death locations are displayed as hospitals, addresses, or sub-city locales, this flies in the face of standard biographical conventions (I mean elsewhere in the real world, not the Wiki universe). This same observation applies to the death location in {{Creator}} templates. A refined creator template should indicate nationality, life span, and major locations with respect to the creator's work and life (e.g. city of birth/death, cities/countries where work was produced), being no more specific than necessary. The building in which one was born or died is of negligible to zero value for determining provenance, copyright, or gleaning much other realistically useful information beyond trivia. If it's possible to "round up" to display the city (or at least the smallest administrative entity encompassing a building), that'd be nice. Alternatively, if it's possible to customize/override the infobox locally to substitute the city in place of hospital, that'd be nice too. I don't like the prospect of every decision on 2 million+ infoboxes being forced by Wikidata alone: issues like aesthetics, relevance, and common sense involve more than mere data. --Animalparty (talk) 02:04, 14 February 2019 (UTC)

The problem with the circa dates is that Wikidata uses a qualifier to designate circa, and although the code can read that and convert it to a compact abbreviation, it then repeats it again if we ask for |quals=ALL.

For Lawrence Harris (Q61711437), date of birth (P569):

• {{#invoke:WikidataIB |getValue |ps=1 |P569 |qid=Q61711437}} → c. 1873
• {{#invoke:WikidataIB |getValue |ps=1 |P569 |qid=Q61711437 |qual=ALL}} → c. 1873

I've amended the sandbox to suppress a qualifier value of "circa" in favour of the abbreviated form:

• {{#invoke:WikidataIB/sandbox |getValue |ps=1 |P569 |qid=Q61711437}} → c. 1873
• {{#invoke:WikidataIB/sandbox |getValue |ps=1 |P569 |qid=Q61711437 |qual=ALL}} → c. 1873

That should fix the problem at Category:Lawrence S. Harris and similar when the main module is next updated from the sandbox.

We already handle qualifier latest date (P1326), so it shouldn't be difficult to also handle earliest date (P1319) as well.

For Fred W. Wright (Q61714940), date of death (P570):

• {{#invoke:WikidataIB/sandbox |getValue |ps=1 |P570 |qid=Q61714940}} → 20th century
• {{#invoke:WikidataIB/sandbox |getValue |ps=1 |P570 |qid=Q61714940 |qual=ALL}} → 20th century (after 1933)

The problem at Category:Fred W. Wright needs more work, as there are other cases where both earliest and latest dates are present (Julius Caesar (Q1048) date of birth (P569)), as well as cases where the latest date (P1326) qualifies something that's not a date (France (Q142), highest point (P610)).

Being "no more specific than necessary" is quite difficult to write programmatically, but I'll think about it. Perhaps we can examine the instance of (P31) for the place of birth (P19) and place of death (P20) and if it's not some sort of geographical location, then use its location (P276) or located in the administrative territorial entity (P131) if it has either. It may take a while to figure out all the possible types of geographical location, so I'll return to this when I've made some progress. --RexxS (talk) 00:38, 24 February 2019 (UTC)

This section is resolved and can be archived. If you disagree, replace this template with your comment. Yann (talk) 23:25, 18 December 2021 (UTC)

Maps of

Hello. With MisterSynergy's MsynBot's recent work, there now are about 13,000 Wikidata items using P3722 (P3722). I'm not exactly sure how everything works but I guess this template here can probably backtrack those uses and use that to generate content in categories such as Category:Maps of Široki Brijeg, where there is none for the moment (even if Široki Brijeg (Q391729) has a P3722 (P3722) statement pointing to this categry). Give this some thoughts. Maybe we could display something? Like a map-oriented version of what already shows up in Category:Široki Brijeg for instance? We may use route map (P15), locator map image (P242) and the likes to display stuff there. Thierry Caro (talk) 00:31, 4 March 2019 (UTC)

@Thierry Caro and MisterSynergy: This means that Široki Brijeg (Q391729) now has P3722 (P3722)=Category:Maps of Široki Brijeg - however, that category does not have a sitelink on Wikidata, which means that there's no way for the infobox to get from Category:Maps of Široki Brijeg to Široki Brijeg (Q391729). Another case is England (Q21), where P3722 (P3722)=Category:Maps of England, and that category does have a sitelink to Category:Maps of England (Q8607358), but that item does not then link to Q21 in any way. Perhaps I'm misunderstanding things here (@RexxS: any comments?), but linking to Commons using a 'string' datatype seems to be completely useless, you need to use an 'item' format as the topic's main category (P910)/category's main topic (P301) pair does. Thanks. Mike Peel (talk) 00:11, 5 March 2019 (UTC)

OK. You did a great job explaining the problem. We are not going to have a lot of Maps of categories with dedicated Wikidata items, which means not much can happen eventually. Thierry Caro (talk) 01:09, 5 March 2019 (UTC)

@Thierry Caro: Technically, it's quite straightforward to go through all of the categories that P3722 (P3722) links to, and to bot-create new Wikidata items for those categories (where they don't exist already), while adding something like category's main topic (P301) to link them to the main item. It's a community issue, not a technical one. Thanks. Mike Peel (talk) 01:34, 5 March 2019 (UTC)

This section is resolved and can be archived. If you disagree, replace this template with your comment. Yann (talk) 23:26, 18 December 2021 (UTC)

LIBRIS is moving LIBRIS-URI

SELIBR ID (P906) is going to be depreciated and instead we have Libris-URI (P5587) please update - Salgo60 (talk) 18:30, 30 May 2019 (UTC)

This section is resolved and can be archived. If you disagree, replace this template with your comment. Yann (talk) 23:26, 18 December 2021 (UTC)

P996 as alternative image location

Module:Artwork uses document file on Wikimedia Commons (P996) as an alternative to image (P18). Maybe {{Wikidata Infobox}} do the same. Also if there is title page number (P4714) qualifier used than it should be used as well. For example: [[File:{{#property:P996|from=Q19669696}}|thumb|page=9]] gives image on the right. I was trying to look up the page number (9) through {{#invoke:WikidataIB |getQualifierValue |qid=Q19669696 |1=P996 | pval={{#property:P996|from=Q19669696}} |qual=P4714}} but did not get it to work: "". --Jarekt (talk) 12:54, 24 June 2019 (UTC)

• On its last column, there is also a sample use for P4714 on d:Wikidata:Lists/Decameron editions and translations. --Jura1 (talk) 14:51, 24 June 2019 (UTC)

This section is resolved and can be archived. If you disagree, replace this template with your comment. Yann (talk) 23:31, 18 December 2021 (UTC)

Normalize areas?

Is there a chance areas in the infobox map could be normalized? See for example Category:Samsølabyrinten vs Category:Lysbro Skov vs Category:Enø --Hjart (talk) 18:39, 29 June 2019 (UTC)

This section is resolved and can be archived. If you disagree, replace this template with your comment. Yann (talk) 23:31, 18 December 2021 (UTC)

sort spouses chronologically

Currently, when a person has multiple spouses in Wikidata, it appears they are listed here by order of entry in Wikidata (see e.g. Category:Elizabeth Taylor or Category: Jo Davidson). Where dates are given, can the infobox be changed to more intuitively display them chronologically? Also, in my opinion, rounding off to year of marriage would be sufficient and preferable to exact date, which tends to make the infobox overly crowded. --Animalparty (talk) 22:50, 14 July 2019 (UTC)

@RexxS: How difficult would this change to the ordering be to implement in Module:WikidataIB? It would be a useful modification to make, since the entries aren't necessarily stored on Wikidata in date order. Reformatting dates would be a lower priority though. Thanks. Mike Peel (talk) 18:32, 17 July 2019 (UTC)

@Mike Peel: There already exists a parameter |qsorted= which should sort qualifiers when set to true, but unfortunately it only does an alphanumeric sort at present. That doesn't actually help this case anyway, as there are only single values of each date qualifier, and I don't have a means at present of sorting property values by their qualifier values. Sorting dates is a pain unless I do a large re-write to also return the timestamp, use it to sort the dates and then discard it, especially as the calls to complex date will return all manner of character sets when internationalisation takes place.

The other part would be to create the ability to truncate dates to a year independently for qualifiers, which ought to be relatively easy if we add yet another parameter like qualifierdateformat (alias qdf), which can be set to "y" when needed, because the code to handle all of that is already in the module.

I've sandboxed that to try it, and set the default qualifier format to 'year'. That may have unforeseen consequences elsewhere, so we'll need to think about whether to leave the default at dmy and just use |qdf=y when needed. Anyway, for now, Elizabeth Taylor (Q34851), spouse (P26):

• {{#invoke:WikidataIB/sandbox |getValue |ps=1 |lp=: |P26 |qid=Q34851 |qual=DATES}} → Conrad Hilton, Jr. (1950–1951), Michael Wilding (1952–1957), Mike Todd (1957–1958), Eddie Fisher (1959–1964), Richard Burton (1964–1974), Richard Burton (1975–1976), John Warner (1976–1982), Larry Fortensky (1991–1996)
• {{#invoke:WikidataIB/sandbox |getValue |ps=1 |lp=: |P26 |qid=Q34851 |qual=DATES |qdf=dmy}} → Conrad Hilton, Jr. (6 May 1950 – 29 January 1951), Michael Wilding (21 February 1952 – 30 January 1957), Mike Todd (2 February 1957 – 22 March 1958), Eddie Fisher (12 May 1959 – 5 March 1964), Richard Burton (15 March 1964 – 26 June 1974), Richard Burton (10 October 1975 – 29 July 1976), John Warner (4 December 1976 – 7 November 1982), Larry Fortensky (6 October 1991 – 31 October 1996)
• {{#invoke:WikidataIB/sandbox |getValue |ps=1 |lp=: |P26 |qid=Q34851 |qual=DATES |qdf=mdy}} → Conrad Hilton, Jr. (May 6, 1950 – January 29, 1951), Michael Wilding (February 21, 1952 – January 30, 1957), Mike Todd (February 2, 1957 – March 22, 1958), Eddie Fisher (May 12, 1959 – March 5, 1964), Richard Burton (March 15, 1964 – June 26, 1974), Richard Burton (October 10, 1975 – July 29, 1976), John Warner (December 4, 1976 – November 7, 1982), Larry Fortensky (October 6, 1991 – October 31, 1996)

We may need to put sorting on the back-burner and come back to it while I do the research; perhaps I can find some time at the Wikimania hackathon to sort it out. --RexxS (talk) 00:11, 18 July 2019 (UTC)

This section is resolved and can be archived. If you disagree, replace this template with your comment. Yann (talk) 23:32, 18 December 2021 (UTC)

Display P1559?

I have a suggestion, let the box display name in native language (P1559) if it's available. It may help users using non-Latin and non-Cyrillic scripts a lot. (I am Chinese but I use English interface.)--Roy17 (talk) 17:04, 6 August 2019 (UTC)

@Roy17: It's in the sandbox, please give it a go. Thanks. Mike Peel (talk) 16:32, 21 August 2019 (UTC)

@Mike Peel: thx a lot! I just tried previewing Category:Alan Li Tung Sing and Vladimir Vysotsky using different UI languages. I'm sorry to say, it doesnt look very good. The change is gonna add a row name in native lang and a line below date of birth? The row looks bad for languages that have a long name label for P1559, because for example in English the width of the box makes the four-word phrase break into three rows, resulting in a tall row. IMHO the additional line beneath DoB is good enough.

Unless, the infobox is widened a bit. It seems to be way too narrow in its current form. Long entries often break into lines of one to three words. See Vysotsky for example. The property label column and the entries column are equal in width. The Spouse entry is broken into lines of single words. So I'd suggest a wider infobox, and the ratio of property label column to entries column should be 2:3, 1:2, or 1:3. Examples from frwp and yuewp.--Roy17 (talk) 17:07, 21 August 2019 (UTC)

@Roy17: I don't want to widen the infobox as that leaves less space for the media in the category, which is the main content of Commons. A tall infobox isn't too much of a problem here, though, particularly if there are lots of media files. It looks like @Laddo: added the line below the date of birth without me noticing - but I don't like that solution as it implies that name in native language (P1559) is the name at birth, which is often wrong. So I've removed that, and kept it as a separate row for now, let's see how that goes. Thanks. Mike Peel (talk) 17:24, 21 August 2019 (UTC)

Sorry Mike I should have mentioned that test here. Indeed name in native language (P1559) is not related to birth :S Thanks - Laddo (talk) 21:46, 21 August 2019 (UTC)

@Mike Peel: well, keeping it as a row and removing the line under DoB are good. Check Vysotsky or Category:Rachel Weisz for the infobox. It currently takes up more than one but less than two media files' width. A little bit wider would not leave less space.--Roy17 (talk) 17:42, 21 August 2019 (UTC)

I assume it depends on users' screen resolution too... I'm using a browser in full screen and my screen is 1366 X 768. The infobox takes up roughly 1.2 columns.--Roy17 (talk) 17:45, 21 August 2019 (UTC)

Two suggestions:

• Checking sandbox output on Benyamin Netanyahu, I suggest to use |qual=NONE to avoid displaying pointlessly the associated language;
• Also "Name in native language" is quite long and not that useful, since the value is pretty self-explanatory; that name could be centered across the infobox, just like the English name (in bold) gets centered at the top.

Laddo (talk) 22:24, 21 August 2019 (UTC)

I had thought about Laddo's suggestion, to put the native name beneath the title, but then it would look rather strange to Latin users (the largest group here) when they look at any entities with a Latin native name (again the largest group). They just show up as two identical or very similar lines. But I support a label either way, in a row entry or as a line beneath the title.

It would also be quite beneficial if title (P1476) or native label (P1705) is displayed for books, music albums, movies, etc. For example, a Chinese-literate user would immediately understand what the long pinyin name Category:Chong sheng hai cao di si ji wei ti sheng wu qun ji qi di zhi yi yi actually means. The same applies to Japanese, Korean, all the languages on the Indian subcontinent, etc.--Roy17 (talk) 14:24, 25 August 2019 (UTC)

This section is resolved and can be archived. If you disagree, replace this template with your comment. Yann (talk) 23:32, 18 December 2021 (UTC)

Display P54 - member of sports team

Moin Moin Mike Peel, for the sports area it would be totally helpful if we could display P54. I'll put the external identifiers in the sandbox. Then I'd need a second opinion. Regards --Crazy1880 (talk) 17:33, 22 August 2019 (UTC)

@Crazy1880: P54 is now in the sandbox for testing [11]. Thanks. Mike Peel (talk) 17:49, 24 August 2019 (UTC)

Moin Moin @Mike Peel: , can it be that only the current club is displayed? Each club is usually marked with "Start date" and "End date". And what I personally also don't like so much is the arrangement of "games played" and "goals scored", which are in brackets directly after the "start date". What could we do? Regards --Crazy1880 (talk) 19:14, 24 August 2019 (UTC)

This section is resolved and can be archived. If you disagree, replace this template with your comment. Yann (talk) 23:33, 18 December 2021 (UTC)

Stadium location

Hello! I would like to draw the attention of Wikimedia administrators one inaccuracy in the template for stadiums on the Wikimedia Commons. In the LOCATION field, instead of the current 2019 administrative-territorial structure of the country outdated information from the year of construction of the sports facility is indicated.

It turns out such nonsense: Category:Dynama Stadium, Minsk built in 1934, but instead of a location in the country BELARUS, in the Wikidata Infobox description indicates the states that existed in the 1930s on the territory of modern BELARUS — Lithuanian–Belorussian Soviet Socialist Republic, Byelorussian Soviet Socialist Republic. And it should be: LOCATION - MINSK, BELARUS.

Same thing with Category:Central Stadium, Gomel. The stadium was built in the 1920s, but Gomel Povet and Mogilyov Viceroyalty no longer exists. And it should be: LOCATION - GOMEL, GOMEL DISTRICT, GOMEL REGION, BELARUS.

By administrative-territorial structure of the Republic of BELARUS for 2019 all cities is part of the district, then the region, then the country. The capital city of Minsk is a separate administrative unit within BELARUS.

In this regard, I ask administrators to make the necessary changes to the Wikidata Infobox on the Wikimedia Commons for stadiums so that outdated information does not mislead readers. Is it possible to make changes to this template so that the location of the stadium is displayed as of today, and not at the time of construction?

Thanks for attention! --Football Beetle (talk) 20:23, 22 August 2019 (UTC)

@Football Beetle: The data displayed in the infobox is from Wikidata, you need to change things there. For your first example, I think @Tacsipacsi: already fixed it with [12]. For the second example, it was necessary to say which is the preferred value of located in the administrative territorial entity (P131) so that the historical one was not accidentally selected, see [13]. These are a bit complex to debug, sorry, as you have to follow the location tree from the Wikidata item. Thanks. Mike Peel (talk) 07:03, 23 August 2019 (UTC)

Thanks for the answer! Regarding the location of stadiums in Minsk, I’ll try to invite administrators of the Belarusian Wikipedia to make changes to Wikidata. --Football Beetle (talk) 10:28, 23 August 2019 (UTC)

@Football Beetle: My (above-linked) edit was on the Wikidata item of Minsk itself, so all places in the city should look OK. By the way, such edits require no administrator access, any autoconfirmed user can edit this item (you’re autoconfirmed as well; this right—as its name suggests—is automatically assigned by the software). You can ask for help from more experienced users if you have difficulties, but they don’t need to be administrators to be able to help.
@Mike Peel: This issue may need module change indeed. It’s fairly common to not have located in the administrative territorial entity (P131) for entities of administrative level just below country, which was the case at Minsk until now. It was complicated with the fact that this was not true in Soviet times, but all P131 statements were (are) properly qualified with start time (P580)/end time (P582). It may be worth checking them, and using only statements that are currently applicable (i.e. have no P582 qualifier, or, in rare cases, that’s in the future). —Tacsipacsi (talk) 21:54, 23 August 2019 (UTC)

@Tacsipacsi: Thanks for the answer! In the future, I will take into account the comments that you have indicated. But it would be great if information on the location of all the stadiums of the world was displayed on the Wikimedia Commons at the current moment, and not in the past tense. --Football Beetle (talk) 09:20, 24 August 2019 (UTC)

@Tacsipacsi and Football Beetle: It's best to just fix this on Wikidata if you can. An alternative might be to sort property values by date qualifiers and to only select the most recent, but as @RexxS: explained above at #sort spouses chronologically, that's rather tricky. Thanks. Mike Peel (talk) 17:46, 24 August 2019 (UTC)

@Mike Peel: I don’t know exactly how the module works, but I can imagine simply discarding statements with given qualifiers is much easier than returning the qualifier along with the statement. As I mentioned, this issue is fairly common on Wikidata (I didn’t make any measures, but come across such cases from time to time), so it’s worth dealing with. —Tacsipacsi (talk) 22:53, 24 August 2019 (UTC)

This section is resolved and can be archived. If you disagree, replace this template with your comment. Yann (talk) 23:34, 18 December 2021 (UTC)

Displayed Wikidata QIDs not linked

It seems that for a place of birth (and probably all item values), which doesn't have a label in the user language or English, the Wikidata identifier gets displayed like this: "Q2006937". I don't think that's particularly useful considering en:WP:Readers first, anyway … but it isn't even linked! It should at least be something like "Q2006937". Thanks for any changes to this! Cheers, (pings appreciated) --Marsupium (talk) 18:27, 5 September 2019 (UTC)

@Marsupium: Can you point to some examples, please? Thanks. Mike Peel (talk) 18:15, 13 September 2019 (UTC)

Mike Peel, you can use queries like this one to find probably concerned category pages (here those where the value of place of burial (P119) has the problem), e.g. on Category:Peter Steiner. Thanks for any changes to this situation! --Marsupium (talk) 23:02, 13 September 2019 (UTC)

This section is resolved and can be archived. If you disagree, replace this template with your comment. Yann (talk) 23:41, 18 December 2021 (UTC)

parameter defaultsort

Is it ok to change the line

| defaultsort = y

to

| defaultsort = y

? Some users might be too lazy to type and copypaste the allcaps version.--Roy17 (talk) 14:10, 13 September 2019 (UTC)

@Roy17: I'd rather not, if that's OK. The parameter is only really meant to be used temporarily (and added via bot edit), until someone can check why the conflict exists and resolves it by removing the local definition or tweaking the information on Wikidata. Also, I'm not sure if the MediaWiki software has a problem with the capital letter version, as it isn't showing up above. Thanks. Mike Peel (talk) 18:13, 13 September 2019 (UTC)

thx a lot! You're right. I shouldnt be too lazy. However, users may often want to specify defaultsort for Chinese people who dont have their common names in pinyin. For example, a person with the name 吳華 would have a surname item Wu and a given name Hua (in pinyin, the standard romanisation scheme), so sorted by Wu, Hua, but if he's a Hong Kong Cantonese and were to be sorted by his common name, it could be Ng, Wah. I'm not sure whether this can be fixed on wikidata side.--Roy17 (talk) 18:26, 13 September 2019 (UTC)

This section is resolved and can be archived. If you disagree, replace this template with your comment. Yann (talk) 23:41, 18 December 2021 (UTC)

Location in Scotland issues

P1813 short name, icons

For example, Category:Blantyre, South Lanarkshire gives location: South Lanarkshire, 🏴󠁧󠁢󠁳󠁣󠁴󠁿, but it should give South Lanarkshire, Scotland, United Kingdom.

South Lanarkshire (Q209142) has P131=Scotland, and Scotland (Q22) has P131=United Kingdom. Obviously, short name (P1813)=🏴󠁧󠁢󠁳󠁣󠁴󠁿 is used instead, see also [14].

For comparison, England (Q21) has the same constellation afaics, but infoboxes for locations in England don't have the same problem. Could someone help please? --Te750iv (talk) 21:12, 22 September 2019 (UTC)

@Te750iv: I see it as "South Lanarkshire, Blantyre, United Kingdom", where "Blantyre" is because Blantyre (Q881708) and Blantyre (Q68815005) seem to be different things. I think 'Scotland' is automatically skipped when assembling the location string, but I'm not sure - @RexxS: can you have a look? I have reverted the icon as short name addition, though, which might help. Thanks. Mike Peel (talk) 13:26, 28 September 2019 (UTC)

There are multiple problems, Mike. First, Blantyre (Q881708) is located in the administrative territorial entity (P131) of both Blantyre (Q68815005) and South Lanarkshire (Q209142), which is ridiculous over specification – it might as well be in the administrative territorial entity of Scotland and of the UK (both having role of country) in that case. It is not helpful to state location A is in both location B and location C, when location B is in location C already. In this case, the code will skip the second 'Blantyre' as a duplicate name, so it won't cause issues.

The next problem is that the parish is stated as being in both South Lanarkshire (Q209142) (true) and in Lanarkshire (Q530296) (untrue for the last 44 years). I've made the former the preferred value to alleviate that.

The last problem is that Template:Wikidata Infobox/core is switching to using {{Wikidata location}} in this case, rather than #invoke:WikidataIB|location for reasons that aren't obvious to me. We know that {{Wikidata location}} can be flakey, and it doesn't work well when Wikidata is over-complicated. Compare:

{{#invoke:WikidataIB |location |Q881708}} → South Lanarkshire, Scotland

{{Wikidata location | qid=Q881708}} → South Lanarkshire, United Kingdom

To pick up on your other point, the code in WikidataIB|location terminates the chain when it encounters a country (Q6256) (or constituent country of the United Kingdom (Q3336843) if |skip =true). However, according to Wikidata, Scotland (Q22) is both a constituent country of the United Kingdom (Q3336843) and a country (Q6256), while England (Q21) is a constituent country of the United Kingdom (Q3336843), but not a country (Q6256). Garbage in, garbage out:

• {{#invoke:WikidataIB |location |first=true |Q881708}} → Blantyre, South Lanarkshire, Scotland
• {{#invoke:WikidataIB |location |Q881708 |first=true |skip=true}} → Blantyre, Scotland
• {{#invoke:WikidataIB |location |Q1684337 |first=true}} → Tipton, Sandwell, West Midlands, England
• {{#invoke:WikidataIB |location |Q1684337 |first=true |skip=true}} → Tipton, England

I've removed some more icons pretending to be short name (P1813), but no doubt they will be back, polluting the data. --RexxS (talk) 14:55, 28 September 2019 (UTC)

@RexxS: Thanks! I'd forgotten that we were falling back to {{Wikidata location}} where there are multiple located in the administrative territorial entity (P131) values. It would be good to get rid of that at some point, but I think that needs some more of the special cases integrating into the Lua code first. Thanks. Mike Peel (talk) 15:01, 28 September 2019 (UTC)

@Mike Peel: you'll have to remind me what are the special cases you want integrating into the Lua code, as my poor dinosaur brain can't remember. --RexxS (talk) 15:58, 28 September 2019 (UTC)

@RexxS: Neither can mine! Looking at line 259 of Template:Wikidata Infobox/core, I think the main thing is being able to cope with multiple values of located in the administrative territorial entity (P131) and location (P276) in the connected item. So in the case of Blantyre (Q881708), perhaps the ideal thing to do is to follow both chains and print them out, either on separate lines or by following them until they reach a common point and then joining them together somehow. There were some cases where that does make sense (windmills on one site that spans multiple regions comes to memory). All that {{Wikidata location}} does is dump out all values of located in/on physical feature (P706), location (P276) and located in the administrative territorial entity (P131), plus country (P17) with a fallback to continent (P30) in Antarctica. Thanks. Mike Peel (talk) 16:10, 28 September 2019 (UTC)

Thanks for solving the issue. --Te750iv (talk) 00:39, 29 September 2019 (UTC)
Only noticed after Jheald's post below: I reported the example Blantyre (Q881708) on 22 September 2019. The item was changed afterwards, so Mike Peel saw a different location chain on 28 September (without the 🏴󠁧󠁢󠁳󠁣󠁴󠁿 short name, which was given instead of Scotland before). I don't know therefore, if the original issue (usage of P1813) really is solved. --Te750iv (talk) 08:58, 6 October 2019 (UTC)

P131, civil parishes

• @Te750iv, Mike Peel, and RexxS: Just to reopen this: in the last week or so, I have started work with User:Tagishsimon to add values of Scottish civil parish (Q5124673) (Scottish parish) into the location chains.

Because the parish boundaries were frozen in 1930 when they ceased to have an administrative role, parishes sometimes now split over more than one modern council area (partial list at Category:Civil_parishes_in_multiple_council_areas_of_Scotland, full list at https://w.wiki/9H6), so we have been giving both the civil parish and the modern council area in the located in the administrative territorial entity (P131) statement, qualified with object of statement has role (P3831) = Scottish civil parish (Q5124673) and local authority (Q837766) respectively. See eg Kiltarlity (Q2790381) for an example, as well as most listed buildings in Scotland.

In turn, the parish items (eg Q6881584) also typically have two P131 statements, qualified object of statement has role (P3831) = local authority (Q837766) for the modern council areas, and shire of Scotland (Q1350181) for the traditional counties respectively.

Ideally the order returned should probably be (locality), parish, historic county, modern council area -- unless the modern council area (eg South Ayrshire) includes the name of the historic county, in which case it may make sense to put it first; or if the two have the same name, in which case it probably makes sense to keep the modern council area and suppress the historic county.

Would this seem sensible/doable ? Jheald (talk) 10:08, 3 October 2019 (UTC)

@Jheald: I don't know if this would be doable. In general, I think, outdated "historic" location values should not be displayed in infobox location chains. Otherwise, we would have too much confusion worldwide (see e.g. more complex cases of old Soviet Union administrative units, or various past administrative changes in Germany including old GDR districts). --Te750iv (talk) 08:58, 6 October 2019 (UTC)

@Te750iv: Thanks, Te750iv. Civil parishes in Scotland are an odd case. On the one hand, they lost their decision-making powers in 1930, and were formally abolished in 1975. But on the other hand, they were never systematically replaced with anything at that scale. So a lot of land records, historical buildings records, etc, still record the civil parish (even for new records), according to the final 1930s boundaries. Because they are well-defined territories over time, census summaries and aggregates are also systematically calculated and made available for them. Finally, because (especially in rural areas), their boundaries still typically are very similar to Church of Scotland boundaries, there is still significant local identification with them, and eg local societies may be structured on a parish bases. So I don't think the parallel with old Soviet administrative units is exact.

The key argument here, I think, is the lack of any unit as readily available at the same scale. The formal units now, the Scottish council areas, are very big. It's really helpful to be able to indicate units that are at a more local scale than that, eg for grouping together listed buildings (important for Wiki Loves Monuments). We systematically have pages on en-wiki for listed-builidings-by-civil-parish for Scotland. We also have categories here for about 80% of them. So IMO it is useful to be able to give a link from an infobox here to a civil parish, that people can then browse down from to find other buildings and settlements in the vicinity.

The case for the traditional counties is more balanced; but again, they existed for hundreds of years, and there is still very strong identification with them from local people. Significantly in rural areas they again tend to be singnificantly smaller than council areas, so identifying places as being in eg "Caithness" or "Dumfriesshire" or "Selkirkshire" is a useful level of identification, beyond "Highland" or "Dumfries and Galloway" or "Scottish Borders". Why, I suppose, may be part of why they have continued to persist in people's minds locally.

So I do think this is quite useful information to be able to give in the infobox. But if there is a better way to model it, that could be adjusted.

The situation at present is that this is in the P131s, so is being presented; but often rather out-of-order in the sequence. Jheald (talk) 09:22, 6 October 2019 (UTC)

This section is resolved and can be archived. If you disagree, replace this template with your comment. Yann (talk) 23:42, 18 December 2021 (UTC)

Display code/encoding for numbers

I added code (P3295) and encoding (P3294) in the sandbox. It's currently visible at Category:987_(number).

Is there a predefined way to switch display to the following:

• have the first cell display the encoding (a qualifier on Wikidata)
• the second cell the code (the value that has that qualifier).
• Then do a new line for the next statement (different encoding).

The current label "Code" wouldn't be needed. Jura1 (talk) 16:15, 28 September 2019 (UTC)

That's not currently possible, but perhaps @RexxS: could magic something up. Thanks. Mike Peel (talk) 16:22, 28 September 2019 (UTC)

The simplest would be:

• {{wdib |ps=2 |qid=Q258492 |P3295 |qual=P3294 |list=ubl}} →
  • ⁹⁸⁷ (Unicode superscript number)
  • 3DB (hexadecimal in 0-9A-F notation)
  • ๙๘๗ (Thai numeral)
  • ৯৮৭ (Bengali–Assamese numeral)
  • CMLXXXVII (Roman numeral in basic notation)
  • 1111011011 (binary in 0/1 notation)
  • ९८७ (Devanagari numeral)
  • ૯૮૭ (Gujarati numeral)
  • ௯௱௮௰௭ (Tamil number notation using ௰, ௱, ௲)
  • ௯௮௭ (Tamil number notation using ASCII 0)
  • − − − − · − − − · · − − · · · (Morse code in · −  notation)
  • ៩៨៧ (Khmer numbers)
  • ೯೮೭ (Kannada numerals)
  • ໙໘໗ (Lao numerals)

Otherwise, I can kludge table cells using the separators and prefix/suffixes using {{wdib |ps=2 |qid=Q258492 |P3295 |qual=P3294 |sep="&nbsp;</td></tr>" |prefix="<tr><td>" |postfix="</td><td>"}}:

⁹⁸⁷	(Unicode superscript number)
3DB	(hexadecimal in 0-9A-F notation)
๙๘๗	(Thai numeral)
৯৮৭	(Bengali–Assamese numeral)
CMLXXXVII	(Roman numeral in basic notation)
1111011011	(binary in 0/1 notation)
९८७	(Devanagari numeral)
૯૮૭	(Gujarati numeral)
௯௱௮௰௭	(Tamil number notation using ௰, ௱, ௲)
௯௮௭	(Tamil number notation using ASCII 0)
− − − − · − − − · · − − · · ·	(Morse code in · −  notation)
៩៨៧	(Khmer numbers)
೯೮೭	(Kannada numerals)
໙໘໗	(Lao numerals)

But that would need more kludging in the template to enclose them inside the current table cells. --RexxS (talk) 18:04, 28 September 2019 (UTC)

• Cool. Thanks. Looks good. I don't really mind having the values first. I added the last one to the sandbox (visible at Category:987_(number)). Is there a way to have the encoding value link (WD or locally)? Jura1 (talk) 18:29, 28 September 2019 (UTC)
• @Mike Peel: would you mind copying it from the sandbox to the "real" template? Jura1 (talk) 20:18, 30 September 2019 (UTC)
  • @Jura1 and RexxS: I think this needs some more work before it's ready for deployment. In particular, the columns need to be swapped, and brackets should be removed. Thanks. Mike Peel (talk) 05:12, 1 October 2019 (UTC)
    • I see. If the current approach isn't convincing, maybe a solution could be to re-add the "code"-column and place the reminder in the second cell. Jura1 (talk) 06:29, 1 October 2019 (UTC)
• @Mike Peel:  Done Jura1 (talk) 15:36, 1 October 2019 (UTC)
  • @Jura1: Interesting! I've merged the code into Module:Wikidata Infobox/sandbox and made some formatting changes. Most notably, the infobox doesn't link to Wikidata as a rule, it only links within Commons. How does that look now? If it's OK, I'll make it live shortly. Thanks. Mike Peel (talk) 18:17, 1 October 2019 (UTC)
    • Thanks. Ok for me. Personally, I'd have opted for a smaller font-size in the first cell. I also increased the font-size for the second cell. BTW Category:8_(number) has the test version as well. Jura1 (talk) 19:21, 1 October 2019 (UTC)

• @Mike Peel: I did some more tweaks to it, do you think it's ready to go live? I was hoping to include d:Wikidata:Property proposal/code (image), but that part might take a bit more time. Jura1 (talk) 08:39, 8 October 2019 (UTC)
  • @Jura1: Sorry to have taken a while to come back to this. The remaining issue is the text sizes - it would be better to have them uniform so that they match the rest of the infobox, rather than having some smaller and some larger. If you're OK with that, then I'll look again at making this live. Thanks. Mike Peel (talk) 18:55, 11 October 2019 (UTC)
    • @Mike Peel: np, I'd rather not, but feel free to do so, as it's licensed CC BY-SA 3.0. Jura1 (talk) 20:44, 11 October 2019 (UTC)
      • @Jura1: Could you explain why you'd rather not? Thanks. Mike Peel (talk) 20:46, 11 October 2019 (UTC)
    • @Mike Peel: most labels of encodings are relatively long and the code itself is usually just a few characters, possibly not that readable if the numeral isn't an Arabic numeral.Jura1 (talk) 21:03, 11 October 2019 (UTC)
      • On my computer, it doesn't look good - the label text is too small, while the content is too large. Perhaps it displays differently on different computers. There are also accessibility issues with having small text in a box that already has reduced font size. So I'll change it back to the standard text size for the next release, and we can revisit this again in the future. Thanks. Mike Peel (talk) 13:54, 18 October 2019 (UTC)
        • Np. Maybe my browser is borked. Jura1 (talk) 15:09, 18 October 2019 (UTC)
    • @Mike Peel: code (image) (P7415) is active now too. Would you update the live versions? Jura1 (talk) 12:14, 14 October 2019 (UTC)
      • @Jura1: It's now live, thanks for your work and patience. Thanks. Mike Peel (talk) 11:06, 19 October 2019 (UTC)

This section is resolved and can be archived. If you disagree, replace this template with your comment. Yann (talk) 23:42, 18 December 2021 (UTC)

Hiero name

name in hiero markup (P7383) can be used to add hieroglyphs in hiero syntax. I added support for that in the sandbox.

Samples at Category:Anubis and Category:Thutmosis III.

The first one looks fine. I'm not quite sure how to improve the second one. Jura1 (talk) 12:11, 8 October 2019 (UTC)

Maybe it should be collapsed if the source string exceeds a defined length. Jura1 (talk) 12:13, 8 October 2019 (UTC)

• Seems to work now. Jura1 (talk) 11:21, 11 October 2019 (UTC)
  • @Jura1: It looks OK, but it would look better if it were centre-aligned. I attempted to do this, but there seems to be a lot of nested HTML code (particularly tables) that I don't fully understand... Thanks. Mike Peel (talk) 14:16, 18 October 2019 (UTC)
    • I tried to fix it, but didn't really succeed. Jura1 (talk) 15:08, 18 October 2019 (UTC)

This section is resolved and can be archived. If you disagree, replace this template with your comment. Yann (talk) 23:43, 18 December 2021 (UTC)

suggestion to ignore disambiguation-related statements

For infoboxes, please ignore different from (P1889) if criterion used (P1013) is used with descriptive page and disambiguation page have to be in different items (Q24005632). Such statements are usually of no use here, and they take much space (example). --Te750iv (talk) 01:47, 25 October 2019 (UTC)

 Support For my sake the display of different from (P1889) could be dropped completely. --Marsupium (talk) 12:43, 25 October 2019 (UTC)

 Support. We don't need to see so much of the guts of Wikidiata, i.e. criteria used in distinguishing items. It may be relevant on Wikidata, but it's just noise on Commons. Especially pointless are the "different from" statements on surname categories, e.g. McNeil (surname) or Hodges (surname), and even when the disambiguation has a actually a functional Commons link (e.g. Johnson (surname), I see little use in the link, because unlike Wikidata items, Commons categories and galleries cannot have the same name, and so we disambiguate by parenthetical terms or other means. --Animalparty (talk) 16:47, 25 October 2019 (UTC)

It's probably useful at, e.g., Category:London, Ontario, so I don't want to get rid of it completely, but I wonder if it's best to not show it for unlinked statements. @RexxS: Is that something that would be easy to do? (i.e., if there isn't a link for a value, ignore it). Thanks. Mike Peel (talk) 17:21, 25 October 2019 (UTC)

@Mike Peel: Another example: see Category:London (surname) where a disambiguation actually is linked via such a statement. I would prefer it being ignored; your suggestion would keep it (because it's linked).

I think P1889 statements – linked, or not (or not yet; categories might be created in the future) – can be useful sometimes. But those disambiguation-related ones (some more criteria here) are dispensable in any case. --Te750iv (talk) 18:52, 25 October 2019 (UTC)

@Mike Peel: It would need a fairly big re-write to provide the ability to return nothing when a sitelink doesn't exist. Currently when a sitelink doesn't exist, the code in WikidataIB looks for a local page with the same name and creates a linked item if it is a redirect. Otherwise it looks for a label in the local/target language and returns that unlinked. That behaviour is required for most items most of the time, and we would probably break a lot of uses if we didn't return the label.

If we must process different from (P1889) at all, then surely the way to suppress it on some articles is to use a |spf=different from parameter in the article, as I've just done at Category:Houses of culture? --RexxS (talk) 19:36, 26 October 2019 (UTC)

• One could check for a few values in P31 (e.g. family name, given name) and not display it when present. Jura1 (talk) 07:17, 5 November 2019 (UTC)

This section is resolved and can be archived. If you disagree, replace this template with your comment. Yann (talk) 23:44, 18 December 2021 (UTC)

Bridges and tunnels

For bridges and tunnels, displaying both next crossing upstream (P2673) and next crossing downstream (P2674) would be useful. @Mike Peel: Can you do that? That would be nice. Thierry Caro (talk) 20:02, 18 November 2019 (UTC)

@Thierry Caro: It's now in the sandbox, please test {{Wikidata Infobox/sandbox}} in a relevant category. Thanks. Mike Peel (talk) 19:48, 14 December 2019 (UTC)

@Mike Peel: It works perfectly fine. I would display this right under carries (P2505) though. Thierry Caro (talk) 12:25, 24 December 2019 (UTC)

This section is resolved and can be archived. If you disagree, replace this template with your comment. Yann (talk) 23:44, 18 December 2021 (UTC)

rounding of coordinates

I have noticed that the infobox takes the coordinates from Wikidata, then rounds them to D.dddd°, which is fine by me. However, it then reports those coordinates as D°M′S.ss″. An example is Category:Camp Fire (2018) which shows 39° 48′ 37.08″ N, 121° 26′ 13.92″ W (which works out to 39.8103, -121.4372) even though Wikidata item Q58416875 has 39°48′37″N 121°26′14″W. Either the infobox should just report the 39.8103, -121.4372, that it is really using, or it could round the D°M′S.ss″ back to D°M′S″. Abductive (talk) 19:10, 23 November 2019 (UTC)

Notice the "precision" value. If you don't want the coordinates rounded, remove the "precision" by unmarking the checkbox. --Hjart (talk) 19:20, 23 November 2019 (UTC)

It is unchecked, on Wikidata, if that is what you are referring to. In any case, this should be fixed so that it does not require intervention on every item, or by every user who wants to improve the Commons. Abductive (talk) 05:01, 24 November 2019 (UTC)

This section is resolved and can be archived. If you disagree, replace this template with your comment. Yann (talk) 23:45, 18 December 2021 (UTC)

Error message: "Does not match [..] pattern"

https://commons.wikimedia.org/w/index.php?search=%22does+not+match%22&title=Special%3ASearch&go=Seite&ns0=1&ns6=1&ns9=1&ns12=1&ns14=1&ns100=1&ns106=1 --Arnd (talk) 22:18, 7 December 2019 (UTC)

This section is resolved and can be archived. If you disagree, replace this template with your comment. Yann (talk) 23:45, 18 December 2021 (UTC)

URNs?

If there is interest, there is a way to include urns based on statements on Wikidata items/properties, e.g.

• urn:uuid:c69592c2-9b6b-48ee-b9a4-65591da9d0f6 for Category:Annika_Strandhäll based on d:Q4980750#P3479. This is a UUID-URN.
• urn:lsid:biodiversity.org.au:afd.taxon:36752d3b-1d5f-4517-812b-cd52c81f8785 for Category:Aleeta curvicosta. This is a LSID-URN.

One concept can have different URNs. These are meant to be persistent. Unless one has some special extension installed, they are not URLs.

URNs could be displayed on the category or merely made available for text search or Special:LinkSearch/urn:*. Jura1 (talk) 11:31, 11 December 2019 (UTC)

This section is resolved and can be archived. If you disagree, replace this template with your comment. Yann (talk) 23:46, 18 December 2021 (UTC)

Link to sdcquery

In addition to Reasonator/PetScan/Scholia/Statistics, eventually (once it updates regularly), it would be interesting to include a link to Query Server for Commons.

I'm not entirely sure about the query to use. The item of the category should probably be either a value or a qualifier value. Jura1 (talk) 07:06, 13 December 2019 (UTC)

This section is resolved and can be archived. If you disagree, replace this template with your comment. Yann (talk) 23:49, 18 December 2021 (UTC)

How sort key for DEFAULTSORT is created?

In particular for persons. An info on Commons:Wikidata infobox help would be nice. Also what categories are automatically added? Based on what properties? --jdx ^Re: 14:58, 24 December 2019 (UTC)

This section is resolved and can be archived. If you disagree, replace this template with your comment. Yann (talk) 23:49, 18 December 2021 (UTC)

Odd Wikidata additions

WD Infobox occasionally adds WD properties as floating text: see Category:Romeo (character) which improperly displays manner and cause cause of death (suicide and poison, respectively), and Category:Mrs. Brooks (née Watson), which improperly displays "unknown", presumably due to the unknown value listed in Given name (P735). --Animalparty (talk) 06:05, 26 December 2019 (UTC)

@Animalparty: The infobox definitely shouldn't be doing that. For the first case, I've reworked the 'death' section so thatt it includes manner and cause of death within separate rows, {{Wikidata Infobox/sandbox}} seems to work OK now. For the latter, that's coming in through the sort key code, so that's more difficult to fix - @RexxS: perhaps another option is needed to be able to suppress 'unknown' from being returned? Or we could just remove the 'unknown' value from the Wikidata item... Thanks. Mike Peel (talk) 08:29, 26 December 2019 (UTC)

@Mike Peel: The code currently returns this for Mrs. Brooks (Q79727976), given name (P735):

• {{wdib|ps=1|qid=Q79727976|P735}} → unknown value

but note:

• {{#property:P735 | from=Q79727976 }} → some value

You will need to check the logic in the template to work out why the value 'unknown' appears outside of the infobox.

If we don't know a given name (and we know that we don't know the given name), then it seems reasonable to me that an infobox should state "Given name: Unknown", which is why I coded it that way. However, you're using P735 to create a category, so that is less relevant. You can deal with that in the template logic: look at this bit of the template:

• forename -->{{#if:{{#property:P735 | from={{#invoke:WikidataIB |getQid |qid={{{qid|}}} }}}} | {{#invoke:WikidataIB |getValue |rank=best |P735 |qid={{#invoke:WikidataIB |getQid |qid={{{qid|}}} }} | name=forename | |fwd={{{fwd|ALL}}} |osd={{{osd|no}}} |noicon=yes | linked=n | spf={{{spf|}}} | prefix="[""[Category:" |postfix=" (given name)]]" | lang=en | sep=" "}} | [[Category:Uses of Wikidata Infobox with no given name]]}}<!--

You could add a test for a value equal to "Some value without a Wikidata item" and then also set the category 'Uses of Wikidata Infobox with no given name'.

Optionally, and more simply, I could suppress returning "Unknown" for unknown values inside WikidataIB by default. For more flexibility, I could implement a parameter to set the value returned for unknown, |unknown=, and use |unknown=nil to suppress it. Please let me know what you prefer. Cheers --RexxS (talk) 19:41, 26 December 2019 (UTC)

This section is resolved and can be archived. If you disagree, replace this template with your comment. Yann (talk) 23:51, 18 December 2021 (UTC)

NO WIKIDATA ID FOUND!

This message keeps on displaying on the Category:Lego-Brücke_Dahler_Straße, although it has been properly sitelinked from the corresponding Wikidata item: Lego Bridge 2.0 (Q109978360). Any clue what I'm doing wrong, or is it a bug? -- H005 18:29, 7 December 2021 (UTC)

I refreshed the page and it worked! MSGJ (talk) 20:41, 7 December 2021 (UTC)

Hmm, thanks! I have tried F5, Ctrl+F5, Shift+F5, Ctrl+Shift+F5, ... nothing works. Using MS Edge. But you are correct, when opening the page in Chrome it works. Strange. I am using Edge for a year and never had a problem with refreshing. -- H005 07:51, 8 December 2021 (UTC)

EDIT: It appears that this is not a refresh problem. I was not logged in on Chrome. As soon as I log in there, I have the same problem as with Edge. When I log out on Edge, I also see the Infobox. I have this problem only with this item/page, all other pages I try work well.

Any clues? -- H005 10:15, 8 December 2021 (UTC)

Moin Moin MSGJ, you can "purge" the site in two ways. First is you go in edit mode an change the URL in the end to "&action=purge" or second you go in the Gadgets and there is an option for purge at every site. Regards --Crazy1880 (talk) 11:41, 8 December 2021 (UTC) @User:H005 --Crazy1880 (talk) 11:45, 8 December 2021 (UTC)

Now it works also when I am logged in, so that is resolved. However, I do not understand the previous comment. I would like to understand the exact cause/solution so that I can add it to Commons:Wikidata infobox help for future reference. -- H005 13:53, 8 December 2021 (UTC)

Moin User:H005, from time to time a page does not refresh correctly, then it helps once to help with a refresh. Don't know why. Regards --Crazy1880 (talk) 18:31, 8 December 2021 (UTC)

Ich sehe gerade, ich kann dir ja auch auf deutsch antworten ;) mfg --Crazy1880 (talk) 18:33, 8 December 2021 (UTC)

Yes you can, but I prefer if other people also understand me ... :) As said before, this is not related to a refresh, because on Chrome, which I never used before on that page, the problem occurred as soon as I logged in, but not before. -- H005 21:53, 8 December 2021 (UTC)

Moin User:H005, but you open Commons with Chrome before, right? In the settings of Chrome you can make a button, that everytime when you close Chrome, all Cache an Cookies will be deleted. And you have a button for advanced deleting of history. Did you tried that already? And what does another browser say? I checked now IE, Edge, FireFox, Chrome and Opera on two different systems. I everytime get the Infobox. Regards --Crazy1880 (talk) 17:11, 9 December 2021 (UTC)

This section was archived on a request by: Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 16:54, 20 December 2021 (UTC)

What does the |title= parameter do?

{{Wikidata Infobox}} passes |title={{{title|}}} to {{Wikidata Infobox/core}}:

Template:Wikidata Infobox

<!-- Core code is at Template:Wikidata Infobox/core Modify the styling at Template:Wikidata Infobox/styles.css -->{{Wikidata Infobox/core <!-- Configuration pass-through and/or defaults --> | qid = {{#invoke:WikidataIB |getQid |qid={{{qid|}}} }} | defaultsort = {{{defaultsort|y}}} | interwiki = {{{interwiki|yes}}} | spf = {{{suppressfields|{{{spf|}}} }}} | fwd = {{{fetchwikidata|{{{fwd|ALL}}} }}} | osd = no | autocat = {{{autocat|yes}}} | trackingcats = {{{trackingcats|yes}}} | noicon = yes | conf_upload = yes <!-- Show the upload link --> | conf_sitelinks = yes <!-- Show the sitelinks --> | conf_authoritycontrol = yes <!-- Show the authority control section --> | conf_helperlinks = yes <!-- Show the helper links at the end --> | conf_coordtemplate = 1 <!-- 0 = none, 1 = Geohack, 2 = Coord --> | conf_imagesize = 230x500px | conf_mapwidth = 250 | conf_mapheight = 250 }}{{#invoke:Interwiki from P460|InterwikiP1420}}<!-- check for manual qid --><includeonly>{{#if:{{{qid|}}} | [[Category:Uses of Wikidata Infobox with manual qid]] | {{#ifeq:{{NAMESPACE}}|Category|{{#if:{{#property:P373}}|<!-- Commons category is already set-->|{{#if:{{#invoke:Wikidata|pageId}}|[[Category:Uses of Wikidata Infobox missing Commons Category statement]]| <!-- No connected Wikidata item so don't add the tracker-->}} }} }} }}</includeonly><!-- --><noinclude>{{Documentation}}</noinclude>

That said, I can’t find any documentation for, or usage of, {{{title|...}}} in {{Wikidata Infobox/core}}, so I’m wondering what it’s used for (it was introduced in revision 425792743 by @Mike Peel, if that helps). — ExE Boss (talk) 05:45, 27 August 2021 (UTC)

It lets you pass a manual title to the infobox. It doesn't support multiple languages - so it would always display the same text in all languages. If I recall correctly, it was added to handle ship names that are supposed to be in italics, and don't vary between languages. Thanks. Mike Peel (talk) 07:51, 27 August 2021 (UTC)

اچ‌ام‌اس ویکتوری ? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 18:47, 24 September 2021 (UTC)

Moin Moin ExE Boss, was this answer helpful? Regards --Crazy1880 (talk) 19:12, 8 December 2021 (UTC)

This section is resolved and can be archived. If you disagree, replace this template with your comment. Mike Peel (talk) 20:39, 26 December 2021 (UTC)

Add property request Property:P4819

Swedish Portrait Archive ID (P4819) is a Swedish community initiative that has scanned > 800 000 pictures it would be nice to have it in the Infobox - Salgo60 (talk) 11:37, 3 October 2021 (UTC)

Moin Moin Salgo60, Its added to {{Wikidata Infobox/sandbox}}, please test. Thanks. --Crazy1880 (talk) 18:40, 8 December 2021 (UTC)

Crazy1880 Thanks and excellent just one thought

1) as the id is a en:GUID I feel just the name with a link is enough example Category:Sten_Berglund_1889

1-1) we get now "Swedish Portrait Archive ID: sj9PGLAlnmUAAAAAABkaBA"

1-2) I feel enough is to display this text with a link "Swedish Portrait Archive ID"

- Salgo60 (talk) 07:19, 9 December 2021 (UTC)

This section is resolved and can be archived. If you disagree, replace this template with your comment. Mike Peel (talk) 20:38, 26 December 2021 (UTC)

weird coordinates behavior

{{Wikidata Infobox/sandbox|qid=Q38132084|spf=P18 P31 P1435}} @Mike Peel: (eventually related to #Drop coordinates rounding): Category:Wegkapelle, Zuberbach uses the Infobox and Coordinates from Wikidata ({{Object location|wikidata=Q38132084}}). Navigating to geohack via both ways gives slightly different locations. What I do in cases like this, I check which of the locations is the right one, the better one, whatever. Annoying in such a case where there is only a difference in presentation, rounding, etc, but not in data value. I feel, that same value might have different rounding in presentation (not even sure about that), but definitely should always link to the exactly same value. I didn't dig into it, maybe also {{Object location}} might be the reason. At least give me a hint. best --Herzi Pinki (talk) 09:01, 5 October 2021 (UTC)

{{Object location}} in this case links to 47.286445, 16.354142 that are the exact decimal coordinates stored in Wikidata. Unlike Wikidata Infobox it doesn't move object to different location. If my proposed fix is applied then Wikidata Infobox would also link to exactly the same value (see sandbox example to the right). Number of decimal places in DMS value displayed in these templates would be still different. The latter issue is less important and can be tackled separately later on. 2001:7D0:81DA:F780:AD05:D510:C4F3:7179 07:42, 11 October 2021 (UTC)

Again @Mike Peel: : Infobox in Category:Fountain Domplatz, Feldkirch using coordinates from wikidata and the unterlying wikidata object Fountain Domplatz, Feldkirch (Q38080750) do show different locations. While the coordinate location (P625) of Fountain Domplatz, Feldkirch (Q38080750) hits the object, the infobox coords don't. It takes me some minutes to resolve a discrepancy where there is none. best --Herzi Pinki (talk) 16:47, 13 October 2021 (UTC)

 Not done, it seems that coordinate rounding was implemented while I wasn't watching this, hopefully that solved this issue, otherwise the coordinates need to be corrected on Wikidata to implement appropriate precision. Thanks. Mike Peel (talk) 20:35, 26 December 2021 (UTC)

This section is resolved and can be archived. If you disagree, replace this template with your comment. Mike Peel (talk) 20:35, 26 December 2021 (UTC)

Stuttgart Database of Scientific Illustrators ID

Please display d:Property:P2349 in the infobox - for some illustrators, it's the only external ID we have Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 12:45, 24 November 2021 (UTC)

Moin Moin Andy Mabbett, Its added to {{Wikidata Infobox/sandbox}}, please test. Thanks. --Crazy1880 (talk) 18:42, 8 December 2021 (UTC)

@Crazy1880: tested and working, thank you. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 19:49, 8 December 2021 (UTC)

@Pigsonthewing: This is now live. Thanks. Mike Peel (talk) 19:31, 26 December 2021 (UTC)

This section is resolved and can be archived. If you disagree, replace this template with your comment. Mike Peel (talk) 19:31, 26 December 2021 (UTC)

Infobox displays data which doesn't belong to the Wikidata-item

The Wikidata Infobox of Category:Jazz musicians from Catalonia displays next to the info from the corresponding Wikidata item, the info from Wikidata item Catalonia (Q5705). Maybe this is a bug. Behanzane (talk) 07:46, 5 December 2021 (UTC)

@Behanzane: That's working as expected, the infobox displays the category combines topics (P971) items unless they have subclass of (P279) properties. Thanks. Mike Peel (talk) 19:27, 26 December 2021 (UTC)

This section is resolved and can be archived. If you disagree, replace this template with your comment. Mike Peel (talk) 19:27, 26 December 2021 (UTC)

Weird behaviour of automatic categorization

Hello,

Category:English language is currently populated by a lot of computing-related subcategories which seem to be automatically placed there by {{Wikidata Infobox}}. As an example, the current code of Category:Amiga 3000 is :

 {{Wikidata Infobox}}
 [[Category:Commodore Amiga]]

List of categories which seem to be affected: Adobe InCopy, Amiga 3000, Amiga 4000, Among Us, Amstrad NC100, Anim8or, Atari Portfolio, Atari TT, Canon EOS 7D, Canon EOS 7D Mark II, Canon EOS-1D, Created with Krita, Deno, Event Metrics, GanttProject, Glue guns, GMP, GNU ed, Godot (game engine), Hanazono Rugby Stadium, IMSAI 8080, Intertec Superbrain, IoBroker, K3b, Kalzium (software), Kanagram, Kanotix, Kate (text editor), KAtomic, KBlackBox, KBounce, KColorEdit, Kexi, KGeography, Kig, KMyMoney, KolourPaint, Konquest, Konversation, KPatience, Krita, Krusader, KStars, KSysguard, KTechlab, KTorrent, KTouch, Marble (KDE), Mpv (media player), Netlify, NetworkManager, OOjs UI, Parley (KDE), PlantUML, PowerBook 100, Rocky Linux, Sinclair QL, Sinclair ZX80, Siril, Strip Poker Night at the Inventory, Tesco EJ09, ThinkPad X1 Carbon, Timex Sinclair 2068, Tipmatic 6120, Ubuntu Touch, UFMOD, Umbrello, Weka (machine learning), Wikimedia hashtag search, Zig (programming language).

Any idea of what could create this seemingly unwanted behaviour, and how to solve it? Place Clichy 12:11, 7 December 2021 (UTC)

I randomly looked at a few of these categories, and all have a link titled “() user manual URL”—in wikitext it’s ([[Category:English language|English]]) user manual URL, without colon-escaping the category link. I don’t know how this happens, but there should certainly be no internal link within the external link at all ((English) user manual URL, or even better, user manual URL (English)). —Tacsipacsi (talk) 13:05, 7 December 2021 (UTC)

@Place Clichy: {{Wikidata Infobox}} notices that English (Q1860) is the value of the language of work or name (P407) property of the item's user manual URL (P2078) and categorizes its Commons category accordingly. --Iketsi (talk) 04:12, 8 December 2021 (UTC)

No, it doesn’t “notice” it and categorize the page accordingly. First, this kind of categorization makes no sense, the language of some documentation is not relevant for the software itself at all. Second, if this categorization was intentional (as opposed to simply forgetting to colon-escape the link), there were no empty parentheses left in the text. —Tacsipacsi (talk) 01:23, 9 December 2021 (UTC)

This is a bug, thanks for reporting. I suggest to remove quals=ALL in the P2078 code in Template:Wikidata Infobox/core MSGJ (talk) 06:18, 9 December 2021 (UTC)

I think displaying the language is actually a good thing. There are two bugs here, and I’d like to have them fixed instead of working them around by removing the qualifier:

• Qualifiers should not add categories. All links to categories should be colon-escaped, no matter what, except when explicitly categories are requested. (It may be easier to just colon-escape all links, the leading colon never hurts as long as there’s no more than one consecutive colon.)
• Qualifiers used within links should not add any links. There should be a parameter to disable linking the qualifiers, to be used in cases like this one, when the output ends up within a link (or it should be used if there’s already one).

Of course, just removing the qualifiers is a viable short-term solution, but I don’t think it’s the right long-term decision. —Tacsipacsi (talk) 22:14, 9 December 2021 (UTC)

@Place Clichy, MSGJ, and Tacsipacsi: Should be fixed with this edit. Thanks. Mike Peel (talk) 19:25, 26 December 2021 (UTC)

The fix seems to have worked: the wrongly- placed content is no longer present in Category:English language. @Mike Peel: thanks! Place Clichy 21:47, 26 December 2021 (UTC)

This section is resolved and can be archived. If you disagree, replace this template with your comment. Mike Peel (talk) 19:25, 26 December 2021 (UTC)

Archiving

Hi, This talk page needs archiving, but sorting out resolved and non resolved issues is a pain. Any one? Yann (talk) 12:16, 7 December 2021 (UTC)

I've marked a number of issues as "resolved"; excepting any where there might be pushback, I will archive them in a day or two. Unfortunately, RexxS is no longer active, so any that are waiting on his response or action will have to be picked up by someone else, or abandoned. Mike Peel is, AIUI, enjoying a short vacation. On his return we can ask him to peruse the remainder. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 14:25, 8 December 2021 (UTC)

@Mike Peel: Do you have time to check the outstanding issues on this page, and mark as resolved any that can be, please? And perhaps update some of the others? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 16:59, 20 December 2021 (UTC)

@Yann and Pigsonthewing: I was archiving items as they were deployed, but there's a big backlog here. Will check through the ones you've archived to make sure they're deployed or otherwise resolved (this has thrown the process somewhat), and try to catch up with the backlog shortly. Thanks. Mike Peel (talk) 17:39, 26 December 2021 (UTC)

@Yann and Pigsonthewing: OK, I checked through the recently archived items, and there was only one that needed pulling back to this talk page (celestial coordinates), but a bunch of others needed edits made in the infobox - which I've now done. Will try to catch up with the rest of the items here. I definitely need to use WONTFIX much more than I have done in the past, though - and thanks for archiving the items that were due to that and those that I'd missed! Thanks. Mike Peel (talk) 19:06, 26 December 2021 (UTC)

This section is resolved and can be archived. If you disagree, replace this template with your comment. Mike Peel (talk) 19:06, 26 December 2021 (UTC)

Lua error in Pronunciation audio

In Category:Zotero, for the line "Pronunciation audio", it currently shows "[[File:Lua error in Module:WikidataIB at line 1485: attempt to index field 'datavalue' (a nil value). | 100px]]". Script error pop-up says:

Lua error in Module:WikidataIB at line 1485: attempt to index field 'datavalue' (a nil value).
Backtrace:
   1. Module:WikidataIB:1485: ?
   2. (tail call): ?
   3. mw.lua:525: ?
   4. [C]: ?

朝彦 | asahiko (talk) 04:11, 16 December 2021 (UTC)

@朝彦: Fixed by editing Wikidata, there was a stray 'no value' qualifier. Thanks. Mike Peel (talk) 17:35, 26 December 2021 (UTC)

This section is resolved and can be archived. If you disagree, replace this template with your comment. Mike Peel (talk) 19:03, 26 December 2021 (UTC)