Template talk:Wikidata Infobox/Archive 1

From Wikimedia Commons, the free media repository
Jump to navigation Jump to search

Monument numbers

Nice template! It is possible to add monumnet numbers (and links) as well ? Here is an inspiration.--Jklamo (talk) 17:12, 29 January 2018 (UTC)

@Jklamo: Thanks! National Heritage List for England number (P1216) is included at the moment (e.g., see Category:Manchester Central Library), and I can add more individual property numbers like that if you want - just let me know which. :-) Thanks. Mike Peel (talk) 19:59, 29 January 2018 (UTC)

Revisiting this; could we make {{Listed building England}} (and a bunch more like it) redundant? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 21:57, 19 March 2018 (UTC)

@Pigsonthewing: I hope so, at least for category usage (they are also used in quite a lot of file pages). Is there anything more that needs to be done to this template before that is the case (aside from add more IDs as needed)? Thanks. Mike Peel (talk) 22:07, 19 March 2018 (UTC)
This section was archived on a request by: Mike Peel (talk) 17:45, 29 March 2018 (UTC)

Languages of dates

Sorry if this has already been discussed, but: I use my native Polish as my Commons interface language and I've noticed that while Template:Wikidata person displays dates of birth and death using the language of the user (Polish in my case), this template always shows me dates in English. I hope this can be fixed at some point in future (@Mike Peel: ). Thank you in advance! Powerek38 (talk) 12:27, 14 February 2018 (UTC)

@Powerek38: That's a good catch, thanks for pointing it out. This template uses Module:WikidataIB, while the other one uses Module:Creator, which in turn uses Module:Wikidata date, so has more complex data formatting. @RexxS: is there a way that code from those two could be used in WikidataIB to handle dates multilingually at all? Thanks. 15:19, 14 February 2018 (UTC)
This section was archived on a request by: Mike Peel (talk) 17:45, 29 March 2018 (UTC)

ISSN

Hi. It'd be nice having such a basic identifier as ISSN displayed in the infobox. We have many categories on periodicals and ISSN is not even shown in the {{Authority control}} template. Thanks! strakhov (talk) 22:11, 15 February 2018 (UTC)

@Strakhov: done. I would have added BNE at the same time, but there's a problem - in that example there are two BNE IDs on Wikidata, and it's supposed to be a unique ID. I've seen this happen elsewhere with other IDs too. I'm thinking about applying a maximum number of values of 1 for each ID, do you think that would be an issue anywhere? Thanks. Mike Peel (talk) 10:02, 16 February 2018 (UTC)
Thanks. I think it's a great solution for now, prioritizing the one added first. Wrt BNE's ID, I added several times two ID's: edition and work. The first one is more generous with regard to data. I'm very careful with that stuff in book-items, but when it comes to periodicals ..splitting items into "edition" and "work" seems (most of the time) just wrong to me. With this approach we would potentially give a single ISSN instead of two (paper, online) in some periodical-items (online and printed edition usually share the same item in Wikidata) ...but IMHO it's mostly OK. strakhov (talk) 13:26, 16 February 2018 (UTC)
@Strakhov: OK, maxvals=1 is now implemented (by a considerable rewrite of {{Wikidata ID line}}), and I've added BNF to the infobox too. How does that look - any problems you can spot? Thanks. Mike Peel (talk) 22:16, 16 February 2018 (UTC)
It's OK ..so far. Thanks! strakhov (talk) 15:32, 17 February 2018 (UTC)
This section was archived on a request by: Mike Peel (talk) 17:45, 29 March 2018 (UTC)

P281 in infobox

I think I've found another issue: Wikidata property P281 is obviously postal code, but the description of the infobox field, which uses values from this property, says "located on street" in English and the same in Polish. For example Category:Milanówek. Powerek38 (talk) 15:17, 16 February 2018 (UTC)

@Powerek38: That line (added due to @Atamari: 's request in the wishlist section above) actually shows P969 (P969) if that is present, and then falls back to displaying located on street (P669), house number (P670) and postal code (P281) if one or more of those is available. In this case, it looks like only P281 is available. I think there's two options here: either we change the label we use from P669 to another one, perhaps "address" (d:Q319608), or we change the logic so that the line is only shown if either P969 or P669 are available (i.e., if P670 and/or P281 is available, but the others aren't, then nothing's shown). Thoughts? Thanks. Mike Peel (talk) 15:55, 16 February 2018 (UTC)
Well, I would opt for the second option. Otherwise it will look quite strange whenever the template is used for any larger geographic or administrative unit, which for obvious reasons will never have any P669 or P670 values, like in my example (Milanówek is a town in the Warsaw metropolis). Powerek38 (talk) 16:02, 16 February 2018 (UTC)
@Powerek38: OK, I've updated the logic accordingly. How does that look now? Thanks. Mike Peel (talk) 21:52, 16 February 2018 (UTC)
@Mike Peel: Much better, thank you! Powerek38 (talk) 07:37, 17 February 2018 (UTC)
This section was archived on a request by: Mike Peel (talk) 17:45, 29 March 2018 (UTC)

GLAMorgan statistics

When this template is used on a category page, please could it link to GLAMorgan, using the link code from {{GLAMorgan}}? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 15:16, 26 February 2018 (UTC)

@Pigsonthewing: In principle, yes. I'll look into it. Is the caution translated anywhere (mediawiki interface, or on wikidata), or is it OK to be removed in the version added here? Thanks. Mike Peel (talk) 17:06, 26 February 2018 (UTC)
No translation; should be OK to ignore it. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 18:26, 26 February 2018 (UTC)
@Pigsonthewing: It's now in the sandbox, can you try {{Wikidata Infobox/sandbox}} and see if that works as expected, please? Thanks. Mike Peel (talk) 21:10, 26 February 2018 (UTC)
It does. Thank you. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 21:41, 26 February 2018 (UTC)
Having used this some more, I think we need to change the URL. Instead of &depth=12 use &depth=1, unless someone has a counter argument for a different value? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 00:44, 27 February 2018 (UTC)
@Pigsonthewing: Done. It's straightforward to change, so if another number looks better in the future then we can switch to that easily. Thanks. Mike Peel (talk) 09:40, 27 February 2018 (UTC)
This section was archived on a request by: Mike Peel (talk) 17:45, 29 March 2018 (UTC)

Identifiers of Spanish monuments

Hello, I'd like to suggest to include the properties that hold the identifiers of elements of the Spanish cultural heritage. Namely: d:P4868 (Hispania Nostra Red List of Endangered Heritage ID), d:P808 (code Bien de Interés Cultural), d:P1586 (Catalan object of cultural interest ID), d:P1600 (code Inventari del Patrimoni Arquitectònic de Catalunya), d:P2917 (COAM structure ID), d:P3177 (Patrimonio Web JCyL ID), d:P3178 (Zaragoza monument ID), d:P3318 (Patrimonio Inmueble de Andalucía ID), d:P3580 (SIPCA code), and d:P3758 (DOCOMOMO Ibérico ID). Many thanks for your understanding. --Discasto talk 21:26, 26 February 2018 (UTC)

Yeah! P808 is already included but supporting the rest. strakhov (talk) 21:30, 26 February 2018 (UTC)
@Discasto and Strakhov: I've added them in the sandbox, please try {{Wikidata Infobox/sandbox}} to see if that works as expected. (Note that the template now shows up to 23 IDs, which is quite a lot, and {{Wikidata ID}} currently has a maximum of 30. I'm not 100% sure how efficient it is when there are lots of ID properties to check...) Thanks. Mike Peel (talk) 21:54, 26 February 2018 (UTC)
Well, P3580 and P1600 are not giving their best because of not having a formatter url in Wikidata (P1600) or that url being currently deprecated (I hope it recovers soon, P3580). I meant their display isn't cute. The rest did great. I do not know much about these limits in {{Wikidata ID}}. strakhov (talk) 22:21, 26 February 2018 (UTC)
OK, I've removed those two for now, they can be added back once the formatter URLs for them are sorted out. Thanks. Mike Peel (talk) 22:26, 26 February 2018 (UTC)
Sorry! it was P1586 instead of P1600. strakhov (talk) 22:26, 26 February 2018 (UTC)
De nada, I've swapped those over. Thanks. Mike Peel (talk) 22:31, 26 February 2018 (UTC)
Thanks! strakhov (talk) 22:53, 26 February 2018 (UTC)

@Mike Peel and Strakhov: Thanks to both of you --Discasto talk 07:32, 27 February 2018 (UTC)

This section was archived on a request by: Mike Peel (talk) 17:45, 29 March 2018 (UTC)

ORCID

Please add ORCID (P496) to the Authority control section. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 09:38, 28 February 2018 (UTC)

@Pigsonthewing: I'm hesitant with this one, but only because it's always a long numerical string. Does the number definitely need to be shown for this one? Thanks. Mike Peel (talk) 11:40, 28 February 2018 (UTC)
Ideally, but a link would be better than nothing. The ORCID icon could be used. Wikidata has >30k people with no other identifier than an ORCID iD. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 12:04, 1 March 2018 (UTC)
@Pigsonthewing: Done, example at Category:Andy Mabbett. ;-) Thanks. Mike Peel (talk) 17:23, 3 March 2018 (UTC)
This section was archived on a request by: Mike Peel (talk) 17:45, 29 March 2018 (UTC)

?

Hi, @Mike Peel: I've been giving this a thought (the first {{Wikidata Infobox}} thread). I don't wanna insist too much on this issue, if I'm the only one concerned (we'll, at least @Incnis Mrsi: showed some concern too).

But... would it be a solution when the bot massively adds the template, it reads the wikidata ID too, in order to write it in the edit summary? I mean: to do this. Nothing more. Would that be too computationally expensive? strakhov (talk) 17:25, 3 March 2018 (UTC)

@Strakhov: That sounds fine to me. Thanks. Mike Peel (talk) 17:47, 3 March 2018 (UTC)
Thank you! strakhov (talk) 17:54, 3 March 2018 (UTC)
@Strakhov: So the edits will look like this [1] (this edit was made using the draft bot code), that good? Thanks. Mike Peel (talk) 18:21, 3 March 2018 (UTC)
Good enough for me. The only potential problem I foresee is the bot printing the "category-wikidata-ID" instead of "object-wikidata-ID" (in those "P373 cases in which data are pulled from... blablabla..."). I guess you have that in mind, so go ahead! :) strakhov (talk) 18:31, 3 March 2018 (UTC)
@Strakhov: In those cases, how about this format of edit summary? Thanks. Mike Peel (talk) 20:48, 3 March 2018 (UTC)
Great! :) strakhov (talk) 20:56, 3 March 2018 (UTC)
Useless – there is no Q number for the topic in arguments. Incnis Mrsi (talk) 23:46, 3 March 2018 (UTC)
@Incnis Mrsi: I don't understand what you mean? For [2], both Q8419873 (the category item) and Q33093130 (the topic item) is included in the edit summary? Thanks. Mike Peel (talk) 23:54, 3 March 2018 (UTC)
@Mike Peel: it is continuation of the previous dispute. If even Ymblanter—Wikidata’s bureaucrat—is not sure about data integrity on his site, the we obviously may not trust reverse site links on Wikidata. Incnis Mrsi (talk) 07:33, 4 March 2018 (UTC)
This section was archived on a request by: Mike Peel (talk) 17:45, 29 March 2018 (UTC)

Should the infobox call {{Interwiki from Wikidata}}?

When I designed {{Flumen}}, I made it call {{Interwiki from Wikidata}} if transcluded from the category: space unless «interwiki=-» is specified as an argument. My opinion – {{Wikidata Infobox}} should do the same to avoid template clutter in the page code. Incnis Mrsi (talk) 09:57, 4 March 2018 (UTC)

The code already auto-includes {{Interwiki from Wikidata}} when category's main topic (P301) is set in the Wikidata item the category is sitelinked to. Thanks. Mike Peel (talk) 10:15, 4 March 2018 (UTC)
Interwiki seemingly are not called with {{Wikidata Infobox|qid=Qnumber}}. May I fix it? Incnis Mrsi (talk) 10:22, 4 March 2018 (UTC)
That would cause problems when the infobox is used in places where interwikis aren't wanted, for example in the Village Pump discussions... Are there cases when we would want interwikis that can't be solved by adding the commons sitelink on Wikidata? Thanks. Mike Peel (talk) 10:29, 4 March 2018 (UTC)
@Mike Peel: please read what do I write: from the category: space — see {{Ifcategory}}). Incnis Mrsi (talk) 10:52, 4 March 2018 (UTC)
Ah, OK. Want to demo what you mean at {{Wikidata Infobox/sandbox}}? Thanks. Mike Peel (talk) 10:54, 4 March 2018 (UTC)

@Mike Peel: added, tested, waiting for peer review. Incnis Mrsi (talk) 07:18, 8 March 2018 (UTC)

@Incnis Mrsi: Thanks, it looks good, and it's now in the live version. Mike Peel (talk) 22:26, 9 March 2018 (UTC)
This section was archived on a request by: Mike Peel (talk) 17:45, 29 March 2018 (UTC)

List markup

Lists like Reasonator | Scholia | WikiShootMe should use {{Flatlist}} (or list markup and the equivalent styling on the tempate's outermost container), and not pipe characters, please. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 21:38, 7 March 2018 (UTC)

@Pigsonthewing: This is now coded in the sandbox, please let me know if there are any issues with it. I'll move it into the main version soon. Thanks. Mike Peel (talk) 21:30, 9 March 2018 (UTC)
@Pigsonthewing: It's now live. Thanks. Mike Peel (talk) 22:26, 9 March 2018 (UTC)
Looks good. Thank you. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 14:43, 12 March 2018 (UTC)
This section was archived on a request by: Mike Peel (talk) 17:45, 29 March 2018 (UTC)

Sorting

Category:Rebecca White is sorted under 'White' in Category:White (surname), should be 'Rebecca'. --ghouston (talk) 04:22, 11 March 2018 (UTC)

@Ghouston: Thanks for mentioning this, @Richard Arthur Norton (1958- ): mentioned something similar before but in this case it seems to be very repeatable, which is perfect for debugging. This edit should have fixed the issue. Thanks. Mike Peel (talk) 10:38, 11 March 2018 (UTC)
Thanks. Now here's one with bad sorting of the surname, Category:Brooke Sweat. --ghouston (talk) 10:36, 16 March 2018 (UTC)
@Ghouston: In that case, there's no value for family name (P734) in the Wikidata entry, so the template doesn't set a defaultsort value. The solution is either to add the P734 value, or if need be set the defaultsort manually (the first solution is better in the long run, but you may need to make a new Wikidata item for the family name if it's not already there). Thanks. Mike Peel (talk) 10:54, 16 March 2018 (UTC)
OK, thanks. --ghouston (talk) 10:58, 16 March 2018 (UTC)
This section was archived on a request by: Mike Peel (talk) 17:45, 29 March 2018 (UTC)

Ship infos

Hello, I already use your useful template in some categories that I have edited/created. Some of those categories are regarding ships. Example Category:Alondra (ship, 1995), you will see on the left of category page several informations that are specific to each ships. Those informations are added in many categories by several users interested the the maintenance of ship category tree. As you can see in Wikidata those informations are matchings with some propreties. Can you add to your infobox the following properties?

MMSI (P587)
gross tonnage (P1093)
beam (P2261)
length (P2043)
width (P2049)
service entry (P729)

All properties corresponding to the listed infos are not yet existing, but well its a beginning, I will try to get them created in Wikidata. Christian Ferrer (talk) 09:04, 25 March 2018 (UTC)

@Christian Ferrer: P729's already included. The others I've added at {{Wikidata Infobox/sandbox}}, want to give that a go? I have two warnings, though: we have categories here for each name a ship's had, and one for its IMO, but on Wikidata there is only one entry for all of those. The second is that I haven't tested dimensions here yet, so I'm not sure how well they will translate: can others watching this page please test this to see how well it works in different languages? Thanks. Mike Peel (talk) 11:27, 25 March 2018 (UTC)
BTW, would call sign (P2317) and payload mass (P4519) also be useful? I'm not sure how flags for ships work on Wikidata, but maybe flag (P163) would be useful too. Thanks. Mike Peel (talk) 11:58, 25 March 2018 (UTC)
Thanks I checked {{Wikidata Infobox/sandbox}} on the category, it is fine. Please add call sign (P2317) too. However although payload mass (P4519) met the description en:"Deadweight" (Q1332978) is a specific term for ship, as well as the "flag" ship. I highlighted the question at Wikidata_talk:WikiProject_Ships, I would wait for those two. Christian Ferrer (talk) 12:46, 25 March 2018 (UTC)
@Christian Ferrer: Call sign's now added, and I've moved the new code from the sandbox to the main version. Please let me know if you spot any issues, and when you want more properties adding! Thanks. Mike Peel (talk) 11:25, 26 March 2018 (UTC)
This section was archived on a request by: Mike Peel (talk) 17:45, 29 March 2018 (UTC)

Reasonator box

The separate Reasonator box on pages like Category:Raspberry Pi is redundant to this template. I'm not sure what causes it to appear. How can it be disabled? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 11:40, 29 March 2018 (UTC)

@Pigsonthewing: Is it in your javascript, or enabled as a gadget? I don't see it. Thanks. Mike Peel (talk) 12:13, 29 March 2018 (UTC)
Yes; User:Jheald/wdcat.js. Apologies. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 12:36, 29 March 2018 (UTC)
This section was archived on a request by: Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 12:36, 29 March 2018 (UTC)

ID P3580 SIPCA

With regard to this thread, d:P3580 is back from the dead (links). Can it be included again? Thanks! strakhov (talk) 19:43, 1 April 2018 (UTC)

✓ Done [3]. Thanks. Mike Peel (talk) 20:00, 1 April 2018 (UTC)
This section was archived on a request by: Mike Peel (talk) 20:00, 1 April 2018 (UTC)

Bot deployment

I've started a discussion about whether we want to bot-deploy this template on VP/Proposals - please comment there! Thanks. Mike Peel (talk) 22:57, 25 February 2018 (UTC)

Discussion continues at Commons:Bots/Requests/Pi bot 1. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 11:37, 29 March 2018 (UTC)
This section was archived on a request by: Mike Peel (talk) 22:00, 20 April 2018 (UTC)

Audio

Please include audio files; for example:

Thank you. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 11:15, 27 March 2018 (UTC)

@Pigsonthewing: This is now in {{Wikidata Infobox/sandbox}}, please can you test it and see if it works as you expect it to? Thanks. Mike Peel (talk) 23:05, 27 March 2018 (UTC)
Working perfectly. Thank you. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 10:17, 28 March 2018 (UTC)
@Pigsonthewing: Hi. Mike has suggested my talking to you [...] --Joalpe (talk) 12:17, 28 March 2018 (UTC)
Off topic here, and long, so moved to my talk page. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 11:42, 29 March 2018 (UTC)
The audio property code is now live. Thanks. Mike Peel (talk) 15:13, 28 March 2018 (UTC)
Thank you. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 11:42, 29 March 2018 (UTC)
This section was archived on a request by: Mike Peel (talk) 12:37, 20 April 2018 (UTC)

Some minor ideas / comments

@Mike Peel: I don't want to keep spamming you with new comments every day, so here are the things I've noticed recently, all in one post:

  1. It is a very nice idea to add flags and coats of arms, but IMHO they are currently too large. Please compare how they're displayed here and here. I think it currently looks better on enWiki.
  2. Is there some limit for the width of the box? For example here it got much wider than average and that happened after "member of" was added, because Cardinal Nagy was a member of International Theological Commission and that's a really long name.
  3. Are you sure that Scholia link at the bottom is always a good idea? I mean, it automatically launches several Wikidata Query Service queries, which I think are quite expensive, but in fact it gives similar results (in terms of what one can actually learn from this) as Reasonator and some authority control links, like WorldCat. That's just a thought, I accept people may disagree with me on that one.

By the way, I'd just like to ping my Polish collegue @Paweł Ziemian: , whose one of plWiki's top technicians and he is currently in development phase of a similar box at plWiki (here's his project). Paweł, maybe you would like to join forces with Mike or at least share your thoughts on various issues that come up on this talk page? Powerek38 (talk) 09:24, 30 March 2018 (UTC)

@Powerek38: There's a new version at {{Wikidata Infobox/sandbox}} that has smaller flags and coats of arms, and should fix the width problem with member of (this was previously set to nowrap). There is a defined width for the box, but that can be ignored by the browser when rendering if there are particularly long strings. Can you have a look and see if those work for you? With Scholia, it was @Pigsonthewing who wanted that included. Paweł, help is always appreciated. :-) Thanks. Mike Peel (talk) 15:59, 30 March 2018 (UTC)
Now live. Thanks. Mike Peel (talk) 16:37, 30 March 2018 (UTC)
Thank you, it's much better now. I think I would still add a few pixels (or what's the unit...) of space between P18 and flag/coat of arms, because at the moment (in the Milanówek example I linked above) top of the flag and bottom of the photo are right next to each other, with no space between them. As for width, I checked both on Chrome and Firefox and it looks very similar, the only way to make it more narrow is to change language to one with shorter labels :) But I guess it's up to individual preferences, what width seems nice to you etc., so I think we can keep it that way unless more people start complaining :) As for Scholia, again that was just my opinion and I actually don't mind it if other people find it warranted. Powerek38 (talk) 16:48, 30 March 2018 (UTC)
(I crossed out the width issue, the latest update to code resolved that one, thank you!) Powerek38 (talk) 16:53, 30 March 2018 (UTC)
Scholia only makes queries if people click the link, not every time the infobox is displayed. So far as I am aware, no performance concerns have been reported. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 22:15, 30 March 2018 (UTC)
This section was archived on a request by: Mike Peel (talk) 12:37, 20 April 2018 (UTC)

“{{#ifeq:aviation accident|human|” leaking out of infobox

On Category:1948 Glasgow Prestwick air crash, the text “{{#ifeq:aviation accident|human|” appears at the start of the page. This seems to have leaked out of the infobox, but I'm afraid I have no idea how to debug this. --bjh21 (talk) 10:54, 30 March 2018 (UTC)

This was briefly caused by changes in code applied by @Jérémy-Günther-Heinz Jähnick: , but it has now been reverted. Powerek38 (talk) 10:59, 30 March 2018 (UTC)
@Bjh21 and Powerek38: Yes, I was working at the addition of a field when I see similar things at you give, so I revert and then rewrite my line. I can't explain it, it is very slow when I want to write on this page, but only on it. I plan to continue to add fields this afternoon. Jérémy-Günther-Heinz Jähnick (talk) 11:37, 30 March 2018 (UTC)
@Jérémy-Günther-Heinz Jähnick: Please use the sandbox to test new changes, and ideally make changes in bulk rather than one-by-one. I've been trying to keep my edits to the live version of the template down to one a day, since it's now used in nearly 8,000 categories and it takes MediaWiki time to refresh those uses each time an edit is made. Thanks. Mike Peel (talk) 14:36, 30 March 2018 (UTC)
BTW, I also find the interface slow when editing this template, I don't know why. I copy-paste it to an external editor, make changes there, and then copy-paste back, as that's much faster. Thanks. Mike Peel (talk) 16:00, 30 March 2018 (UTC)
@Jérémy-Günther-Heinz Jähnick: could you please wrap those of the properties, which you add, that tend to have long strings, for example P119? Mike has just resolved this issue for some properties, but I think we all need to remember about it. Powerek38 (talk) 17:09, 30 March 2018 (UTC)
I am not able to make more on the side of programming, I just take lines and adapt fields, but I don't know how to wrap. Jérémy-Günther-Heinz Jähnick (talk) 17:16, 30 March 2018 (UTC) PS : I just see a diff now, I understand.
If the line should be wrapped, then change <td style="white-space: nowrap"> to <td>. It helps to have nowrap on short lines (such as units) to make the right-hand column wider, but not so much for longer lines. Thanks. Mike Peel (talk) 17:19, 30 March 2018 (UTC)
This section was archived on a request by: Mike Peel (talk) 12:37, 20 April 2018 (UTC)

Width on Birmingham

The box is too wide on Category:Birmingham. Is it caused by the formatting of Area, "267.77 ±0.0099999999999909 square kilometre"? --ghouston (talk) 10:35, 7 April 2018 (UTC)

Yes. The simple way to fix this would be to remove the uncertainty on the value from Wikidata - it's from an era when those uncertainties were being auto-added, so it's not really meaningful. However, the code shouldn't be showing that many digits, @RexxS: could this kind of issue be caught and changed to show 0.01 instead? Thanks. Mike Peel (talk) 13:39, 7 April 2018 (UTC)
@Ghouston and Mike Peel: I upgraded Module:WikidataIB to use the quantity-datatype handler from en:Module:WikidataIB which is more robust. Then I rounded the differences between the amount and its upper and lower bounds to 2 significant figures, as I reckon that's plenty for a precision. Category:Birmingham looks okay to me now.
As a bonus from the handler upgrade, we can now switch to using abbreviations for common units, which might make sense in infoboxes. The switch is |unitabbr= which is true/false (or yes/no or 0/1). The default is false for backwards compatibility. The list of "common" units starts around line 42 and can be extended easily.
  • {{#invoke:WikidataIB |getValue |P2046 |qid=Q2256 |fetchwikidata=ALL |onlysourced=no}} → 267.77 ±0.01 square kilometre Edit this on Wikidata
  • {{#invoke:WikidataIB |getValue |P2046 |qid=Q2256 |fetchwikidata=ALL |onlysourced=no |unitabbr=yes}} → 267.77 ±0.01 km² Edit this on Wikidata
Let me know if you spot any problems. Cheers --RexxS (talk) 17:12, 7 April 2018 (UTC)
Thanks RexxS, looks good! I think we'll stick with the full unit name rather than the abbreviation, since the abbreviation doesn't seem to auto-translate. Thanks. Mike Peel (talk) 17:25, 7 April 2018 (UTC)
Well, abbreviations are often the same across multiple languages, but non-Latin scripts will need translation, I agree. We could read the unit symbol (P558) from the data-entry for the unit (e.g. d:Q712226), but of course, that's yet another expensive call so I can't justify it, as usual. It really is annoying that the folks at Wikidata don't realise that we can't just look up a property in another entity without penalty. It's fine for site-links, labels, descriptions, etc. but looking up properties indirectly is going to lead to larger templates exceeding the parser limit quite quickly. In the end it will be the death-knell for general-purpose tools like WIkidataIB that allow template editors to create and upgrade infoboxes, and every infobox will have to be implemented in its own Lua module to keep arbitrary access within limits. That will be a real pity. --RexxS (talk) 17:45, 7 April 2018 (UTC)
This section was archived on a request by: Mike Peel (talk) 12:36, 20 April 2018 (UTC)

Computing categories

I'm not sure if there is any version/variant of {{Wikidata Infobox}} concerning computing; OS'es, hardware, software etc? Probably no - so there is some work for us to do about it. There is not much such categories in Category:Uses of Wikidata Infobox, so I'v placed some templates in OS categories: Arch Linux, Gentoo, Slackware, Raspberry Pi, Ubuntu. My conclusion is, that such categories lack some essential data existed in WD:

I'm not a Linux or every software / hardware expert, maybe someone of more experienced users have a better ideas, how to improve {{Wikidata Infobox}} in whole computing context ? --Jasc PL (talk) 22:41, 13 April 2018 (UTC), edited by: --Jasc PL (talk) 20:57, 15 April 2018 (UTC)

@Jasc PL: inception (P571) was already there; I've added the rest to {{Wikidata Infobox/sandbox}}, either as line items or in authority control as appropriate. Please can you give it a go and see if it works as expected? In particular, software version identifier (P348) is tricky - we have to rely on the latest version being marked as preferred on Wikidata (we can't [yet] pick the one with the latest date). That may work OK if that's the standard approach on Wikidata, or it may result in some long lists if not. Thanks. Mike Peel (talk) 23:47, 15 April 2018 (UTC)
Nice to see you again Mike Peel. I just placed sandbox version at the 5 above categories - for me now is much better. Some fresh observations (the rest tomorrow); in some cats the left column is to wide (Gentoo, Slackware, Ubuntu) - but Arch Linux and Raspberry Pi are OK; Platform - the values are usually short so could be in one line, separated with comma. --Jasc PL (talk) 01:18, 16 April 2018 (UTC)
@Jasc PL: Platforms are now comma-separated. The left column width is a bit tricky to control: at the moment it auto-adjusts based on the amount of content on the right, and seems to be be up to 50% of the width if there isn't much content on the right. If you look at Gentoo, you can see it's now narrower because of the comma-separated platform line. I can set it to a fixed width of, say, 35 or 40 pixels, but keeping it dynamic seems to be OK in most cases. Thanks. Mike Peel (talk) 11:44, 16 April 2018 (UTC)
  • @Mike Peel: columns width - I agree, that dynamic are better, as we can't guess what will be in the right and left in every case;
  • software version - I understand, but manually switching preferred every time, by every version, in every item is some problematic. Maybe scenario like - read all (numerical or date - e.g. Arch Linux) statements of the software version then take highest (stable), will work? By the way - also publication date, if exist? Anyway, software version in the infobox, regardless if it will work perfectly or sometimes not, I find very useful. --Jasc PL (talk) 01:10, 17 April 2018 (UTC)
You can also check all the existing properties used by different software items here (around 75 properties) and those concerning hardware here (around 15 properties). For example operating system (P306), source code repository URL (P1324) etc. John Samuel (talk) 19:42, 17 April 2018 (UTC)
Thanks for your feedback @John Samuel, I found also some infobox templates at the WikiProject Informatics: OS, OS component, software, web browser, computer hardware and very useful software properties sheet, but we must remember that we talking about Commons - not Wikipedia infobox, so it must have the essential elements for most aspects of informatics only. I agree with the operating system (P306) and I'm not sure with the source code repository URL (P1324) as we have GitHub username (P2037) already. --Jasc PL (talk) 21:40, 17 April 2018 (UTC)
@Jasc PL and Jsamwrites: Operating system is added, and I've synced the main version from the sandbox. 75 properties would definitely be overkill, so let's stick with the essentials. Thanks. Mike Peel (talk) 22:30, 17 April 2018 (UTC)
@Jasc PL and Mike Peel: I would also suggest user manual URL (P2078) John Samuel (talk) 18:04, 18 April 2018 (UTC)
@Jsamwrites: is this property widely used in the WD computing items and usually available in one place (under 1 link only)? --Jasc PL (talk) 18:49, 18 April 2018 (UTC)
@Jasc PL: Currently there are 334 items with values. John Samuel (talk) 19:11, 18 April 2018 (UTC)
@Jsamwrites and Jasc PL: It's now in the sandbox, coded the same way as the external link, please test {{Wikidata Infobox/sandbox}} to make sure it works as expected. Thanks. Mike Peel (talk) 22:04, 18 April 2018 (UTC)
It works @Mike Peel - tested on about 20 items, 10 of them are visible here.
user manual URL (P2078) is a very useful property @John Samuel, unfortunately not many popular and underused so for. There are some more interesting things that could be added to the infobox - not only concerned with informatics but... - the rest tomorrow, in the separate topic. --Jasc PL (talk) 23:27, 19 April 2018 (UTC)
It's now in the live version. Thanks. Mike Peel (talk) 12:35, 20 April 2018 (UTC)
This section was archived on a request by: Mike Peel (talk) 12:35, 20 April 2018 (UTC)

Width issue

The infobox as currently seen on Category:Àlex Hinojo is too wide, apparently caused by the occupation cultural activist, Wikipedian in Residence row.

It would be better to display those occupations vertically, as a list, perhaps using {{Plainlist}}. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 19:50, 3 February 2018 (UTC)

@Pigsonthewing: Now fixed at {{Wikidata Infobox/sandbox}}, which I'll deploy later today (hopefully once I've finished figuring out the sitelinks). Thanks for the feedback! Thanks. Mike Peel (talk) 20:57, 3 February 2018 (UTC)
✓ Done Now deployed. Thanks. Mike Peel (talk) 21:40, 3 February 2018 (UTC)
Thank you; that worked. May I suggest {{Plainlist}} for other multi-value entries, including the authority control data? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 15:27, 4 February 2018 (UTC)
I added "list=ubl" (unbulleted list) to most parameters. Authority control currently uses {{Br separated entries}}. Switching to plainlist might be a bit tricky, since it requires bullet points (which means lots of #if statements to check if something is going to be put after the bullet point). Thanks. Mike Peel (talk) 18:11, 4 February 2018 (UTC)
This section was archived on a request by: Mike Peel (talk) 12:23, 23 April 2018 (UTC)

If there is no P18 value available in wikidata but P154, would it be OK showing the logo instead? strakhov (talk) 19:57, 10 February 2018 (UTC)

@Strakhov: The logo should now be displayed below the image, where available. Does that look OK to you? Thanks. Mike Peel (talk) 15:15, 14 February 2018 (UTC)
It's OK. Rewording my previous suggestion, I'd avoid P18 if there's a P154 value. Example: Category:McDonald's -> IMHO the pic taken in Saugus, Massachusetts is kinda disposable in that infobox. But it's no big deal. Thanks. strakhov (talk) 15:26, 14 February 2018 (UTC)
@Strakhov: I've been thinking about this, and I'm a bit reluctant to hide one if the other is present as I suspect there are cases where we want to display both, e.g., for a company with a logo here that is based in a notable building. It's easy to make the change at any point in time, though - it's just an if statement that needs to be added. So shall we see how displaying both goes for now, and if there is an issue or if others express opinions here then we can reconsider, if that's OK? Thanks. Mike Peel (talk) 22:22, 16 February 2018 (UTC)
It's OK for me. :) strakhov (talk) 15:33, 17 February 2018 (UTC)
This section was archived on a request by: Mike Peel (talk) 12:22, 23 April 2018 (UTC)

P856: Website display

It would be cool avoiding this situation, which happens when too-lenghty-links are added in Wikidata. strakhov (talk) 17:16, 17 February 2018 (UTC)

@Strakhov: There are two options. The first is demo'd at [4] - but note that the formatting of the whole block changes, and there are also some oddities when you view the category on mobile that I need to look into. The other option is, rather than "Official URL: <URL>", they could instead be displayed as "[Official URL]", i.e. with the label as the link rather than showing the URL. Or we go with URLs that look like [5]. What do you think? Thanks. Mike Peel (talk) 13:14, 18 February 2018 (UTC)
@Mike Peel: Hi! Well, I do not have a strong opinion, but I'd probably say I'm with the second one. I mean, people add some pretty weird official websites in Wikidata. Seeing that displayed in three, four lines... not OK, specially if it puts a heavier workload on you. strakhov (talk) 21:56, 18 February 2018 (UTC)
@Strakhov: OK, I've now implemented the second option. Thanks. Mike Peel (talk) 21:44, 25 February 2018 (UTC)
This section was archived on a request by: Mike Peel (talk) 12:22, 23 April 2018 (UTC)

Templates that the infobox should be added below?

I've added some code to the bot that will add the infobox below named templates, e.g. like this, to avoid large areas of whitespace due to the other templates requiring 100% of the width of the page. So far I have {{On Wikidata}}, {{Object location}}, {{Authority control}}, and {{New Testament papyri}}. Are there others we should include as well? (Note that the bot doesn't add the infobox to pages using {{Wikidata person}}, {{Wikidata place}}, {{Institution}}, {{Creator}}, and of course those that already have the infobox). Thanks. Mike Peel (talk) 22:31, 4 March 2018 (UTC)

While {{GeoGroupTemplate}} doesn't use the full width, it's wider than the infobox and should probably go above it. See Category:A3 road (England) for an example. --bjh21 (talk) 10:21, 6 March 2018 (UTC)
I've added that to the list, thanks for the suggestion. Mike Peel (talk) 12:43, 6 March 2018 (UTC)
Put it below all templates, maybe. --ghouston (talk) 22:26, 6 March 2018 (UTC)
@Ghouston: We could do that, but that would probably include the intro sentences marked with {{En}} for example. Thanks. Mike Peel (talk) 22:38, 6 March 2018 (UTC)
Would it matter if it went below those? The infobox doesn't add anything to the header itself. --ghouston (talk) 22:40, 6 March 2018 (UTC)
Oh, I see, you want it to be beside the header in most cases, because it has a header of its own. --ghouston (talk) 22:43, 6 March 2018 (UTC)
The infobox is also doing the job of those headers, since it contains a description itself, so potentially replaces them. But I suppose you wouldn't want the bot to do that. --ghouston (talk) 22:45, 6 March 2018 (UTC)

Do we want to auto-remove other templates?

Of those you list, {{On Wikidata}} and {{Object location}}, at least, should surely be removed, if the infobox is used? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 19:48, 6 March 2018 (UTC)
@Pigsonthewing: we could do. At Commons:Bots/Requests/Pi bot 1, @EugeneZelenko: also just suggested that we remove {{Object location}} and {{Authority control}} when adding the infobox. It's easy to do for cases where those templates have no input parameters (I already auto-remove {{Interwiki from Wikidata}} like that, since the infobox auto-includes in when needed), or just have the same qid as the sitelink/P301 target as the input. Cases with different input parameters should probably be manually handled / need a more complex bit of bot code to handle.
The question is, do we want to? It should essentially remove all uses of those templates in category pages. @Strakhov: you were suggesting not to do this just yet at VP/P? Thanks. Mike Peel (talk) 22:38, 6 March 2018 (UTC)
If that thing about "bot-registering ID's in Commons through edit summaries" is ready, the part on "not removing current templates" is not that important to me. Anyway, I would ask ... Jarekt?, Tony Wills?, Dschwen?, the guys who created/edited those templates (villagepumping it would be nice too). Basically to assure deleting them is OK and it does not break some unknown tracking purpose or whatever function they have. Wrt {{Authority control}} it'd be nice to be sure different identifiers are not lost with this change (I mean, people could say ¿y qué hay de lo mío? ["What happened with my favourite external ID? uhh? where is it now, dude?"]).. I keep thinking that displaying too many ID's in a vertical box is somehow unsightly, unless collapsed by default, but... strakhov (talk) 23:02, 6 March 2018 (UTC)
The IDs are in the bot's edit summaries by default. @Jarekt, Tony Wills, and Dschwen: as suggested. If this needs to go to VP, then I think it'd be best to keep the existing templates for now and start that discussion once the infoboxes are in wider circulation. Thanks. Mike Peel (talk) 23:08, 6 March 2018 (UTC)
Perfect. I agree it's better to put the infoboxes in circulation first. When people see everything is OK, then our current wikidata-based-templates could be retired for good. Thanks. strakhov (talk) 23:14, 6 March 2018 (UTC)
I do not like the idea of removing of {{Object location}} or {{Authority control}} at least not until the new template includes information from them. {{Object location}} has a lot of links, people were using for last decade, which are not included in {{Wikidata Infobox}}. {{Wikidata Infobox}} rewrites {{Authority control}}, so as a result all identifiers have different names and different set of identifiers is shown. Why not just use {{Authority control|Wikidata=Q....|bare=1}} call the way all other templates do. Also In last few years we are trying to move away from writing templates in the Wikitext which often resulted in unreadable and hard to maintain templates. The current state of art is to use Lua, so this template feels a bit like blast from the past. The template also relies a lot on modules newly imported from EN wikipedia. Modules pulled from Wikipedia project often do not do a good job at presenting information in user's language and often require templates and other modules only present on that project. Finally I do like infobox location on the right which plays nicely with the rest of page layout, but I have bunch of small style requests which would make it more consistent with {{Information}} and other infoboxes: capitalize first letter in field names, add somewhere (if I want to find corresponding item on Wikidata, I usually look for that icon). Looking at Category:Prague: the existing wikidata link led me to Category wikidata item not the article item as expected, the date of inception was not localized (at least not in Polish), the list of "instance of" labels needs ";" or "," so we can tell where one ends and the next one starts. --Jarekt (talk) 14:11, 7 March 2018 (UTC)
@Jarekt: Thanks for the feedback. I'm unindenting and replying in bullet point form to work through the many points you've raised:
  • With object location: the main change here is that this template shows the map, and showing the links as well would take up more space. However, the links should all still be there, you just have to double-click on the map (or click on the expand icon in the top-right) to see them (in the right-hand column).
  • With authority control: I would like to switch to that at some point, as I suspect it's more efficient (although just testing it at User:Mike Peel/AC 1, it seems to use 11 Wikidata sitelinks, which seems excessive/computationally costly/not as translation-friendly as it could be - why not use the labels instead? Compare to User:Mike Peel/AC 2, although that uses more expensive queries and CPU time). The main issue is that it's very limited in the number of IDs it shows - it works well for people, but doesn't have any of the monument IDs - so there needs to be an easy way to add a lot more IDs to it. There also doesn't seem to be any way to change the separators, since we're currently using new lines here.
  • With Lua: a lot of the heavy lifting here uses Lua modules (kindly written by @RexxS and Ederporto, but I don't know the language myself, while I do know parser functions, so it made sense to use that here, and I've been trying to keep it as readable as I can. I'm also more interested in functionality than the language used. So in the long term I'd be happy to see this rewritten in Lua, although I'd prefer if we didn't do that until it's feature-stable so I can continue working on it without learning Lua for now. ;-)
  • Those Lua modules were designed to work in different language versions of Wikipedia, and so far they've been doing a pretty good job at handling the multilingual site here. Dates are one exception, and I'm hoping RexxS can have a look at that at some point, unless there's already another way to do those here.
  • Does capitalising the first letter make sense in all languages? Is there a function here already that can do that in a multilingual way?
  • Icon, Wikidata link, separators I'll sort out in the sandbox shortly.
Thanks. Mike Peel (talk) 20:55, 7 March 2018 (UTC)
I've just updated the template to link to Wikidata through the icon to the topic (not category) item. The separator for instance of (and a few others) is now ",<br />". Please let me know if there are any issues with those changes. Thanks. Mike Peel (talk) 21:32, 7 March 2018 (UTC)
I thought we were supposed to be using <br>, not <br />, now? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 21:39, 7 March 2018 (UTC)
@Pigsonthewing: Are we? Last I heard we were changing from the former to the latter? BTW, is the new Wikidata link (through the icon) OK with you? Thanks. Mike Peel (talk) 21:51, 7 March 2018 (UTC)
You can use either, according to en:Wikipedia:Line-break_handling. The version with a slash is an XMLism. --ghouston (talk) 22:47, 7 March 2018 (UTC)
Mike Peel:
  • Most of the links from {{Object location}} show positions of images related to that category. Clicking on the map did not do anything. Double click opened a page with a lot of good links but none of them show commons image locations. See for example Category:Warsaw and look at 4 links in the center of {{Object location}}.
  • About authority control: all the templates on Commons use one template so it is confusing to see other look. Also if you look at your test pages:
However you are right about {{Authority control}} being only useful for people. So far that is mostly what we used it for. However That template is easy to expand so maybe we should start a new discussion about adding identifiers useful for places, taxons, etc.
  • About Lua vs. wikitext. I agree that it might be sometimes easier to get proof of concept done in wikitext, but let's plan to have final version in Lua.
  • I met RexxS before and he is a great guy, but localization is not a high priority for Wikipedias the way it is on Commons. If you need localized dates than you should use Module:Wikidata date
  • About capitalization: just use ucfirst parser function. Or if you pull labels from Wikidata use Module:Wikidata label with capitalization option.
Hope that helps. --Jarekt (talk) 03:19, 8 March 2018 (UTC)
@Jarekt: OK, object location should be left as-is for now. I tried adding it into the module, but it seems like the Wikidata integration there isn't complete, it only works with the full box that has unnecessary formatting, and not the subparts. I've switched the authority control for people categories to that template, but the other one is still used for non-people categories. If it can be expanded in the future then we can switch over to using that system then, but I think this means that we can now remove that template from categories. ucfirst is now implemented, thanks for pointing that out - I just hope it doesn't cause any issues in different languages. There doesn't seem to be any documentation for Wikidata date, can you give some examples, please, and does it auto-detect the language to use? Thanks. Mike Peel (talk) 22:44, 9 March 2018 (UTC)
I began to work on Module:Wikidata date/doc. --Jarekt (talk) 04:25, 10 March 2018 (UTC)
@Jarekt: Thanks for the documentation for Wikidata date, it's now implemented here. How does it handle preferred vs. normal-ranked properties? Thanks. Mike Peel (talk) 21:52, 11 March 2018 (UTC)
I am not sure I understand the question, but statement ranks are handled by using mw.wikibase.entity:getBestStatements, which ignores statement with lesser rank. --Jarekt (talk) 02:59, 12 March 2018 (UTC)
That's good, thank you. Mike Peel (talk) 10:26, 12 March 2018 (UTC)

It needs to go below {{Birthcat}} in Category:1985 births, and I suppose there could be a lot of others like that. However, the template doesn't pick up anything useful if the Wikidata structure is "category combines topics" instead of a single topic. --ghouston (talk) 11:06, 11 March 2018 (UTC)

@Ghouston: For the main bot run, I'm leaning towards putting it below the last }} on the page, as that should avoid any problems even if it's not the ideal position. For Category:1985 births, I'm not sure what content could/should be shown in that case? The bot run will avoid adding the template to any category that is instance of (P31)=Wikimedia category (Q4167836) with no category's main topic (P301) to follow to a topic item. Thanks. Mike Peel (talk) 11:13, 11 March 2018 (UTC)
Possibly just a list of the topics that the category combines? --ghouston (talk) 11:18, 11 March 2018 (UTC)
@Ghouston: That's a good point. Something like [6] might do the job - try {{Wikidata Infobox/sandbox}} and see how that looks? Thanks. Mike Peel (talk) 11:31, 11 March 2018 (UTC)
Yes, I think that's useful for showing how the Wikidata item is set up. It also works if the the item is a bit confused, like Category:1986 births and other years, which have P301 and P971 together. --ghouston (talk) 11:42, 11 March 2018 (UTC)
@Ghouston: It's now in the main version. Thanks. Mike Peel (talk) 21:52, 11 March 2018 (UTC)
This section was archived on a request by: Mike Peel (talk) 12:21, 23 April 2018 (UTC)

Q-values leaking into DEFAULTSORT

Prompted by discussion in COM:VP, I looked at Category:Pages with DEFAULTSORT conflicts and noticed a common pattern where {{Wikidata Infobox}} was setting default sort keys with Wikidata Q-values in them. For instance, Category:Nina Andrycz got a sort key of "Q21125736, Nina", and Category:Susanne Brantl got "Q50809058, Susanne". In each case, the subject's family name (P734) is lacking a writing system (P282) and a native label (P1705). Can the template detect this and avoid generating default sort keys in those cases? --bjh21 (talk) 11:58, 18 April 2018 (UTC)

Relating to this, can someone edit the template in order to use the second family name in Spanish name (P1950) property to complete the DEFAULTSORT for hispanic names with two family names (that is: family name (P734) second family name in Spanish name (P1950), given name (P735) giving for example Category:Begoña García Martín the GARCÍA MARTÍN, BEGOÑA sorting)? Regards.--Asqueladd (talk) 12:06, 18 April 2018 (UTC)
@Bjh21 and Asqueladd: both of these should now be implemented in the sandbox, please could you test {{Wikidata Infobox/sandbox}} to make sure it behaves as expected? (BTW, I've written some bot code to auto-fix cases where this template triggers Category:Pages with DEFAULTSORT conflicts, which I'll start running soon.) Thanks. Mike Peel (talk) 21:59, 18 April 2018 (UTC)
@Mike Peel: I did some minimal tests on Category:Nina Andrycz and it seems to have worked. --bjh21 (talk) 10:57, 19 April 2018 (UTC)
The new version was deployed this morning, let me know if there are any issues. Thanks. Mike Peel (talk) 12:34, 20 April 2018 (UTC)
Hi, again @Mike Peel: . The bot is running smoothly for Madrid-related wd-items, :) About the DEFAULTSORT, the first comma separating the first family name and the second family name is not needed. Just a space. The sorting for Category:Armando López Salinas should be López Salinas, Armando instead of López, Salinas, Armando. Best regards.--Asqueladd (talk) 23:20, 20 April 2018 (UTC)
@Asqueladd: Hopefully [7] fixed this? Thanks. Mike Peel (talk) 23:30, 20 April 2018 (UTC)
@Mike Peel: It seems so. Thanks.--Asqueladd (talk) 23:32, 20 April 2018 (UTC)
This section was archived on a request by: Mike Peel (talk) 12:21, 23 April 2018 (UTC)

Errors at Category:War of the Fourth Coalition

There are some errors at Errors at Category:War of the Fourth Coalition. I bet they can be fixed by changing things at d:Q9554293, but I wander if template can detect such cases. --Jarekt (talk) 02:09, 23 April 2018 (UTC)

@Jarekt: Hmm, that's an odd one. It looks like @Place Clichy and ValterVB: have merged two different category topics into one somehow, resulting in two values of category's main topic (P301), and the infobox then tries to use both of them. I've deployed a fix so that it no longer does that, and the errors are now gone from the category - but this should really be fixed on Wikidata! Thanks. Mike Peel (talk) 11:38, 23 April 2018 (UTC)
I removed one of the two category's main topic (P301) values. I'm not sure if it fixed the problem you saw, as I have no way to go back. Place Clichy 11:51, 23 April 2018 (UTC)
@Place Clichy: Thanks, that would have fixed it, but having the general fix in place here is better. There's still fr:Catégorie:Campagne de Prusse et de Pologne in the QID, which looked like it corresponded with the P301 value you removed, or is that the same topic? Thanks. Mike Peel (talk) 11:56, 23 April 2018 (UTC)
It is the same topic. Most of the fighting of the Fourth Coalition War occured in Prussia and Poland, and although fr does not have a category named, for instance, Quatrième Coalition, existing fr:Catégorie:Campagne de Prusse et de Pologne is so much about the same topic that is is worth being linked to equivalent categories in other languages via site links (interwiki links). Place Clichy 12:16, 23 April 2018 (UTC)
OK, thanks for sorting it out! Mike Peel (talk) 12:20, 23 April 2018 (UTC)
This section was archived on a request by: Mike Peel (talk) 12:20, 23 April 2018 (UTC)

Preferred/Normal/Deprecated ranks

@Apalsola: Investigating this further, it seems that this is actually connected to located in the administrative territorial entity (P131), which in d:Q47048 has normal and deprecated rank values, but no preferred value. In this case,

{{#invoke:WikidataIB|getPreferredValue|P131|qid=Q47048|fetchwikidata=ALL|onlysourced=no|linkprefix=":"|noicon=yes}}

returns:

Northern Ostrobothnia, Oulu Province, Ostrobothnia County, Oulu sub-region

while it should return:

Northern Ostrobothnia, Oulu sub-region

So that's a Module:WikidataIB issue (although I've fixed the {{Wikidata location}} issue anyway). I think that the expected behaviour would be that if getPreferredValue doesn't find a preferred value, it defaults to getNormalValue (returning only normal-ranked values) rather than to getValue (returning all values). @RexxS: would that tweak be possible, please? Thanks. Mike Peel (talk) 12:27, 25 April 2018 (UTC)

@Mike Peel: I can't easily change the behaviour just for getPreferredValue, as it now uses the same code as getValue. That's one of the issues in consolidating duplicate code while a module is still in development. Oh well. For now, I've suppressed the fetching of any values that are marked as "deprecated" for all getValue, getPreferredValue, etc. calls. Let's see if that causes any problems going forward. Now we have:
  • {{#invoke:WikidataIB|getPreferredValue|P131|qid=Q47048|fetchwikidata=ALL|onlysourced=no|linkprefix=":"|noicon=yes}} → North Ostrobothnia
and
  • {{#invoke:WikidataIB|getValue|P131|qid=Q47048|fetchwikidata=ALL|onlysourced=no|linkprefix=":"|noicon=yes}} → North Ostrobothnia, Oulu Province, Ostrobothnia County
The module at en:Module:WikidataIB/sandbox has more sophisticated handling of ranks, but I can't directly implement that here because of intervening changes to the code on Commons. --RexxS (talk) 16:47, 25 April 2018 (UTC)
@RexxS: Thanks! That seems to have solved this problem, and I can't think of a reason why we'd want to display deprecated rank values here, so I think that's fine. I hope the different versions aren't diverging too much! Thanks. Mike Peel (talk) 16:51, 25 April 2018 (UTC)
This section was archived on a request by: Mike Peel (talk) 16:51, 25 April 2018 (UTC)

Completed wishlist items

Hi! Site-links to languages other than English don't work (Wikiquote & Wikisource, Wikipedia is OK though) since they redirect to the English version. Field "architect" could be interesting for building categories. Thanks! strakhov (talk) 22:22, 6 February 2018 (UTC)

@Strakhov: Architect should now be included. Can you point me to a case where Wikiquote and Wikisource aren't working, please? Thanks. Mike Peel (talk) 22:42, 6 February 2018 (UTC)
Great! Uhmmm: Category:Ángel Ganivet: wikisource & wikiquote (Spanish). strakhov (talk) 22:48, 6 February 2018 (UTC)
Ah, sorry, I'm browsing in English so I didn't notice those links (yay, the checking code works? ;-) ). Will look into it! Thanks. Mike Peel (talk) 22:52, 6 February 2018 (UTC)
@Strakhov: It should now be fixed - can you check again, please? You might need to purge your cache (add "?action=purge" onto the end of the URL). For some reason it bounces through the English version of the project, but it should end up at the right place. Thanks. Mike Peel (talk) 23:00, 6 February 2018 (UTC)
Yep, it's all right. Apparently it uses the English version, but the prefix es: redirects the click to the right place. Thanks! ~~
Great! Please ping me if you spot any other issues! Thanks. Mike Peel (talk) 23:19, 6 February 2018 (UTC)
This section was archived on a request by: Mike Peel (talk) 22:22, 2 May 2018 (UTC)

Bot run

Commons:Bots/Requests/Pi bot 1 has now been approved, so I'm starting to run the bot through a series of specific topic category trees, before starting it at Category:CommonsRoot. If you have any requests, please add them below. Thanks. Mike Peel (talk) 13:04, 20 April 2018 (UTC)

  1. Category:São Paulo (city) ✓ Done
  2. Category:Madrid Mostly ✓ Done - although the bot got quite distracted by the subcategories...
  3. Category:Greater Manchester ✓ Done
  4. Category:Brazil
  5. Category:Astronomical objects
  6. Category:United Kingdom
  7. Category:India  Doing… (first 5,000)
  8. Category:Jainism ✓ Done @Capankajsmilyo:
  9. Category:Spain
  10. Category:Art
    I'm still doing these for now, so ping me if you have any additional requests, but I'm not tracking the completion of them here any more since they typically run until they've made the first N edits and then they take ages to resume. I'm going for larger N and switching between different categories for now, before going for CommonsRoot. Thanks. Mike Peel (talk) 22:26, 2 May 2018 (UTC)
This section was archived on a request by: Mike Peel (talk) 22:26, 2 May 2018 (UTC)

ID's

Hi! Several external ID's are not working well. The template isn't taking values from Wikidata while creating the link, in spite of showing them. For example, here:

Thanks! strakhov (talk) 10:54, 21 April 2018 (UTC)

Oops, fixed. Sorry about that. Thanks. Mike Peel (talk) 11:23, 21 April 2018 (UTC)
Thank you! strakhov (talk) 12:29, 21 April 2018 (UTC)
@Mike Peel: why don’t you call {{label}} instead of calculating the same value twice? Incnis Mrsi (talk) 11:30, 21 April 2018 (UTC)
@Incnis Mrsi: I think they both do the same thing? The value isn't calculated twice, the if statement is in place to pick between the page ID or the QID/P301 value (since I can't spot a simpler way to do that). If they do the same thing, then let's stick with Module:WikidataIB to minimise dependencies. Thanks. Mike Peel (talk) 23:24, 22 April 2018 (UTC)
This section was archived on a request by: Mike Peel (talk) 22:18, 2 May 2018 (UTC)

Displayed template breaks Cat-a-lot

I have discovered that the Cat-a-lot Gadget does not work for me while there is a displayed instance of this template on a category page. When I click C-a-l the panel flickers open for a fraction of a second, then disappears. If I click “Hide” on the infobox, the panel immediately reappears (and functions normally). I had not seen any similar behaviour from C-a-l before this template was introduced. Any idea what might be causing it? Should I report it at MediaWiki talk:Gadget-Cat-a-lot.js instead?—Odysseus1479 (talk) 22:54, 23 April 2018 (UTC)

@Odysseus1479: Which browser are you using? I'm using catalot myself, on Firefox, and it seems to work OK for me... Thanks. Mike Peel (talk) 16:14, 24 April 2018 (UTC)
@Mike Peel: it’s Safari v5—don’t laugh. I hadn’t considered browser incompatibility as a cause; if that’s indeed it, it’s probably not worth fixing because there can’t be many of us with such old software—and it’s only a minor inconvenience. I might try another browser when I have time to mess about a bit: I find it’s rather awkward on this system because whenever I’ve done so in the past, Safari had problems staying logged in for weeks afterward, and I don’t care to switch over permanently (although I expect I’ll be forced to eventually). Thanks for checking, anyway.—Odysseus1479 (talk) 23:56, 25 April 2018 (UTC)
@Odysseus1479: Ah, that's not a browser version that I can test on my current mac I'm afraid, as I'm currently using Safari 11.1 and I don't think I can install an older version (no laughing, honest!)! If you can share more technical details about the issue (e.g., if you have the web developer tools installed and they are reporting any warnings/errors) then I can look into it. But beyond that, I'm afraid that all I can do is recommend using Firefox! Thanks. Mike Peel (talk) 00:06, 26 April 2018 (UTC)
This section was archived on a request by: Mike Peel (talk) 22:17, 2 May 2018 (UTC)

Just say thanks

Hello Mike, thanks for creating this template, which I find very convenient. Actually, it should be a must when creating and describing categories. Unfortunately I found it only now... I could have saved a lot of work... Greetings -- Walter Anton (talk) 01:19, 29 April 2018 (UTC)

Yeh, and a biiiig thank you from me to you and Walter Anton. Lotje (talk) 05:00, 29 April 2018 (UTC)
Thanks for the notes, I'm glad you find it useful! Thanks. Mike Peel (talk) 10:23, 29 April 2018 (UTC)
This section was archived on a request by: Mike Peel (talk) 22:16, 2 May 2018 (UTC)

Proposal for new properties (Transport)

Could connects with (P2789) be added to the Wikidata Infobox template? It may be useful for items of streets, roads and the like. It may be convenient for it to be displayed in a collapsed mode if it's too numerous (I dunno, about 10?). Also worth discussing transport network (P16). Regards.--Asqueladd (talk) 12:52, 29 April 2018 (UTC)

@Asqueladd: ✓ Done, please let me know if you spot any issues. Thanks. Mike Peel (talk) 20:48, 29 April 2018 (UTC)
This section was archived on a request by: Mike Peel (talk) 22:16, 2 May 2018 (UTC)

It can get too wide

See for instance Category:Bezerra de Menezes. ~★ nmaia d 03:04, 2 May 2018 (UTC)

@NMaia: Can you try adding "?action=purge" onto the end of the URL? It looks OK to me, but I made a tweak to the nowrap statements recently, so maybe it's a cached version you were seeing? Thanks. Mike Peel (talk) 08:58, 2 May 2018 (UTC)
I tried purging, to no avail. This is what is looks like to me: https://framapic.org/dOxa5ipzwPP0/94cVEG9alYZ7.png. It's wide like that because of the section on notable works, which displays a work with a long title. ~★ nmaia d 12:54, 2 May 2018 (UTC)
@NMaia: Aah, I was looking at it in English, and the long title's in Portuguese. It should be fixed now. Thanks. Mike Peel (talk) 19:20, 2 May 2018 (UTC)
This section was archived on a request by: Mike Peel (talk) 22:16, 2 May 2018 (UTC)

image annotations message

the image used in the infobox at Category:Umspannwerk Etzenricht has an annotation. therefore, the actual description ("transmission substation in Germany") starts with "This file has annotations. Move the mouse pointer over the image to see them." this is not really helpful. is it possible to deactivate the annotations feature specifically for Wikidata infoboxes? --Te750iv (talk) 11:05, 2 May 2018 (UTC)

@Te750iv: I believe annotations are a wonderful tool, but I think --seconding the previous comment-- we might not need them activated on the infobox main image. They are too small to read, and the main function of the infobox is not to highlight different aspects of the image but to provide an important illustration for a category. --Joalpe (talk) 16:56, 2 May 2018 (UTC)
I'll investigate this and get back to you soon. Thanks. Mike Peel (talk) 19:22, 2 May 2018 (UTC)
@Te750iv and Joalpe: Please can you test {{Wikidata Infobox/sandbox}} in a few categories where you know image captions are present? This uses {{ImageNoteControl}} to hide the message below the image, but the image notes will still work. I can also turn off the image notes themselves if you want. Thanks. Mike Peel (talk) 22:14, 2 May 2018 (UTC)
@Mike Peel: sandbox tested in preview, message gone, works well. the notes can stay, i think. Thanks for your work. --Te750iv (talk) 23:16, 2 May 2018 (UTC)
@Te750iv: Thanks for testing it, the new version is now live. Thanks. Mike Peel (talk) 23:19, 2 May 2018 (UTC)
This section was archived on a request by: Mike Peel (talk) 23:19, 2 May 2018 (UTC)

Hide by default?

I use Commons to find useful images, which I expect is the primary mission of many other Commons users. Consequently, this infobox is nothing more than an obstacle that must be circumnavigated or hidden -- every bloody time I encounter it -- before I can advance toward my goal. On desktop browsers, it consumes the space of at least one category column, which causes the page to stretch vertically and slows down navigation. Mobile devices display yet another clump of unnecessary info at the top of the page, which must be hidden or scrolled over to get to the meat and potatoes. An obvious way to avoid these problems is to hide the infobox by default; is there some way to do that? Lambtron (talk) 19:03, 2 May 2018 (UTC)

@Lambtron: If you never want to see it, you can hide it completely using custom CSS, see the last line above 'Template parameters' on the documentation page. Or do you mean showing it in its collapsed state by default, i.e. the current equivalent of having pressed the top 'Hide'? If so, I think that might cause the page to jump at the start (the two-stage loading problem). Thanks. Mike Peel (talk) 19:18, 2 May 2018 (UTC)
Thanks for the quick reply Mike; that simple CSS change did the trick. Lambtron (talk) 19:30, 2 May 2018 (UTC)
OK, I had a look into the other option but it seems more tricky than I expected, so I'll leave that for now. Thanks. Mike Peel (talk) 21:56, 2 May 2018 (UTC)
This section was archived on a request by: Mike Peel (talk) 21:56, 2 May 2018 (UTC)

Film duration

There seems to be a problem with the duration of films (see here for an example). Not a number is not a useful information, its acronym Nan is not understandable, and the precision +/- is silly. — Racconish ☎ 05:39, 3 May 2018 (UTC)

It's because the value of Wikidata is 16±0. The simple solution is to remove the meaningless uncertainty from Wikidata (they are a legacy of when uncertainties were required there). But in general, this is probably a bug in Module:WikidataIB - @RexxS: can this be fixed please? Thanks. Mike Peel (talk) 14:46, 3 May 2018 (UTC)
@Racconish and Mike Peel: Thanks for catching that. I've amended the routine that rounds to n sig fig so that it catches zero (taking the log of zero was what produced the "-nan"):
  • {{#invoke:WikidataIB |getValue |P2047 |qid=Q1857702 |fetchwikidata=ALL |onlysourced=no}} → 16 minute Edit this on Wikidata
  • {{wdib |P2047 |qid=Q1857702 |fwd=ALL |osd=no |unitabbr=yes}} → 16 min Edit this on Wikidata}
Should be fixed now everywhere. Cheers --RexxS (talk) 16:45, 3 May 2018 (UTC)
Thanks RexxS! Mike Peel (talk) 16:54, 3 May 2018 (UTC)
This section was archived on a request by: Mike Peel (talk) 16:54, 3 May 2018 (UTC)

Unwanted categories on gallery pages

I know this template is specifically designed for categories, but it is being used on gallery pages too. How can we stop this template from generating unwanted categories such as Category:1911 births on gallery pages? For instance, please take a look at Ronald Reagan gallery. I think the problem arises from item category combines topics (P971). Thank you 4nn1l2 (talk) 09:56, 4 May 2018 (UTC)

@4nn1l2: There are two options. The first is to manually add "autocat=off" on gallery pages where the categories aren't wanted. The second would be to auto-detect that it's being used on a gallery page, and always turn off the automatic categories in those cases. Which would be better? Thanks. Mike Peel (talk) 10:23, 4 May 2018 (UTC)
I think the second option would be better. Some users may have no clue where these categories come from, so they may not be able to turn off autocat option. 4nn1l2 (talk) 10:42, 4 May 2018 (UTC)
@4nn1l2: OK, I've turned off auto categories for uses outside of the category namespace - that's a bit more than I was thinking about before, but I think that probably sorts this out more consistently across non-category namespaces. Thanks. Mike Peel (talk) 23:18, 4 May 2018 (UTC)
This section was archived on a request by: Mike Peel (talk) 23:18, 4 May 2018 (UTC)

IUCN protected areas category (P814)

Hello, is it possible to add this? Christian Ferrer (talk) 18:07, 6 May 2018 (UTC)

@Christian Ferrer: It's now in the sandbox, can you test {{Wikidata Infobox/sandbox}} and see if that looks as expected please? Thanks. Mike Peel (talk) 19:04, 6 May 2018 (UTC)
This section was archived on a request by: Mike Peel (talk) 07:35, 7 May 2018 (UTC)

Maps

Hi! Location maps are not working for me (I do not know if it's only me). They show in the infobox, but they are not 'interactive' and there isn't 'expand'-button. strakhov (talk) 22:20, 8 May 2018 (UTC)

@Strakhov: They seem to be working for me (Firefox v59). Try adding ?action=purge to the end of the URL, and clear your browser cache (command-shift-R on a mac), to see if that fixes it. Otherwise it might be worth submitting a ticket to phab:. Thanks. Mike Peel (talk) 22:37, 8 May 2018 (UTC)
Thanks, it didn't work though. Sorry for the inconvenience, it was me. Restarting the computer finally solved the thing. :) strakhov (talk) 22:51, 8 May 2018 (UTC)
This section was archived on a request by: Mike Peel (talk) 00:28, 9 May 2018 (UTC)

Where is the edit button?

As someone who knows about Wikidata, I am aware that clicking on the Q code listed first under "Authority Control" allows me to access the Wikidata entry, and thereby edit and improve a Wikidata infobox that I see here on Commons. But for the unexperienced user, this serves as a Wikimedia object with no obvious way to edit. Which is a problem. How can it be fixed?--Carwil (talk) 18:09, 25 April 2018 (UTC)

@Carwil: I'm open to ideas here. I was originally using {{EditOnWikidata}}, which shows up at the bottom-right as "[edit on Wikidata]" (which is what I've used at, e.g., en:South Pole Telescope). The problem is that it doesn't auto-translate, since it's not linked to a Wikidata property (the labels like 'instance of' are linked to instance of (P31) and so on, which auto-translates). So I moved on to using "Wikidata (Q2013)", but that was removed to reduce the duplication of the link to Wikidata. If there's a different suitable Wikidata property then we could use that. The alternative is to show small icons to the right of the text, e.g. like "North Ostrobothnia, Oulu Province, Ostrobothnia County Edit this on Wikidata" - and those pen icons link to the relevant line on Wikidata. However, some people think that they are too messy/clutter up the infobox too much. We could use a single icon without text at the bottom of the box, but what would be a suitable icon? Or is there another way we could do this? Thanks. Mike Peel (talk) 19:48, 25 April 2018 (UTC)
I think either a pencil at the top or text at the bottom works. There's a tradeoff between lessening astonishment/promoting participation and generating clutter, but I think leaning heavily towards the former is good. If a pencil solves the translation issues good. Still the image should have alternate text in the user's language to make it accessible to the visually impaired.--Carwil (talk) 21:09, 25 April 2018 (UTC)
@Carwil: How does the version at Template:Wikidata Infobox/sandbox look as a first go? I'm still not sure how to do the alt text / sort out the translation issue here, I'm afraid. Thanks. Mike Peel (talk) 22:59, 30 April 2018 (UTC)
@Carwil: The edit button is now live. Thanks. Mike Peel (talk) 22:17, 2 May 2018 (UTC)
This section was archived on a request by: Mike Peel (talk) 23:25, 11 May 2018 (UTC)

Mapframe zoomlevel

Another Mapframe question, what about zoomlevel? At the moment zoomlevel is set as fixed 7 in the template. I have no problem with setting 7 as default, but I think that option to change it via parameter may be useful.--Jklamo (talk) 09:02, 10 May 2018 (UTC)

@Jklamo: It's easy enough to add it as a parameter (now in the sandbox). I've never been sure that 7 is the best default value to use, though, and I'm open to changing it if there's a better default to use! Thanks. Mike Peel (talk) 13:16, 10 May 2018 (UTC)
This is now live. Thanks. Mike Peel (talk) 23:24, 11 May 2018 (UTC)
This section was archived on a request by: Mike Peel (talk) 23:24, 11 May 2018 (UTC)

Script Error

Category:Iron Man (film) has script error. --Jarekt (talk) 11:46, 15 May 2018 (UTC)

This looks like one for @RexxS: here's a short version of the code that's throwing the error:
{{#invoke:WikidataIB|getPreferredValue|P161|name=cast|linkprefix=":"|list=ubl|qid=Q192724|suppressfields={{{suppressfields|}}}|fetchwikidata={{{fetchwikidata|ALL}}}|onlysourced={{{onlysourced|no}}}|noicon=yes}}
Thanks. Mike Peel (talk) 12:15, 15 May 2018 (UTC)
@Mike Peel and Jarekt: Good catch. On Commons (unlike on the Wikipedias), it's possible that an attempt to create an article title may fail, so when we check its id, it throws that error. I've fixed that now. Cheers --RexxS (talk) 16:26, 15 May 2018 (UTC)
Thanks RexxS! Mike Peel (talk) 21:37, 15 May 2018 (UTC)
:This section was archived on a request by: Mike Peel (talk) 21:37, 15 May 2018 (UTC)

Mapframe error

Tried template at Category:Danube and there is some mapframe error. How to fix this? Or is it possible to deactivate mapframe by parameter?--Jklamo (talk) 09:14, 8 May 2018 (UTC)

@Jklamo: This one was weird. It turns out that it's due to a lower-case q being used for the QID, and this edit fixed it. I don't know why that affects the map but not the rest of the content, though. @RexxS: maybe there's a subtle bug in WikidataIB here? (see the calls at Template:Mapframe/Wikidata) Thanks. Mike Peel (talk) 11:41, 8 May 2018 (UTC)
@Mike Peel and Jklamo: Nah, all the calls used in WikidataIB are case-insensitive for qid - and it would be easy to force the parameter into upper case anyway. The problem lay in the "ids": "{{{qid|{{#invoke:Wikidata2|pageId}}}}}" line in Template:Mapframe/Wikidata which does require the qid to be upper case "Q". I've forced that now, so that problem won't recurr. However, all of those calls to {{{qid | {{#invoke:Wikidata2|pageId}} }}} in that template should actually be something like: {{{qid | {{#if: {{#invoke:wd|property|raw|P301}} | {{#invoke:wd|property|raw|P301}} | {{#invoke:Wikidata2|pageId}} }}} - i.e. qid; if not then category's main topic (P301); if not then id of current page. In the same sort of way as done at Template:Wikidata Infobox. That would allow you to do without the qid parameter most of the time. HTH --RexxS (talk) 16:07, 8 May 2018 (UTC)
I've started {{GetQID}} that will hopefully solve this more generally (and condenses the wikitext in the infobox a bit - currently in the sandbox). Let's see how that goes. Thanks. Mike Peel (talk) 23:43, 17 May 2018 (UTC)
This section was archived on a request by: Mike Peel (talk) 12:48, 21 May 2018 (UTC)

DEFAULTSORT

Values for #DEFAULTSORT key should be called from English labels only. Currently this is depends from UI-language. See as example warning in the Category:Maddie_Ziegler.--Kaganer (talk) 12:13, 16 May 2018 (UTC)

@Kaganer: Nice catch! I've started working on this in the sandbox by changing over from the #property calls to Module:WikidataIB. But I'd forgotten that it was Module:Wikidata2 that had the language-specific code: @RexxS: any chance of modifying WikidataIB so that it can accept something like a "lang=en" parameter please? Thanks. Mike Peel (talk) 22:49, 17 May 2018 (UTC)
@Mike Peel and Mike: Yes of course. As I grow older and more senile, I'm having difficulty keeping all the different contexts in my head. Could you help me out a little bit by saying exactly which call(s) you want to accept a language parameter, please? --RexxS (talk) 22:56, 17 May 2018 (UTC)
@RexxS: I think it's me that's going more senile, sorry for not providing an example. Something like:
{{#invoke:WikidataIB|getPreferredValue|P734|linked=no|name=forename|qid=Q16240603|fetchwikidata=ALL|onlysourced=no|noicon=yes|lang=en}}
should return "Ziegler" rather than "Циглер", even when the site language is set to Russian. Thanks. Mike Peel (talk) 23:01, 17 May 2018 (UTC)
Done. I'm a bit leery of making a major hack of the getValue code for Wikibase-entities, so I've confined this feature to cases where |linked=no for now. You can probably see the complications I would have if I wanted to have linked values in other languages, because of the problems with dabs and redirects. Anyway, here are three test cases. The first one will give a value in the local/set language; the second one always returns English; and the third always Russian (not that you need that in this case).
  • {{#invoke:WikidataIB|getPreferredValue|P734|linked=no|name=forename|qid=Q16240603|fetchwikidata=ALL|onlysourced=no|noicon=yes|lang=}} → Ziegler
  • {{#invoke:WikidataIB|getPreferredValue|P734|linked=no|name=forename|qid=Q16240603|fetchwikidata=ALL|onlysourced=no|noicon=yes|lang=en}} → Ziegler
  • {{#invoke:WikidataIB|getPreferredValue|P734|linked=no|name=forename|qid=Q16240603|fetchwikidata=ALL|onlysourced=no|noicon=yes|lang=ru}} → Циглер
If the label doesn't exist in the language passed, it falls back to the local/set language. If that label doesn't exist, it returns the Qid (entity ID) of the item, like Q16240603 for Ziegler, as usual. Those errors should be fixed by adding the appropriate label on Wikidata. Cheers --RexxS (talk) 13:13, 18 May 2018 (UTC)
This section was archived on a request by: Mike Peel (talk) 12:48, 21 May 2018 (UTC)

multiple given names / Defaultsort

Hi, quite useful template.

If there are more than one given name given name (P735), as in Eduard Suess (Q156941), this leads to a DEFAULTSORT value of Suess, Eduard, Edward (which is questionable). Found this by incident in Category:Eduard Suess (where a duplicate and different defaultsort was set manually). In other cases (without manual DEFAULTSORT), this will not even show up. Setting different ranks did help.

There is a different meaning of alternative given names (Eduard Suess (Q156941)) and multiple given names (Wolfgang Amadeus Mozart (Q254)). --Herzi Pinki (talk) 09:59, 21 May 2018 (UTC)

There is a maintenance category Category:Pages with DEFAULTSORT conflicts for that, but this seems to be a modelling issue, that has to be catched somehow differently. --Herzi Pinki (talk) 10:03, 21 May 2018 (UTC)

@Herzi Pinki: This looks like something that needs to be fixed on Wikidata, either by removing 'Edward' (since that doesn't seem to be his name anyway), marking it as deprecated, or marking the other one as preferred. Any of those will lead to a DEFAULTSORT value here of Suess, Eduard. BTW, defaultsort conflicts with this infobox only end up in Category:Pages with DEFAULTSORT conflicts for up to a day before the bot disables the automatic DEFAULTSORT to avoid the conflict and adds them to Category:Uses of Wikidata Infobox with defaultsort suppressed for manual/automatic checks later. Thanks. Mike Peel (talk) 11:09, 21 May 2018 (UTC)
yeah, agree. The problem is the case where there is no obvious conflict cumulating in DEFAULTSORT handling, but wrong data. But this is not really related to your template. I will remove the Edward in the specific case above. best --Herzi Pinki (talk) 11:24, 21 May 2018 (UTC)
This section was archived on a request by: Mike Peel (talk) 22:51, 22 May 2018 (UTC)

Looks weird

Hello! The result of the Template looks weird if the notable works are books: book, book, book, .... For example: Category:Dietmar Rabich. --XRay talk 05:10, 22 May 2018 (UTC)

See your WD talkpage.--Jklamo (talk) 07:59, 22 May 2018 (UTC)
This section was archived on a request by: Mike Peel (talk) 22:51, 22 May 2018 (UTC)

Addition of new fields

Hi. I see this template is now protected and it is not a bad thing when we see how it is used : 70494 times against around 4000 a month ago. When we have generally five articles in different languages for a person, this template offers the possibility to display the informations in their language for readers. I list different properties to add. It is for people, I work on another list for other items.

manner of death -->{{#if:{{#property:P1196|from={{{qid|{{#invoke:wd|property|raw|P301}}}}}}}|<tr> <td style="text-align: right; background: #ccf; padding-right: 0.4em;">'''{{ucfirst:{{#invoke:WikidataIB |getLabel |P1196}}}}'''</td><td>{{#invoke:WikidataIB|getPreferredValue|P1196|name=manner of death|linkprefix=":"|list=ubl|qid={{{qid|{{#invoke:wd|property|raw|P301}}}}}|suppressfields={{{suppressfields|}}}|fetchwikidata={{{fetchwikidata|ALL}}}|onlysourced={{{onlysourced|no}}}|noicon=yes}}</td></tr>}}<!--

spouse -->{{#if:{{#property:P26|from={{{qid|{{#invoke:wd|property|raw|P301}}}}}}}|<tr> <td style="text-align: right; background: #ccf; padding-right: 0.4em;">'''{{ucfirst:{{#invoke:WikidataIB |getLabel |P26}}}}'''</td><td style="white-space: nowrap">{{#invoke:WikidataIB|getPreferredValue|P26|name=spouse|linkprefix=":"|list=ubl|qid={{{qid|{{#invoke:wd|property|raw|P301}}}}}|suppressfields={{{suppressfields|}}}|fetchwikidata={{{fetchwikidata|ALL}}}|onlysourced={{{onlysourced|no}}}|noicon=yes}}</td></tr>}}<!--

partner -->{{#if:{{#property:P451|from={{{qid|{{#invoke:wd|property|raw|P301}}}}}}}|<tr> <td style="text-align: right; background: #ccf; padding-right: 0.4em;">'''{{ucfirst:{{#invoke:WikidataIB |getLabel |P451}}}}'''</td><td style="white-space: nowrap">{{#invoke:WikidataIB|getPreferredValue|P451|name=partner|linkprefix=":"|list=ubl|qid={{{qid|{{#invoke:wd|property|raw|P301}}}}}|suppressfields={{{suppressfields|}}}|fetchwikidata={{{fetchwikidata|ALL}}}|onlysourced={{{onlysourced|no}}}|noicon=yes}}</td></tr>}}<!--

notable work -->{{#if:{{#property:P800|from={{{qid|{{#invoke:wd|property|raw|P301}}}}}}}|<tr> <td style="text-align: right; background: #ccf; padding-right: 0.4em;">'''{{ucfirst:{{#invoke:WikidataIB |getLabel |P800}}}}'''</td><td style="white-space: nowrap">{{#invoke:WikidataIB|getPreferredValue|P800|name=notable work|linkprefix=":"|list=ubl|qid={{{qid|{{#invoke:wd|property|raw|P301}}}}}|suppressfields={{{suppressfields|}}}|fetchwikidata={{{fetchwikidata|ALL}}}|onlysourced={{{onlysourced|no}}}|noicon=yes}}</td></tr>}}<!--

award received -->{{#if:{{#property:P166|from={{{qid|{{#invoke:wd|property|raw|P301}}}}}}}|<tr> <td style="text-align: right; background: #ccf; padding-right: 0.4em;">'''{{ucfirst:{{#invoke:WikidataIB |getLabel |P166}}}}'''</td><td style="white-space: nowrap">{{#invoke:WikidataIB|getPreferredValue|P166|name=award received|linkprefix=":"|list=ubl|qid={{{qid|{{#invoke:wd|property|raw|P301}}}}}|suppressfields={{{suppressfields|}}}|fetchwikidata={{{fetchwikidata|ALL}}}|onlysourced={{{onlysourced|no}}}|noicon=yes}}</td></tr>}}<!--

movement -->{{#if:{{#property:P135|from={{{qid|{{#invoke:wd|property|raw|P301}}}}}}}|<tr> <td style="text-align: right; background: #ccf; padding-right: 0.4em;">'''{{ucfirst:{{#invoke:WikidataIB |getLabel |P135}}}}'''</td><td style="white-space: nowrap">{{#invoke:WikidataIB|getPreferredValue|P135|name=movement|linkprefix=":"|list=ubl|qid={{{qid|{{#invoke:wd|property|raw|P301}}}}}|suppressfields={{{suppressfields|}}}|fetchwikidata={{{fetchwikidata|ALL}}}|onlysourced={{{onlysourced|no}}}|noicon=yes}}</td></tr>}}<!--

@Jérémy-Günther-Heinz Jähnick: Can you add them to the sandbox, please? We can then test them there before copying it over to the main version. Thanks. Mike Peel (talk) 10:27, 29 April 2018 (UTC)
... I forget the sandbox. I put the lines I previously add here. A return at the line is necessary for the awards received. I am not able to display the qualifiers because I have no examples to then adapt the code. Jérémy-Günther-Heinz Jähnick (talk) 10:56, 29 April 2018 (UTC)
@Jérémy-Günther-Heinz Jähnick: Thanks, I've synced the sandbox to the main version now. If you can continue making changes to the sandbox, I'll sync them over every so often, ping me if I don't spot them quickly. I think that qualifiers-in-brackets is a 'coming soon' feature, but I'm afraid I've lost track of where @RexxS: is with that. Thanks. Mike Peel (talk) 20:50, 29 April 2018 (UTC)
@Mike Peel and Jérémy-Günther-Heinz Jähnick: "Qualifiers in brackets" is fully functional in the sandbox on enwiki (en:Module:WikidataIB/sandbox). See en:User talk:Mike Peel/Archive 33 #More updates. If I can merge the enwiki module sandbox into the module sandbox here, you can try it out. --RexxS (talk) 20:57, 29 April 2018 (UTC)
[Update:] @Mike Peel and Jérémy-Günther-Heinz Jähnick: I've now merged the enwiki developments into Module:WikidataIB/sandbox. It's a major revision, so needs to be well tested before updating the main module. However, when you're happy with it, it will give you a lot more functionality and convenience. --RexxS (talk) 21:33, 29 April 2018 (UTC)
I plan to work today on the sandbox. Jérémy-Günther-Heinz Jähnick (talk) 11:49, 13 May 2018 (UTC)
@Jérémy-Günther-Heinz Jähnick: I'm worried that it looks like you're adding all Wikidata properties to the infobox. We should try to be selective and just use the ones that are particularly relevant here - otherwise in big topics the infobox is going to be huge and people will start complaining about that. For examples of this already becoming an issue, see Gdansk and Paris at User:Jasc_PL/WDinfoboxTEST#Cities. Thanks. Mike Peel (talk) 20:33, 13 May 2018 (UTC)
Hi, I add properties that can be interesting in various domains, for some properties (notable work (P800), award received (P166), contains the administrative territorial entity (P150), twinned administrative body (P190)), I was interested by the fact we can wrap if we have numerous values, as we already do in FR Wiki, see fr:Eddy Merckx. I think this solution is a good equilibrium between informations that can interest readers and a happy display. But I just do propositions in the sandbox, it is not a problem if we don't display some or if we wait for others. I recognize for the moment we have a problem for these towns, but tries are good in other domains, especially when I try non latin languages. So I propose to wait the time we can wrap for some properties, and see if it is good when it will become possible. Jérémy-Günther-Heinz Jähnick (talk) 10:53, 14 May 2018 (UTC)
I had few time, so I create the list of properties 4700-4799, 4800-4899, 4900-4999, 5000-5099 and 5100-5199. Numerous identifiers, but some interesting properties. Jérémy-Günther-Heinz Jähnick (talk) 18:02, 14 May 2018 (UTC)
  • Hi! Honestly, I do not like twinned administrative body (P190) here. It's data I'd avoid even in wikipedia infoboxes. I agree with Mike Peel we should try to be more selective.
With regard to items of mountains and such, including at least mountain range (P4552) would be nice.
With regard to reservoirs and dams, dam (P4792), reservoir created (P4661), inflows (P200), outflows (P201) are pretty basic too.
WIth regard to rivers, mouth of the watercourse (P403) is fundamental. Including tributary (P974) could (sometimes) return too many values, so I'd probably avoid it as a first approximation. strakhov (talk) 18:28, 14 May 2018 (UTC)
To give more informations about my work, I add properties few weeks ago but I started to have problems to work, so I try a new way : I make in my computer a new list of the properties used in the module and I start to add properties that can be interesting from the list of properties of Wikidata. With this solution, it is more easy because when I see a property in the order, I can choose to propose it or not. But it is just a proposition, with tries, we can see if it is a good idea or not for each property. Sometimes, something looks to be a good idea and finally no. . For tributary (P974), the idea could be also to make a wrap as I explain below if for example we have more than five values (I think it will arrive soon, idem for the display of some qualifiers). Jérémy-Günther-Heinz Jähnick (talk) 10:11, 15 May 2018 (UTC)
I add the properties you proposed in the sandbox. Jérémy-Günther-Heinz Jähnick (talk) 10:30, 15 May 2018 (UTC)
@Jérémy-Günther-Heinz Jähnick: The new properties are now live. Thanks. Mike Peel (talk) 12:49, 21 May 2018 (UTC)
Yes, I see, but on certain aspects I am not modern . Jérémy-Günther-Heinz Jähnick (talk) 12:59, 21 May 2018 (UTC)
This section was archived on a request by: Mike Peel (talk) 23:02, 25 May 2018 (UTC)

problem with multiple P443 values (pronunciation audio)

see Category:Meats, and the plain text [[File:Sv-kött.ogg, En-uk-meat.ogg, En-us-meat.ogg, Hr-meso.oga, Lv-riga-gaļa.ogg, Ru-мясо.ogg, Uk-м'ясо.ogg, Da-kød.ogg, Cs-maso.ogg, Nl-vlees.ogg, Be-мяса.ogg, Ar-لحم.ogg, It-la carne.ogg, De-Fleisch.ogg, Fr-viande.ogg, Mg-hena.ogg, Wo-yapp.ogg|100px]] there. --Te750iv (talk) 19:23, 19 May 2018 (UTC)

Hmm. I can set maxvals=1 to just get the first one, which solves the plain text issue, but then that's in a random language. @RexxS: any suggestions for how to select (from meat (Q10990)) a property with the language of work or name (P407) qualifier that contains the appropriate {{BaseLang}}? Thanks. Mike Peel (talk) 11:31, 20 May 2018 (UTC)
Sorry for the late reply, Mike, I've been out at the Oxford meetup all day. It will need a new call. I'll knock up a generic call something like 'getValueByQual' that returns the value of a property when it has a qualifier of a particular type with particular value. That will find more general use at some point. Watch this space. --RexxS (talk) 20:31, 20 May 2018 (UTC)

We can already get a list of all the property values and their qualifiers using the sandbox version:

  • {{#invoke:WikidataIB/sandbox |getValue |qid=Q10990 |P443 |fwd=ALL |osd=no |qual=ALL}} → Ar-لحم.ogg () Edit this on Wikidata

I've now created getValueByQual() function in Module:WikidataIB/sandbox. It takes an optional qid for the item; a property; a qualifier for that property (qualID); a value for that qualifier (qvalue) (just a wikibase-entity for now). It returns the value (just a string for now) of the property where the qualifier matched the given value.

So, in meat (Q10990), the property pronunciation audio (P443) which has qualifier language of work or name (P407) equal to British English (Q7979) is:

  • {{#invoke:WikidataIB/sandbox |getValueByQual |qid=Q10990 |P443 |qualID=P407 |qvalue=Q7979 |fwd=ALL |osd=no |noicon=true}} →

Note: I was getting concerned that the en-wiki and commons versions were diverging too much, so I've checked histories and made all the modifications the same, which has allowed me to copy the en-wiki sandbox to the commons sandbox. I would like to update the main modules from the sandboxes at some point, but I'd like to coordinate with you for the commons change, so that we can jointly catch any problems that might arise. Let me know when you feel able to give some time to that. In the meantime, please try out Module:WikidataIB/sandbox wherever you can. Cheers --RexxS (talk) 23:35, 20 May 2018 (UTC)

@RexxS: Thanks! That looks like it does most of the work, but there's still the step from {{BaseLang}} to Q7979 (or the relevant other QID corresponding to the wiki's language), is that feasible? I'm very sorry for not following up on the sandbox changes yet - I'm planning on looking through those and implementing them here once the current set of changes in this template's sandbox are live (hopefully that will take place tomorrow, then I can start using the sandbox version of the module later this week). Thanks. Mike Peel (talk) 00:18, 21 May 2018 (UTC)
Sorry, Mike, I had it in my head that it was a simple lookup to change a language code into its Wikidata-entity. It isn't. So either I have to create the lookup explicitly for all 443 recognised languages, or I need to modify the function to be more specific. I've done the latter, adding a function getValueByLang to the sandbox:
{{#invoke:WikidataIB/sandbox |getValueByLang |qid=Q10990 |P443 |fwd=ALL |osd=no |noicon=true}}
{{#invoke:WikidataIB/sandbox |getValueByLang |qid=Q10990 |P443 |fwd=ALL |osd=no |noicon=true |lang=sv}}
{{#invoke:WikidataIB/sandbox |getValueByLang |qid=Q10990 |P443 |fwd=ALL |osd=no |noicon=true |lang=en}}
{{#invoke:WikidataIB/sandbox |getValueByLang |qid=Q10990 |P443 |fwd=ALL |osd=no |noicon=true |lang=en-gb}}
{{#invoke:WikidataIB/sandbox |getValueByLang |qid=Q10990 |P443 |fwd=ALL |osd=no |noicon=true |lang=en-us}}
The snag is that we may have our default language set to "English" (English (Q1860)) and there is actually no audio for plain English in "Meat" (meat (Q10990)). I refuse to arbitrate whether English (Q1860) should default to British English (Q7979) or American English (Q7976) or any other variety. Best of luck with that one. --RexxS (talk) 16:53, 21 May 2018 (UTC)
@RexxS: The infobox also shouldn't be the arbitrator of that, let's leave it up to users to make their selection, or for other editors to add that language preference on Wikidata. Thanks. Mike Peel (talk) 23:00, 25 May 2018 (UTC)
This section was archived on a request by: Mike Peel (talk) 23:00, 25 May 2018 (UTC)

Category:Europa-Park

Category:Europa-Park has an infobox for a specific park in Germany, but the category is the parent category for several such parks, in different countries. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 18:47, 23 May 2018 (UTC)

@Pigsonthewing: It looks like there's one park that has different areas named after countries... Thanks. Mike Peel (talk) 19:56, 23 May 2018 (UTC)
This section was archived on a request by: Mike Peel (talk) 12:43, 25 May 2018 (UTC)

Doesn't it make sense to show the coordinates?

Hello, in tons of categories we have documented the coordinates of the item, now the Wikidata inbofox is being inserted and the coordinates (at least partially) are being removed. I believe that the box should replace all information that is available in Wikidate, like the coordinates. but wouldn't it make sense to show the coordinates in the infobox as we used to do (in addition to the map)? Poco2 10:14, 25 May 2018 (UTC)

@Poco a poco: We can show the coordinates if needed, it just makes the box a bit bigger. I thought the map was the more important thing to show instead of the numbers. But displaying the coordinates is now in the sandbox - try {{Wikidata Infobox/sandbox}} at your favourite geographical object category and let me know how it looks. Thanks. Mike Peel (talk) 12:42, 25 May 2018 (UTC)
Coordinates looks good, but I expect link to Geohack with wide selection of services (including local), not the maplink again. In case of linking to Geohack direct links to OpenStreetMap, Google Maps, Google Earth and Proximityrama are not necessary.--Jklamo (talk) 16:59, 25 May 2018 (UTC)
@Jklamo: Is there a template I can use to link to geohack? The direct links are to replace those shown in {{Object location}}, so they serve a different purpose (suggestions of how to make that more obvious in a multilingual way would be appreciated). Thanks. Mike Peel (talk) 17:20, 25 May 2018 (UTC)
I figured out the geohack link, so that's now implemented in the sandbox. Thanks. Mike Peel (talk) 17:26, 25 May 2018 (UTC)
Mike, it looks like an improvement to me, I don't think that the fact that the infobox is longer would be a problem, specially when the added information is at the bottom, so nobody have to scroll down to find what it usually looked for. Thank you! --Poco2 19:39, 25 May 2018 (UTC)
@Poco a poco and Jklamo: This is now live, please let me know if you spot any problems. Thanks. Mike Peel (talk) 21:05, 25 May 2018 (UTC)
This section was archived on a request by: Mike Peel (talk) 21:05, 25 May 2018 (UTC)

Line for industry (P452)

Please add support for property P452 (industry). This is useful to show what business companies are involved in. I've added it to the [ sandbox] and it appears to work just fine. Thanks! Josh (talk) 21:52, 25 May 2018 (UTC) 

industry -->{{#if:{{#property:P452|from={{getQID|qid={{{qid|}}}}}}}|<tr>
<td style="text-align: right; background: #ccf; padding-right: 0.4em;">'''{{ucfirst:{{#invoke:WikidataIB |getLabel |P452}}}}'''</td><td>{{#invoke:WikidataIB|getPreferredValue|P452|name=instance|linkprefix=":"|sep=",<br />"|qid={{getQID|qid={{{qid|}}}}}|suppressfields={{{suppressfields|}}}|fetchwikidata={{{fetchwikidata|ALL}}}|onlysourced={{{onlysourced|no}}}|noicon=yes}}</td></tr>}}<!--
@Joshbaumgartner: Thanks for the edit to the sandbox - it looked fine, so I already made this live with the last update to the infobox! Thanks. Mike Peel (talk) 22:20, 25 May 2018 (UTC)
Thanks Mike, you're fast! Josh (talk) 22:34, 25 May 2018 (UTC)
This section was archived on a request by: Mike Peel (talk) 22:56, 25 May 2018 (UTC)

Displaying qualifier values - please test the sandbox version!

Thanks to @RexxS, it's now possible to display qualifier values in the infobox. It's currently live at {{Wikidata Infobox/sandbox}} - please test that in your favourite categories, or see 'diameter' in [8], or 'material used' and the dimensions at [9]. There's a bug with the coordinates (see the links below the map); after that's fixed I'm hoping to make this new version live. Thanks. Mike Peel (talk) 22:30, 25 May 2018 (UTC)

This is now live. There is a known issue that it displays qualifier dates in English format rather than localised format, but if you spot any issues apart from that please comment here. Thanks. Mike Peel (talk) 21:36, 28 May 2018 (UTC)
Hi Mike, after your update several categories appear in category:Pages using duplicate arguments in template calls. The preview shows: "Warning: Template:Wikidata Infobox (edit) is calling Module:WikidataIB with more than one value for the "qual" parameter. Only the last value provided will be used.". --Arnd (talk) 11:16, 29 May 2018 (UTC)
Thanks for the heads-up - there was a duplicate in the diameter line. That's now fixed. Thanks. Mike Peel (talk) 11:51, 29 May 2018 (UTC)
Thank you for qualifiers. Jérémy-Günther-Heinz Jähnick (talk) 10:00, 31 May 2018 (UTC)
This section was archived on a request by: Mike Peel (talk) 22:12, 30 May 2018 (UTC)

Qualifier values – wikilinks

Sorry, but what is this good for? Have a look at Category:Villa Spiritus. The red wikilinks to the street number and the monument ID are unneccessary, not to say misleading or counterproductive. Thanks --Leit (talk) 11:24, 29 May 2018 (UTC)

I've removed the linking from those lines, it should look better now. Thanks. Mike Peel (talk) 11:52, 29 May 2018 (UTC)
This section was archived on a request by: Mike Peel (talk) 22:11, 30 May 2018 (UTC)

Error in Category:Emmanuel Le Maout

There is an error in Error in Category:Emmanuel Le Maout. --Jarekt (talk) 03:50, 1 June 2018 (UTC)

I can't see the error, but suspect that this edit probably fixed it by changing the year from 121869 to 1869. Thanks. Mike Peel (talk) 10:33, 1 June 2018 (UTC)
This section was archived on a request by: Mike Peel (talk) 12:46, 1 June 2018 (UTC)

Error in location template in category:Al Dente (Villefranche-sur-Saône)

--Arnd (talk) 08:49, 1 June 2018 (UTC)

This was a problem with the {{Object location}} call, where the 'wikidata=' parameter was set to al dente (Q181570) rather than Al Dente (Q54556023) - the first doesn't have coordinates, so there was nothing to show. I'm not sure why @Benoît Prieur: set it that way. However, the object location functionality is now in the infobox, so I've simply removed that template. Thanks. Mike Peel (talk) 10:31, 1 June 2018 (UTC)
Hi  sorry.
I did a mistake in indicating the wikidataid. The wrong one was opened on my browser (used just before to provide P138 value) and I used it in place of the right (and geolocated) one.
thanks for the vigilance. --Benoît Prieur (d) 10:36, 1 June 2018 (UTC)

✓ Done --Arnd (talk) 12:11, 1 June 2018 (UTC)

This section was archived on a request by: Mike Peel (talk) 12:46, 1 June 2018 (UTC)

where are grey map areas stored?

Category:Itaipu Dam (d:Q244169) is for the hydroelectric dam (building/power plant), but on the infobox map the grey area of the large lake (Category:Itaipu Reservoir, d:Q10315670) is wrongly shown. The dam was marked correct on the infobox map a couple of days/weeks before, pretty sure. I don't see where this can be changed (OSM relation statement or similar on Wikidata). Help appreciated. --Te750iv (talk) 10:15, 7 June 2018 (UTC)

@Te750iv: These are actually defined on OpenStreetMap, not on Wikidata, which means that changing them is rather complicated, sorry. The reason for that is that OSM IDs aren't stable, so rather than linking from Wikidata to OSM, OSM links to Wikidata. The links are defined as OSM tags to Wikidata IDs - to change it you need to find the object that currently has the wikidata ID, remove that ID, then find the correct ID and add it there. There is then a delay before that change is synced to the WMF servers. Perhaps @Sturm: can help here, as he's active both here and on OSM. Thanks. Mike Peel (talk) 11:04, 7 June 2018 (UTC)
Fixed on OSM, it will take a while to show up.--Jklamo (talk) 11:59, 7 June 2018 (UTC)
@Mike Peel and Jklamo: thanks for the good explanation and quick help. --Te750iv (talk) 13:11, 7 June 2018 (UTC)

just a note: Jklamo's OSM fix shows up on both infobox maps as of today. great! --Te750iv (talk) 16:11, 8 June 2018 (UTC)

This section was archived on a request by: Te750iv (talk) 13:11, 7 June 2018 (UTC)

Error

Error in Category:Jerzy Popiełuszko, Category:Audrey Tang, Category:Yoko Ono, Category:Pu Yi, Category:Guangxu Emperor, etc. --Jarekt (talk) 23:58, 1 June 2018 (UTC)

@Jarekt: Just spotted this sorry. I think this is the same as User_talk:RexxS#Bug - should now be fixed. Thanks. Mike Peel (talk) 18:59, 2 June 2018 (UTC)
Thanks, All my reports come from watching pages in Category:Pages with script errors. As I make corrections to Modules related to Module:Artwork I often introduce new really seen errors, so I monitor that category to spot and correct them. I only report problems where purging the page does not fix the issue. Like Category:How I Met Your Mother observed today. --Jarekt (talk) 13:55, 3 June 2018 (UTC)
This section was archived on a request by: Mike Peel (talk) 11:58, 17 June 2018 (UTC)

P39

IMHO the addition of position held (P39) cluttered the box too much when it comes to politicians. Example -> Category:Alfredo Pérez Rubalcaba. strakhov (talk) 18:45, 2 June 2018 (UTC)

I've set the sandbox version to auto-collapse that field if there's more than 6 values, demo on the category in question. Does that help, or should we remove that line? Thanks. Mike Peel (talk) 18:58, 2 June 2018 (UTC)
Hmmmm. As far as I'm concerned ...the collapse is enough for now. I mean, IMHO it's not the most needed data to be displayed in Commons (not many categories linked, not very multimedia-ish stuff, maybe too many details) but... someone could make use of it. Thanks! strakhov (talk) 19:46, 2 June 2018 (UTC)
This section was archived on a request by: Mike Peel (talk) 11:58, 17 June 2018 (UTC)

Display of labels

I've noticed lately that the box has a tendency to display the names of Commons galleries/categories, matched with the target WD element, rather then the label of this element in the language of user's interface. For example, Polish actress Patrycja Soliman was born in Cairo (Q85). The thing is that the box in her category displays, while using Polish as the language of interface, the Arabic name of the city, not the Polish one. I've had similar situations before and I think this is because this gallery has an Arabic name. I think this should be fixed. Powerek38 (talk) 15:39, 13 June 2018 (UTC)

I also see that for a temple in Asia. Jérémy-Günther-Heinz Jähnick (talk) 15:52, 13 June 2018 (UTC)
@Powerek38 and Jérémy-Günther-Heinz Jähnick: This was because we were showing the commons sitelinked name rather than the label, this should be fixed already. Thanks. Mike Peel (talk) 23:49, 14 June 2018 (UTC)
This section was archived on a request by: Mike Peel (talk) 11:57, 17 June 2018 (UTC)

Excessive width from non-breaking parts

See Category:Marvel Cinematic Universe. --ghouston (talk) 06:53, 14 June 2018 (UTC)

@Ghouston: Thanks, should now be fixed. Mike Peel (talk) 23:49, 14 June 2018 (UTC)
This section was archived on a request by: Mike Peel (talk) 11:57, 17 June 2018 (UTC)

Error in Category:Collégiale Saint-Pierre-et-Saint-Paul et Palais Delphinal de Saint Donat

Hi I bumped into error in Category:Collégiale Saint-Pierre-et-Saint-Paul et Palais Delphinal de Saint Donat, in case you do not know about it. --Jarekt (talk) 01:43, 17 June 2018 (UTC)

due to wrong 5-digit date, see [10]. --Te750iv (talk) 01:54, 17 June 2018 (UTC)
Thanks for checking. I should have figured it out before reporting. --Jarekt (talk) 02:26, 18 June 2018 (UTC)
This section was archived on a request by: Mike Peel (talk) 11:56, 17 June 2018 (UTC)

When no Wikidata item is known

When the template is used on a category with no known Wikidata item, it sensibly offers a "Create new Wikidata item" link. However, it also displays a Wikidata link, and "Reasonator" & "Scholia" links, and an "edit on Wikidata" pencil icon, which are not so good. Can these be suppressed, in such cases? And perhaps a "search Wikidata" link be added? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 12:29, 18 June 2018 (UTC)

@Pigsonthewing: how does {{Wikidata Infobox/sandbox}} look? Thanks. Mike Peel (talk) 21:04, 18 June 2018 (UTC)
@Mike Peel: Exactly what I had in mind, thank you - though on reflection I might be tempted to reverse the order. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 22:37, 19 June 2018 (UTC)
@Pigsonthewing: Order switched, and it's now live. Thanks. Mike Peel (talk) 23:07, 19 June 2018 (UTC)
@Mike Peel: Working well. Thank you again. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 12:23, 20 June 2018 (UTC)
This section was archived on a request by: Mike Peel (talk) 23:07, 19 June 2018 (UTC)

Error at Category:Francisco Javier Rodríguez Rodríguez

I noticed errors at errors at Category:Francisco Javier Rodríguez Rodríguez. --Jarekt (talk) 01:38, 24 June 2018 (UTC)

This section was archived on a request by: Mike Peel (talk) 10:48, 24 June 2018 (UTC)
I looked at the wikidata record this time but did not spot it. Thanks for fixing. --Jarekt (talk) 01:33, 25 June 2018 (UTC)

Errors at Category:Carbon

I just started a discussion about carbon_(Q623)_lists_1454_part_of_(P361)_properties, but perhaps we should have some safety measures in the code to prevent that. Or maybe we should just remove {{Wikidata Infobox}} from items like that. --Jarekt (talk) 02:21, 25 June 2018 (UTC)

@Jarekt: Um ... wow. I've added limits - it now has a cap of 30 'part of' statements, and auto-hides after 10. It's no longer showing the error. Thanks. Mike Peel (talk) 09:32, 25 June 2018 (UTC)
This section was archived on a request by: Mike Peel (talk) 21:03, 1 July 2018 (UTC)

Andrzej Duda

I was asked to investigate why Category:Andrzej Duda (and other categories) are autocategorized into Category:Poland and how to fix it. I think it is done by {{Wikidata Infobox}} but I could not find documentation on how to suppress it. --Jarekt (talk) 12:06, 26 June 2018 (UTC)

@Jarekt: It is through this template. this edit fixed it, but that shouldn't be happening anyway. Will look into a fix for that shortly. Thanks. Mike Peel (talk) 13:23, 26 June 2018 (UTC)
@Jarekt: Now fixed, it was a stray "quals=ALL" in the website URL for people, which I've removed. Thanks. Mike Peel (talk) 13:38, 26 June 2018 (UTC)
This section was archived on a request by: Mike Peel (talk) 21:01, 1 July 2018 (UTC)

Different language maps

Per this WMF blog post, kartographer now supports multiple language maps. I've added support for this into {{Wikidata Infobox/sandbox}}, and an example is at Category:Lovell Telescope (try Russian!). I'm double-checking at mw:Topic:Uc2aga6pune64rax to see if there might be any issues with this, before it's rolled out - probably next week as I'm going to be offline for most of this weekend. Thanks. Mike Peel (talk) 20:04, 28 June 2018 (UTC)

It turns out that if anything was going to go wrong, the infobox would have already made it go wrong - so this is now live with this edit. I also started a tracking category at Category:Uses of Wikidata Infobox with maps, but it's taking a while to fill up (this affects ~600,000 categories). Please let me know if there are any problems. Thanks. Mike Peel (talk) 23:02, 28 June 2018 (UTC)
This section was archived on a request by: Mike Peel (talk) 21:01, 1 July 2018 (UTC)

Retrieving coordinates of categories

Hi maintainers of the template, when i try to retrieve the coordinates of a category via the Wiki-API (example) i get an empty result although the WD item has coordinates (which are actually use within the IB). It this the expected behaviour? --Arnd (talk) 09:42, 1 July 2018 (UTC)

@Aschroet: Wikimedia Commons runs on MediaWiki – it is a kind of content management systems, although you should know it. Behaviour of its action=query is documented at mw:API:Query #query. Where do we see such value for prop= as “coordinates”? Incnis Mrsi (talk) 09:58, 1 July 2018 (UTC)
Incnis Mrsi, maybe it is not documented but see the behaviour for a file with coordintes (represented by the location template): https://commons.wikimedia.org/w/api.php?action=query&prop=coordinates&format=xml&colimit=10&titles=File:Pechofen_Bobeck_07.jpg. --Arnd (talk) 10:08, 1 July 2018 (UTC)
@Aschroet: I think this is documented at mw:Extension:GeoData? I've tried to implement this in the sandbox, please see if Category:Lovell Telescope works as expected. Thanks. Mike Peel (talk) 11:26, 1 July 2018 (UTC)
Thanks Mike. Looks fine for me. If nobody complains you could activate it for the main template. --Arnd (talk) 19:00, 1 July 2018 (UTC)
@Aschroet: Now live, please let me know if you spot any problems. Thanks. Mike Peel (talk) 21:00, 1 July 2018 (UTC)
This section was archived on a request by: Mike Peel (talk) 21:00, 1 July 2018 (UTC)

Error at Category:Streets in Togliatti

Another one of those strange items with large number of items listed in one of the properties. --Jarekt (talk) 02:03, 2 July 2018 (UTC)

Thanks for reporting it. Fixed by setting maxvals=30 for 'has part'. Thanks. Mike Peel (talk) 23:39, 2 July 2018 (UTC)
This section was archived on a request by: Mike Peel (talk) 23:39, 2 July 2018 (UTC)

indentation

The code is a bit dense. I recommand identation in that form (I did not change thee code one bit): Sitelinks -->{{#if:<!--
-->{{#invoke:Wikidata2|getSiteLink|{{siteID}}wiki|qid={{getQID|qid={{{qid|}}}}}}}<!--
-->{{#invoke:Wikidata2|getSiteLink|{{siteID}}wikiquote|qid{{getQID|qid={{{qid|}}}}}}}<!--
-->{{#invoke:Wikidata2|getSiteLink|{{siteID}}wikisource|qid{{getQID|qid={{{qid|}}}}}}}<!--
-->{{#invoke:Wikidata2|getSiteLink|specieswiki|qid{{getQID|qid={{{qid|}}}}}}}<!--
-->{{#invoke:Wikidata2|getSiteLink|{{siteID}}wikivoyage|qid={{getQID|qid={{{qid|}}}}}}}<!--
-->|<tr><td colspan=2 style="text-align: center; font-weight: bold;"><!--
 -->{{#if:{{#invoke:Wikidata2|getSiteLink|{{siteID}}wiki|qid={{getQID|qid={{{qid|}}}}}}}<!--
    -->|[[:{{projID}}:{{#invoke:Wikidata2|getSiteLink|{{siteID}}wiki|qid={{getQID|qid={{{qid|}}}}}}}|{{#invoke:WikidataIB |getLabel |Q52}}]]}}<!--
 -->{{#if:{{#invoke:Wikidata2|getSiteLink|{{siteID}}wikiquote|qid={{getQID|qid={{{qid|}}}}}}}<!--
   -->|<br />[[:wikiquote:{{projID}}:{{#invoke:Wikidata2|getSiteLink|{{siteID}}wikiquote|qid={{getQID|qid={{{qid|}}}}}}}<!--
 -->|{{#invoke:WikidataIB |getLabel |Q369}}]]}}<!--
 -->{{#if:{{#invoke:Wikidata2|getSiteLink|{{siteID}}wikisource|qid={{getQID|qid={{{qid|}}}}}}}<!--
   -->|<br />[[:wikisource:{{projID}}:{{#invoke:Wikidata2|getSiteLink|{{siteID}}wikisource|qid={{getQID|qid={{{qid|}}}}}}}|{{#invoke:WikidataIB |getLabel |Q263}}]]}}<!--
 -->{{#if:{{#invoke:Wikidata2|getSiteLink|specieswiki|qid={{getQID|qid={{{qid|}}}}}}}<!--
   -->|<br />[[:species:{{#invoke:Wikidata2|getSiteLink|specieswiki|qid={{getQID|qid={{{qid|}}}}}}}|{{#invoke:WikidataIB |getLabel |Q13679}}]]}}<!--
 -->{{#if:{{#invoke:Wikidata2|getSiteLink|{{siteID}}wikivoyage|qid={{getQID|qid={{{qid|}}}}}}}<!--
   -->|<br />[[:wikivoyage:{{projID}}:{{#invoke:Wikidata2|getSiteLink|{{siteID}}wikivoyage|qid={{getQID|qid={{{qid|}}}}}}}|{{#invoke:WikidataIB |getLabel |Q373}}]]}}<!--
 --></td></tr>}}<!--
BR Liné1 (talk) 13:56, 14 July 2018 (UTC)

@Liné1: Done, at the same time as adding the icons/logos that you suggested. Thanks. Mike Peel (talk) 14:47, 14 July 2018 (UTC)
Excellent the logos. Thanks Liné1 (talk) 15:08, 14 July 2018 (UTC)
This section was archived on a request by: Mike Peel (talk) 14:47, 14 July 2018 (UTC)

Far too many incorrect locations

The latest major error is Category:East New York (LIRR station), which is incorrectly located four blocks west of the real location. There was also Category:Captree State Park which is mislocated in the Fire Island Inlet, and one of the more blatant false locations like the Birdland Jazz Club in Hell's Kitchen in Manhattan mislocated in Hamburg, Germany! And this is far from the only error. ----DanTD (talk) 11:49, 24 June 2018 (UTC)

@DanTD: Most of these are due to incorrect coordinates in the Wikipedia articles, which were then imported into Wikidata and then used here. The best solution is to correct the coordinates on Wikidata and on the Wikipedias. Thanks. Mike Peel (talk) 11:54, 24 June 2018 (UTC)
Which is fine if you know the coordinates, but not otherwise. I saw another site that was incorrectly placed in a nearby waterway recently, but I can't remember where it was. ----DanTD (talk) 12:09, 24 June 2018 (UTC)
UPDATE - Here's the site. This church in Whitestone, Queens is not in the middle of the East River. ----DanTD (talk) 12:14, 24 June 2018 (UTC)
Here's another problem; Even if you know the coordinates, and you fill them in, you can't get them to stay there. ----DanTD (talk) 12:39, 24 June 2018 (UTC)
Rubbish. I just fixed the coordinates in Saint Nicholas Orthodox church in Whitestone (Q9187974), which simply needed the proper precision being set (0.0001 degrees). Please don't remove infoboxes just because you don't understand the precision of a location. --RexxS (talk) 17:50, 24 June 2018 (UTC)
Rubbish, you say? I put the proper categories in there too, and I found nothing there that gives you replace the incorrect location with the correct one. Also, if you don't want me to remove the infoboxes, don't put them in the wrong locations. -----DanTD (talk) 18:13, 24 June 2018 (UTC)
Yes, I said "rubbish", because that's an accurate description of your previous message: "Even if you know the coordinates, and you fill them in, you can't get them to stay there". I do know the coordinates, and I did fill them in, and they did stay there. The only inaccuracy in the location on Wikidata was the precision that was given for it. If the precision is given as ±1 mile, you can hardly be surprised if the map shows you something in the middle of the river. You need a certain amount of competence to edit Wikimedia projects, and until you acquire those skills, please leave fixing any problems to those who know how to do that. --RexxS (talk) 18:27, 24 June 2018 (UTC)
You don't know how I tried to get this to work. When I did know the coordinates (such as with the church in Whitestone), I actually tried to correct them, and I saw no editing tools that allowed you to do replace the incorrect coordinates with the correct ones. Thankfully, I was able to fix this problem with Captree State Park, and I might be able to fix this with a lot of other projects. Nevertheless I really don't like having to wait for other people to correct the errors. Now I just have to find a way to get User:RudolphousBot to add the Wikidata Infobox for Birdland (Hamburg jazz club) to the commons category for Birdland (New York jazz club). ----DanTD (talk) 18:45, 24 June 2018 (UTC)
Commons link for Birdland (Hamburg jazz club) now fixed -- Birdland (Q800176) had had an incorrect Commons category (P373) statement. Jheald (talk) 05:04, 25 June 2018 (UTC)
DanTD, this is wikipedia and if one user provides bad information it will stay in the system (and might get copied to other locations) until someone else fixes it or removes it. Using central data repository like Wikidata has a huge advantage because the bad data is looked at many more people who are more likely to correct it, otherwise it might stay bad for a long time. --Jarekt (talk) 02:27, 25 June 2018 (UTC)
This section was archived on a request by: Mike Peel (talk) 23:42, 23 July 2018 (UTC)

Wikimania poster

Hi all. I'm giving a poster presentation about the infobox at Wikimania later this month. The draft poster is here. It's just the text without images/design at the moment (I'm probably going to use a mix of different example infoboxes as the background, suggestions welcome!). I'd appreciate any comments on things that I've missed, explained badly, or shouldn't mention on the poster. The deadline for sending it to the WMF to be printed is this Friday, so please let me know any comments in the next few days. (pinging @RexxS, Jheald, Jarekt, Jmabel, Ghouston, and Pigsonthewing: but comments from everyone are welcome!) Thanks. Mike Peel (talk) 19:57, 3 July 2018 (UTC)

The poster seems fine and I think you captured all main points. Some comments:
  • In "Concepts" you say that Commons' default language is English. That might be defacto true, but per Commons:Language policy Commons is supposed to be multilingual with no preferences for one language of the other. The only exceptions are category names.
  • About "The infobox is not used where other boxes such as {{Creator}} are already in use": I noticed some pages with {{Wikidata Infobox}} and {{Artwork}}. Sometimes interacting badly, like here. We should probably avoid those too. Comment not on poster but on the bot jobs.
  • About "Taxonomy categories are also a special case, as there are a number of different taxonomy structures in use across different Wikimedia projects." I think the reason is that the information traditionally shown in Taxonomy categories like taxonomy tree are hard to get from Wikidata at the moment and might require accessing multiple items (expensive). We should be able to get it in the future. The part about "different Wikimedia projects" makes little sense.
  • I would mention the load impact, as that would be what I would be interested in. How many full items are downloaded on average. I am not sure if it is easy to access those stats.
  • About the future steps: I still think that eventually the template should be written in Lua, for ease of maintenance.
--Jarekt (talk) 21:02, 3 July 2018 (UTC)
@Mike Peel: I like the poster, and I think it will generate some real enthusiasm at Wikimania. Just a couple of points to follow on from Jarekt's comments:
  • When you call getContentLanguage, it returns English for Commons, so it's the content language, not the 'default' language that Mike means. However, we are able to use a hack to return the result of {{int:lang}} which will show the user's set language, and then apply the fallback chain to deal with values that are of type 'monolingual text' to try to get the best match (not always possible, of course).
  • At present, the infobox is still slowly evolving and it is important that Mike can drive that development; that would not be possible if the entire infobox were re-written in Lua. As a principle, I prefer to see development done in a programming medium where most editors can contribute. When we get to the stage where we think the infobox is not going to undergo any significant changes, I'll happily render the entire thing in Lua, if that's what people want. However, I should say that since the introduction of getBestStatements and getAllStatements, and the conversion of WikidataIB to use those instead of getEntity, each call now only retrieves the relevant property on each call (rather than the whole Wikidata item on each call). That dramatically reduces the advantage of coding the entire infobox in Lua.
I'll have a think about what else you might want to say, but it does look pretty comprehensive already. --RexxS (talk) 21:42, 3 July 2018 (UTC)
Thanks for the feedback. A few quick comments: 'defacto' is what I meant rather than 'default', I'll correct that. Pi bot does avoid the artwork template, but it looks like @Rudolphous's bot doesn't. Really that template sholudn't be used in categories, though! Thanks. Mike Peel (talk) 00:25, 4 July 2018 (UTC)
Included this too now and removed the infobox from a couple of them. Rudolphous (talk) 07:18, 4 July 2018 (UTC)
RexxS I agree that casting the template in Lua should happen after it stabilizes and stops evolving. I just suspects that it can be written in much more readable fashion. Mike Peel I also agree that {{Artwork}} infobox in categories might be an overkill, As I am working a lot with those templates at the moment I will try to get to the stage where it is actually safe to replace them, if we choose too. At the moment we still have ~50k files transcluting 12k {{Artwork}} templates stored in category pages, see Category:Pages using Category definition: Object template. Weird. --Jarekt (talk) 02:41, 4 July 2018 (UTC)
@Jarekt and RexxS: There's a new version at [11] that includes the layout/graphics. I'm still tweaking the text, so there's a chance for any last-minute comments (but will submit it in the next couple of hours). On taxonomy, the problem doesn't seem to be technological - even if/when we can replicate the taxonomy tree information from Wikidata, there's still fundamental differences in the data that need to be resolved. See the discussion at User_talk:Josve05a/Archive_10#Wikidata_Infobox. Thanks. Mike Peel (talk) 16:23, 6 July 2018 (UTC)
The final version is now at File:Wikimania2018 CommonsInfobox.pdf. Thanks. Mike Peel (talk) 16:48, 6 July 2018 (UTC)
This section was archived on a request by: Mike Peel (talk) 23:41, 23 July 2018 (UTC)

Mapshape inverted for certain locations

I've noticed that for locations such as airports, which have a geographical shape associated with them, the shape is inverted - instead of the area outside of the outline being shadowed, the area inside is. Has this been seen or reported before? MSG17 (talk) 19:28, 19 July 2018 (UTC)

@MSG17: This sounds like the normal behaviour? Kartographer highlights the associated area with the grey shading, not the area outside it. E.g. at Category:Manchester Airport, the airport area is shaded. Thanks. Mike Peel (talk) 19:34, 19 July 2018 (UTC)
So it's supposed to happen? OK. Still, the shading pretty much blacks out the area. Is there any way to highlight it in a more opaque manner? MSG17 (talk) 19:55, 19 July 2018 (UTC)
@MSG17: After some digging, I found a bug in the code for the colouring, which I've now fixed [12]. Can you have another look at the category to see if that's better? If it doesn't look any different, try adding "?action=purge" onto the end of the URL. If not, then I can adjust the opacity and colour to something fainter. Thanks. Mike Peel (talk) 20:28, 19 July 2018 (UTC)
Thanks, that looks much better. MSG17 (talk) 20:34, 19 July 2018 (UTC)
This section was archived on a request by: Mike Peel (talk) 23:40, 23 July 2018 (UTC)

Error in Category:Pacific Ocean

There is some issue with Error in Category:Pacific Ocean and few other oceans. --Jarekt (talk) 20:35, 22 July 2018 (UTC)

@Jarekt: Pacific Ocean (Q98) has about 410 entries for tributary (P974), but it seems there's a limit of around 390 imposed by the server. In the sandbox, I've set the field to only retrieve 20 tributaries and to autocollapse if there's more than 5. I've used the sandbox version to fix Category:Pacific Ocean for now. Some admin will have to update the code in Template:Wikidata Infobox to whatever values are wanted when they get a chance. Cheers --RexxS (talk) 13:24, 23 July 2018 (UTC)
@RexxS: Thanks for the fix. I'll sync it over soon, I want to make a couple of other changes first and merge them all in one go. Thanks. Mike Peel (talk) 22:46, 23 July 2018 (UTC)
Now synced over. Thanks. Mike Peel (talk) 23:40, 23 July 2018 (UTC)
This section was archived on a request by: Mike Peel (talk) 23:40, 23 July 2018 (UTC)

Warning: Default sort key "Neuenschwander, Marie, Bryn" overrides earlier default sort key "Brennan,Marie".

That doesn’t make any sense. The local DEFAULTSORT should always overwrite the Wikidata template, not the other way round. Rdgs •  • hugarheimur 14:05, 27 July 2018 (UTC)

@Torana: This kind of conflict needs manually figuring out. So if the infobox causes this kind of conflict, then the bot returns to the category to disable the defaultsort from the infobox. You spotted it before the bot came back to the page to do that, though. Thanks. Mike Peel (talk) 20:36, 27 July 2018 (UTC)
This section was archived on a request by: Mike Peel (talk) 22:32, 5 August 2018 (UTC)

Bad location on map?

There's something odd about the map on Category:Brooke Street Pier. Where are the coordinates coming from (42° 52′ 48″ S, 147° 19′ 48″ E)? They don't match the Wikidata value (42°53'7"S, 147°19'39"E), and are a few city blocks inland from the actual location of the pier. --ghouston (talk) 09:58, 5 August 2018 (UTC)

@Ghouston: It looks like there were two issues here. The first was that the uncertainty on the coordinates was set incorrectly on Wikidata - it was set to ~40 arcseconds rather than ~1 arcsecond, so there was a rounding error, that was fixed by [13]. The second was that the coordinates didn't match those from enwp somehow, so I re-copied them over [14]. It should hopefully look correct in the infobox in the category now. Thanks. Mike Peel (talk) 11:27, 5 August 2018 (UTC)
Thanks, it's strange that field in the Wikidata item page apparently wasn't displayed with the same rounding, but I'll know where to look next time. --ghouston (talk) 21:55, 5 August 2018 (UTC)
This section was archived on a request by: Mike Peel (talk) 22:31, 5 August 2018 (UTC)

Category loop

This template adds the wikicode [[Category:Minecraft]] in Category:Minecraft, which is a category loop. It happens in the software version identifier (P348) field, which is strange because the category is not used as qualifier in Minecraft (Q49740). I suppose it is redundant in this case to list applies to part (P518) and title (P1476). --bdijkstra (overleg) 07:54, 3 August 2018 (UTC)

@Bdijkstra: Thanks for spotting the bug, I've fixed it in {{Wikidata Infobox/sandbox}}, will make that live soon. Thanks. Mike Peel (talk) 22:29, 5 August 2018 (UTC)
Great! --bdijkstra (overleg) 06:17, 6 August 2018 (UTC)
@Bdijkstra: Now live. Thanks. Mike Peel (talk) 23:45, 6 August 2018 (UTC)
This section was archived on a request by: Mike Peel (talk) 23:45, 6 August 2018 (UTC)

Identifier: INE

Hi! Would it be possible including P772 as identifier in this template? Problem is... it has no formatter url in wikidata. It's somehow a complex thing (see this module: lines 22 to 41). (Example). If not possible offering the link, it would be 'OK enough' showing the number as plain text. Thanks, strakhov (talk) 12:39, 5 August 2018 (UTC)

@Strakhov: I've added it to the sandbox as plain text - try using {{Wikidata Infobox/sandbox}} at, e.g., Category:Madrid. Will make it live soon. Thanks. Mike Peel (talk) 22:24, 5 August 2018 (UTC)
Thanks. I tried it (successfully) with province-categories, municipality-categories and locality-categories, so I guess it works for everything. strakhov (talk) 11:52, 6 August 2018 (UTC)
@Strakhov: It's now live. Thanks. Mike Peel (talk) 23:46, 6 August 2018 (UTC)
This section was archived on a request by: Mike Peel (talk) 23:46, 6 August 2018 (UTC)

Floruit

On pages like Category:Grace Edwards, please can we display work period (start) (P2031)/work period (end) (P2032) dates (providing DoB/DoD, respectively, are not available)? floruit (P1317) may also be useful for other categories. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 12:18, 11 August 2018 (UTC)

@Pigsonthewing: Done (in yesterday's update). Thanks. Mike Peel (talk) 21:13, 19 August 2018 (UTC)
This section was archived on a request by: Mike Peel (talk) 21:13, 19 August 2018 (UTC)

Include P2783 and P3596

Is there a chance Danish ancient monument ID (P3596) and Danish listed buildings case ID (P2783) could be included?--Hjart (talk) 07:18, 19 August 2018 (UTC)

@Hjart: They are now in the sandbox, try {{Wikidata Infobox/sandbox}} for testing purposes. Do they have tracking categories that should be added as well? Thanks. Mike Peel (talk) 21:25, 19 August 2018 (UTC)
It works :-). I'm not sure what "tracking categories" are. Passage grave at Stursbøl (Q25917185) is an example that uses one of these properties.--Hjart (talk) 22:37, 19 August 2018 (UTC)
@Hjart: Great. :-) I was meaning along the lines of Category:HPIP with known IDs. Thanks. Mike Peel (talk) 23:18, 19 August 2018 (UTC)
Oh... They indeed have tracking categories: Category:Cultural heritage monuments in Denmark with known IDs and i.e. Markmandshuset was silently added to them. None of those in i.e. Kong Asgers Høj however, were added. --Hjart (talk) 08:51, 20 August 2018 (UTC)
@Hjart: OK, I've also added the two tracking categories, demo at Category:Jættestue ved Stursbøl and Category:Torbenfeldt Slot - how does that look? Thanks. Mike Peel (talk) 10:31, 20 August 2018 (UTC)
Looks good :-). I think a few guys will be happy to see it. --Hjart (talk) 11:33, 20 August 2018 (UTC)
@Hjart: This is now live. Thanks. Mike Peel (talk) 12:01, 23 August 2018 (UTC)
This section was archived on a request by: Mike Peel (talk) 12:01, 23 August 2018 (UTC)

Add surname category red links

Would it be possible to automatically categorize in "surname categories" [[:Category:<FamilyName> (surname)]] all persons having family name (P734) defined? It would be an incentive for creating missing surname categories. See for example Category:Alessia Gennari for which there is no Category:Gennari (surname) category. -- Laddo (talk) 19:52, 22 August 2018 (UTC)

@Laddo: The infobox currently checks to see if the surname category exists, and if it does then it adds it. You can set "test=y" and it will show the redlinks - that could be changed so that the redlinks are shown by default. However, surnames are complicated, as they vary between different languages (which is why Category:Uses of Wikidata Infobox with no family name has so many items!). Thanks. Mike Peel (talk) 22:15, 22 August 2018 (UTC)
@Mike Peel: "test=y" does exactly what I mean, i.e. red categ links only for cases where all that's missing is the creation of the Commons surname category itself. That's waaayyy much less than the 220000+ uses listed in Category:Uses of Wikidata Infobox with no family name... To assess the scope of changing the default behavior of the template, could it initially categorize in, say, Category:Uses of Wikidata Infobox missing surname category ? -- Laddo (talk) 23:26, 22 August 2018 (UTC)
@Laddo: That would work, I've made that change at [15] (please test it!). I'll deploy that (and the other changes currently in the sandbox) tomorrow. Thanks. Mike Peel (talk) 00:48, 23 August 2018 (UTC)
@Mike Peel: Wow thanks for the quick change. I tested various cases, behavior seems all OK. Anxious to see the result! -- Laddo (talk) 01:26, 23 August 2018 (UTC)
@Laddo: This is now live. Thanks. Mike Peel (talk) 12:01, 23 August 2018 (UTC)
This section was archived on a request by: Mike Peel (talk) 12:01, 23 August 2018 (UTC)

apostrophe encoding problem

see heritage designation at Category:Grand Canyon and America's Most Endangered Historic Places (Q4742563). The apostrophe ' in America's is given as 

&#39;

there. No problem with that on Wikidata noticable. --Te750iv (talk) 10:51, 2 August 2018 (UTC)

I think this is a bug with Module:WikidataIB - @RexxS: could you have a look please? Thanks. Mike Peel (talk) 22:30, 5 August 2018 (UTC)
Is there a particular reason why is the value not linked? The problem disappeared if you use linked=yes. The fault was in the unlinked part of the code that makes different languages available by using a different call, which seems to return the html entity instead of the actual character. I've re-written that part, but I'm not sure that it won't cause problems elsewhere now.
  • {{#invoke:WikidataIB |getValue |rank=best |P1435 |linked=yes |linkprefix=":" |qid=Q118841 |fwd=ALL |osd=no |noicon=yes |qual=ALL}} → America's Most Endangered Historic Places, National Treasure
  • {{#invoke:WikidataIB |getValue |rank=best |P1435 |linked=no |linkprefix=":" |qid=Q118841 |fwd=ALL |osd=no |noicon=yes |qual=ALL}} → America's Most Endangered Historic Places, National Treasure
Unlinked items will fall back to the content language, i.e. English here. Try changing you user language at Category:Grand Canyon to see what I mean. Let me know if more of these problems arise, but I'll try and look again at the code tomorrow to see if I can persuade the label to use the user language instead of the content language. --RexxS (talk) 00:02, 6 August 2018 (UTC)
Thanks! linked=no was set as qualifier values had redlinks at Category:Villa Spiritus, however that's no longer the case so the next version of the infobox will have linked=yes (currently in the sandbox). Thanks. Mike Peel (talk) 10:23, 6 August 2018 (UTC)
This section was archived on a request by: Mike Peel (talk) 23:41, 28 August 2018 (UTC)

about "version"

Version, for books, provides a link to a category for "first editions", which the version most often is not a first edition of (at least the "odds" are that it isn't).

Maybe it could link to whatever it is a version of instead?

See Category:Tales from Shakespeare and the versions which are some sub-directories for an example.--RaboKarbakian (talk) 17:59, 11 August 2018 (UTC)

@RaboKarbakian: This is quite a broad question, you might want to ask it at d:Wikidata:Project chat to get different people's feedback. My understanding is that different versions of books can have different Wikidata entries, and those can be linked to commons categories on the different version - as is done at Category:Tales from Shakespeare (19??). I've added edition or translation of (P629) to the sandbox of the version so that the back-link from the version to the main edition/overall topic item will be shown. I'm not sure if there's a property for the reverse, though. Thanks. Mike Peel (talk) 21:35, 19 August 2018 (UTC)
Since writing this, I have found the "of" of (P642) qualifier for version. Maybe that will help. Thanks for looking into this.--RaboKarbakian (talk) 02:42, 21 August 2018 (UTC)
This section was archived on a request by: Mike Peel (talk) 23:15, 28 August 2018 (UTC)

chess properties

For chess players, it would be very useful to add at least d:Property:P2962, d:Property:P1440 and d:Property:P1665. Steak (talk) 14:54, 14 August 2018 (UTC)

@Steak: I've added title of chess person (P2962). The authority control for people is done through {{Authority control}} - maybe @Jarekt: could add FIDE player ID (P1440) and Chessgames.com player ID (P1665) there? Thanks. Mike Peel (talk) 21:20, 19 August 2018 (UTC)
@Steak: No reply from @Jarekt: , so I figured out how to add them to authority control myself. All three properties should now be displayed where available. Thanks. Mike Peel (talk) 23:08, 28 August 2018 (UTC)
Sorry I saw it at the end of one day and forgot about it next day. Thanks for adding them to authority control template. --Jarekt (talk) 02:45, 29 August 2018 (UTC)
Thanks guys! Steak (talk) 07:44, 29 August 2018 (UTC)
This section was archived on a request by: Mike Peel (talk) 23:08, 28 August 2018 (UTC)

Small sorting issue

Hi again Mike. I noticed that Adama Diakhaby‎ is not correctly sorted in Category:Uses of Wikidata Infobox missing surname category. It's sorted based on given name (P735) rather than on family name (P734). I figured that Wikidata family name item "Diakhaby" / Diakhaby (Q54935611) / only bears Dutch and French label - so that, I guess, the combined sort string "<family name> <given name>" somehow leads to plain "Adama". As if the query was not using the language fallback scheme... Not a big issue, though. Cheers -- Laddo (talk) 20:07, 24 August 2018 (UTC)

@Laddo: The family name has to have a label in English, otherwise this doesn't work. English is the last language in the fallback scheme, so there's nothing more to fall back on, and you end up with the Q-code - which is then not displayed. Thanks. Mike Peel (talk) 20:28, 24 August 2018 (UTC)
Noted, thanks. I'll rather fix labels of Diakhaby (Q54935611) then. -- Laddo (talk) 00:40, 25 August 2018 (UTC)
This section was archived on a request by: Mike Peel (talk) 23:09, 28 August 2018 (UTC)

"unknown value"/"no value" for P625 leading to a rendering error

Example: Category:Synagogue de Lingolsheim resp. Category:Drottningholm (ship, 1909). However, i am not sure if "unknown value" is a valid value/information on WD. --Arnd (talk) 06:36, 24 July 2018 (UTC)

It is inaccurate to have "no value" as an entry for coordinate location (P625) for a vessel that clearly exists, so I've removed it from Drottningholm (Q10659251). If there are other examples, then we need to look at the Wikidata for errors. It is conceivable that "some value" or "no value" may be viable values for some cases, so we may then need to deal with those in the template. --RexxS (talk) 15:32, 24 July 2018 (UTC)
This section was archived on a request by: Mike Peel (talk) 23:08, 29 August 2018 (UTC)

Tottenville, Staten Island and other NYC errors

Is there any way you can move the coordinates for Category:Tottenville, Staten Island out of Arthur Kill and onto dry land? I know we've had these discussions before, but I'm really not sure exactly where on land they should be located. I also recently found another site in New York City who's coordinates were way far southeast of New York Harbor, but I can't remember what that site was right now. ----DanTD (talk) 16:20, 29 August 2018 (UTC)

NeverDoING has corrected the coordinates on Wikidata now. --RexxS (talk) 19:20, 29 August 2018 (UTC)
This section was archived on a request by: Mike Peel (talk) 21:37, 29 August 2018 (UTC)

P17/country missing

I can't find any reason on Wikidata: Why is the location information incomplete (missing country: Luxembourg) at Category:Biwelser Millen? And why is Putscheid unlinked at Category:Bivels (where Luxembourg is also missing)? --Te750iv (talk) 20:52, 3 September 2018 (UTC)

@RexxS: looks like this is a bug in the logic for the location code in WikidataIB. Thanks. Mike Peel (talk) 21:57, 3 September 2018 (UTC)
@Mike Peel: There's no bug. The location function doesn't return country. Country is used at far too many levels of the hierarchical chain to be of any use. It returns the chain of located in the administrative territorial entity (P131) or location (P276) or located in/on physical feature (P706). Since Putscheid (Q513740) has none of those properties, the chain stops there. That's how the logic works. It seems Putscheid isn't located anywhere according to Wikidata. --RexxS (talk) 22:14, 3 September 2018 (UTC)
@RexxS: . I thought the last thing it did was fetch the country (P17) value at the end of the chain, which is how "United Kingdom" is appearing at Category:Lovell Telescope... Maybe that only happens after the first level though? Thanks. Mike Peel (talk) 22:20, 3 September 2018 (UTC)
Aah, I see - this edit was needed. @Te750iv: does that look OK to you now? Thanks. Mike Peel (talk) 22:23, 3 September 2018 (UTC)
No Mike, it never returns the value of property country (P17) because that can often be found in almost step of the chain. It simply works up the chain until the entity has none of the properties P131 / P276 / P706, or the entity is an instance of (P31) a country (Q6256), then it stops. The "United Kingdom" is appearing at Category:Lovell Telescope because it's the value of located in the administrative territorial entity (P131) for England (Q21) (the previous step). The infobox can therefore be quite useful for spotting items that are not linked to their parent geographical entity (as Putscheid wasn't). The solution is then to make the missing link. Cheers --RexxS (talk) 23:58, 3 September 2018 (UTC)
@Mike Peel: thanks for spotting the missing P131 info. Problems solved for the two categories.
@RexxS: Do I understand correctly, and P17 is now only used if there is no P131 statement? P17 is used in some cases obviously, e.g. here.
Incomplete P131 chains exist for numerous items and numerous countries. This overall issue is not likely to be fixed on Wikidata alone in short time. Is there a way to find them, maybe by a new Infobox maintenance category? --Te750iv (talk) 00:26, 4 September 2018 (UTC)
@Te750iv: You understand correctly. If there is no P131 or P276 or P706 to start a chain with the WikidataIB|location function, then the infobox template uses the WikidataIB|getValue function to return the value(s) of P17.
I don't think the Lua-Wikibase functionality is currently sufficient to search for broken chains. That really is the province of SPARQL queries where you can ask for a list of geographical items that have no P131 or P276 or P706, but are not an instance of country. HTH --RexxS (talk) 01:27, 4 September 2018 (UTC)
This section was archived on a request by: Mike Peel (talk) 12:49, 4 September 2018 (UTC)

Rotated image

On Category:Vestedatoren, I'm seeing the image in the infobox rotated 90 degrees to the left. Odd, since the image is fine when displaying elsewhere. --ghouston (talk) 01:07, 31 August 2018 (UTC)

Even more oddly, if I go to the Wikidata item, then click on the Commons link in Other Sites at the bottom of the page, it displays the category with the image the right way up. But then if I refresh the page, it's sideways again. --ghouston (talk) 04:22, 31 August 2018 (UTC)
That's very odd. I can't reproduce the problem here. Which browser/OS are you using? Thanks. Mike Peel (talk) 09:48, 31 August 2018 (UTC)
Firefox on Linux. The size of the browser window doesn't seem to matter. It's sometimes OK, but goes bad after a refresh. --ghouston (talk) 10:10, 31 August 2018 (UTC)
Actually I think it has nothing to do with the infobox itself. The image is quite low resolution, so the infobox is presumably displaying the original image, not a thumbnail. I think the thumbnails are good, but the original image at [16] is rotated, at least with my setup. --ghouston (talk) 22:25, 31 August 2018 (UTC)
If I download the original image and open it in Gimp, it gives a message at startup: According to EXIF data, this image is rotated. Would you like GIMP to rotate it into the standard orientation? --ghouston (talk) 22:29, 31 August 2018 (UTC)
I was just about to mention to you that the EXIF orientation field of that jpeg is set to "Rotate 270 CW". Perhaps your JPEG renderer is out of date? —RP88 (talk) 22:30, 31 August 2018 (UTC)
Or for that matter, http://exif.regex.info shows that the EXIF data for the original image looks sort of weird with many duplicated fields. In particular, the Orientation field is duplicated, with the first showing no rotation and the second showing 270° CW, so it may be a case of corrupted EXIF with some renderers using the first Orientation field and others using the last Orientation field. —RP88 (talk) 22:36, 31 August 2018 (UTC)
Yes, that's likely the problem. I should be able to fix it by uploading a replacement image with the incorrect Orientation field removed. I'll put a better image into Wikidata first though, since it's not the best one anyway. --ghouston (talk) 22:41, 31 August 2018 (UTC)
Thanks to RP88 for finding the problem — Preceding unsigned comment added by Ghouston (talk • contribs) 23:16, 31 August 2018‎ (UTC)
Checkmark This section is resolved and can be archived. If you disagree, replace this template with your comment. Mike Peel (talk) 23:21, 5 September 2018 (UTC)

Airport codes

{{Editprotected}} There is currently two problems with the airport codes:

  • The label for the ICAO code (P239) is used also for the IATA code (P238).
  • There is a typo ("ICOA") in a comment related to the ICAO code. This problem does not affect to the functionality of the template, of course.

Thus, the following code: 

IATA airport code -->{{#if:{{#property:P238|from={{getQID|qid={{{qid|}}}}}}}|<tr>
<td style="text-align: right; background: #ccf; padding-right: 0.4em;">'''{{ucfirst:{{#invoke:WikidataIB |getLabel |P239}}}}'''</td><td>{{#invoke:WikidataIB|getValue|rank=best|P238|name=iata|link=no|list=ubl|qid={{getQID|qid={{{qid|}}}}}|spf={{{suppressfields|}}}|fwd=ALL|osd=no|noicon=yes|qual=ALL}}</td></tr>}}<!--

ICOA airport code -->{{#if:{{#property:P239|from={{getQID|qid={{{qid|}}}}}}}|<tr>
<td style="text-align: right; background: #ccf; padding-right: 0.4em;">'''{{ucfirst:{{#invoke:WikidataIB |getLabel |P239}}}}'''</td><td>{{#invoke:WikidataIB|getValue|rank=best|P239|name=iata|link=no|list=ubl|qid={{getQID|qid={{{qid|}}}}}|spf={{{suppressfields|}}}|fwd=ALL|osd=no|noicon=yes|qual=ALL}}</td></tr>}}<!--

shoud be replaced with the following code: 

IATA airport code -->{{#if:{{#property:P238|from={{getQID|qid={{{qid|}}}}}}}|<tr>
<td style="text-align: right; background: #ccf; padding-right: 0.4em;">'''{{ucfirst:{{#invoke:WikidataIB |getLabel |P238}}}}'''</td><td>{{#invoke:WikidataIB|getValue|rank=best|P238|name=iata|link=no|list=ubl|qid={{getQID|qid={{{qid|}}}}}|spf={{{suppressfields|}}}|fwd=ALL|osd=no|noicon=yes|qual=ALL}}</td></tr>}}<!--

ICAO airport code -->{{#if:{{#property:P239|from={{getQID|qid={{{qid|}}}}}}}|<tr>
<td style="text-align: right; background: #ccf; padding-right: 0.4em;">'''{{ucfirst:{{#invoke:WikidataIB |getLabel |P239}}}}'''</td><td>{{#invoke:WikidataIB|getValue|rank=best|P239|name=iata|link=no|list=ubl|qid={{getQID|qid={{{qid|}}}}}|spf={{{suppressfields|}}}|fwd=ALL|osd=no|noicon=yes|qual=ALL}}</td></tr>}}<!--

Best regards, Apalsola t • c 15:37, 4 September 2018 (UTC)

@Apalsola: Done, thanks for catching the errors! Thanks. Mike Peel (talk) 23:17, 5 September 2018 (UTC)
This section was archived on a request by: Mike Peel (talk) 23:17, 5 September 2018 (UTC)

Do we want to have a horizontal display option?

'Why is this infobox vertical rather than horizontal?' is turning into a frequently asked question. When I started it, I was planning on having a horizontal box to fit in with other templates here. However, @DarwIn: pointed out that having a vertical template meant that the category content - the lists of subcategories and images - was always at the start of the page, which made the categories easier to use/maintain/read. Since then it's been vertical, and that has meant that the first few rows of images might end one image earlier, but that's OK. It's also meant that there's a conflict with other templates here that use "clear:both" in their css styling, which creates a lot of unnecessary whitespace if the infobox is placed above them, but if it's placed below then there's no problem. Having a vertical infobox is also the norm on Wikipedias. So by and large, the vertical format seems OK to me. But still, people are asking 'why not have it horizontal'?

It should actually be very straightforward to convert this to a horizontal template. We just need to change some of the css to move it to the left of the page, and add an extra table layer to break up the existing columns into a set of columns, having the images in the first column, data in the second (and maybe also the third) column, then the map in the last column. I can probably add a parameter like "horizontal=yes" that would make those changes, although it will make the code a bit more complicated. Is that something that would be useful in particular cases/topics, or is it better to use the vertical infobox format uniformly across all categories? Mike Peel (talk) 00:23, 16 April 2018 (UTC)

Mike Peel - the shortest answer for me is: YES, of course!
Both options have advantages and disadvantages. An argument that something was always don't mean that it should be always and - Wikipedia (is for reading; most of text with some illustrations) is something else as Commons (is for watching; contains near only pictures), so simple comparison is unjustified.
Personally, I prefer the horizontal variant and there is many arguments to support it, but not in every situation, nor for every category. So, we must decide which variant will be default and, regardless of result - possibility to switch H <-> V form will be very needful. Mike, if it's not a big problem, maybe we can try the both versions together and see how it looks like in the real situations, without guessing? --Jasc PL (talk) 02:32, 17 April 2018 (UTC)
@Jasc PL: As a test, try {{Wikidata Infobox/sandbox|horizontal=yes}}. The main issue is probably that the column breaks might not be in the right place in different categories, as it depends on how much content is available. I can try to tweak them if need be. Here's how it looks for Category:Lovell Telescope. Thanks. Mike Peel (talk) 23:05, 17 April 2018 (UTC)

Template:Wikidata Infobox/horizontal

I was so excited before first try @Mike Peel and still I am, but some things goes wrong in the first test version - examples are at the dedicated sandbox. Feel free to use it anywise you need, I 'll put there some more examples I find:
@Mike Peel, there are also tons of ready javascripts for every situations, but it consuming extra time, we haven't now of course. I feel that work with horizontal version should not stop deployment of "classic" vertical variant what will be more appropriate for most categories, so default. By the way:
  • mascot (P822) need to be scaled down in the same way as logo image (P154)
  • There is a small bug (probably not concerned with infobox directly) with the link under map: when the mouse is from the left over "Wikidata: Qxxx, Wikimedia maps" rolling out element is blinking, when you try from the right - all is as should be. Tested with FF 56 (Gecko), Iron (Chrome) 65, Opera 50
  • I see that some qualifiers need to have the rank set to preferred, otherwise we have a long list of values with normal rank (e.g. Raspberry Pi - operating system = 15 :) --Jasc PL (talk) 21:56, 18 April 2018 (UTC)
@Jasc PL: This is definitely a bonus feature, so shouldn't hold up the deployment, and if we want to convert a given topic to use the horizontal version in the future then it should be simple to write a bot to do that. Javascript would work, but that will cause a two-stage loading problem, and I want to avoid that. Maybe something could be done using Lua to count elements that will be shown and divide them up into rows accordingly, but fully Lua-using this is still a way off (and probably isn't something I'll be doing, since I don't know Lua). We're not using P822 at the moment, want me to add it? I can't reproduce the bug using FF 59, but see it in Chrome 65; that must be a bug with Kartographer, so I suggest you take that to phabricator. Normal rank values will show up when there's no preferred rank value, that's the expected behaviour. Thanks. Mike Peel (talk) 22:14, 18 April 2018 (UTC)
Thanks for your answer @Mike Peel: ; I don't know how many items use mascot (P822), but it's popular by Linux categories, e.g. Slackware, so - YES. --Jasc PL (talk) 22:34, 18 April 2018 (UTC)
I was expecting it to be an image, but it turns out to be a link. Anyhow, now added to the sandbox for testing. Thanks. Mike Peel (talk) 22:49, 18 April 2018 (UTC)
Sorry @Mike Peel, my mistake, and the effect of work in the nights; at the Slackware Category there is a Linux mascot (Slackware-mascot.png), but it's a regular image (P18). --Jasc PL (talk) 23:42, 19 April 2018 (UTC)
@Mike Peel: , @Jasc PL: I'm exited for the option of a horizontal display which works a lot better for some applications. The work so far looks promising. One of the advantages of a horizontal format is that the fields can be wider and there doesn't have to be so much uncomfortable word wrapping going on, so freeing it up to . Right now if there is no image, you get a lot of white space on the left which could be put to better use. One thing I'm thinking is that we can maybe have a couple of options for how it is oriented. Maybe instead of merely thinking of it as a boolean horizontal option, it could be a general 'orientation' or 'style' option ('vertical' (force the vertical choice), 'horizontal' (force horizontal), 'horizontal-noimage' (optimized for those that may not need an image displayed), etc.) which would default to vertical but allow possibly a few different options to best meet editors' needs. Anyway, looking forward to working on it going forward. Josh (talk) 22:28, 25 May 2018 (UTC)
@Jasc PL and Joshbaumgartner: I had another play with this, and I now have something that works in some browsers (tested on Chrome and Safari) but not others (Firefox). It's a per-user css configuration. If you want to give it a go, try copying the contents of User:Mike_Peel/vector.css to your own vector.css file. It should then look something like this:
Let me know how that goes. Thanks. Mike Peel (talk) 04:09, 23 July 2018 (UTC)
This section was archived on a request by: Mike Peel (talk) 23:50, 7 September 2018 (UTC)

Unnecessary links

Do we really need Scholia, Reasonator and so on? As a ordinary John Doe user I wouldn't get any meaning out of this pages when clicking on this links.--Ditch Witch (talk) 17:27, 21 April 2018 (UTC)

Thanks for bringing this to the talk page. I was asked to add them by editors who are hopefully watching this page, so hopefully they'll comment on this. Personally, I find the wikishootme link particularly useful. Thanks. Mike Peel (talk) 17:44, 21 April 2018 (UTC)
Mike, let me paste one of my comments placed at the first topic (Wishlist):
  • 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? - or arrow right / arrow down, as a switch? --Jasc PL (talk) 15:44, 22 April 2018 (UTC)
I think that's mixing two somewhat separate points, although we could move the tools to the authority control show/hide section to handle them together. The norm here with {{Authority control}} and similar has been to show the numbers. As long as the links/IDs are accessible, I personally don't mind if they are hidden or not. But @Pigsonthewing: has been arguing for showing them here by default in the past - any comments? Thanks. Mike Peel (talk) 23:30, 22 April 2018 (UTC)
Mike, he best conclusions are usually based on the real effects; some tool links in one line are not a special problem - yet; authority items often are not also - but we have many categories with a big amount of such links and this amount will be still expand. E.g. big cities, notable persons, important objects or so. Unfortunately I can't show it by ready examples, as Yann has deleted yesterday my whole sandbox page in my user space - User:Jasc PL/WDinfoboxTEST and ignoring my questions why? So, if I haven't any safe working space, I must stop any further works - sorry. --Jasc PL (talk) 17:17, 23 April 2018 (UTC)
Thanks Mike :/. Not the big cities, but the notable and/or popular Peoples are one of the real problem in the context of Authority control. BTW, there is a quite good example of what should be (visible) in the infobox (horizontal variant at the top), and what is much to much - resulting the excessively big dimensions of the box. I have some good (I hope) ideas how to play with such problems, but need some time to prepare the visual example. --Jasc PL (talk) 19:21, 23 April 2018 (UTC)
Could we add the option for individually suppressing the display of certain properties? For example, if on Category:Air Tractor, I didn't want to show the inception date, have an option like 'hideP571=yes' that would just simply skip that line? This could help cut down on some long ones where there is extra data not really needed for the infobox. It may also help as we develop a horizontal format to make it work more cleanly. Josh (talk) 22:38, 25 May 2018 (UTC)
This section was archived on a request by: Mike Peel (talk) 23:53, 7 September 2018 (UTC)

error?

currently i see the text string [[File:|95px]] below the infobox image at Category:Blankenfelde-Mahlow. no clue where it could come from. --Te750iv (talk) 18:54, 1 May 2018 (UTC)

@Te750iv: Should be gone now, with this edit on Wikidata. I'll have a think about how to better catch that oddity. Thanks. Mike Peel (talk) 20:06, 1 May 2018 (UTC)
This section was archived on a request by: Mike Peel (talk) 23:54, 7 September 2018 (UTC)

grayed out map

Please can you have a look at Category:Austria, where the osm map is greyed out (and thus worse to read). What is the meaning of this? can this be generally undone? Or at least added some docu on the template's doc page? --Herzi Pinki (talk) 17:47, 30 May 2018 (UTC)

If you zoom out, you'll see that the outline of Austria is being highlighted. At some point soon I hope to automate the zoom level of the map so that this works better. Thanks. Mike Peel (talk) 18:11, 30 May 2018 (UTC)
@Herzi Pinki and Jarekt and all: auto-zoom for the map (based on area (P2046)) is now available at {{Wikidata Infobox/sandbox}}. Some test examples are shown in User:Mike Peel/Mapzoom examples. Please try it and see how it looks. Thanks. Mike Peel (talk) 22:09, 30 May 2018 (UTC)
Much better for me (in Category:Austria), as now it is obvious what the grey color is used for. And there is no need to see any details for such an arbitrary coordinate. --Herzi Pinki (talk) 22:29, 30 May 2018 (UTC)
This section was archived on a request by: Mike Peel (talk) 23:55, 7 September 2018 (UTC)

property links

Why are some property values linked, and some not? E.g., on Category:Lovell Telescope, "Jodrell Bank Observatory" is linked, but "radio telescope" and "United Kingdom" are not. --ghouston (talk) 21:57, 27 February 2018 (UTC)

@Ghouston: Broadly speaking, it depends on the links available on Wikidata. If there is a sitelink on the page for the property, then a link is shown here. If there isn't, or if the sitelink is on a "category" Wikidata item rather than the main one, then there's no link shown here. In the long term, I hope that we can show more links rather than less. Thanks. Mike Peel (talk) 22:18, 27 February 2018 (UTC)
Why not use the P373 value for the link? --ghouston (talk) 22:45, 27 February 2018 (UTC)
We could do that. In principle that should be identical to using the sitelink either from the main item (which we already have) or the category item (which we don't yet have). However, both approaches need someone who knows Lua (like @RexxS) to implement in Module:WikidataIB. Thanks. Mike Peel (talk) 22:50, 27 February 2018 (UTC)
WikidataIB's getValue with a qid parameter maybe? Apparently looking up a Wikidata item by qid is "expensive", except for the item connected to the current page. But that will be a potential problem regardless of whether a sitelink or a P373 value is taken from the other items. But getting a sitelink from a category item would be worse, because that would be an extra lookup. --ghouston (talk) 23:11, 27 February 2018 (UTC)
  • @Mike Peel and RexxS: Could we bump this? Now that it seems references-by-QID may not be quite so expensive as was once thought, it would be really good to turn more black-text items into blue links, if a QID-valued statement has a P373 but not a sitelink. Particularly useful for values of category combines topics (P971), but probably many other properties too. Jheald (talk) 13:43, 23 June 2018 (UTC)

@Mike Peel and Jheald: The Module:WikidataIB now links the label to Commons category (P373) where it exists, if there is no sitelink. Check some samples for errors when you get a chance, please. --RexxS (talk) 16:45, 24 June 2018 (UTC)

@RexxS, Mike Peel, and Ghouston: Just checked a few examples, and this is now incredibly impressive. We're now at the stage, where if a link is black text, that is now a real flag to the user: why is this link still black text, why isn't it blue text yet? That's a real step change, and from the talk page is clear is becoming a really powerful engine for navigability of Commons, and data improvement on Wikidata. And it looks as though the servers have coped with the step-up without melting. Huge kudos to both of you!
One further request. Where there is a sitelink to a gallery, but also a P373 to a category, could you switch the blue link to follow the P373? The reason being that categories have infoboxes (and are generally more primary), but galleries don't, so if the link goes to the category one can continue navigating through Commons from infobox to infobox -- something which the switch from black text to blue links is really now making very impressive!
(Example: navigating from the infobox on Category:University museums to 'museum', it would be nice if this took one to Category:Museums rather than Museum) Jheald (talk) 19:02, 24 June 2018 (UTC)
Question: on Category:Fitzwilliam Museum, why is 'heritage designation': 'Grade I listed building' not appearing as a blue link to Category:Grade I listed buildings ? There's a Commons category (P373) on Grade I listed building (Q15700818), so at first sight it all ought to join up? Jheald (talk) 19:26, 24 June 2018 (UTC)
(Edit conflict) @Jheald: is that equivalent to saying that where a P373 exists, it should be preferred to a sitelink in all cases? If so, that would be easy to implement, I think. --RexxS (talk) 19:32, 24 June 2018 (UTC)
@RexxS: Yes. I think that would be a good step. Almost all wikipedias now link to Commons categories if possible rather than galleries, and I think that would make sense for the infoboxes too. Jheald (talk) 19:35, 24 June 2018 (UTC)
@Jheald and Mike Peel: The lack of linking is because Template:Wikidata Infobox has this in its call for heritage designation (P1435):
  • {{#invoke:WikidataIB|getValue|rank=best|P1435|name=heritage|linked=no|list=ubl|qid={{getQID|qid={{{qid|}}}}}|spf={{{suppressfields|}}}|fwd=ALL|osd=no|noicon=yes|qual=ALL}}
The |linked=no suppresses any linking. You'll have to check with Mike for his thinking on that one. --RexxS (talk) 19:46, 24 June 2018 (UTC)
@RexxS and Jheald: The problem there was that there are heritage statuses with the number attached to them through a qualifier, and that was also being linked. I'm not sure if it's possible to disable links for qualifier while keeping them for the main properties? Thanks. Mike Peel (talk) 19:49, 24 June 2018 (UTC)
@Jheald: Category:University museums now links to Category:Museums instead of Museum.
@Mike Peel: Anything is possible, but some things are impractical. I'll have to think about unlinking qualifiers. Maybe I should make a qlinked parameter? I'll have to think about that. --RexxS (talk) 20:22, 24 June 2018 (UTC)
Thanks. An alternative might be to avoid redlinks (the numbers sometimes appeared as 12-34-56 for example). Thanks. Mike Peel (talk) 20:26, 24 June 2018 (UTC)
This section was archived on a request by: Mike Peel (talk) 19:09, 23 September 2018 (UTC)

Default hide?

I wish I could hide the infobox by default, as it is often so long that it intrudes in the list of categories and files. Is there a switch in the user preferences for this kind of thing? --Schlosser67 (talk) 14:23, 18 May 2018 (UTC)

@Schlosser67: From the documentation, "It can be hidden by adding #wdinfobox { display: none;} to Special:MyPage/common.css." Thanks. Mike Peel (talk) 14:46, 18 May 2018 (UTC)
Thanks, but this code does a bit too much - it hides the infoboxes completely. I'd rather see that they are there, but at reduced size ("Title [Show]"). --Schlosser67 (talk) 14:57, 18 May 2018 (UTC)
Hmm. That needs some way of passing the "mw-collapsed" class to id="wdinfobox". I looked into that before, but couldn't find a good way to do that... Thanks. Mike Peel (talk) 15:10, 18 May 2018 (UTC)
Just as a little encouragement: If you - or anybody else - could find a way to do this, I'd greatly appreciate it. --Schlosser67 (talk) 05:20, 6 June 2018 (UTC)
@Schlosser67: I think I just figured out how you can do this. Try adding $( "#wdinfobox" ).addClass( "mw-collapsed" ); to Special:MyPage/common.js. Thanks. Mike Peel (talk) 22:29, 10 September 2018 (UTC)
This section was archived on a request by: Mike Peel (talk) 19:10, 23 September 2018 (UTC)

Maps of categories

I haven't been paying attention to the efforts to put Wikidata to work in Commons, but noticed problems in two categories, namely Category:Lady Franklin Bay Expedition and Category:Denmark Expedition. The various maps bring us to Null Island or nowhere, or are at wrong scale resulting in showing only a featureless blue sea. Presumably other categories have similar mapping problems. I hope these matters are already being worked on and my notice is unnecessary. Jim.henderson (talk) 11:52, 30 May 2018 (UTC)

@Jim.henderson: It looks like the maps are working OK, but the coordinates are in the middle of nowhere so there's nothing to show in them. In both cases the coordinates were imported from Wikipedia (en and da respectively). I'm not sure if they should be removed from Wikidata or if they are useful coordinates to have... Thanks. Mike Peel (talk) 12:22, 30 May 2018 (UTC)
I had another look at this, and ended up removing the coordinates from Wikidata as they're not relevant. Thanks. Mike Peel (talk) 19:15, 23 September 2018 (UTC)
This section was archived on a request by: Mike Peel (talk) 19:15, 23 September 2018 (UTC)

Errors at Category:Meryl Streep

There are errors at Category:Meryl Streep category. --Jarekt (talk) 12:31, 30 May 2018 (UTC)

Looks like an issue where the qualifier has "no value". @RexxS: can you have a look please? Thanks. Mike Peel (talk) 12:41, 30 May 2018 (UTC)
It's specific to setting "qual=DATES", so I've applied a work-around to show qual=ALL for now. Minimal code to reproduce the bug:
{{#invoke:WikidataIB |getValue |qid=Q873 |P26 |fwd=ALL |osd=no |collapse=0|linkprefix=":"|qual=DATES}}
Thanks. Mike Peel (talk) 12:48, 30 May 2018 (UTC)
Thank for spotting that. I set the function that returns the values of P580/P582 to give nil when the value is 'no value' (which can't be concatenated). I've now trapped that and set it to the empty string (which can be concatenated). Is this output what you wanted?
  • {{#invoke:WikidataIB |getValue |qid=Q873 |P26 |fwd=ALL |osd=no |collapse=0|linkprefix=":"|qual=DATES}} → Don Gummer (1978–) Edit this on Wikidata
Let me know if you think something different would be better. --RexxS (talk) 13:24, 30 May 2018 (UTC)
That seems to work fine, thanks for the quick fix! Mike Peel (talk) 13:27, 30 May 2018 (UTC)
Thanks, There is another at Category:Joseph Souham which does not seem related. --Jarekt (talk) 13:08, 30 May 2018 (UTC)
Hmm, this one seems to be because @Totorvdr59: set the date to '1 May 18121' for some reason. Minimal code to reproduce:
{{#invoke:WikidataIB |getValue |qid=Q1064944 |P166 |fwd=ALL |osd=no |collapse=0|linkprefix=":"|qual=ALL}}
Thanks. Mike Peel (talk) 13:13, 30 May 2018 (UTC)
Thank you. @Jarekt and Mike Peel: that's an interesting problem. Five-digit years will cause the code to throw an error. I could cope with those and return the date as if it were correct. However, I'm guessing that 99% of the time, a 5-digit year will be an error, and probably ought to be flagged as such. Wikidata needs smarter bounds (like flagging when a person who died in the 19th century is associated with a date far in the future; or flagging when an award is received millennia in the future), but if that doesn't happen, should every third-party re-user have to implement their own error-correction code? What are your thoughts in this particular case? Should I return 5-digit years as correct? --RexxS (talk) 13:39, 30 May 2018 (UTC)
In my Module:Wikidata date designed to only deal with dates, I allow 5-digit years or even much longer ones. They are perfectly valid, especially for BC dates. Although they might be rare in the context of dates of birth or death. --Jarekt (talk) 14:51, 30 May 2018 (UTC)
This should have been resolved now by the switch to the complex date module. Thanks. Mike Peel (talk) 19:16, 23 September 2018 (UTC)
:This section was archived on a request by: Mike Peel (talk) 19:16, 23 September 2018 (UTC)

wide infobox

also, the infobox in Category:Austria is rather wide. What is the reason for this and how can the width be kept in sound ratio to the page width? One candidate that might cause the greater width is the area (with uselang=de as well as uselang=en). IMHO it would be sufficient to give the area in km² (without precision and without reference date).

In general there still is WD. So there is no need to put every tiny piece of information to the pages using this infobox. One can go to WD and query the very specific values there. --Herzi Pinki (talk) 17:47, 30 May 2018 (UTC)

@Herzi Pinki: It was due to the nowrap settings for the content on the right. I've tweaked these now, and it should look better at Category:Austria now. Thanks. Mike Peel (talk) 18:10, 30 May 2018 (UTC)
thanks that helps. But still, instead of 'square kilometres' or 'Quadratkilometer' km² should be understandable by all being used to the SI metric system (and consume less space). --Herzi Pinki (talk) 19:00, 30 May 2018 (UTC)
Even in place of "平方キロメートル" and "квадратный километр"? I'd prefer to stick with a multilingual label than specify an English-specific one. Thanks. Mike Peel (talk) 20:09, 30 May 2018 (UTC)
Sorry, you are right Mike Peel, but what about unit symbol (P5061), which seems to be internationalized? --Herzi Pinki (talk) 21:07, 30 May 2018 (UTC)

@Mike Peel: I've checked out Category:Ronald Reagan today and have seen that the infobox there is also quite wide. After reading your comments above I went back to the page and purged the server cache of the category page but it stayed the same. (I presume this also clears the cached WD infobox and regenerates it, or am I wrong?). My question is: Is it intended to show such large infoboxes now? Especially the infoboxes of US Presidents contain lots of information and grew considerably large. Infoboxes this size maybe look great when someone is using a very large monitor. Browsing Commons categories with a laptop computer with a 15" screen allready gives a different feeling: Some infoboxes then are shown approx. two screens in height. Also quite many users access our websites today using mobile devices; their experience must be even more severe.

I want to say that I am very thankful for what you are doing here. Having Wikidata powered infoboxes shown in categories and some basic features (such as DEFAULTSORT, basic categories or even geocoordinates) getting automatically provided is a huge improvement. It not only helps Commons getting forward but also increases the usage of Wikidata and (hopefully) encourages some users to also use Wikidata instead of producing duplicate information on Commons. I've seen you working here for months now on the development of this feature and can imagine how much work this probably is. My current wish is that we end up with a user-friendly solution. With that I mean infoboxes showing well thought information without being to large.

In my opinion the displayed information is just one part. The invisible features are also great and with more of them we could have more great benefits – especially with Wikidata powered autocategorization. Just having that for person categories would allready be a remarkable improvement. We have so many users investing time and work effort into tasks which could be done automated. Relieving these people from such avoidable work would be a great achievement letting them focus on more important tasks to do. For the meantime thanks again and keep up the good work. Best regards. --Zaccarias (talk) 20:29, 30 May 2018 (UTC)

@Zaccarias: Thanks for the feedback! A lot of this is thanks to @RexxS's excellent Lua work, I'm mostly just putting bricks together.
With the width, my intention is to keep it at 200px wide, and if you spot one that's wider than that then it's a bug with the text wrapping settings. I've made tweaks at {{Wikidata Infobox/sandbox}} that should fix the one at Category:Ronald Reagan, I'll make that live soon.
The height is a different issue. It matters a lot less if the infobox is long, as the cases where that happen are often where there are a lot of images anyway. There's a balance here between showing useful information and showing too much info, especially given that the infobox has to work well for all topics. Fields that show a lot of lines can now be auto-collapsed by default, which should help (see 'Award received' in Category:Ronald Reagan). We can always discuss whether it's worth keeping different lines or not, though, as adding/removing a line here doesn't require edits to all of the uses of it. Thanks. Mike Peel (talk) 20:59, 30 May 2018 (UTC)
This section was archived on a request by: Mike Peel (talk) 19:28, 23 September 2018 (UTC)

Width at 210px is too narrow

Hardcoded "width:210px;" is too narrow for some languages as Russian, with longer words than in English. And in general it is too small. As example, in the en-wp default width for infoboxes is 22em.

I propose changing this option to "min-width": replace style="width:210px;" to style="width:22em;" --Kaganer (talk)

@Kaganer: see the comments just above by @Zaccarias. The small size is deliberate to minimize the impact on the categories. If it needs to be wider then I think that needs some discussion here first. Thanks. Mike Peel (talk) 13:03, 31 May 2018 (UTC)
This section was archived on a request by: Mike Peel (talk) 19:29, 23 September 2018 (UTC)

Two new properties proposed

Hi! I propose including facet of (P1269) and present in work (P1441) in this template. Thanks. strakhov (talk) 16:14, 1 September 2018 (UTC)

@Strakhov: Done. Please let me know if you spot any problems with it. Thanks. Mike Peel (talk) 12:47, 4 September 2018 (UTC)
Thanks, @Mike Peel: ! P1269 is apparently OK. P1441 is not working though (e. g. Category:Gavroche). strakhov (talk) 13:09, 4 September 2018 (UTC)
@Strakhov: Can you test {{Wikidata Infobox/sandbox}} there? It should now display the info for fictional humans in the same way as for non-fictional humans (based on instance of (P31) containing fictional human (Q15632617)), except for not adding the categories at the bottom. That should mean that P1441 will now be displayed for fictional humans. Thanks. Mike Peel (talk) 18:49, 8 September 2018 (UTC)
@Mike Peel: it works well with humans (showing also data on "father", "mother"...) but not for characters such as... Category:Rocinante. But non-human fictional characters are a 'minority' in Commons categories (I guess..). strakhov (talk) 18:57, 8 September 2018 (UTC)
This section was archived on a request by: Mike Peel (talk) 19:30, 23 September 2018 (UTC)

Dates

Dates: Something went south (Category:Eduardo Pelayo). strakhov (talk) 18:56, 9 September 2018 (UTC)

Huh. @RexxS: ... Mike Peel (talk) 19:28, 9 September 2018 (UTC)
@Mike Peel and Strakhov: More stuff added to the date by Module:Complex date - this time for use with Quick Statements. I've ripped that out as well now.
  • {{complex date |date1=1850 |precision1=year}} →
  • {{wdib |qid=Q56547544 |P569 |fwd=ALL |osd=no |noicon=true}} → c. 1850
  • {{wdib |qid=Q56547544 |P569 |fwd=ALL |osd=no |noicon=true |qual=ALL}} → c. 1850
Module:Complex date actually adds something like <div style="display: none;">date QS:P,+1850-00-00T00:00:00Z/9,P1480,Q5727902</div> to the date. I don't think you want the extra '{circa}', though.--RexxS (talk) 20:27, 9 September 2018 (UTC)
Sorry about that. I use this "stuff" to allow {{Artwork}} to understand the content of the date field (which might be otherwise translated to some exotic language) so in case wikidata is missing an inception date than it can be added, by a single click or a batch process. Category:Artworks with Wikidata item missing date still has 8k files with dates associated with items without. But maybe I should add an option to strip it. --Jarekt (talk) 13:52, 10 September 2018 (UTC)
No need for the WikidataIB application:
  • fdate = fdate:gsub(' <div style="display: none;">[^<]*</div>', '')
strips it out quite nicely so far. Cheers --RexxS (talk) 16:38, 10 September 2018 (UTC)
This section was archived on a request by: Mike Peel (talk) 19:31, 23 September 2018 (UTC)

Errors

There is couple errors in Category:Pages with script errors

--Jarekt (talk) 13:42, 10 September 2018 (UTC)

There's an infinite loop: Saint-Louis (Q273779) and Saint-Louis Department (Q2066134) both have located in the administrative territorial entity (P131) equal to the other entry. Easy to fix on Wikidata, but perhaps there should be some code in place to catch that somehow (@RexxS?). Thanks. Mike Peel (talk) 13:56, 10 September 2018 (UTC)
Ah, I was looking for something like that. but did not noticed the loop. --Jarekt (talk) 17:09, 10 September 2018 (UTC)
Thanks Jarekt. I've fixed the "some value" issue by checking for v1.datavalue and v1.datavalue.value.id in line 692, but now we won't find the Wikidata errors ("some value" isn't an allowed value for sourcing circumstances (P1480)). What do you think? should I keep the fix or revert it and use the error message to help fix the invalid Wikidata?
I've limited the depth of iteration over the location chain to 10 values. Both Category:Saint-Louis (Senegal) and Category:Université Gaston Berger no longer throw errors, and you can clearly see the looping between two values in the Location field, so it's a flag to fix Saint-Louis Department (Q2066134). Let me know if anything else crops up. Cheers --RexxS (talk) 17:23, 10 September 2018 (UTC)
I am all for finding errors in Wikidata, but not at the price of breaking pages on Commons or other projects. Wikidata has its own mechanism of detecting errors: through listing constraint violations. So such issues should show up as constraint violations. Unfortunately many properties have so many of them that many of them remain unfix and the system is occasionally breaking down as in P373 constraints. --Jarekt (talk) 17:45, 10 September 2018 (UTC)
Maybe a tracking category would be useful for this sort of errors - something like Category:WikidataIB parsing issues that the module adds the page into when it comes across an issue like this? Thanks. Mike Peel (talk) 18:01, 10 September 2018 (UTC)
This section was archived on a request by: Mike Peel (talk) 19:32, 23 September 2018 (UTC)

New features based on P758

Wikidata property P758 Norwegian heritage property identification number is being used by Commons Template:Monument Norge to mark cultural heritage sides in Norway and to link to more information. Can the features of this template be included in Wikidata infobox? The features include

  1. displaying the ID number
  2. linking the ID number to the external register
  3. adding the category to c:Category:Cultural heritage monuments in Norway with known IDs.

Toresetre (talk) 22:59, 11 September 2018 (UTC)

@Toresetre: It's now in {{Wikidata Infobox/sandbox}}, live demo at Category:Klinga kirke. How does that look? Thanks. Mike Peel (talk) 10:28, 12 September 2018 (UTC)
@Mike Peel: Very well, this looks perfect. Toresetre (talk) 12:52, 12 September 2018 (UTC)
@Toresetre: OK, I'll deploy that later today, and will run through uses of {{Monument Norge}} in categories (not touching any files) to remove them where the infobox is present (and adding P758 to Wikidata if not already present), and to try to add commons sitelinks by matching the P758 value for the others, if that's OK. Thanks. Mike Peel (talk) 14:04, 12 September 2018 (UTC)
Good plan @Mike Peel: . That's fine with me, but let's check with @Danmichaelo: and @Kjetil r: if they have any comments on this way on going forward. Toresetre (talk) 18:50, 12 September 2018 (UTC)
@Toresetre: The infobox modification is now live, let's see how that goes. For future reference, there are currently 2780 categories in Category:Cultural heritage monuments in Norway with known IDs. It's been a long day, so I won't start the bot edits to move the category uses of {{Monument Norge}} over to the infobox just yet. Thanks. Mike Peel (talk) 23:37, 12 September 2018 (UTC)
Thanks Mike, looks very good! Regards, Kjetil_r 18:13, 13 September 2018 (UTC)
@Toresetre: I ran the bot tasks today. There are still just over 500 cases without Wikidata links that need manually matching / new Wikidata items creating for them. Please let me know if there are any problems! Thanks. Mike Peel (talk) 22:15, 20 September 2018 (UTC)
Great job @Mike Peel: , thanks! I'll have a look at it and verify. Just wondering about the cases without WD link. A category like Category:Evanger Church shows up in that list, but this has a WD-link. What's missing for this entry? Toresetre (talk) 16:52, 21 September 2018 (UTC)
@Toresetre: The IDs on Wikidata and on Commons are different - the infobox at Category:Evanger kirke says Kulturminne ID: 84105, the monument box says 84104. I've only bot-removed ones that are identical. Thanks. Mike Peel (talk) 23:26, 21 September 2018 (UTC)
, ok - I see that now. Thanks again @Mike Peel: ! Toresetre (talk) 11:28, 22 September 2018 (UTC)
This section was archived on a request by: Mike Peel (talk) 19:33, 23 September 2018 (UTC)

P1092 production numbers

P1092 on production numbers would be nice for automobiles. Ketil3 (talk) 06:07, 24 September 2018 (UTC)

@Ketil3: It's now in the sandbox, please test {{Wikidata Infobox/sandbox}} and see how it looks. Thanks. Mike Peel (talk) 10:23, 24 September 2018 (UTC)
Looks good! Thanks. Ketil3 (talk) 10:57, 24 September 2018 (UTC)
@Ketil3: It's now live. Thanks. Mike Peel (talk) 22:55, 24 September 2018 (UTC)
This section was archived on a request by: Mike Peel (talk) 22:55, 24 September 2018 (UTC)

Media legends

This section was archived on a request by: Mike Peel (talk) 21:23, 25 September 2018 (UTC)

new bug with surnames

@User:Mike Peel, your recent change resulting any (newly edited) people get nor sorted in their nurnames categories under space and not under the first character of their given name - see i.e. Category:Bonisoli (surname). Can you please have a look and fix this? Thx. --JuTa 23:14, 24 September 2018 (UTC)

@JuTa: That's weird. I've reverted the changes I made to that bit of code (which were just adding spaces to make the code clearer), hopefully that should have fixed this. Thanks. Mike Peel (talk) 23:22, 24 September 2018 (UTC)
User:Mike Peel, sorry, but it seems that this doesnt helped. I make a little change in Category:Agostino Bonisoli and the sorting under Category:Bonisoli (surname) didnt changed. --JuTa 23:28, 24 September 2018 (UTC)
@JuTa: I've reverted the whole change. I don't understand how the space was getting into the DEFAULSORT. It needs some more testing in the sandbox. Thanks. Mike Peel (talk) 23:40, 24 September 2018 (UTC)
@Mike Peel: , its not the DEFAULTSORT which is broken. The surnames have special sorting. DEFAULTSORT is "<surname>, <given name>". Under surname they get sorted just under "<given name>". Just as a remark (I saw your edit comment). --JuTa 23:52, 24 September 2018 (UTC)
I'll look into this more tomorrow. I can't make sense of it this evening. Thanks. Mike Peel (talk) 00:09, 25 September 2018 (UTC)
@JuTa: Found the bug, now fixed. Thanks. Mike Peel (talk) 17:48, 25 September 2018 (UTC)
@Mike Peel: , look good as far I can see up to now. Thx a lot. --JuTa 22:00, 25 September 2018 (UTC)
This section was archived on a request by: Mike Peel (talk) 22:01, 25 September 2018 (UTC)

Protected areas

Hello. Can we get located in protected area (P3018) added to the template? Thierry Caro (talk) 09:33, 14 September 2018 (UTC)

Is this not possible? Thierry Caro (talk) 20:39, 29 September 2018 (UTC)
@Thierry Caro: This got lost among the other discussions, sorry. It's now in {{Wikidata Infobox/sandbox}}, please test that and see if it's working as you expect it to. Thanks. Mike Peel (talk) 21:31, 29 September 2018 (UTC)
It's now live. Thanks. Mike Peel (talk) 21:51, 29 September 2018 (UTC)
This section was archived on a request by: Mike Peel (talk) 21:51, 29 September 2018 (UTC)

Tweaks -- mobile behaviour + circa dates

(per request moving requested tweaks to talk page)

This section was archived on a request by: Mike Peel (talk) 21:50, 29 September 2018 (UTC)

Request

@User:Mike Peel, could we hide "coordinate location" P625 qualifiers from values of statements for "connects with" (P2789). They are of no help as plain text and in any case they consume too much space. And another different question altogether: where can we ask for the Wikimedia map we use in the infoboxes to be fixed? Alarmingly the centre of Madrid has recently become a "jungle" :).--Asqueladd (talk) 00:07, 26 September 2018 (UTC)

@Asqueladd: I don't understand. Please can you point me to some practical examples? Thanks. Mike Peel (talk) 00:14, 26 September 2018 (UTC)
@User:Mike Peel. The idea is to remove the showing of coordinates from the "connects with" values of this infobox, for instance: Category:Calle de Padilla, Madrid. Regards.--Asqueladd (talk) 09:12, 26 September 2018 (UTC)
@Asqueladd: Ah, I understand now. I've removed the qualifiers from the connects with parameter in the sandbox - try {{Wikidata Infobox/sandbox}} and see how that looks. I guess the place to report problems with the map render is either phabricator or mw:Talk:Map improvements 2018. Thanks. Mike Peel (talk) 15:02, 26 September 2018 (UTC)
@Asqueladd: It's now live. Thanks. Mike Peel (talk) 21:48, 29 September 2018 (UTC)
This section was archived on a request by: Mike Peel (talk) 21:48, 29 September 2018 (UTC)

Parameter labels too bold

I'm not sure when this happened, but the parameter labels seem to be more bold than they should be. For example, in Category:Maarten van der Weijden, the lefthand column labels are bolder than the authority control header. --HyperGaruda (talk) 12:34, 29 September 2018 (UTC)

Both the “header” cells themselves (using CSS) and their content (using ''' wikicode) are set to be bolder than their parent nodes, making them double bold. The wikicode should be removed. —Tacsipacsi (talk) 12:51, 29 September 2018 (UTC)
@HyperGaruda and Tacsipacsi: I've tweaked it, does that look better now? Thanks. Mike Peel (talk) 13:50, 29 September 2018 (UTC)
@Mike Peel: almost. There are still a few doubly bolded parameters, as you can see in Category:William III of England (birth, death date). From what I can tell about this template's source code, the following parameters should ditch their triple apostrohes: audio, audio description, pronunciation, voice, birth, death, location, address, and parent taxon. All other parameters do not have them anyway. --HyperGaruda (talk) 15:06, 29 September 2018 (UTC)
For me it’s perfect, just like before the fix—somehow my Firefox fixed the weight itself, so I saw the problem only by checking the HTML code. —Tacsipacsi (talk) 15:30, 29 September 2018 (UTC)
@HyperGaruda: Try {{Wikidata Infobox/sandbox}}, is that better? Thanks. Mike Peel (talk) 16:54, 29 September 2018 (UTC)
It's now live, please let me know if there are any remaining formatting issues. Thanks. Mike Peel (talk) 21:47, 29 September 2018 (UTC)
This section was archived on a request by: Mike Peel (talk) 21:47, 29 September 2018 (UTC)

infobox pulls "media legend" from all media

I have been using "media legend" qualifiers to note printed text on images at wikidata and I have been using a different qualifier for each line of text.

Sometimes, there is already an image listed and I just add mine -- rarely setting the priority.

Today, I did just that. Added an image, making a list of the image property. The first image on the list did not have a media legend qualifier.

The infobox displays the media legends for all of the images, even after the priority was set and a media legend given to the "first" image on the list.

That all happened at Category:Coprosma foetidissima.--RaboKarbakian (talk) 15:18, 6 October 2018 (UTC)

@RaboKarbakian: That's because the infobox template sets |maxvals=1 and |rank=best for the image, but not for the media legend. @Mike Peel: for info. Unfortunately, because these are two separate calls, I can't guarantee that it will always fetch the media legend corresponding to the image where multiple images with the same preference exist – and that's hardly surprising: there's no such thing as the "first" one on the list. If you set one image to be preferred, then the code can guarantee using just that one for both image and media legend. --RexxS (talk) 00:44, 7 October 2018 (UTC)
By using Lua, it’s pretty easy to ensure the consistency—see hu:Modul:Infobox’s image and kép functions. —Tacsipacsi (talk) 09:07, 7 October 2018 (UTC)
Yes, if you write a new function just for images, then you can read the filename and the media legend at the same time and construct the whole wikitext for [[File: etc]]. However, that still doesn't solve the problem of picking which image to use when more than one has the same rank. Solving the second problem by setting a single preferred image automatically solves the first issue. --RexxS (talk) 13:38, 7 October 2018 (UTC)
As far as I know, the order is stable, although arbitrary (the first statement is the one that was first added). I think it’s worth implementing the Lua-based image selection—this way we can control that the right caption appears always; otherwise we can’t make sure that all items we use have the rank set. —Tacsipacsi (talk) 14:51, 7 October 2018 (UTC)
As far as I know as well, the order is stable, but I'm not prepared to guarantee it. At present, multiple values for a statement are accessed as a sequence, so the first one will be same on each call (unlike for tables that are not sequences). On the assumption that this situation won't change, then we can have Lua-based selection by setting |maxvals=1 and |rank=best. Unfortunately there is no general Lua-based algorithm that I'm aware of for picking values of statements from among multiple ones of equal rank. That still has to be done at the Wikidata level by using a single preferred rank or by deleting and re-adding statements to alter the order. I strongly advise not to use the latter method. --RexxS (talk) 19:20, 7 October 2018 (UTC)
Of course we shouldn’t remove and add statements to get one of them ranked first. But the template is currently used on approximately 1.8 million categories. What is the guarantee that none of them have multiple best-ranked image values? Actually, I’m sure many such items/categories exist, so we have to take care of them. I don’t know how the module works, if it can guarantee that it always returns the caption (even if the right one is nothing, because the first picture doesn’t have one, only subsequent statements), then only performance concerns (about loading the same statement twice) can arise. —Tacsipacsi (talk) 20:27, 7 October 2018 (UTC)
@Tacsipacsi: There is at least the convention (maybe not a constraint violation atm, though) to only have one image (P18) value per Wikidata item, which avoids this issue. You can always set one to 'preferred rank' to get that to show by default, and add a media legend to it so that is shown as well (I think that if the image is preferred, then the qualifier of media legend for that image is also preferred in this setup?). Thanks. Mike Peel (talk) 07:23, 8 October 2018 (UTC)
The constraint to a single value used to be made for image (P18) but has now been removed. The discussion around that does clearly indicate an expectation that one image will be set as preferred. You are quite right that the code uses the rank of the property as the rank for its qualifiers. --RexxS (talk) 16:10, 8 October 2018 (UTC)
Yeah, that’s the theory. But the practice—especially after en masse bot imports—shows else. (I tried to find somewhat exact figures, but unfortunately all my queries timed out.) We don’t have to support this, but it shouldn’t be ignored, either. —Tacsipacsi (talk) 21:44, 8 October 2018 (UTC)
I don't think we ought to support multiple images, either. Just working-round these sort of issues simply encourages the import of indiscriminate data into Wikidata, making life more difficult for every re-user such as other Wikimedia projects. Because nobody has suggested anything better, presently we are choosing to display the image whose table index is 1 when there are multiple images with the same rank. Sadly, without the single-value constraint on image (P18), it's not easy to get a list of entities where the problem can arise. --RexxS (talk) 22:40, 8 October 2018 (UTC)
I have been working on a book that contains historically significant images (taxonomy based). I like not needing to make a decision about whether a photograph or one of these images be the "preferred" image, which is an option for of all of the properties I have used there. I have noticed a tendency to use the botanical drawings on the wikipedia's over the photographs since before wikidata. Just to make the image available is a good option for non-defensive, non-offensive contributors.--RaboKarbakian (talk) 23:23, 8 October 2018 (UTC)
But why should Wikidata have to have all of those images? What purpose does that serve that Commons doesn't already satisfy? --RexxS (talk) 00:12, 9 October 2018 (UTC)
Wikidata shouldn't have all of those images. It is a point where edit wars might occur also. Whatever qualified one image over another in the taxoboxes at the 'pedias should work to help to determine what image(s) should be there. Personal experience, however, I have found that to identify a plant, it is very very useful to have line drawing, photograph and painting available, as none of them totally illustrates a plant well alone. This experience is bordering on the "wikipedia is not a field guide" which it is not. But wikidata isn't an encyclopedia.... --RaboKarbakian (talk) 01:30, 9 October 2018 (UTC)
So, I do apparently make decisions based on a bias. I just opted to make an upload by a commoner (person) the preferred image over a bot upload from some photo.com site. Do, please, forgive me.--RaboKarbakian (talk) 02:16, 9 October 2018 (UTC)
I've added the |maxvals=1 and |rank=best for the media legend in the sandbox version of the template, which seems to work OK in this case. I'll sync that over to the main version soon. Thanks. Mike Peel (talk) 15:48, 7 October 2018 (UTC)

It has occurred to me that the media legend qualifier is set to display the legend in whatever language required. I am using it as a record of a botanical plate, which is not its purpose. Is there a way to make a data point for a notable scientific illustration?--RaboKarbakian (talk) 20:26, 7 October 2018 (UTC)

@RaboKarbakian: You can propose additional properties on Wikidata for diffent special types of images, e.g. image of grave (P1442). Thanks. Mike Peel (talk) 07:23, 8 October 2018 (UTC)
@RaboKarbakian: This is now live, please post back here if you spot any issues with it. Thanks. Mike Peel (talk) 15:05, 13 October 2018 (UTC)
This section was archived on a request by: Mike Peel (talk) 15:05, 13 October 2018 (UTC)

Categories

Hi, When we don't have precise birth and death dates, the categories are wrong, i.e. Category:Suzanne Dalbray. They should be Category:19th-century births and Category:20th-century deaths. Infobox display is OK. Regards, Yann (talk) 09:59, 7 October 2018 (UTC)

Hi, Yann. Thanks for spotting that. The calls in Template:Wikidata Infobox that fetch the birth-date to assemble the categories have |df=y set. That forces a year to be returned always. Compare:
  • {{#invoke:WikidataIB | getValue | rank=best | P569 | qid=Q57000000 | fwd=ALL | osd=no | noicon=yes |df=y |pd=y}} → 19th century
  • {{#invoke:WikidataIB | getValue | rank=best | P569 | qid=Q57000000 | fwd=ALL | osd=no | noicon=yes |pd=y}} → 19th century
I've installed a patch for testing in Module:WikidataIB/sandbox:
  • {{#invoke:WikidataIB/sandbox | getValue | rank=best | P569 | qid=Q57000000 | fwd=ALL | osd=no | noicon=yes |df=y |pd=y}} → 19th century
  • {{#invoke:WikidataIB/sandbox | getValue | rank=best | P569 | qid=Q57000000 | fwd=ALL | osd=no | noicon=yes |pd=y}} → 19th century
  • {{#invoke:WikidataIB/sandbox | getValue | rank=best | P569 | qid=Q57000000 | fwd=ALL | osd=no | noicon=yes |df=y |pd=adj |lang=en}} → 19th-century
Have we got some births in decades to test as well?
@Mike Peel: for info. --RexxS (talk) 00:31, 9 October 2018 (UTC)
Found one: Thomas J. Hagerty (Q7791075). Main module now updated from sandbox.
  • {{#invoke:WikidataIB | getValue | rank=best | P570 | qid=Q7791075 | fwd=ALL | osd=no | noicon=yes |df=y |pd=adj |lang=en}} → 1920s
Those should generate Category:19th-century births for Suzanne Dalbray (Q57000000) and Category:1920s deaths for Thomas J. Hagerty (Q7791075).
Should just need that formulation updating in the infobox. --RexxS (talk) 14:45, 9 October 2018 (UTC)
Thanks @RexxS: {{Wikidata Infobox/sandbox}} has been updated. @Yann: want to test it? Thanks. Mike Peel (talk) 18:38, 9 October 2018 (UTC)
@Mike Peel: If someone views Category:Suzanne Dalbray with language set to French, won't it put the page in Category:XIXe siècle births unless you set |lang=en in the calls that generate the categories? --RexxS (talk) 20:27, 9 October 2018 (UTC)
Presumably, it won't, because you test whether the category already exists. However, viewing the page in French would seem to create the potential for removing it from the births category. Wouldn't it be better to set the call that generates the birth category to "en" (as I did above) and drop that test as no longer needed? --RexxS (talk) 20:35, 9 October 2018 (UTC)
I think such things are statically processed and only depend on site language. A GET request (with language set to French) should not affect the database (where category members are stored). —Tacsipacsi (talk) 21:28, 9 October 2018 (UTC)
@Tacsipacsi: No they are not. There is no GET request. The call is made in Module:WikidataIB at lines 481 or 483 to the database for the birth date (or death date). The timestamp which is returned is processed in lines 681 to 745. That includes a call to Module:Complex date, which translates the date into whatever language is required. The language for the date is set by a call to lines 129-143, which resolves the user's language, if set, in line 135.
At the top of the any page on Commons, you can set the language you wish to see the page in. Try setting français for this page and you can confirm that {{#invoke:WikidataIB/sandbox | getValue | rank=best | P569 | qid=Q57000000 | fwd=ALL | osd=no | noicon=yes |pd=y}} really does result in "XIXe siècle". That is the call that is being used to generate part of the name of the birth category. I hope you understand now. --RexxS (talk) 22:04, 9 October 2018 (UTC)
@RexxS: Good catch, thanks! I thought it was already there, as we had this problem with the name categories, but it looks like I didn't add it here as the numbers would have been unaffected by language - which is no longer the case. It's now changed in the sandbox. Thanks. Mike Peel (talk) 05:57, 10 October 2018 (UTC)
It works! Thanks. Yann (talk) 11:26, 11 October 2018 (UTC)
@Yann: This is now live. Thanks. Mike Peel (talk) 15:04, 13 October 2018 (UTC)
This section was archived on a request by: Mike Peel (talk) 15:04, 13 October 2018 (UTC)

P217

What about inventory number (P217)? I think it should be there, but not sure in what section.--Jklamo (talk) 12:43, 17 February 2018 (UTC)

@Jklamo: I agree it should be there, but I haven't figured out where/how exactly yet. It's a more complicated one, since there can be multiple inventory numbers, and ideally the organisation the number belongs to should also be displayed... Thanks. Mike Peel (talk) 21:46, 25 February 2018 (UTC)
@Jklamo: Rather belatedly, this is now at {{Wikidata Infobox/sandbox}}. How does that look? Thanks. Mike Peel (talk) 19:05, 23 September 2018 (UTC)
Looks good. I am checking popular qualifiers, because of qual=ALL, but it seems OK, as most popular qualifier is collection (P195). That is a bit of duplication, as we have implemented collection (P195) as stand-alone parameter, but I think we do not need to adress that. Other qualifiers are sparsely used.--Jklamo (talk) 14:08, 24 September 2018 (UTC)
This section was archived on a request by: Mike Peel (talk) 08:38, 27 October 2018 (UTC)

Taxon

Hi, when the item is an instance of taxon (Q16521), would it be possible to make appear a section "Scientific classification" with a list of all the parent taxonomic ranks as we can see in the infoboxes in Wikipedia, as well as the authority? Christian Ferrer (talk) 12:30, 16 September 2018 (UTC) + a list of the Taxon identifiers a bit as Taxonbar Christian Ferrer (talk) 12:51, 16 September 2018 (UTC) :well in fact and in summary would it be possible to use the Wikidata Infobox to display what we currently display with {{Taxonavigation}} + {{VN}} +, the Taxon identifiers? for the obvious purpose of simplification and harmonization. Or maybe a specific, and different, infobox in the kind {{Taxon Infobox}} for the categories and galleries relative to a taxon? Christian Ferrer (talk) 13:18, 16 September 2018 (UTC) forgot that, this is too much specific, though can be useful for different templates. Christian Ferrer (talk) 14:56, 16 September 2018 (UTC)

@Christian Ferrer: The problem I see is the lack of consistency in labelling and linking for these sort of hierarchical chains. I can write to code to scan up the chain of parent taxon (P171), but I'm at a loss to work out what to display. For Astropectinidae (Q660006) I can read the following (in English – other languages will have their own labels and sitelinks):
Parent taxon (P171) chain for Astropectinidae (Q660006)
EntityID label sitelink taxon name (P225) Commons category (P373) taxon rank (P105)
Q682200 Astropectinidae en:Astropectinidae Astropectinidae Category:Astropectinidae family (Q35409)
Q660006 Paxillosida en:Paxillosida Paxillosida Category:Paxillosida order (Q36602)
Q25349 starfish en:starfish Asteroidea Category:Asteroidea class (Q37517)
Q44631 Echinodermata en:Echinoderm Echinodermata Category:Echinodermata phylum (Q38348)
Q150866 deuterostome en:Deuterostome Deuterostomia Category:Deuterostomia infrakingdom (Q3150876)
Q5173 Bilateria en:Bilateria Bilateria Category:Bilateria subkingdom (Q2752679)
Q5174 Eumetazoa en:Eumetazoa Eumetazoa Category:Eumetazoa subkingdom (Q2752679)
Q3055825 Epitheliozoa Epitheliozoa no value
Q5174 Metazoa Metazoa Category:Animalia subkingdom (Q2752679)
Q129021 opisthokont en:Opisthokont Opisthokonta Category:Opisthokonta no value
These are followed by Unikont (Q964455) → eukaryote (Q19088) → Biota (Q2382443) before the parent taxon (P171) chain ends.
So if we want to mimic the box in en:Astropectinidae, the questions are:
  1. What should be displayed (and linked) for each taxon rank?
  2. What Wikidata property do we use to display the text and make a link where required?
  3. What condition(s) do we test for to stop the chain?
  4. Where do we get the kingdom (Q36732) and its row label from?
  5. What do we do when there is more than one value for parent taxon (P171)?
If those questions can be answered in a way that produces consistent results for all living things, then I can certainly write the code to produce the text we want (either as an infobox or as rows inside an existing infobox). I would like to produce code that works on Commons and other projects if possible. --RexxS (talk) 15:55, 16 September 2018 (UTC)
  • Very great. Let's agree, the purpose should be to display (inside a specific project) all the taxon ranks highly ranked, until chain ends at biota (Q2382443), that have an entry inside that specific project. Here in Wikimedia Commons, Epitheliozoa should therefore be excluded.
Secondly, at first view we could chose to display arbitrarily the same ranks as in Category:Astropectinidae or the same ranks (that are a bit different) of en:Astropectinidae, but that will be in my opinion a mistake. As when you start to be arbitrarily, then you never end, and you have to adopt to many different situations. The purpose is here to automates the thing from what Wikidata provides, it does not matter if it has imperfections or errors on Wikidata, these errors or imperfections must be corrected there, not here. And the purpose is that we can use that for all is under en:Biota (taxonomy), therefore you can not exclude anything IMO, otherwise better not to do anything and to continue with countless manual templates such {{Lepidoptera}}, but you lose the automatic operation, which is the goal here. If you try to heard from specialists or pseudo-specialists then the debates will become passionate and no one will agree on what to keep or not. Therefore my answer for Wikimedia Commons is : display all the ranks that have an entry here, to the highest level possible and at the condition that they are indeed "taxon ranks".
1/What should be displayed? the taxon rank, the taxon name, a link to the category
2/What Wikidata property do we use? for the taxon rank use the label of the taxon rank with a capitalisation of the first letter (when there is no value the correct sentence is "(unranked)"). For the taxon name use the taxon name (P225) and use that text to link the category.
3/What condition(s) do we test for to stop the chain? don't stop, just don't include all the items that don't have a category here.
4/Where do we get the kingdom (Q36732)? well... if that is not enough notable or relevant to be included in the Wikidata tree, that is not our concern, otherwise that should be corrected there. See my comment above.
5/What do we do when there is more than one value? ouch! maybe that's here that we need a test. I mean, here we start to have two values in Bilateria (Q5173) find the higher, then exclude the smaller, and...miracle you have ... Animalia and the "kingdom" rank.
Christian Ferrer (talk) 17:40, 16 September 2018 (UTC)::
@Christian Ferrer:
  1. You need to remember that readers of Commons (and some other projects) will set their preferred language, so I have to ensure that the text displayed is given in the correct language. For that reason most entities that the code reads are entity-ids, such as Q35409, so I have to decide what text to display. I'll assume labels for now. If I link to the Commons category, I'll need to modify the code for use in other projects.
  2. I don't understand what you mean by when there is no value the correct sentence is "(unranked)". Can you give a real example please?
  3. I'm afraid that I have to write code that stops. I'll assume then that the code will stop when it reaches an item that has no parent taxon (P171) or its parent has no value.
  4. Presumably, every chain will end at or before Biota (Q2382443).
  5. I don't understand what you mean by find the higher, then exclude the smaller. Can you give a real example please? I need to know what condition to test for to decide which to use from ParaHoxozoa, Eumetazoa Edit this on Wikidata (for example). I can use preferred ranks if they exist, but how do we deal with an entity that has more than one preferred rank?
I'll write some code and we can see how it turns out. --RexxS (talk) 19:04, 16 September 2018 (UTC)
  1. Yes, for the taxon rank you have indeed to use the label of the item. However for the taxon name you can use use directly taxon name (P225) of the corresponding item because it's a non-translatable proper noun, that's the difference with the vernacular name (that can be a potential field). Example the taxon name of Astropectinidae (Q660006) will always be "Astropectinidae", no matter the language. For the link, one purpose of this template is the navigation, therefore the links to the corresponding categories here have to be provided, at least when the template is used here. I guess you can use the taxon name to give the link to the Wikidata item, and then add a kind of parameter "links to Commons category=yes" that will allow to display the link to the categories (why not in an additional column?).
  2. [18] or see also Holozoa (Q1205110), taxon rank has "no value)
  3. Stop at Biota (Q2382443)
  4. idem
  5. To easily understand compare that to our over-categorization
Example Bilateria (Q5173) has two parent taxon :
Eumetazoa (Q5174)
animal (Q729)
if you look carefully yo see that Eumetazoa (Q5174) has for parent taxon animal (Q729), not the opposite, in other words : Eumetazoa are animals but all animals are not Eumetazoa, but I wonder how you can calculate that.
Maybe the best and simpler way is to start from Biota (Q2382443) and then to chose the shortest and fastest way that lead to the concerned item, is it possible?
I tried to answer at your points. Christian Ferrer (talk) 19:59, 16 September 2018 (UTC)

@Christian Ferrer: Please, please, please, don't intersperse your comments inside mine. You destroy the numbering of the ordered lists and I simply can't work like that. This is not a dialogue. Other editors who want to contribute will not be able to work out who wrote what. --RexxS (talk) 20:19, 16 September 2018 (UTC)

ok sorry
Maybe the best way is to stop when you find a "kingdom", that answer to point 3,4 and maybe 5 too, as when an item has two parent example Bilateria (Q5173) one seems to be a "kingdom". Christian Ferrer (talk) 20:29, 16 September 2018 (UTC) oh I just read a part of en:Kingdom (biology)#Seven kingdoms you should stop when you find one of the 7 listed kingdom (see right of the table in the linked page), and it is very likely that the items with multiple parent taxon have one of these kingdom as parent taxon, therefore chose it when you can. Christian Ferrer (talk) 20:47, 16 September 2018 (UTC)

Testing code

@Christian Ferrer: Perhaps it's better to try some code and see what needs tweaking.

1. 

{| style="text-align:left"
{{#invoke:Taxontree |show |qid=Q660006}}
|}
KingdomAnimalia
SubkingdomEumetazoa
SuperphylumDeuterostomia
PhylumEchinodermata
ClassAsteroidea
OrderPaxillosida

2. 

{| style="text-align:left"
{{#invoke:Taxontree |show |qid=Q156091 |first=y}}
|}
KingdomPlantae
SubkingdomViridiplantae
InfrakingdomStreptophyta
SuperdivisionEmbryophyta
DivisionTracheophyta
SubdivisionSpermatophytes
OrderSolanales
FamilySolanaceae
GenusAtropa
SpeciesAtropa belladonna

Could you try some out and let me know what problems you find? Cheers --RexxS (talk) 21:31, 16 September 2018 (UTC)

  • The second is the good one as it include also the item, three things :
the kingdom should be at top and the smaller rank at bottom,
Kingdom Plantae
..
...
Species Atropa belladonna
the taxon name from the rank "genus" and all those below (example "species", "subspecies"...) should be displayed in italic :
...
Family Solanaceae
Genus Atropa
Species Atropa belladonna
taxon author (P405) year of publication of scientific name for taxon (P574) of the taxon name item should also be displayed when quoted, in this way for an horizontal box :
Species Atropa belladonna Carl Linnaeus 1753
or in this way for a vertical box :
Species Atropa belladonna
       Carl Linnaeus 1753
Note that some taxons has several authors such as Lanmaoa fragrans (Q41713384), in that case the three names (at least the first names) should be displayed:
Species Lanmaoa fragrans
 Vizzini, Gelardi & Simonini 2015
Christian Ferrer (talk) 04:55, 17 September 2018 (UTC)
I made a test at User:Christian Ferrer/sandbox, the page is categorized with the taxon author !?
The kingdom rank have to be placed above all and then decreasing down. See my comment above. Maybe even above "instance of "
There is also some issues with the common name, in this test User:Christian Ferrer/sandbox2 the infobox display the Japanese name, normal as it is written in Wikidata, however I also used {{VN}} and there are other results. This seems to be a better solution for the common names. I think "taxon common name" should not be in the infobox, or at least not in this way.
The infobox should display a title above the imageThe title should maybe be integrated to the infobox as in almost all other infoboxes of other projects
Here the perfect thing should be:
a title
the image
wikipedia/wikispecies : ok
Instance of taxon
Kingdom Animalia
Subkingdom Bilateria
Infrakingdom Deuterostomia
Phylum Echinodermata
Class Asteroidea
Order Forcipulatida
Taxon author list of the author + year of creation
Authority control ...
Christian Ferrer (talk) 11:45, 17 September 2018 (UTC)
"the page is categorized with the taxon author" - that's now fixed. Will look at the others later. Thanks. Mike Peel (talk) 12:22, 17 September 2018 (UTC)
@Mike Peel and Christian Ferrer: I've reversed the order of the rows now. See the examples above. I'm thinking about how we might be able to italicise only a certain set of fields while leaving the others in normal font. I can't just set a trigger at "genus" because it may be missing. The only way I can think of doing it is to have a complete list of all of the entity-ids of possible values of taxon rank (P105) that should have their values italicised and check each time against the list - ugly coding. I've made a start, but somebody will have to provide the full list for me.
Mike: the left column is a row-header, both logically and semantically. However, with only two columns, it's not so important, so I've (reluctantly) changed it to a ‎<td>...‎</td> - horrible html. You should be using TemplateStyles by now to format text (assuming it's enabled on Commons), so I've added classes .taxontree-lcell, .taxontree-rcell, and .taxontree-row to the code for the left-cell, right-cell and row to encourage you to use TemplateStyles (even if it's only for the TaxonTree). I'll look at the other stuff, like adding qualifiers, a bit later, when we've got the first bit working properly. --RexxS (talk) 17:32, 17 September 2018 (UTC)
Great! here is the complete list (complete: I think) to italicise (taken from en:Taxonomic rank) :

genus (genus) genus (Q34740)

subgenus subgenus (Q3238261)
section (sectio) section (Q3181348)
subsection subsection (Q5998839)
series (series) series (Q3025161)
subseries subseries (Q13198444)

species (species) species (Q7432)

subspecies subspecies (Q68947)
variety (varietas) variety (Q767728)
subvarietas subvariety (Q630771)
form (forma) form (Q279749)
subforma subform (Q12774043)
I included the rank of the item as it is in this way as all other taxon boxes are working. Christian Ferrer (talk) 17:55, 17 September 2018 (UTC)
Another thing to do, above the higher rank, we should invoke the label of taxonomy (Q8269924) with a capitalisation and make a clear section, example look at en:Palastericus, there is a clear section header in the infobox "Scientific classification", for us "Taxonomy" seems good. Christian Ferrer (talk) 18:23, 17 September 2018 (UTC)
I'm not planning on adding extra header rows, as it adds to the length of the template unnecessarily. The only header that the infobox uses is the authority control section, and that's so the show/hide link is there. I could be persuaded to add the header if we also want show/hide for this bit too, though. Thanks. Mike Peel (talk) 21:21, 17 September 2018 (UTC)
@Mike Peel: yes a header with show/hide is worth to be tried. Christian Ferrer (talk) 08:51, 23 September 2018 (UTC)
@Christian Ferrer: OK, I've added the header with show/hide, and added instructions for how to auto-hide it to Template:Wikidata Infobox/doc. How does that look? Thanks. Mike Peel (talk) 16:05, 23 September 2018 (UTC)
@Mike Peel: great, it seems very good. Now it lacks only the author and publication date be given by the module, and we will have something that will begin to be good. Christian Ferrer (talk) 16:19, 23 September 2018 (UTC)
  • @RexxS: I added the list to your module. Christian Ferrer (talk) 18:43, 17 September 2018 (UTC)
    • I'll have a look at TemplateStyles later, it looks useful. I suspect the italics could be done there rather than in the code if needed, if each level has its own css class. Thanks. Mike Peel (talk) 18:45, 17 September 2018 (UTC)
      • @Christian Ferrer: Thank you. I love it when other folks can help maintain the code. It's now our module.
      • @Mike Peel: I could add <span class="italic"> ... </span> instead of ‎<i>...‎</i>, but for something that is still consistently styled via a tag (like bold or italic), it's a bit of a sledgehammer to crack a walnut. Classes are most useful when you might want to tweak the formatting at a later point, so taxon names that are always italicised won't feel any benefit from TemplateStyles. Have a look at en:Template:Thermometer for a demo that I made to illustrate how the local class styles work. --RexxS (talk) 20:32, 17 September 2018 (UTC)
        • OK, the infobox is now using TemplateStyles for the taxon bits, which looks to be working OK. I've switched back to th rather than td, I guess you're right there (and that seems to be how the infoboxes elsewhere are) although I always thought the headers should be horizontal. Thanks. Mike Peel (talk) 21:17, 17 September 2018 (UTC)
          • Nice work. You'll love TemplateStyles when you get used to them: cleaner, uncluttered templates; add a class in multiple places and tweak all of them in one go from the CSS file; useful, descriptive class names. What's not to like about it? Cheers --RexxS (talk) 21:45, 17 September 2018 (UTC)

Taxon common name

@Mike Peel: Is it possible to impose conditions to the display of the "taxon common name"?
2 possibilities :
1/ The visitor of the page is a user with a definite language setting :
a/ A "taxon common name" is available in the user language → then the "taxon common name" is displayed in "this language" in the Infobox
b/ No "taxon common name" is available in the user language → then nothing is displayed
2/ The visitor is exterior, and without a definite language setting :
a/ A "taxon common name" is available in English → then the "taxon common name" is displayed in English
b/ No "taxon common name" is available in English → then nothing is displayed
Because this is not top IMO Christian Ferrer (talk) 11:19, 18 September 2018 (UTC)
@RexxS: I remember you did something like this for getImageLegend in en:Module:Wikidata, but I'm not sure if that functionality is in WikidataIB? The language here is set in wikibase, not by a qualifier, so I think that means that getValueByLang doesn't work for this at the moment. Tests:
  • {{#invoke:WikidataIB | getValue | rank=best | P1843 | name=taxoncommon | linkprefix=":" | qlinkprefix=":" | sep=",<br />" | qid=Q1002824 | spf={{{suppressfields|}}} | fwd=ALL | osd=no | noicon=yes | qual=ALL}} -> キヒトデ目 (should return nothing unless language is set to Japanese)
  • {{#invoke:WikidataIB | getValueByLang | rank=best | P1843 | name=taxoncommon | linkprefix=":" | qlinkprefix=":" | sep=",<br />" | qid=Q1002824 | spf={{{suppressfields|}}} | fwd=ALL | osd=no | noicon=yes | qual=ALL}} -> (should return nothing unless language is set to Japanese)
Thanks. Mike Peel (talk) 16:22, 23 September 2018 (UTC)
@Mike Peel: The getValue function in Module:WikidataIB handles monolingual text much better than the old Module:Wikidata, which is why I didn't feel we needed a separate routine to get an image legend. The algorithm I wrote collects each of the monolingual text values available and their corresponding languages. If there is only one value, it returns that. If there are multiple values available, then it looks at the user's language and goes through the fallback sequence for that language searching for a value in that language; if it finds one, it returns that. If there are multiple values available, but none is on the fallback languages list, then it just returns the first value.
Now, that algorithm is designed to ensure that we get a value returned whenever possible. What you seem to be suggesting is that we should not return anything that is not in the user's language. That goes against the principle of supplying fallbacks. I hope you can see the disjoint in expecting everybody to accept a value in English (everybody's final fallback), but as English-speakers, we're not prepared to accept a value in a foreign language?
So, I'm willing to be persuaded to apply a different algorithm – or even yet another parameter to switch behaviour – but I'm going to need a decent argument why {{#invoke:WikidataIB | getValue | rank=best | P1843 | name=taxoncommon | linkprefix=":" | qlinkprefix=":" | sep=",<br />" | qid=Q1002824 | spf={{{suppressfields|}}} | fwd=ALL | osd=no | noicon=yes | qual=ALL}} should not return キヒトデ目.
For comparison:
  • {{#invoke:WikidataIB |getValue |P18 |linkprefix=":File:" |qlinkprefix=":" |qid=Q1513315 |fwd=ALL |osd=no |noicon=y |qual=P2096}} → South pole telescope nov2009.jpg (The South Pole Telescope in November 2009)
  • {{#invoke:WikidataIB |getValue |P18 |linkprefix=":File:" |qid=Q1513315 |fwd=ALL |osd=no |noicon=y |qual=P2096 |lang=lt}} → South pole telescope nov2009.jpg (Pietų ašigalio teleskopas 2009 m. lapkritį)
  • {{#invoke:WikidataIB |getValue |P18 |linkprefix=":File:" |qid=Q1513315 |fwd=ALL |osd=no |noicon=y |qual=P2096 |lang=ja}} → South pole telescope nov2009.jpg (The South Pole Telescope in November 2009)
Convince me! --RexxS (talk) 18:12, 23 September 2018 (UTC)
Aah, thanks for the background. Personally I'm OK with the current behaviour, so it's up to @Christian Ferrer: to do the convincing. :-) Thanks. Mike Peel (talk) 18:17, 23 September 2018 (UTC)
(BTW @RexxS: , please remind me how to just get the qualifier value in that case - just "The South Pole Telescope in November 2009" without the image? Thanks. Mike Peel (talk) 18:37, 23 September 2018 (UTC)
@RexxS: That is a rational logic : the homogeneity of the language throughout the infobox. I've just added the English common names there the result can be seen at User:Christian Ferrer/sandbox2. If your language settings is in English then you can now see the names that I just added, before that you saw "Kaniso (Esperanto)" that was the first of the list in Canis (Q149892). Where is the logic in that? What is the usefulness to display a common name in another language than the page language, and especially why only the first of the list? Why "Kaniso (Esperanto)" should be displayed in a page that is in displayed in Kazakh language? I maybe wrongly asked at beginning, I should have asked "if a common name is not available in the language in which the page is displayed, then don't display it in the Taxontree. Christian Ferrer (talk) 19:24, 23 September 2018 (UTC)
@Christian Ferrer: We don't have rational logic and the language used throughout an infobox is not guaranteed to be homogeneous. If you change your language settings to French and look at your sandbox, you get "Nom vernaculaire: Coyote, dingoes, dogs, jackals & wolves". Where's the logic in that? Are you going to add the common names of every taxon in every language? Of course not. So the only decision to make is whether you show something (even "Kaniso") or nothing at all, as if there were no common name anywhere. The usefulness in displaying common names in other than the page language is to indicate that a value exists. And if you don't want the first in the list, then give me an algorithm to decide on the one that you like better. You seem okay with showing a French, Japanese or Khazaki visitor the common name in English, but you have a problem with showing them the common name in Esperanto. How logical is that? Remember that the common name is actually displayed by a call to Module:WikidataIB, not to Module:Taxontree, so none of this has anything to do with what you asked for earlier in this thread. It's just how WikidataIB displays monolingual text. --RexxS (talk) 20:13, 23 September 2018 (UTC)
"Where's the logic in that?" that was exactly what I said : I don't find that logic at all. And I want to have something logical.
"Are you going to add the common names of ....?" no, the exact opposite, I wanted only the common name of one language only in the page of that language,
"You seem okay with showing a French...." : absolutely not, that's exactly the thing I tried to explain.
"then give me an algorithm to decide on the one that you like better" the one that i like better is the one of the page : french common name for a french page, Esperanto common names for the Esperanto pages, ect, ect.... IF the page where is displayed the taxon tree called by Module:Taxontree is in x language → then search a common name in this x language → if a common name in this x language is available then display it in the taxon tree → if a common name in this x language is not available then display nothing.
"How logical is that?" it is not logical, exactly what I said several times. It is not logic to display an Esperanto common name in an English page as well as it is not logical to display an English common name in an Esperanto page. Otherwise I wonder why it is not the case in the hundred of hundred of infoboxes already used.
"Remember that the common name is actually displayed by a call to Module:WikidataIB....." that's exactly what I asked here. If it was possible that you call from Module:Taxontree only the taxon common name in the right language then we stop to call it from Module:WikidataIB
"but you have a problem with showing them the common name in Esperanto" : yes indeed, when the page is not in Esperanto. I talked about Esperanto because it was the first of the list, but another it is the same, example a the French common name have nothing to do in a Russian page...
"So the only decision to make is whether you show something (even "Kaniso") or nothing at all" : yes I strongly agree. @Mike Peel and RexxS: can we remove the field common name, as we already have {{VN}} that we can still use and that display all the common names available.
Sorry for the inconvenience, and thanks you for all you works. I think I overestimated my English language capacity, as it seems that I'm not able to be rightly understood. Christian Ferrer (talk) 05:08, 24 September 2018 (UTC)
The actual problem is that in our Wikimedia projects we have over 300 languages, and that is nowhere near the number of languages spoken by visitors to the projects. Having 300+ entries for each piece of monolingual text in Wikidata is simply not a realistic proposition. Fortunately, most visitors are able to read more than one language, so we have a convention that we try to supply a monolingual text in a language that a reader is likely to understand. For every language except English, there is a chain of fallbacks. So if a visitor's language is Mandarin and there is no text in Mandarin, they may be offered Cantonese if that value is available. This has worked well so far, and I don't think we should abandon it. The open question is what we do if a term is not available in any of the visitor's fallback languages. I've chosen to display something, rather than nothing in those cases, but we could reach a different decision. --RexxS (talk) 10:03, 24 September 2018 (UTC)
Ok thanks you and sorry again for the insistence I showed. Is is because I've trouble understanding why to display something inside one field in one language while the page is in an other. Try to put a Chinese common name in an infobox in the English Wikipedia, your action will be very very likely cancelled. Try to put an English common name in an infobox in Chinese wikipedia, your action will be cancelled as well. That is rational and logic, and this is my logic. But no matter. The result is very acceptable as it is, and I think we can now move the result from the Wikidata Infobox sandbox to the {{Wikidata Infobox}}. Thanks you again for your useful help and works. @RexxS and Mike Peel: Christian Ferrer (talk) 11:00, 24 September 2018 (UTC)
@Mike Peel: The getValue function in Module:WikidataIB handles monolingual text much better than the old Module:Wikidata, which is why I didn't feel we needed a separate routine to get an image legend. The algorithm I wrote collects each of the monolingual text values available and their corresponding languages. If there is only one value, it returns that. If there are multiple values available, then it looks at the user's language and goes through the fallback sequence for that language searching for a value in that language; if it finds one, it returns that. If there are multiple values available, but none is on the fallback languages list, then it just returns the first value.
Now, that algorithm is designed to ensure that we get a value returned whenever possible. What you seem to be suggesting is that we should not return anything that is not in the user's language. That goes against the principle of supplying fallbacks. I hope you can see the disjoint in expecting everybody to accept a value in English (everybody's final fallback), but as English-speakers, we're not prepared to accept a value in a foreign language?
So, I'm willing to be persuaded to apply a different algorithm – or even yet another parameter to switch behaviour – but I'm going to need a decent argument why {{#invoke:WikidataIB | getValue | rank=best | P1843 | name=taxoncommon | linkprefix=":" | qlinkprefix=":" | sep=",<br />" | qid=Q1002824 | spf={{{suppressfields|}}} | fwd=ALL | osd=no | noicon=yes | qual=ALL}} should not return キヒトデ目.
For comparison:
  • {{#invoke:WikidataIB |getValue |P18 |linkprefix=":File:" |qlinkprefix=":" |qid=Q1513315 |fwd=ALL |osd=no |noicon=y |qual=P2096}} → South pole telescope nov2009.jpg (The South Pole Telescope in November 2009)
  • {{#invoke:WikidataIB |getValue |P18 |linkprefix=":File:" |qid=Q1513315 |fwd=ALL |osd=no |noicon=y |qual=P2096 |lang=lt}} → South pole telescope nov2009.jpg (Pietų ašigalio teleskopas 2009 m. lapkritį)
  • {{#invoke:WikidataIB |getValue |P18 |linkprefix=":File:" |qid=Q1513315 |fwd=ALL |osd=no |noicon=y |qual=P2096 |lang=ja}} → South pole telescope nov2009.jpg (The South Pole Telescope in November 2009)
Convince me! --RexxS (talk) 18:12, 23 September 2018 (UTC)
Aah, thanks for the background. Personally I'm OK with the current behaviour, so it's up to @Christian Ferrer: to do the convincing. :-) Thanks. Mike Peel (talk) 18:17, 23 September 2018 (UTC)
(BTW @RexxS: , please remind me how to just get the qualifier value in that case - just "The South Pole Telescope in November 2009" without the image? Thanks. Mike Peel (talk) 18:37, 23 September 2018 (UTC)
(Edit conflict) @Mike Peel: At present, you can't. There is an intrinsic problem when there may be multiple statements on Wikidata. It's what I call "Burton's wives". The question is, what should be returned if I request the start time (P580) for Richard Burton (Q151973)'s spouse (P26)? Should it return "15 March 1964, 3 July 1983, 5 February 1949, 21 August 1976, 10 October 1975" (does that have any useful meaning)? Or should it return the start time (P580) for a specific value of Richard Burton (Q151973)'s spouse (P26)? This is what you can do at the moment using WikidataIB (the second is just for Elizabeth Taylor (Q34851):
  • {{#invoke:WikidataIB |getValue |qid=Q151973 |P26 |qual=P580 |fwd=ALL |osd=no |linkprefix=":"}} → Elizabeth Taylor (1964–), Sybil Christopher (1949–), Suzy Miller (1976–), Elizabeth Taylor (1975–), Sally Burton (1983–) Edit this on Wikidata
  • {{#invoke:WikidataIB |getQualifierValue |qid=Q151973 |P26 |pval=Q34851 |qual=P580 |fwd=ALL |osd=no}} → 15 March 1964, 10 October 1975 Edit this on Wikidata
Okay, if we have cases where we're pretty sure that there is only one value for a property, we could sensibly ask for the value of one (or more) of its qualifiers, so in the sandbox I've implemented a new parameter (!) called |qualsonly= (or its alias qo) which can be set true/yes/1 as usual with a default of false.
  • {{#invoke:WikidataIB/sandbox |getValue |P18 |qid=Q1513315 |fwd=ALL |osd=no |noicon=y |qual=P2096 |qualsonly=yes}} → The South Pole Telescope in November 2009
Naturally, the "Burton's wives" issue is still with us:
  • {{#invoke:WikidataIB/sandbox |getValue |qid=Q151973 |P26 |qual=DATES |noicon=y |fwd=ALL |osd=n |qo=y}} → 15 March 1964 – 26 June 1974, 5 February 1949 – 5 December 1963, 21 August 1976 – 1982, 10 October 1975 – 29 July 1976, 3 July 1983 – 5 August 1984
  • {{#invoke:WikidataIB/sandbox |getValue |qid=Q151973 |P26 |qual=DATES |noicon=y |fwd=ALL |osd=n |qo=y |maxvals=1}} → 15 March 1964 – 26 June 1974
But all of the familiar functionality of getValue is still there. Obviously |qualsonly= only has an effect if |qual= is used. See if it's what you want. Cheers --RexxS (talk) 19:53, 23 September 2018 (UTC)
@RexxS: Thanks! One bug, {{#invoke:WikidataIB/sandbox |getValue |P18 |qid=Q333638 |fwd=ALL |osd=no |noicon=y |qual=P2096 |qualsonly=yes}} → - this one should definitely return nothing if there are no qualifiers. Thanks. Mike Peel (talk) 20:06, 23 September 2018 (UTC)
@Mike Peel: Yikes! That wasn't a bug; it was a complete failure of logic on my part. The code was only suppressing the property values when qualifiers were present, so I've had to do a bit of a re-write. Should be fixed now, though. --RexxS (talk) 21:27, 23 September 2018 (UTC)
Thanks, looks good! Mike Peel (talk) 21:29, 23 September 2018 (UTC)

Module Taxobox

Links

  • @RexxS: I remember that I asked you to make appears the links to the categories when they exist, it was not one of your choices because you wanted to make a module usable for all the projects. I think you may be right. A good/better thing should to give the link (when this link exist) inside the said project, I mean the among the interwiki links. One concrete example : in the box of Tosia if you click on "Pentagonasterinae" then you come to Category:Pentagonasterinae, that was indeed the thing I asked you. However now I made a few tests and I realized that my logic is not necessarily the right one. Indeed for these tests I created two other pages Pentagonasterinae and Goniasteridae, these both pages are listed as interwiki links in their respective items (example) Goniasteridae (Q2076886) and their respective items are parent taxon of Tosia → some thing more logic would be to make appear the interwiki links. The navigation would be more logic, and the principle should be applicable for other projects, the purpose of the module. Christian Ferrer (talk) 07:24, 23 September 2018 (UTC)
    @Christian Ferrer: The code in Module:Taxontree at lines 127–128 reads the Commons category (P373). It then uses it on line 140, if it exists, as the link for the displayed taxon name. Is that what you're talking about here? This module is not internationalised at all yet, in the sense of using local sitelinks. If you remember, I offered you a table of possibilities. Are you now saying that you don't want the link to be made to the Commons Category, but to something else? @Mike Peel: Would that fit your ideas of how the module will be used? --RexxS (talk) 16:36, 23 September 2018 (UTC)
    I suspect the ideal here would be to use Commons gallery (P935) (with a fallback to the commons sitelink) if the code is used in the gallery namespace, or Commons category (P373) if it's used in the category namespace... Thanks. Mike Peel (talk) 16:42, 23 September 2018 (UTC)
@RexxS: yes I concur with Mike. Christian Ferrer (talk) 16:49, 23 September 2018 (UTC) @RexxS: forget what I said please, and keep the links to the categories for now, please. thanks and Sorry again. Christian Ferrer (talk) 17:12, 23 September 2018 (UTC)
@Mike Peel: I think that taxon rank and taxon name are redundant with the infos given by the module, can we remove them? Christian Ferrer (talk) 16:59, 23 September 2018 (UTC)
I've removed them. Thanks. Mike Peel (talk) 17:04, 23 September 2018 (UTC)

Taxon author

@Mike Peel: hello, is it possible to make some test to try to make appear the taxon author (P405), but it could be displayed in a separate field in the infobox. I mean I know that is is a qualifier of taxon name (P225) in Wikidata, example Notocidaris mortenseni (Q2127996). However I think it is worth to have a separate field in the infobox, especially for the readability. And just below the taxon tree, something in the kind

(...)
Genus Notocidaris
Species Notocidaris mortenseni
Author Jean Baptiste François René Koehler, 1900
Common name: ....

Christian Ferrer (talk) 10:09, 19 October 2018 (UTC)

@Christian Ferrer: It's easy to support if it's a main property, try {{Wikidata Infobox/sandbox}} now. Getting it as a qualifier is more difficult. Maybe @RexxS: could add that to the taxontree code? Thanks. Mike Peel (talk) 11:08, 19 October 2018 (UTC)
@Mike Peel: I try in Notocidaris mortenseni, but I don't see the author.... Christian Ferrer (talk) 11:21, 19 October 2018 (UTC)
@Christian Ferrer: It works if you do this, but that has a constraint violation on Wikidata... Thanks. Mike Peel (talk) 11:25, 19 October 2018 (UTC)
  • Ok thanks you, but don't move it to the Wikidata Infobox, I think that we should find a way to display the taxon author when it is stated as a qualifier, or we should change/discuss the constraint in Wikidata. Christian Ferrer (talk) 11:38, 19 October 2018 (UTC)

@Mike Peel: will this not work? taxon author -->{{Wikidata Infobox/line | P405 | {{#invoke:WikidataIB | getQualifierValue | P225 |pval= P405| name=taxonauthor | linkprefix=":" | qlinkprefix=":" | list=ubl | qid={{getQID | qid={{{qid|}}}}} | spf={{{suppressfields|}}} | fwd=ALL | osd=no | noicon=yes | qual=ALL}} }}<!--

Christian Ferrer (talk) 11:50, 19 October 2018 (UTC)

(Edit conflict) @Christian Ferrer and Mike Peel:
Is that what you want? --RexxS (talk) 11:55, 19 October 2018 (UTC)
@RexxS: yes it is, the year of publication is possible too? Christian Ferrer (talk) 11:57, 19 October 2018 (UTC)
@Christian Ferrer:
  • {{wdib |qid=Q2127996 |P225 |qual=P574 |fwd=ALL |osd=no |qlinkprefix=":" |qualsonly=yes}} → 1900 Edit this on Wikidata
Or even:
That works with all qualifiers. --RexxS (talk) 12:05, 19 October 2018 (UTC)
Great that works with several authors too, see User:Christian Ferrer/sandbox3. From my point of view, I think that works well and that can be moved to the Wikidata Infobox, or integrated to the taxontree as well. Christian Ferrer (talk) 12:22, 19 October 2018 (UTC)
It's now live. Thanks. Mike Peel (talk) 12:25, 19 October 2018 (UTC)
Retrieved from "https://commons.wikimedia.org/w/index.php?title=Template_talk:Wikidata_Infobox/Archive_1&oldid=325846811"