Template talk:Wikidata Infobox

From Wikimedia Commons, the free media repository
Jump to navigation Jump to search
Filing cabinet icon.svg
SpBot archives all sections tagged with {{Section resolved|1=~~~~}} after 1 day. For the archive overview, see Special:PrefixIndex/Template talk:Wikidata Infobox/Archive.


  • Link to create a new Wikidata item is English-only, is there a translated text that could be used instead? Mike Peel (talk) 20:55, 9 February 2018 (UTC)
  • What's the best zoom level to use for the map? How should it depend on the type of object that the category is about? Mike Peel (talk) 21:15, 9 February 2018 (UTC)
  • How to handle long strings for IDs, e.g., Category:Monumento Pedro Álvares Cabral (Parque do Ibirapuera). Mike Peel (talk) 23:19, 13 February 2018 (UTC)
    • Is not a good solution to shorten (xxx...) names longer than x signs (keeping - or not, last word entirely)? Whole names could be visible as a tooltip. --Jasc PL (talk) 17:13, 15 April 2018 (UTC)
    • Could we have the Title in the smaller font size, but in bold - as in the Wikipedia infoboxes? This way we will have more place for long titles and better look. --Jasc PL (talk) 22:08, 18 April 2018 (UTC)
  • If we really need the Authority control in Commons - OK, but must it be always visible with our tools also? Why not to keeping it hidden by default, having the only [linked WD icon] [Authority control title] [Show/Hide swith] on one bar, or - clickable [Authority control title] as a show/hide switch? --Jasc PL (talk) 22:08, 18 April 2018 (UTC)
  • Could we add a link to Crotos for artworks? (see http://zone47.com/crotos/). Sadads (talk) 13:28, 23 May 2018 (UTC)
  • Auto-categorisation should handle multiple possible dates, e.g. at Category:Mary Somerville. Mike Peel (talk) 23:36, 1 June 2018 (UTC)
  • A field for "Former name" with qualifiers: "Start time", "end time" and "named after".-- Darwin Ahoy! 23:37, 20 June 2018 (UTC)

Female forms for P106[edit]

I'd like to suggest, to put it as briefly as possible, that if P31 is Q5 and P21 is Q6581072 (in other words, in cases of human women), then P106 displayed in the infobox should try to use female forms for all its values, if available. Those forms can be found as P2521 in the WD elements for each job. For example, in the infobox I've just put in Category:Hanka Bielicka all names of Ms Bielicka's professions are displayed in male forms (at least in Polish), which looks quite bad and artificial to me as native speaker. Powerek38 (talk) 23:11, 19 March 2018 (UTC)

@Powerek38: Sorry for not replying quicker, I only just noticed this. I think this needs a modification to Module:WikidataIB. @RexxS: Could you have a look at this, please? Something analogous to 'getShortValue' that uses the value from P2521 might work, as I can then use an if statement to detect when that's what we want, or a parameter for 'female=yes' or similar might also work. Thanks. Mike Peel (talk) 11:16, 25 March 2018 (UTC)
@Mike Peel: That would mean that every time a Wikidata-entity was returned for any property, the code would have to check whether it had a P2521 property (i.e. the entity's label has a female form) in the currently selected language. That requires an expensive arbitrary access for each value of each property in every case. I'm sorry, but that would make the code unusable in my opinion. Perhaps somebody else can figure out how to write code that gets round the problem that Wikidata creates in retrieving female forms of labels by the way it presently stores them; otherwise it needs to change to actor and actress being two different entities, so we can use the associated labels without expensive calls. --RexxS (talk) 12:40, 25 March 2018 (UTC)
@RexxS: Yes, I'd agree that would make the code unusable if applied by default. :-( Is it possible to have it as an option, so it's only triggered for cases where it's needed? I can write some if statements here that would minimise the times it's called to just the cases where it's needed. Thanks. Mike Peel (talk) 11:10, 26 March 2018 (UTC)
@Mike Peel: That would require a significant re-write of the code, and even then I worry about the overhead. Remember the code is generic for every property that is fetched from every page. For example, let's say your infobox script only called the new code for the occupation field. It still means that every page where there is 'occupation' has to have an extra expensive call for each value of the occupation property - and there are often quite a few of them. Then what about when somebody finds other fields where the label has a female form?
Where does this stop? In the Polish Wikipedia, how are they going to fill in the occupation field on the infobox for pl:Hanka Bielicka from Wikidata? If I look at the Wikidata entry for Hanka Bielicka in Polish, I see her occupations are: aktor, piosenkarz, artysta kabaretowy and aktor filmowy - grammatically incorrect. The problem is created by Wikidata not understanding that aktor and aktorka are different things, and need to be separate entities if retrieval of those labels as values in other entities is to be grammatically correct. A good database will store its contents in a way that doesn't put the onus on every single application that uses it to create its own complex code for what should be simple operations, like retrieving Hanka Bielicka's occupations. --RexxS (talk) 17:16, 26 March 2018 (UTC)
OK, I've now raised this for discussion on the Wikidata Project chat. Thanks. Mike Peel (talk) 21:17, 26 March 2018 (UTC)
And I've raised that at the technical table at Polish Wikipedia's bar (here), because our language seems to be among those quite seriously affected by this issue. You can try to read it using a translator, but to summarise it very briefly: most of my collegues seem to think that this should be solved by WMF / WMDE as Wikidata developers and that is technically feasible, if they really want to do it. Another point that was made (and I share this concern) is that an infobox relying so heavily on Wikidata labels and descriptions is quite risky, because of poor anti-vandal patrolling of WD. I mean, I love this box and as you can see I've been spending quite a lot of time lately putting it into various "Polish" categories, but I do hope they come up with some better quality control solutions at WD. Powerek38 (talk) 19:53, 29 March 2018 (UTC)
Thanks for raising it there. It would be useful if you could mention that at the Wikidata project chat discussion as well, please. On the labels/descriptions: those are what enable the multilingual benefits, and it's not feasible to start caching every label in every language. Hopefully anti-vandal patrolling will improve on Wikidata directly, but I also hope that making more use of the labels improves the rate at which vandalism (and data inaccuracy) is fixed. Thanks. Mike Peel (talk) 20:33, 29 March 2018 (UTC)
Yes, I did link both discussions (this one here and the one at WD) and I offered my services as translator if someone would like to have some input into this conversation but prefers to write in Polish. Powerek38 (talk) 20:53, 29 March 2018 (UTC)

Wrong capital letters[edit]

When using the infobox, all items start with capital letters, even when not being named like that. It would be helpful to disable that function, so descriptions and names starting with small letters will also be shown as they should be shown. Thanks! --j.budissin+/- 16:42, 3 April 2018 (UTC)

@J budissin: Can you point out a problem case in action, please? Wikidata systematically uses lower case letters at the start, so mostly we need to convert them to upper case, but if there are places where that shouldn't be happening then I can see if we can avoid that in those cases. Thanks. Mike Peel (talk) 17:06, 3 April 2018 (UTC)
@Mike Peel: When I use Commons with Polish interface, then all descriptions (as understood in WD terms) in the box start with capital letter, even if they start with lower case in WD. That's generally wrong, because usually the descriptions are not sentences in grammatical sense. Powerek38 (talk) 17:25, 3 April 2018 (UTC)
It's simple enough to remove the upper letter from the start of the descriptions unless it's present on Wikidata. @Jarekt: You suggested using ucfirst above, any comments on this? Thanks. Mike Peel (talk) 17:43, 3 April 2018 (UTC)
The names of the fields (in the blue boxes, like "Instance of" or "Location") should be capitalized as we do with any infobox, see {{Information}}. The values of each field, if fetched from Wikidata, I would not change, so it might be capitalized in German and lower case in Polish. --Jarekt (talk) 19:19, 3 April 2018 (UTC)
OK, I've removed ucfirst from the content, it's just used for the labels now. Let me know if there are still problems. Thanks. Mike Peel (talk) 21:49, 3 April 2018 (UTC)
@Mike Peel: It's correct, what Powerek38 says, and that's the case not just for Polish, but also for Sorbian, Czech and other Slavic languages. As an example, see Category:Jurij Brězan in Upper Sorbian (hsb). There you have the labels "Date of birth" (datum narodźenja), "Date of death" (datum zemrěća) and so on starting with capital letters, which is wrong according to Sorbian orthography. Regards, j.budissin+/- 07:21, 4 April 2018 (UTC)
@Jarekt: should be capitalized as we do with any infobox – No, they shouldn't for example in Sorbian and that's also not as we do with infoboxes. --j.budissin+/- 07:22, 4 April 2018 (UTC)
j.budissin, I will be first to admit that I do not know nothing about Upper Sorbian (hsb) orthography, but if you view Template:Information using that language all the names of the fields are capitalized ("Žórło", "Druhe wersije tuteje dataje"). That template is sort of a golden standard for us as it is used on so many millions of pages and viewed in so many languages. {{Creator|Wikidata=Q77196|lang=hsb}} gives
Jurij Brězan  (1916–2006) link=Creator: wikidata:Q77196
Jurij Brězan
alternatiwne mjena Dušan Šwik
wopisanje němski žurnalist, přełožowar a spisowaćel
datum narodźenja/smjerće 9. junija 1916 12. měrca 2006
Městno narodźenja/smjerće Worklecy Kamjenc
Normowe daty
creator QS:P170,Q77196
which also have "Datum narodźenja/smjerće" starting with the capital letter. The capitalization come from https://translatewiki.net/wiki/Special:Translations/MediaWiki:wm-license-creator-date-of-birth Where a native speaker have chosen that capitalization. --Jarekt (talk) 12:32, 4 April 2018 (UTC)
Thanks, I corrected that. The problem while translating those things is, that you don't always know where the word is going to be used, so such things may happen. Which doesn't automatically mean that it's right. --j.budissin+/- 13:38, 4 April 2018 (UTC)
j.budissin, If you want to correct more of them at Template:Information or other infoboxes use this trick to see where the messages are stored. --Jarekt (talk) 15:48, 4 April 2018 (UTC)
Note that this template uses Wikidata labels, and doesn't rely on translatewiki at all. So changing them there won't change them here. I'm leaning towards pulling ucfirst from the rest of the template, any comments? Thanks. Mike Peel (talk) 15:52, 4 April 2018 (UTC)
I would be fine with that. Jarekt just mentioned the templates above as a "role-model" for how to capitalize or not labels here, I guess. --j.budissin+/- 18:06, 4 April 2018 (UTC)

Display image of tomb / display qualifiers[edit]

Hi. I made an edit to display the image of tomb at the bottom of the infobox following the line of image (P18), see Category:Georges Hage and Category:Rudolf von Delbrück, but I don't know if you prefer this display at the top of the infobox, following the image, or at its bottom, as we do on FR Wiki. I have no specific opinions about this.

On another hand, I am interested to display qualifiers for some fields, but I am not able to do this (it is more easy for me with Lua). Jérémy-Günther-Heinz Jähnick (talk) 18:02, 4 April 2018 (UTC)

My personal opinion is that I would be cautious not to have too many pictures in one box, because then the whole thing gets very large and the crucial elements (like dates of birth/death etc.) are quite far away from the top. We're on Commons anyway, so people can access those pictures with ease. In case of people, who have coats of arms (like aristocrats or bishops) this will be the third picture in the box. I'm slightly against adding the image of tomb. Powerek38 (talk) 22:00, 4 April 2018 (UTC)
I agree, I think that one picture in the infobox is enough. I prefer to not add an image of the tomb to the infobox, but I have no problem to show an image of the tomb in a case, where there is no P18.--Jklamo (talk) 08:08, 5 April 2018 (UTC)
By the way, please take a look here. There's clearly a bug in the code section, which diplays the tomb images. Powerek38 (talk) 09:30, 5 April 2018 (UTC)
@Powerek38: The issue there is that P18 existed, but was set to "no value". So it was triggering the check for P18, but then returning nothing. As far as I'm aware, that's not a valid thing to do on Wikidata, so I removed it and that fixed it. Maybe @Jklamo:, who added it there in the first place, has a comment on this? Thanks. Mike Peel (talk) 11:13, 5 April 2018 (UTC)
One thing I was playing around with a few months back was to use Javascript to have a switch between different image options, see User:Mike Peel/Sandbox2. The downside is that the javascript has to be loaded by MediaWiki by default, it can't just be added for this template. But if this approach is of interest then it can be improved upon a bit more (checkboxes as a horizontal list for example) and we can see if it can be added to the main javascript repository. Thanks. Mike Peel (talk) 11:13, 5 April 2018 (UTC)
... of course, if you want to see that working, then you need to have the javascript. That's at [1] - either include that javascript page in your own, or copy-paste that to your own common.js to try it out. Or, have a look at en:London - in the infobox, there are a series of location maps you can switch between, it's the same setup here. Thanks. Mike Peel (talk) 11:30, 5 April 2018 (UTC)
Yes, we also use this solution for location maps at plWiki, I think it's a good idea to solve it this way. Powerek38 (talk) 13:15, 5 April 2018 (UTC)

I will not open a new section just for that : this morning, I add the idea to add number of casualties (P1590), number of deaths (P1120), number of missing (P1446) and number of injured (P1339). So I copy paste, but there is not display on c:Category:Phnom Penh stampede. Jérémy-Günther-Heinz Jähnick (talk) 12:17, 5 April 2018 (UTC)

@Jérémy-Günther-Heinz Jähnick: You added it to the part that shows for categories about humans, not the part for everything else. I've moved the code down the page, and that seems to work OK now. [2]. Thanks. Mike Peel (talk) 14:00, 5 April 2018 (UTC)

Displaying of "owned by"[edit]

I'm not sure how this could be fixed but the displaying of the "owned by" property qualifiers should probably be improved. As you can see at Category:Kronprinzenvilla the end time is shown first, then the start time. I would suggest the opposite order and to replace the comma by an en dash (–). Thanks--Leit (talk) 12:37, 29 May 2018 (UTC)

@Leit: Try {{Wikidata Infobox/sandbox}} - does that look better? The downside is that it won't show any qualifiers for that field that aren't the start/end dates, do you think that will be an issue? Thanks. Mike Peel (talk) 13:02, 29 May 2018 (UTC)
That looks fine, I don't think other qualifiers than start/end time would be useful.--Leit (talk) 13:36, 29 May 2018 (UTC)

@Mike Peel: displaying proportion qualifiers would be nice, e.g. from items like d:Q2328468. --Te750iv (talk) 15:06, 31 May 2018 (UTC)


Thanks for adding population (P1082). But I am not sure about "qual=ALL" setting, as in my opinion, not all qualifiers are suitable to display (and undoubtedly they look odd without any explanation, see Category:Prague for example). I think that point in time (P585) is the most important, not sure about determination method (P459) and criterion used (P1013), but female population (P1539) and male population (P1540) seems to be too much detailed to me.

Another population (P1082) related remark is the format of values. For higher numbers, a plain format is not easy to ready, some digit group separator may be useful. As it varies among countries, it is not easy to select one, I prefer spaces per ISO 31-0. This may apply to{ {P|2046}} as well.--Jklamo (talk) 09:35, 31 May 2018 (UTC)

@Jklamo: I've tweaked the sandbox to just display the point in time (P585) qualifiers here, how does that look? Formatting is a tricky question as that needs to be internationalised - so displaying in English might be 1,234.56, but Portuguese 1.234,56 - and then there's the space option, and more. Not sure if @RexxS: wants to look at this, but it might be better to leave this for the future to handle alongside other issues (unit conversions for example). Thanks. Mike Peel (talk) 13:09, 31 May 2018 (UTC)
@Mike Peel, Jklamo: Actually, formatting numbers is already done in the MediaWiki software, so it's fairly simple to use that. I've made a demo/utility function in Module:WikidataIB/sandbox.
  • {{#invoke:WikidataIB/sandbox |formatNumber |1294513 }} → 1,294,513
  • {{#invoke:WikidataIB/sandbox |formatNumber |1294513 |lang=}} → 1,294,513
  • {{#invoke:WikidataIB/sandbox |formatNumber |1294513 |lang=en} → 1,294,513
  • {{#invoke:WikidataIB/sandbox |formatNumber |1294513 |lang=en-gb}} → 1,294,513
  • {{#invoke:WikidataIB/sandbox |formatNumber |1294513 |lang=xyx}} → 1,294,513
  • {{#invoke:WikidataIB/sandbox |formatNumber |1294513 |lang=cs}} → 1 294 513
  • {{#invoke:WikidataIB/sandbox |formatNumber |1294513 |lang=de}} → 1.294.513
  • {{#invoke:WikidataIB/sandbox |formatNumber |1294513 |lang=ar}} → ١٬٢٩٤٬٥١٣
  • {{#invoke:WikidataIB/sandbox |formatNumber |1294513 |lang=hi}} → १२,९४,५१३
You could use that to wrap values for now to try it out.
Optionally: population is data-type quantity, so I could just use a form of the formatting code internally to format quantities by default. That may have side-effects? Or I could add yet another parameter to switch on the formatting of quantities on demand? What are your wishes? (and if the last option, please suggest a name for the new parameter!). --RexxS (talk) 14:15, 31 May 2018 (UTC)
@RexxS: It sounds like it might be best to turn it on by default, then, and we can see if any side-effects show up. Thanks. Mike Peel (talk) 14:20, 31 May 2018 (UTC)
@Mike Peel, Jklamo: Done. It will be simple to switch it on or off with a parameter if you can think of a name (maybe |fnum = true/false?). population (P1082) of Prague (Q1085):
  • {{#invoke:WikidataIB/sandbox |getValue |qid=Q1085 |P1082 |rank=b |fwd=ALL |osd=no}} → 1,294,513 Edit this on Wikidata
  • {{#invoke:WikidataIB/sandbox |getValue |qid=Q1085 |P1082 |rank=b |fwd=ALL |osd=no |lang=en}} → 1,294,513 Edit this on Wikidata
  • {{#invoke:WikidataIB/sandbox |getValue |qid=Q1085 |P1082 |rank=b |fwd=ALL |osd=no |lang=cs}} → 1 294 513 Edit this on Wikidata
  • {{#invoke:WikidataIB/sandbox |getValue |qid=Q1085 |P1082 |rank=b |fwd=ALL |osd=no |lang=de}} → 1.294.513 Edit this on Wikidata
Let me know if problems arise. --RexxS (talk) 15:07, 31 May 2018 (UTC)
@RexxS: Testing at Category:Prague and changing language (e.g. [3]), the format doesn't seem to change. Can it auto-detect the language, or does the lang= parameter have to be set? Thanks. Mike Peel (talk) 15:37, 31 May 2018 (UTC)
Hi Mike. Reading mw:Extension talk:Scribunto/Lua reference manual #getContentLanguage() brings up the interesting fact that the content language for Commons is not what the user sets (as we thought), but English. So try changing your language for these:
  • {{#invoke:WikidataIB/sandbox |getLang}} → en
  • {{int:Lang}} → en
I've used the 'hack' which calls {{int:lang}} so the getValue formatting should auto-change with user's preference now. Let me know if problems arise. --RexxS (talk) 16:17, 31 May 2018 (UTC)
@RexxS: Interesting. The hack seems to be working nicely, though. Time to move things out of sandbox? Thanks. Mike Peel (talk) 16:21, 31 May 2018 (UTC)
On commons we had for a long time {{Formatnum}} which was at some point implemented in Lua: Module:Formatnum which uses {{int:Lang}} as default language and mostly follows mw.language:formatNum Lua function. The module handles wider range of numbers, precision and some languages Lua does not (unclear if that last functionality is ever used but it was in the original template). That is what my codes use for number formatting. --Jarekt (talk) 16:35, 31 May 2018 (UTC)
That's interesting, Jarekt. You've obviously put a lot of thought into that. Do you think that setting fnum = require("Module:Formatnum") in Module:WikidataIB and then simply using fnum.formatNum(number) in place of langobj:formatNum(number) would be a "drop-in" replacement? If I've read the code correctly, it looks like it would use {{int:Lang}} by default and would retain the precision of the value supplied. --RexxS (talk) 19:08, 31 May 2018 (UTC)
RexxS, the way most modules are written on Commons is that all external functions which can be called from Lua or wikitext take "lang" parameter. Than the Lua function which is called from wikitext check if "lang" is provided and if not than it calls {{int:Lang}}, but from that point on "lang" is passed to all the functions and there is no need to call {{int:Lang}} again. Code require("Module:Formatnum").formatNum(number, lang) should be "drop-in" replacement of mw.getLanguage(lang):formatNum(number). However if the input string is not in scientific notation and you do not specify precision than I think the only difference between two outputs would be support of several very rarely used languages. --Jarekt (talk) 11:40, 1 June 2018 (UTC)
Thanks, Jarekt. The original en:Module:Wikidata had a 'global' table that kept the current language object. It goes against the grain for me to have the global-level processing needed to check whether a parameter has been passed, then get fallbacks if not. So I didn't implement that in WikidataIB which originally didn't need much language processing for enwiki. Now that it's being used on Commons, I've had to expand the language-handling, but I think I'd prefer to wrap up the code into a function to aid portability. I'm also averse to passing a long string of parameters from one function into another, so I'll keep the language object in the local args table. It's no increase in efficiency to avoid expanding a template more than once if it dramatically complicates the rest of the code. I've tried to strike a balance in the current implementation. Cheers --RexxS (talk) 21:00, 1 June 2018 (UTC)

Language handling[edit]

@Mike Peel: There's a rather intractable problem with languages and monolingual text. Take the example of birth name (P1477) for Bebe Rexha (Q16185856), which is specified in Wikidata as "en". The current implementation looks for the user language if not specified and returns the value that matches the language of the monolingual text. That would allow a birth name to have a transcription into Cyrillic script or Arabic, Hindi, etc. and the user would then see the birth name in their language. The problem then is that when we don't have a birth name version in German or French, we won't get anything.

Testing getDescription
Bebe Rexha (Q16185856) {{#invoke:WikidataIB/sandbox |getValue |P1477 |qid=Q16185856 |fwd=ALL |osd=no}} Bleta Rexha Edit this on Wikidata
Bebe Rexha (Q16185856) {{#invoke:WikidataIB/sandbox |getValue |P1477 |qid=Q16185856 |fwd=ALL |osd=no |lang=}} Bleta Rexha Edit this on Wikidata
Bebe Rexha (Q16185856) {{#invoke:WikidataIB/sandbox |getValue |P1477 |qid=Q16185856 |fwd=ALL |osd=no |lang=en}} Bleta Rexha Edit this on Wikidata
Bebe Rexha (Q16185856) {{#invoke:WikidataIB/sandbox |getValue |P1477 |qid=Q16185856 |fwd=ALL |osd=no |lang=en-gb}} Bleta Rexha Edit this on Wikidata
Bebe Rexha (Q16185856) {{#invoke:WikidataIB/sandbox |getValue |P1477 |qid=Q16185856 |fwd=ALL |osd=no |lang=de}} Bleta Rexha Edit this on Wikidata
Bebe Rexha (Q16185856) {{#invoke:WikidataIB/sandbox |getValue |P1477 |qid=Q16185856 |fwd=ALL |osd=no |lang=zh-mo}} Bleta Rexha Edit this on Wikidata

It would be a lot of complication to implement fallbacks in the code, so maybe it would be better to switch monolingual text to look for the content language (i.e. "en" on Commons), which cuts out the chance of displaying Cyrillic script or Arabic, Hindi, etc. where they exist. Optionally, you could specify |lang=en in the infobox design for certain fields that you expect to only have an English version of something like birth name. I'm not sure what the best line would be. The latter one would improve the compatibility of the module with other language wikis, but requires special considerations for infoboxes on Commons. What do you think? --RexxS (talk) 21:39, 1 June 2018 (UTC)

@RexxS: Hmm, I don't like the idea of just using English here, as that won't work in cases where there isn't an English birth name. Maybe it could fall back to showing the first (and/or only) entry in that case? Or Wikidata has the concept of 'fall-back languages' (although I can't find the documentation for that beyond d:Help:Navigating_Wikidata/User_Options#Language_fallback_chain), maybe those could be used in these cases? Pinging @Lydia Pintscher (WMDE): for help/pointers here. Thanks. Mike Peel (talk) 21:48, 1 June 2018 (UTC)
@Mike Peel: I know how to get the list of fallback languages for a given language, but the code works by looping through each of the values available and adding it to the list of items to return or not - it's a big complication to say "only take this one if some other one isn't there" because the values are kept in random order on Wikidata. I mean when the code encounter an English value, it doesn't know that there might be a German or Arabic one later. That's not easy to work around but I'll try. It wouldn't help when the only monolingual test is in Russian, say, because we can either display that or nothing. What do we do when there are two monolingual texts available, but they are in Russian and Chinese? What algorithm do we use to choose? --RexxS (talk) 22:08, 1 June 2018 (UTC)
@Mike Peel: Well, it was a pain, but I think I have a solution. Here's the algorithm:
  • If there's only one value, return that;
  • Otherwise, make a table of languages from the user's default and all its fallback languages, then see if each one in turn matches one of the languages in the property - if so use that;
  • Otherwise, WTF? - might as well just return the first one.
Seems to work - see the table above now - but I have very few test cases to try out. Do you know of any for me? --RexxS (talk) 00:01, 2 June 2018 (UTC)

Disable map option?[edit]

Routes (such as Interstate 696) defined by OSM relations doesn't appear to be displayed on the Infobox map. In those cases creating a "custom" mapframe (width, height, zoom + extra POI's) often appears to make sense though, so to save space & clutter I'd like an option to disable the Infobox map.

— Preceding unsigned comment added by Hjart (talk • contribs)
@Hjart: We could, but I'd like to see if there's a way of doing what you're thinking of automatically, as we could then use that across all routes. Can you set up a demo (or point to where one already exists) that I could have a look at? Thanks. Mike Peel (talk) 00:05, 7 June 2018 (UTC)
My first attempt at visualizing a veteran railroad: Category:Haderslevbanen. There are a few long distance cycle- and hiking routes I'd like to do something similar with. --Hjart (talk) 13:24, 7 June 2018 (UTC)

Please don't display Q-IDs to the end user![edit]

I don't know if this has been addressed before, but I don't think it is ok to display Q-IDs to the end user even if there isn't a localized label, even worse if the Q-ID isn't clickable to at least lead to the Wikidata item that might tell more. Example is the last spouse here. Please make it clickable and replace the Q-ID with for example an italic name missing or one of the foreign language names with a dotted underline (if no fallback exists, than try to fallback to same script, if still no label matches and there is more than one label, more complex heuristics could be used, e.g. here reading of country of citizenship (P27) could indicate that Russian is the most relevant language, but all that is not necessary), but anything will still be better than a Q-ID. Thanks in advance, --Marsupium (talk) 13:29, 13 June 2018 (UTC)

@RexxS: Curious to know what you think might be possible here. (It connects to Francis's comments on enwp, but I'm not going to comment there!) Personally I like showing the Q-number as it's a call-to-action to add the English label on Wikidata (since that's the base fall-back language that all other languages end up at where their labels are missing), but a number of suggestions here would still do that while making things more user-friendly. Thanks. Mike Peel (talk) 11:56, 17 June 2018 (UTC)
Anything is possible. It just depends on how much effort we want to put into it. It would be trivial to replace the entity-id ("Q-ID") that is returned when there is no sitelink or label available in the user's language. We could have an error message like "name missing in your language", but how would that be better for the reader than the entity-id?
Other options are not so easy. Unfortunately, there is no convenient mechanism exposed to Lua by the Extension:Wikibase Client (that I am aware of) to return the collection of available labels for a given entity-id. That means that we would need to have a list of all available languages and try each of them in turn to see if each one returned a label, which would be an expensive search. Let's say there were labels in Belorussian (old style), Japanese, Hebrew and Hindi: how would we algorithmically determine which one to return for a given user/reader/topic? What if there is no country of citizenship (P27)?
As for the link, the option is already there for each field to have an "edit on Wikidata" link (a pen-icon with tooltip on hover). But if we turn that on, we get some editors complaining that it adds "clutter" to the infobox. In Category:Sergei_Yesenin, the infobox has a pen-icon linking the Wikidata entry at the bottom of the infobox. Why wouldn't we use that to see more? If we turn a piece of text into a clickable link to the Wikidata entry, we have editors complaining that it comes as a surprise to the reader who doesn't expect to be taken to "a different site". Now we have complaints that we need clickable linked text potentially in each field. I have to ask, shouldn't we be establishing a consensus for which option is wanted, rather than trying to guess which option is most desirable? --RexxS (talk) 18:29, 17 June 2018 (UTC)
  • I support the OP's idea to not display Q-IDs to the end user. The link to the en:WP discussion mentioned by Mike is Wikipedia:en:Wikipedia talk:Wikidata#Q numbers showing up in infobox. --Francis Schonken (talk) 05:33, 18 June 2018 (UTC)
    • Yes, Francis, we all know what you don't want. But as usual, you're not capable of saying what you do want. Do you really want what the OP suggests? clickable links to the Wikidata item, or an italic "name missing", or the foreign language name with a dotted underline, or what? --RexxS (talk) 21:18, 18 June 2018 (UTC)

Removing of {{MainW}}[edit]

Is removing mainw well thought? I received on my talk page some questions about it. Rudolphous (talk) 17:39, 18 June 2018 (UTC)

My view is that it makes sense where the sitelinks aren't available and where we don't have this infobox, but where either of those are true then it's just unnecessary clutter presenting a duplicate link, so should be removed. The template can't be completely deleted (yet), though, since it is still useful where we don't have the sitelinks/infobox. Thanks. Mike Peel (talk) 18:19, 18 June 2018 (UTC)
I restored some mainw's and will wait now for other opinions about this. Rudolphous (talk) 19:55, 18 June 2018 (UTC)

start time - end time on occupation qualifier seem to be inverted[edit]

Look here, for instance: Category:Carlos de Almeida Pereira. Should be 1910 - 1913, but it's inverted.-- Darwin Ahoy! 23:36, 20 June 2018 (UTC)

@RexxS: This seems to be an odd one. They display the correct way around on Wikidata, but not in the infobox. Switching to 'qual=DATES' would probably solve this, but that will hide the other qualifiers. Any ideas? Thanks. Mike Peel (talk) 23:43, 20 June 2018 (UTC)
@Mike Peel: When Lua traverses a table, it does it in a non-specific order. So as far as the Lua code is concerned, there is no "correct way around". I could re-write the code to specifically use the same order as in this dump of the property, but we have no guarantee that all qualifiers are the "correct way around" in other entities. I'll have to make use of the ["qualifiers-order"] to fix order of the qualifiers - which I can see how to implement. However, that will need a pretty big revision (as I need to ensure that all qualifiers have a qualifier-order and provide a fall-back if they don't), so you may have to bear with me for a while. Here's what we have to work with:
table#1 {
  table#2 {
    ["id"] = "Q55112623$f83561ca-481c-d892-4779-a71131621448",
    ["mainsnak"] = table#3 {
      ["datatype"] = "wikibase-item",
      ["datavalue"] = table#4 {
        ["type"] = "wikibase-entityid",
        ["value"] = table#5 {
          ["entity-type"] = "item",
          ["id"] = "Q10669499",
          ["numeric-id"] = 10669499,
      ["property"] = "P106",
      ["snaktype"] = "value",
    ["qualifiers"] = table#6 {
      ["P642"] = table#7 {
        table#8 {
          ["datatype"] = "wikibase-item",
          ["datavalue"] = table#9 {
            ["type"] = "wikibase-entityid",
            ["value"] = table#10 {
              ["entity-type"] = "item",
              ["id"] = "Q588089",
              ["numeric-id"] = 588089,
          ["hash"] = "cac177afbb9491e87cd43a9c2f90f8717bd6dd93",
          ["property"] = "P642",
          ["snaktype"] = "value",
    ["qualifiers-order"] = table#11 {
    ["rank"] = "normal",
    ["type"] = "statement",
  table#12 {
    ["id"] = "Q55112623$b5dac161-4848-9762-efff-74e5ab03ba51",
    ["mainsnak"] = table#13 {
      ["datatype"] = "wikibase-item",
      ["datavalue"] = table#14 {
        ["type"] = "wikibase-entityid",
        ["value"] = table#15 {
          ["entity-type"] = "item",
          ["id"] = "Q54366548",
          ["numeric-id"] = 54366548,
      ["property"] = "P106",
      ["snaktype"] = "value",
    ["qualifiers"] = table#16 {
      ["P580"] = table#17 {
        table#18 {
          ["datatype"] = "time",
          ["datavalue"] = table#19 {
            ["type"] = "time",
            ["value"] = table#20 {
              ["after"] = 0,
              ["before"] = 0,
              ["calendarmodel"] = "http://www.wikidata.org/entity/Q1985727",
              ["precision"] = 9,
              ["time"] = "+1910-00-00T00:00:00Z",
              ["timezone"] = 0,
          ["hash"] = "8ffa963f124d126dffac07366687d8c578b078b7",
          ["property"] = "P580",
          ["snaktype"] = "value",
      ["P582"] = table#21 {
        table#22 {
          ["datatype"] = "time",
          ["datavalue"] = table#23 {
            ["type"] = "time",
            ["value"] = table#24 {
              ["after"] = 0,
              ["before"] = 0,
              ["calendarmodel"] = "http://www.wikidata.org/entity/Q1985727",
              ["precision"] = 9,
              ["time"] = "+1913-00-00T00:00:00Z",
              ["timezone"] = 0,
          ["hash"] = "4362eb2d46c233a37ab5e69c290b66030f9428e0",
          ["property"] = "P582",
          ["snaktype"] = "value",
    ["qualifiers-order"] = table#25 {
    ["rank"] = "normal",
    ["type"] = "statement",
  table#26 {
    ["id"] = "Q55112623$e2946681-4d5f-24a0-4b32-01cfdd93ccfa",
    ["mainsnak"] = table#27 {
      ["datatype"] = "wikibase-item",
      ["datavalue"] = table#28 {
        ["type"] = "wikibase-entityid",
        ["value"] = table#29 {
          ["entity-type"] = "item",
          ["id"] = "Q82955",
          ["numeric-id"] = 82955,
      ["property"] = "P106",
      ["snaktype"] = "value",
    ["rank"] = "normal",
    ["type"] = "statement",
Cheers --RexxS (talk) 00:15, 21 June 2018 (UTC)
@RexxS: Ah, OK. So even though they appear in the right order in the source, the Lua parsing changes the order? Would ordering by the property number be easier, as that would solve things in this case? Thanks. Mike Peel (talk) 11:51, 21 June 2018 (UTC)
No, Mike. The order that Lua transverses a table of key-value pairs is not specified, so no amount of jiggling around with what you see on Wikidata will guarantee a particular order. What you see in Wikidata, or in that printout above, is not the source. That's merely a human-readable representation of what's in the database in RDF-format. I could traverse the table by using numerical indices, but that's less efficient and still leaves us vulnerable to changes that look innocuous, but which actually alter the order. --RexxS (talk) 17:26, 21 June 2018 (UTC)
@DarwIn, Mike Peel: Okay, Mike, it wasn't as straightforward as I thought. I now have the code in place to ensure the qualifiers are presented in the order dictated by the ["qualifiers-order"] table (see the printout above). Unfortunately, I don't have any way of writing to that table directly to change the order if it's wrong. We still have to remove qualifiers and replace them in what looks like the right order in the Wikidata interface to affect that table. That's really hacky, but it's the only way I can see of setting the qualifier order definitively.
  • {{wdib |P26 |qid=Q151973 |fwd=ALL |osd=no |qual=ALL |list=ubl}}
(15 March 1964, 26 June 1974)
Sally Burton (3 July 1983, 5 August 1984)
Sybil Christopher (5 February 1949, 5 December 1963)
Suzy Miller (1982, 21 August 1976)
(10 October 1975, 29 July 1976) (Edit this on Wikidata)
  • {{wdib |P106 |qid=Q55112623 |fwd=ALL |osd=no |qual=ALL |list=ubl}}
navy officer ()
Governor of Portuguese Guinea (1910, 1913) (Edit this on Wikidata)
Can we figure out a better way? --RexxS (talk) 22:05, 21 June 2018 (UTC)
@RexxS: Is that table linked to d:MediaWiki:Wikibase-SortedProperties somehow? So if there are issues with the order, we can look at asking for a tweak to be made to that list? Thanks. Mike Peel (talk) 22:25, 21 June 2018 (UTC)
@Mike Peel: I don't see how it could be, as I've just edited Richard Burton (Q151973) to "massage" the start/end times of his spouse (P26) so that they are in the "right order", which changed the ["qualifiers-order"] table. It seems that the last qualifier property edited goes to the end of that table. --RexxS (talk) 22:50, 21 June 2018 (UTC)
  • Note - markup fix: I removed the template {{wdib}} and copied, exactly, the text generated by it (including the link edit this on Wikidata). The problem was that {{wdib}} categorized this page into the categories Elizabeth Taylor, Navy of Portugal and Politicians. As you can see, my solution reproduces exactly the same text generated using wdib (exept for the Wikidata link icon, a sort of pencil). Regards. --Dэя-Бøяg 10:57, 27 June 2018 (UTC)
    • Thanks, DerBorg, for spotting my omission. On Commons, making the link adds the current page to the category, rather than displaying the item linked to the category. The usual solution is to set |linkprefix=":", which adds a colon before the link text thus allowing the display instead of adding the page to the category:
      • {{wdib |P26 |qid=Q151973 |fwd=ALL |osd=no |qual=ALL |list=ubl |linkprefix=":"}}
        • Elizabeth Taylor (15 March 1964, 26 June 1974)
        • Sally Burton (3 July 1983, 5 August 1984)
        • Sybil Christopher (5 February 1949, 5 December 1963)
        • Suzy Miller (1982, 21 August 1976)
        • Elizabeth Taylor (10 October 1975, 29 July 1976) Edit this on Wikidata
    • --RexxS (talk) 12:46, 29 June 2018 (UTC)

Displaying of "construction" and "renovation"[edit]

I propose to change the displaying of the "start time"/"end time" qualifiers in the same way it was changed for "owned by" (see #Displaying of "owned by"). See Category:Langer Eugen as an example. Thanks--Leit (talk) 19:36, 21 June 2018 (UTC)

@Leit: It's in the sandbox, try {{Wikidata Infobox/sandbox}}. However, that doesn't support "point in time", so the dates are no longer shown for e.g. the opening ceremony on that page. So perhaps it's best to leave this as it currently is? Thanks. Mike Peel (talk) 22:29, 21 June 2018 (UTC)

(talk) 19:36, 21 June 2018 (UTC)

(Edit conflict) If you're quite certain that no qualifiers other than start and end times will be wanted, then it's just a matter of replacing |qual=ALL with |qual=DATES in the 'significant event' section of Template:Wikidata Infobox. Here is a comparison for Langer Eugen (Q884122):
For many event-related qualifiers, I expect that start time (P580) and end time (P582) are going to be the only ones. Perhaps using qual=DATES is a better bet in general? Optionally, I could check the qualifiers available when qual=ALL is specified, and if P580/P582 are there, then I could treat those two as if DATES were specified. That would be a bit more work. --RexxS (talk) 22:43, 21 June 2018 (UTC)
It might be good to always format P580/P582 as a range since they are so heavily used on Wikidata to show a date range. Or have point in time (P585) in DATES, which would resolve this, but probably not other cases (particularly preceeded/follows). Thanks. Mike Peel (talk) 10:51, 24 June 2018 (UTC)

Problem with {{Object photo}}[edit]

I tried to find out why File:Logitech ScanMan Color-P4191190-black.jpg is in Category:Uses of Wikidata Infobox with problems.

Ping Zolo and Jarekt in regard to the "Object photo" template. Hope someone finds a solution. --Te750iv (talk) 12:16, 26 June 2018 (UTC)

Use of {{Object photo}} is often a bad idea as the template pretends that a category pages are templates and it transcludes content of the category page. For it to work category page has to be properly set and Category:Logitech ScanMan Color-Musée Bolo is not. As a result {{Wikidata Infobox}} is transcluded into File:Logitech ScanMan Color-P4191190-black.jpg but it is not connected to any wikidata pages through a sitelink (it is not supposed to be). I assume user:Rama was planning to set up Category:Logitech ScanMan Color-Musée Bolo to be compatible with {{Object photo}}. --Jarekt (talk) 12:32, 26 June 2018 (UTC)
This infobox is not compatible at all with object photo. My view is that the latter needs to be deprecated in favour of using Wikidata directly in the file pages, but I haven't looked into this enough yet to propose a solution. For now it's best to avoid adding the infobox to categories that are used by object photo. Thanks. Mike Peel (talk) 13:25, 26 June 2018 (UTC)
My version of Category:Logitech ScanMan Color-Musée Bolo used "User:Rama/Catdef", a draft and proof of concept for functionalities that are now in {{Artwork}}, which works fine with {{Object photo}}. User:Alexis Jazz changed this in favour of {{Wikidata Infobox}}, but I have reverted his edit, since it breaks the documentation of the files. Rama (talk) 14:53, 26 June 2018 (UTC)
@Rama: Because templates that are used in main space (and yours seems to be used on 7451 pages..) should never ever be in user space. - Alexis Jazz ping plz 15:07, 26 June 2018 (UTC)
Things that do not work should be used even less. Rama (talk) 17:38, 26 June 2018 (UTC)

Twitter integration[edit]

I would like to see better twitter integration. If I share a Wikicommon category with a Infobox I would like to see more than a text link see tweet of Category:Post Rotemuseum - Salgo60 (talk) 06:51, 3 July 2018 (UTC)

@Salgo60: It seems that this is an issue with the configuration of MediaWiki here - mw:Extension:PageImages doesn't seem to be enabled for categories, so there is no image provided to twitter/facebook/etc. when someone links to a commons category. This needs WMF dev input, so I've raised that on phabricator, see phab:T198716. Thanks. Mike Peel (talk) 14:47, 3 July 2018 (UTC)
@Mike Peel: thanks I have been out biketouring.... I guess then we get a Twitter card. We did that on another site portrttarkiv-kcb.se ==> Tweet
   <meta name="twitter:card" content="summary_large_image" />
   <meta name="twitter:site" content="portrattarkiv" />
Is there no possibility to do that from a template?!?!? see Extension:Add_HTML_Meta_and_Title - Salgo60 (talk) 10:59, 13 July 2018 (UTC)
@Salgo60: Sorry for not replying quicker to this. I don't think that extension is available here? As per my comment on phabricator, I think PageImages uses the more general approach rather than something that's twitter-specific, but I might be wrong. Thanks. Mike Peel (talk) 08:54, 16 July 2018 (UTC)

"stated as" used as the piped end to a link....[edit]

I have old books who are using some name or another that has a different name now. "American Ornithological Union" vs the current "American Ornithological Society" now. [[:Category:Current name|Stated as]] Category:The Auk --RaboKarbakian (talk) 22:16, 7 July 2018 (UTC)

@RaboKarbakian: I'm not sure I see the problem, can you explain/show a demo of how it should look please? Thanks. Mike Peel (talk) 20:36, 10 July 2018 (UTC)
Wikidata infobox-07-10.png
At source, it is probably going to be the Union, here it is going to be the Society. I don't know when the Society started and the Union ended, but it is still a Union in 1920, I think.... I just want to be able to wrap the old name (red letters) around the new name (blue letters). It is easier for linking the publications. Thanks for answering. @Mike Peel:--RaboKarbakian (talk) 20:56, 10 July 2018 (UTC)
Ah, so you want the link to appear as American Ornithologists' Union rather than American Ornithological Society? Looks like this would need some Lua from @RexxS:. Thanks. Mike Peel (talk) 21:02, 10 July 2018 (UTC)
Yes! The link to the right place, but the name being the one that was published. Thank you for working through this!--RaboKarbakian (talk) 02:34, 11 July 2018 (UTC)
"stated as" takes a string value rather than a link value, so one might expect modern name as a blue link, stated name as black text. That might be a clearer representation of what is at the wikidata item. Or do you specifically want both to be linked as blue links to the category for the modern entity? Jheald (talk) 21:07, 10 July 2018 (UTC)
I should add that I've been working quite a lot on some of these journal items recently, where there are scanned copies in the Biodiversity History Library, so do talk to me if you think there is anything not right or that could be systematically improved with their Wikidata items. Jheald (talk) 21:10, 10 July 2018 (UTC)
I would also tend to be wary about this because I have been using stated as (P1932) to record how names (eg of book authors) have been stated in the source I am citing, which (at least for the BHL index) tends not to what is written on the title-page, and probably is also not how we would want to primarily state them in the infobox.
(See eg: Category:Bird-life; a guide to the study of our common birds. So far we only have categories for about a dozen books with scans from the BHL linked to wikidata; but potentially there could be many tens of thousands, all of which this would apply to.) Jheald (talk) 17:09, 11 July 2018 (UTC)
There is going to be a problem similar to this when source starts doing taxonomy. Stated as is the best way to point to which taxon name and if known system being used. Plants, birds, reptiles, amphibians, probably more. Same problem, really.--RaboKarbakian (talk) 20:00, 11 July 2018 (UTC)
"Stated as" should be used differently per thing (or item). It is safe and good to use author, and publisher stated as this way. Taxonomic names also.--RaboKarbakian (talk) 20:05, 11 July 2018 (UTC)
While trying to fix a similar error reported below, I realised that we're better off not trying to link string values by default, and specifically link them only in rare cases, so I've suppressed the links. --RexxS (talk) 17:15, 24 July 2018 (UTC)

Layout problem[edit]

The following article has a strange layout Category:Museum_De_Moriaan. Does someone know why? It looks like something is changed recently, because normally putting the gps location on top fixes layout problems. Rudolphous (talk) 19:49, 10 July 2018 (UTC)

@Rudolphous: {{Building address}} is broken, apparently intentionally. See the discussion at Template_talk:Building_address#Bug_with_this_template. I've removed that from the page, and all looks OK now. Thanks. Mike Peel (talk) 20:34, 10 July 2018 (UTC)
Hi Mike, thanks for your fix. There are many others too: For example [4]. Is there no way the buildingblock address template can be fixed? A couple of days ago all these monuments where correctly styled if I remember correctly. Rudolphous (talk) 20:44, 10 July 2018 (UTC)
@Rudolphous: It seems that fixing the HTML so that it works right on its own would then break it when it's used inside the information template. The ideal thing would be to (manually or automatically) move the info onto Wikidata and remove the template from the category, as I did at Category:Museum_De_Moriaan. Thanks. Mike Peel (talk) 20:59, 10 July 2018 (UTC)

Another idea[edit]

Hello @Mike Peel:. now the Wikidata-logo.svg feels a bit lonely.
Why not moving it to the sitelinks section (looking like "Wikidata-logo.svg Wikidata"?) ?
Perhaps first of them as it is the source.
It will allow you to suppress all the first "if" part (because there would always be a wikidata link).
Cheers Liné1 (talk) 15:45, 14 July 2018 (UTC)

Links on grave information is odd[edit]

Example Category:Gunnar_Sträng Wikidata Gunnar Sträng (Q354112)

- Salgo60 (talk) 13:41, 19 July 2018 (UTC)

The reason why the value of burial plot reference (P965) is linked is because the template sets |qlinkprefix=":" in the call for "place of burial". That triggers linking for qualifiers that are of type 'string', such as burial plot reference (P965). As the qualifiers for place of burial (P119) are unlikely to be linkable wikibase items, it's probably best not to set the qlinkprefix – unless anybody knows of any examples of wikibase-items that are categories being used as qualifiers for place of burial (P119)? If so, I could always create yet another parameter like qlinked to control linking of qualifier values, although I'd rather not unless there's a demonstrable need. --RexxS (talk) 14:26, 24 July 2018 (UTC)
[Update:] It seems we rarely need qualifiers which are strings to be linked, so I've suppressed linking of qualifiers when the linkprefix is just ":" (i.e. used to suppress categorisation when category links are made). The template seems to be behaving better when there are qualifiers with datatype string now. Let me know if there are any consequential problems arising. --RexxS (talk) 17:19, 24 July 2018 (UTC)

Authority control[edit]

Authority control displays the list of items next to each other. Can that be changed to a line break after each item? For example Category:Felice Varini has a lot of items which is difficult to read with all items next to each other. Behanzane (talk) 17:59, 24 July 2018 (UTC)

Questions ans wishes[edit]

Hello together, since a few days I worked with this infobox, I've asked me a few questions and became wishes.

  • Is it possible to realize a category automated, and thus similar to "born on", for inception (P571)?
  • On the page Commons:Categories you should mention this box and also that these categories are inserted independently.
  • Otherwise, nice thing, congratulations

Thanks for answers --Crazy1880 (talk) 18:20, 1 August 2018 (UTC)

@Crazy1880: Sorry for not replying sooner. It is possible to add additional automated categories, do you have a category tree in mind? I've added a mention of the infobox to Commons:Categories at [5] - please edit that page if you can think of a better way to talk about it. Thanks. Mike Peel (talk) 23:51, 28 August 2018 (UTC)
Moin Moin @Mike Peel:,
Regards --Crazy1880 (talk) 18:32, 29 August 2018 (UTC)
@Crazy1880: I guess we could use inception (P571) and country (P17) to automatically add "Category:<P571> establishments in <P17>" - or if that category doesn't exist then it could be added to "Category:<P571> establishments". Would that make sense? Thanks. Mike Peel (talk) 23:07, 29 August 2018 (UTC)
@Mike Peel: Could we do both? On the one hand "<P571> establishments‎" and on the other hand (if it exists) "<P571> establishments in <P17>". For inaccurate information, such as decade there were "<P571>s establishments in <P17>" (Example). Regards --Crazy1880 (talk) 06:11, 30 August 2018 (UTC)
@Crazy1880: It's now in the sandbox, please can you test {{Wikidata Infobox/sandbox}} to see if it's working as expected? E.g. at Category:Wikidata it would add Category:2012 establishments, and at Category:Gare de Lyon-Gorge-de-Loup it adds Category:1983 establishments in France. Thanks. Mike Peel (talk) 11:51, 30 August 2018 (UTC)
@Mike Peel: Works good, tested with Louvre und Burj Khalifa. Thanks --Crazy1880 (talk) 12:07, 30 August 2018 (UTC)
@Crazy1880: OK, it's now live, let's see how it goes. Thanks. Mike Peel (talk) 12:18, 30 August 2018 (UTC)
I have a problem with Category:State Government Offices, Melbourne: I put it in a category Category:Built in Australia in 1877, as usual, but the template is also adding Category:1877 establishments in Australia, which I don't think is wanted for a building. --ghouston (talk) 10:26, 31 August 2018 (UTC)
Please consider the template does not fit for every cat. see Category talk:Three Musicians by the Master of the Female Half-Lengths Oursana (talk) 00:47, 4 September 2018 (UTC)

P39 qualifiers[edit]

Displaying all P39 qualifiers is a bit excessive (see Category:Andrej Babiš for example). I think none or P580 only is enough.--Jklamo (talk) 08:50, 5 August 2018 (UTC)

We should use small letters (80 %) to generally display all qualifiers, it will permit to have a king of hierarchy in informations. Jérémy-Günther-Heinz Jähnick (talk) 09:47, 5 August 2018 (UTC)
We should never use small letters in any element that's already reduced in size. Any text that less than about 85% of the normal font size for the page is going to be unreadable by most folks with visual impairments, including older readers like me. --RexxS (talk) 18:37, 13 August 2018 (UTC)
@Jklamo: Apologies for the delayed response. I've set qual=DATES (so that only start time (P580) and end time (P582) are shown) in the sandbox at {{Wikidata Infobox/sandbox}} - how does that look? Thanks. Mike Peel (talk) 23:37, 28 August 2018 (UTC)
Much better, thanks.--Jklamo (talk) 07:23, 29 August 2018 (UTC)
It's now live. Thanks. Mike Peel (talk) 21:38, 29 August 2018 (UTC)
@Mike Peel: I just see the change, if it is good for dates, it always lacks the display of of (P642) or electoral district (P768). I often add Wikidata infobox for French mayors and deputies, and it is with the dates the major information. See the example with Nestor Danquigny. Jérémy-Günther-Heinz Jähnick (talk) 12:25, 30 August 2018 (UTC)
@Jklamo, Jérémy-Günther-Heinz Jähnick: The current options available here are to show one qualifier (e.g., P462); the date properties; or all qualifiers. It doesn't seem to be possible to select 4 qualifiers ([6] doesn't work, unless @RexxS: can help). So, which should we do? Thanks. Mike Peel (talk) 13:11, 30 August 2018 (UTC)
I am not a pro in algorithmes. Is it possible to exclude some properties ? (It can be the other solution, but I propose that without having knowledge on this). Jérémy-Günther-Heinz Jähnick (talk) 13:34, 30 August 2018 (UTC)
@Mike Peel, Jérémy-Günther-Heinz Jähnick: I can see how to do what's required, but it will take a bit of a re-write of the code that handles qualifiers. Essentially, we could use something like |qual=P580, P582, P642, P768 and I could then detect the list and arrange for the code to loop through the supplied qualifiers, checking if each one existed in turn, and processing each one found. How would you envisage that the display should handle multiple values for each qualifier? --RexxS (talk) 15:14, 30 August 2018 (UTC)
Normally we can have one and only one value for of (P642), idem for electoral district (P768). And these two properties cannot be present together in one statement. Jérémy-Günther-Heinz Jähnick (talk) 16:27, 30 August 2018 (UTC)

Improvement to "location" field with hierarchical information[edit]


I have had a thought about the "location field", which I will illustrate with an example.

In cases such as Category:Near Eastern Antiquities in the Louvre - Room B, we see things like "Located in: Sully Wing, France". The field takes information directly from the item, in properties "located in" (P276) and "country" (P17). This has obviously been designed with large locations in mind such as cities or regions ("London, UK" or "Kantō, Japan" make sense), but as precision increases the outcome becomes absurd: if you know that the Sully Wing is one of the main subdivisions of the Louvre, you do not need to be told that it is in France; and if you do not know what it is, "France" is too vague.

In the case of Category:Near Eastern Antiquities in the Louvre - Room A, we see a more reasonable hierarchy of locations, generated by a similar list in the Wikidata item for Room A. This sounds sub-optimal as the Wikidata item then contains several locations, more and more precise, instead of the most precise of these.

Would it be possible to perform hierarchical queries to parent items, as to obtain "Sully Wing, Louvre Palace, 1st arrondissement of Paris, France" (with the rule: Room 300 (Q30083572) located in (P276) Sully Wing (Q17309954); Sully Wing (Q17309954) located in (P276) Louvre Palace (Q1075988); Louvre Palace (Q1075988) is in the administrative unit (P131) 1st arrondissement of Paris (Q161741); 1st arrondissement of Paris (Q161741) country (P17) France (Q142)" ?

Thank you very much in advance! Rama (talk) 07:57, 28 August 2018 (UTC)

That sort of thing is easy to do in database query but is hard to do by a code traversing multiple items. Each loaded item is another expense in time and memory. A while ago I wrote phabricator:T167521 proposing a solution, but without changes to the software I do not think it is feasible. --Jarekt (talk) 16:56, 28 August 2018 (UTC)
@Rama: It can partly be done by code that @RexxS: drafted (but I haven't yet implemented in the infobox) that follows located in the administrative territorial entity (P131) down the line, e.g. for Room 300 (Q30083572) it gives Sully Wing, Louvre Palace, 1st arrondissement of Paris, Paris, Metropolis of Greater Paris. That doesn't help with going from Sully Wing (Q17309954) to Louvre Palace (Q1075988) though... Thanks. Mike Peel (talk) 22:04, 28 August 2018 (UTC)
@Mike Peel, Rama: Since I moved the main code in Module:WikidataIB over to using mw.wikibase.getAllStatements instead of mw.wikibase.getEntity, the expense has been greatly reduced, so much so that these sort of chains are now perfectly feasible. I could develop the location function to check for location (P276) whenever located in the administrative territorial entity (P131) is empty, which would allow Sully Wing (Q17309954) to link to Louvre Palace (Q1075988) and that then produces 1st arrondissement of Paris, Paris, Metropolis of Greater Paris. Are there any other likely properties we ought to be catering for? --RexxS (talk) 22:21, 28 August 2018 (UTC)
@RexxS: That sounds good. Perhaps it could also check located on terrain feature (P706). Thanks. Mike Peel (talk) 22:27, 28 August 2018 (UTC)
@Mike Peel, Rama: yer, that works, it seems. Following Sully Wing (Q17309954):
It would be a big help if folks had a chance to test it out on a number of test cases and let me know if any problems arise. Cheers --RexxS (talk) 23:16, 28 August 2018 (UTC)
@RexxS: I've added it to {{Wikidata Infobox/sandbox}} (it now basically replaces {{Wikidata location}}) and have been testing it in a few categories. Using it at Category:Lovell Telescope / Lovell Telescope (Q555130) throws an error, though - "Lua error in Module:WikidataIB at line 1002: attempt to index field 'datavalue' (a nil value)." Thanks. Mike Peel (talk) 23:31, 28 August 2018 (UTC)
@Mike Peel: That's because the geniuses over at Wikidata decided that United Kingdom (Q145) is located on terrain feature (P706) of British Isles (Q38272), which is located on terrain feature (P706) of Europe (Q46), which is located in the administrative territorial entity (P131) of no value. I've simply disabled following located on terrain feature (P706) for now, as we really don't want this sort of crud:
Eventually some clever bugger will link Europe as located on terrain feature (P706) of Earth (Q2), which has a location (P276) in the Solar System (Q544), which is already located on terrain feature (P706) of the Orion Arm (Q33187), which is is already located on terrain feature (P706) of the Milky Way (Q321), which is located in the Local Group (Q3944), located in the Virgo Supercluster (Q175760) or the Laniakea Supercluster (Q17863945), etc. eventually finding itself located in the Universe (Q1). That will embiggen your infoboxes somewhat. Hopefully, I'll have figured out how to stop the chain at an appropriate place before that particular apocalypse occurs. I'll put some more thought into it. --RexxS (talk) 18:29, 29 August 2018 (UTC)
[Update] I figured that we could also terminate the chain when the item is an instance of (P31) of country (Q6256), so I've re-instated P706 and implemented that termination condition. A side-effect is that we can find higher-level chains now:
What's not to like about that, eh? You radio-astrologers will be over the moon about it. --RexxS (talk) 19:12, 29 August 2018 (UTC)
@RexxS: Looks good. It's now live, let's see how it goes. Thanks. Mike Peel (talk) 21:37, 29 August 2018 (UTC)

A huge thank you to all for your attention, your swift answer, your impressive efforts and for the splendid solution! Rama (talk) 06:26, 29 August 2018 (UTC)

I've noticed for some time that located on terrain feature (P706) is no longer displayed (See i.e. Q12307030 (Q12307030)) Do you have plans to reinstate it? --Hjart (talk) 12:57, 4 September 2018 (UTC)
@Hjart: It should still display, but only if located in the administrative territorial entity (P131) isn't present. Thanks. Mike Peel (talk) 13:22, 4 September 2018 (UTC)
Ok, I understand. I added it here because the smallest administrative area here is quite a bit a larger than the town this example is in, so for a lot of cases in Denmark I'd really like to have both though. --Hjart (talk) 13:36, 4 September 2018 (UTC)

Wikidata Infobox adds irrelevent categories to pages[edit]


I have noticed that the Wikidata Infobox adds irrelevent categories to pages. You can see an instance of the problem with Category:Bes-N 5141, which is categorised in Category:Establishments in France. This category is not called in the wikicode of Category:Bes-N 5141, and this diff shows that the extra category stems from invoking {{Wikidata Infobox}}.

Can someone advise ? thanks ! Rama (talk) 10:31, 4 September 2018 (UTC)

I think the problem is that the wikidata item Bes-N 5141 (Q56458656) to which Category:Bes-N 5141 is tied has an inception (P571) property, which is nominally the date or point in time when an organization was founded. However d:Wikidata:WikiProject_Visual_arts/Item_structure seems to suggest that it might also be used for works of art. On Commons the structured data project is proposing using P571 for date a file was created as well as for the date of creation of the depicted content (see Commons:Structured data/Properties table), so I definitely think Wikidata is planning on expanding the P571/Inception property beyond just organizations. The template code for {{Wikidata Infobox}} assumes that the existence of a P571 property implies that the item is an organization/establishment, which appears to no longer be true. —RP88 (talk) 10:57, 4 September 2018 (UTC)
fascinating, thank you! Rama (talk) 12:27, 4 September 2018 (UTC)
This auto-categorisation was added at @Crazy1880:'s request, see the discussion above. As it's causing problems and I'm not too sure how to resolve them, I've disabled it. You might still see the categories being added until the server cache catches up (try ?action=purge at the end of the URL to see if that is the case or not). Thanks. Mike Peel (talk) 12:46, 4 September 2018 (UTC)
Moin Moin together, @Rama:, yes, the mindset was as @RP88: described it. Thanks at @Mike Peel: deactivate this categories. Is there a way, for example, to restrict for buildings? Regards --Crazy1880 (talk) 18:57, 4 September 2018 (UTC)
@Crazy1880:: that would only be possible if we could identify some Wikidata property value that was present for all buildings, but absent for all non-buildings. Looking at Castleton (Q5050630), for example, which is a railway station opened in 2010, the only possible thing I can see is instance of (P31) which is railway station (Q55488). If we could create an exhaustive list of all property values that represented buildings, we might be able to check instance of (P31) against the list in order to identify a "building", but frankly Wikidata isn't structured consistently enough to have much hope of that working reliably. --RexxS (talk) 15:50, 6 September 2018 (UTC)
@RexxS: If this were an important requirement, would it be possible to track up the subclass of (P279) chains a little way, and look for architectural structure (Q811979) ? Jheald (talk) 19:51, 6 September 2018 (UTC)
@Jheald: I actually looked at that, but wasn't convinced that it would be present in every case, especially when there are so many values of subclass of (P279) to check against. I suppose I ought to knock up some test code or at least write a SPARQL query to see what sort of results we'd get. I'll put it on the to-do list. --RexxS (talk) 20:42, 6 September 2018 (UTC)
@Mike Peel: that auto categorization feature is still causing problems as discussed here. Can you confirm it is currently disabled? Thanks, --Joschi71 (talk) 15:54, 6 December 2018 (UTC)
@Joschi71: It's a different issue, should now be fixed with this edit. Thanks. Mike Peel (talk) 17:34, 6 December 2018 (UTC)
@Mike Peel: thanks for the fast reply, but unfortunately category:Volkswagen Polo III is still listed in category:Germany, even with action=purge. I suspected the starttime attribute, but with your amendments it now looks the same as endtime. Could you please have a 2nd look? --Joschi71 (talk) 21:45, 6 December 2018 (UTC)
@Joschi71: I did a null edit (open edit window, then save without changing anything) to the VW Polo category, it's no longer in the German category. Thanks. Mike Peel (talk) 01:10, 7 December 2018 (UTC)
@Mike Peel: great, thanks a lot! --Joschi71 (talk) 07:50, 7 December 2018 (UTC)

Aircraft registration[edit]

{{editprotected}} Please add a line to display property P426 (aircraft registration) with date qualifiers. This will allow WD Infobox to supercede Template:Individual aircraft. Thanks, Josh (talk) 16:38, 5 September 2018 (UTC)

@Joshbaumgartner: Done, how does that look? I can run a bot through the existing uses of {{Individual aircraft}} to move them over to the infobox, if you'd like. Thanks. Mike Peel (talk) 23:24, 5 September 2018 (UTC)
@Mike Peel: It looks perfect, thanks, and in fact a bot job to go through them would be fantastic! By the way, I really appreciate the infobox and I know you've put a lot of work into it, so, thank you! Josh (talk) 06:51, 6 September 2018 (UTC)
@Joshbaumgartner: I've run the bot through the ones that are linked to from Wikidata (and added the sitelinks for the others that I could). There are still a few that the bot couldn't migrate as their wikidata entries are already linked to another item, perhaps you could have a look through those manually? Thanks. Mike Peel (talk) 22:25, 6 September 2018 (UTC)
@Mike Peel: No problem, I can take care of the sticky ones. There are some aircraft which have multiple categories on Commons but one entry on Wikidata. Thanks! Josh (talk) 22:28, 6 September 2018 (UTC)

Text wrap[edit]

@Mike Peel: Mass implementation of Wikidata Infobox cause graphical disruption of category pages because the infobox pushes other templates, description and content of the category out of the screen. Some solution should be developed:

  • wrap text, all other templates and section titles around the infobox
  • a bot task which would manage pernamently an optimal order of templates and boxes to minimalize unwanted effects. --ŠJů (talk) 12:44, 8 September 2018 (UTC)
@ŠJů: Pi bot has been adding the templates below the last }} for this reason. I'm not aware of anything that can be done with the infobox code to fix this - the other templates' codes need to be fixed so that they no longer insist on 100% of the screen width (which is why browsers then display them below the infobox). Or hopefully the functionality of those templates is now in the infobox, and the other templates can simply be removed. Thanks. Mike Peel (talk) 19:32, 9 September 2018 (UTC)
Only several templates are fully replaced by Wikidata infobox. Some other (as "cat see also", "do not confuse", naviboxes, warning and maintenance templates etc.) should remain in the head of the page. --ŠJů (talk) 19:45, 9 September 2018 (UTC)
Most of those should work OK (e.g., {{Categorise}} can be put after the infobox and it displays fine). Others need to be fixed. If they use mbox, then I think the trick is to use auto width, e.g., see {{Categorise/layout}} (I don't know why that's not the default). Thanks. Mike Peel (talk) 19:57, 9 September 2018 (UTC)

@Mike Peel: As I noticed now, it is a problem with [Mark this page as patrolled] link. It displays below the infobox and pushes all content below. However, this problem affects "patrollers" only. --ŠJů (talk) 19:50, 12 September 2018 (UTC)

@ŠJů: I have patrol rights, and I see that link, but it appears to the left of the infobox for me, and doesn't push the content down... Can you link to a case where it does push it down for you? Maybe there's something else that's also going on there. Thanks. Mike Peel (talk) 20:27, 12 September 2018 (UTC)
@Mike Peel: File:Patrol link bug.jpg, Commons:Village pump#Infobox Wikidata interactions. --ŠJů (talk) 20:30, 12 September 2018 (UTC)
@ŠJů: Ah, you're using Monobook still. If I add "?useskin=monobook" onto the end of the URL, then I can reproduce the problem. If you want to try "?useskin=vector", then it should look OK. It seems to track back to a div.patrollink {clear: both;} *somewhere* in the CSS for Monobook - if that can be removed then the problem should go away. Thanks. Mike Peel (talk) 23:09, 12 September 2018 (UTC)
Found it - it's in the 'skins.monobook.responsive' module, see [7] (search for 'patrollink'). I have no idea what Mediawiki namespace page that corresponds to, though, so I don't know how to fix it. Thanks. Mike Peel (talk) 23:23, 12 September 2018 (UTC)
It seems that interaction with {{Commons nudity (category header)}} is also broken, e.g. Category:Clitoris. —⁠andrybak (talk) 02:17, 13 September 2018 (UTC)
@Andrybak: I think that's fixed with this edit. Thanks. Mike Peel (talk) 21:39, 23 September 2018 (UTC)

@Mike Peel: It’s defined at phab:diffusion/SMNB/browse/master/resources/screen-common.less;ac0ac079baf2$262 and has been added in phab:rMW01eb893b778d. In phab:T14857, it was said to be an issue that floating boxes float past the patrol link. (It’s Monobook skin itself, patches can be submitted using Gerrit.) —Tacsipacsi (talk) 16:26, 13 September 2018 (UTC)

@Tacsipacsi, ŠJů: I've filed a bug report on phabricator at phab:T205230. Thanks. Mike Peel (talk) 21:47, 23 September 2018 (UTC)

Problems with P131 chains in case of more than one administrative unit[edit]

Please see the infobox at Category:Windpark Kandrich and Kandrich wind farm (Q56558844). The wind farm is located in 4 municipalities, which belong to different districts within the state of Rhineland-Palatinate of Germany:

Problem: taken from the first statement for located in the administrative territorial entity (P131), only the Daxweiler chain is given in the infobox. The rest is missing.
P131 statements like in this case are quite regular ("cross-border" objects located in more than one administrative unit), and they are wanted on Wikidata (be "as exact as possible").
The only solution for a correct infobox on Commons at the moment would be to add the state Rhineland-Palatinate (Q1200) instead of the 4 municipalities, but that would mean loss of precise location information on Wikidata (unwanted).
To add the next higher administrative unit (3 districts) instead of the 4 municipalities, would also be no solution, because the effect would be the same (only the first district would be given). And it would also mean loss of precise location information on Wikidata (please note that there are 118 municipalities in Bad Kreuznach district, 137 in Rhein-Hunsrück-Kreis, and 66 in Mainz-Bingen district, so stating the only relevant 4 municipalities really makes sense).
Another, maybe even better example is Belgium–Germany–Luxembourg tripoint (Q27344570) and the infobox at Category:Tripoint Belgium Germany Luxembourg. Only one municipality and only one country is given in the infobox.
I hope someone can fix this issue. --Te750iv (talk) 18:42, 10 September 2018 (UTC)

@Te750iv: I agree that we lose some information in the infobox when there are multiple values of located in the administrative territorial entity (P131). However, I'm not sure how you want it fixed. At present the call to location for Kandrich wind farm (Q56558844) produces this list:
If you could write exactly what you wanted to see as the list, perhaps I could work out an algorithm to display it. --RexxS (talk) 21:58, 10 September 2018 (UTC)
@RexxS: Sorry for being not clear enough. I want the actual P131 statements (for Q56558844: 4 municipalities), and all countries (if more than one, as in the above tripoint example) to be displayed. This is the correct information.
Such statements were no problem for infoboxes a few weeks ago. The behaviour changed. Displaying only the first P131 statement gives incomplete and incorrect information for numerous affected items/categories, e.g. for linear objects like rivers, roads or railway lines, or for non-administrative areas like mountains, beaches, heritage properties, even for some building or industrial complexes (if located on state or municipal borders like Uchtelfangen substation (Q1515772)). For another prominent example see U.S. Route 66 (Q79934) and Category:U.S. Route 66: per infobox now exclusively located in California, and in no country (don't know why "United States" is missing there).
If I follow the discussions here correctly, you and others have given careful thought and put much work into development of a smart method for displaying complex location chains in infoboxes. I was impressed when I noticed it, and am still astonished what is possible. But the current method of fetching data obviously is highly "automated" and depends on basic assumptions, which are are not (and cannot) be true in too many cases. The main wrong assumption is: everything is located in only one administrative unit. As a result the chosen method has unwanted side effects: loss of information, either on Wikidata by changing P131 statements to less precise levels, or on Commons by displaying precise, but incomplete and only random (=the first) bits of information.
Back to the Kandrich wind farm (Q56558844) example: From my point of view the 4 municipalities and the country (Germany) are the basic and most important information. Displaying location chains completely from low levels upwards is "nice to have", but not a must. The length of chains can be more or less complex (example for Germany: >municipality >collective municipality >district >regional administrative division >state >country). And if you could find a way to display all municipalities including their individual chains, a new problem may arise: what about redundant parts? (often occuring upwards from some administrative unit in the middle; in the given example "Rhineland-Palatinate, Germany" would be identical 4 times). Is it possible to eliminate redundant parts from chains?
So even if I really like seeing location chains in infoboxes, in case I have to choose between the two display variants (complicated but incomplete/ramdom information vs. only basic but correct information), I prefer the latter. Therefore I think a step back and a more conservative approach with less automation is appropriate. --Te750iv (talk) 08:04, 11 September 2018 (UTC)
@Te750iv, RexxS: I've coded up a work-around here, in {{Wikidata Infobox/sandbox}} - please test it to make sure it behaves as expected. Basically, if there are multiple values for located in the administrative territorial entity (P131), then the template falls back to the old {{Wikidata location}}. Hopefully in the long term the Lua code can be modified to handle this directly, but this should do for now. Thanks. Mike Peel (talk) 21:37, 29 September 2018 (UTC)
@Mike Peel: Tested, works as expected. A good solution for now. Thanks very much. --Te750iv (talk) 21:48, 29 September 2018 (UTC)

People with double given and/or surnames[edit]

Hi, there are a lot of cats for people with double, tripple or even more given or surnames. On wikidata they often not claimed as such doubles names, but seperatly to diffenent names. I.e. a person called John Peter Smith Brown doesnt has the claim "John Peter" on commons but seperatly "John" and "Peter". This results this person is sorted into Category:John (given name) and not into Category:John Peter (given name) nor Category:Peter (given name). The same applies to the surname(s). I.e. Category:John Peter Altgeld is now sorted into Category:John (given name) through the infobox and manually Category:John Peter (given name), which is suboptimal. Up to now I fixed that by creating an item on wikidata for such double names see i.e. Gustaf Wilhelm (on wikidata). Bute there a now complains and deletion requests on wikidata to such items - see d:Wikidata:Requests_for_deletions#Q56525307. Is it possible to combine such double claimes on wikidata to one given or surname category here on commons? It would be even OK if the people just get sorted in both (or more) sur- or given name cats. Any coder able and willing to do such a change? Thx in advance --JuTa 19:07, 12 September 2018 (UTC)

@JuTa: It's possible, but it needs some more thinking about. In your example, if 'John', 'Peter' and 'Smith' were all given names on Wikidata, how would you want it handled? What if the 'John Peter (given name)' category doesn't exist, what should the fallback be? Thanks. Mike Peel (talk) 23:34, 12 September 2018 (UTC)
Then leave it out like if single names cats does not exist. I'm busy since years to check people cats and create missing ur- and given name cats. It could be done per bot as well. Laddo initiated a huge bot-run recently - see Commons:Bots/Work_requests#Batch_create_"surname"_categories. Currently I'm rechecking some of them and during that the complaints on wikidate appeared. regards. --JuTa 02:15, 13 September 2018 (UTC)
@Mike Peel: Hi Mike, indeed JuTa's suggestion seems applicable. Simply categorize in all given name categories matching each Wikidata given name property entries (P735). However I'm not sure I understand; you seem to suggest that {{Wikidata infobox}} normally parses the given name from some full name label - or from the Commons page title? If you rely on Wikidata, then there is no issue picking (all the) appropriate given name category/ies.
@JuTa: Regarding WD items for given name combinations like Gustaf Wilhelm (Q56525307), I would also suggest to avoid that, except when such names are linked by dashes (Mary-Laure (Q19689498)) - there are just too many combinations to create an item for each pair. IMHO, rather use multiple given name (P735) entries qualified with series ordinal (P1545), such as in Mary Beth Peil (Q449134). I've seen that a lot in WD already. If Mike can improve given name categorization, the right categorization would be straightforward (e.g. Category:Mary (given name) Category:Beth (given name) for Mary Beth Peil (Q449134)).
Laddo (talk) 02:45, 13 September 2018 (UTC)
Note there is also second family name in Spanish name (P1950) and maybe more similar. People using this claim should be sorted into both surname cats and not into the comibation one. regards. --JuTa 02:55, 13 September 2018 (UTC)
@Laddo: Adding all of the given name categories separately would work, but that wouldn't solve @JuTa:'s request to support Category:John Peter (given name) *unless* that is a specific given name (P735) value on Wikidata. The infobox uses given name (P735) and family name (P734), not the full name label or the commons page title for this. It's the same with second family name in Spanish name (P1950), that can be done, would they just go into the current 'Category:Rodriguez (surname)' format or is there a different format for those? Thanks. Mike Peel (talk) 10:34, 13 September 2018 (UTC)
@Mike Peel: Given name category handling is simpler and cleaner if you simply follow WD's given name (P735) entries. WD and Commons should follow a similar reasoning and policy regarding categories of paired given names like Category:John Peter (given name) : deleting such "double" categories and simply relying on individual given names. WD infobox should categorize in "paired" given name categories only if WD supports one, like for Mary-Laure (Q19689498), IMO. @JuTa: What do you think of avoiding Commons categories like Category:John Peter (given name) altogether ? -- Laddo (talk) 12:29, 13 September 2018 (UTC)
Would be fine for me if this get handeled consequently for all the thousends double name cats, can take a while but there should be a plan to do that including peoples cats which are not yet wikidata connected. regards --JuTa 12:53, 13 September 2018 (UTC)
The first step is to ensure that WD infobox categorizes for all given names, not only the first one. Mike? Laddo (talk) 13:26, 13 September 2018 (UTC)
So, the simplest thing to do is to use the commons sitelinks. Then we can just use {{#invoke:WikidataIB|getValue|rank=best|P735|linked=yes|name=forename|qid={{getQID|qid={{{qid|}}}}}|spf={{{suppressfields|}}}|fwd=ALL|osd=no|noicon=yes|lang=en}} - however, we have more categories here than sitelinked given names right now. How big an issue is that? I was hoping that something like {{#invoke:WikidataIB|getValue|rank=best|P735|linked=no|name=forename|qid={{getQID|qid={{{qid|}}}}}|spf={{{suppressfields|}}}|fwd=ALL|osd=no|noicon=yes|lang=en|prefix="[[Category:"|postfix=" (given name)]]"}} would work - but it just prints out the name, not the prefix or postfix. (Plus, the ifexists check complicates things further). Pinging @RexxS: to see if he can do something magical in Lua / has any thoughts about how to do this with the existing options. Thanks. Mike Peel (talk) 14:09, 13 September 2018 (UTC)
Thx, but sorry, I have now clew of these #invoke things. Thats the reason I'm other people for help :) --JuTa 18:27, 13 September 2018 (UTC)
@Mike Peel: I've enabled unlinked wikibase items to use prefix and postfix now. But that doesn't help much you as you can't pass [[ in a parameter because the wiki-parser immediately creates a link before the invoke is called. I'm not really sure what you want to do, but this formula seems to me to do something in Gustaf Wilhelm af Tibell (Q4457034):
  • {{#invoke:WikidataIB |getValue |rank=b |P735 |qid=Q4457034 |fwd=ALL |osd=no |noicon=yes |linkprefix=":" |prefix="Category:" |postfix=" (given name)"}}Category:Gustaf (given name), Category:Wilhelm (given name) Naturally, you set linkprefix to "" (or leave it out) if you want to add the page to the category, rather than just create the link as I've done here. On the other hand, I'm not sure if will always work or whether it depends on the presence of a commons category. I really need more examples to test on. Maybe play around with the format to see if you can consistently get what you want (whatever that is). Cheers --RexxS (talk) 23:23, 20 September 2018 (UTC)

On the other hand cats like Category:Paul Bailliart would be sorted into Category:Alfred (given name) and Category:Marie (given name) thou the lemma doe not contain Alfred Marie on any project - see d:Q3370547. We would need to either to move the commons cat or throw out the extra given names on WD. --JuTa 21:54, 14 September 2018 (UTC)

Hi, any progress regarding this case? I noticed that the defaultsort allready covers double given/surnames from wikidata except there is a comma too much between the 2 nameparts. That part of the code could be fixed and used to sort the people to the name cats as well, I hope. thx. --JuTa 11:09, 24 September 2018 (UTC)
Sorry, am trying to get a few other things with the infobox sorted out first (there are many changes in the sandbox right now), then will circle back round to this. Thanks. Mike Peel (talk) 11:21, 24 September 2018 (UTC)
@JuTa: It's now in {{Wikidata Infobox/sandbox}} - please test that and see how it works. Thanks. Mike Peel (talk) 23:31, 24 September 2018 (UTC)
@Mike Peel:, I'll do, thx. Please look at #new bug with surnames again. This seems not to be fixed.
@Mike Peel:, tested it. It looks like some brackets are mising - see this version. please reinvestivate. Thx. --JuTa 23:44, 24 September 2018 (UTC)
@RexxS: Somehow this seems to depend on the Commons sitelinks. Compare:
{{#invoke:WikidataIB |getValue |rank=best |P735 |qid=Q47001248 |fwd=ALL |osd=no |noicon=yes | linkprefix=:|prefix="Category:" |postfix=" (given name)"}} -> Category:Luca (given name), Category:Maria (given name)
{{#invoke:WikidataIB |getValue |rank=best |P735 |qid=Q4457034 |fwd=ALL |osd=no |noicon=yes | linkprefix=:|prefix="Category:" |postfix=" (given name)"}}Category:Gustaf (given name), Category:Wilhelm (given name)
I'm not sure what to do here. Thanks. Mike Peel (talk) 00:13, 25 September 2018 (UTC)
Sorry, Mike, the logic does depend on the Commons category (P373) available on Wikidata. I have to get the text to return from somewhere.
Commons category (P373), Gustaf (Q15646212), Wilhelm (Q11027623), Luca (Q1872944), Maria (Q25413386)
  • {{wdib |P373 |qid=Q15646212 |fwd=ALL |osd=n |noicon=y}} → Gustaf (given name)
  • {{wdib |P373 |qid=Q11027623 |fwd=ALL |osd=n |noicon=y}} → Wilhelm (given name)
  • {{wdib |P373 |qid=Q1872944 |fwd=ALL |osd=n |noicon=y}}
  • {{wdib |P373 |qid=Q25413386 |fwd=ALL |osd=n |noicon=y}}
When we request the given name (P735) for Gustaf Wilhelm af Tibell (Q4457034) the logic in WikidataIB goes like this:
  1. We get the qid for Gustaf (Q15646212) and need to find the text to display, so we look at Q15646212 for a Commons category (P373)
  2. That gives "Gustaf (given name)", so we use it to create a link to [[ linkprefix Category: Gustaf (given name) linkpostfix ]] and use the label ("Gustaf") as display text for the link.
However, when we try the same with Luca Maria Bonisoli (Q47001248), there is no Commons category (P373) for Luca, so it looks for a sitelink and there is one in English, so it uses that for the link target - but that will fail for most other languages and we just get the unlinked label.
That is the best we can do for a stand-alone value, but when you're trying to create a compound value, we need a consistent style of output, so you need to avoid requesting linked items and cheat to pass the [[, remembering that the code strips out any double quotes:
That merely depends on the presence of an English label for the name.
In this application, it's probably not essential, but I recommend fixing language as English because all Commons categories are named in English. Does that do the trick? --RexxS (talk) 11:19, 25 September 2018 (UTC)
Thanks RexxS, that seems to do the trick. @JuTa, Laddo: can you test {{Wikidata Infobox/sandbox}} to see if that's working as expected? Thanks. Mike Peel (talk) 18:07, 25 September 2018 (UTC)
@Mike Peel:, looks better, but in the defaultsort there is still a comma to much, see Category:Luca Maria Bonisoli. --JuTa 22:04, 25 September 2018 (UTC)
@JuTa: should be fixed now. Thanks. Mike Peel (talk) 22:08, 25 September 2018 (UTC)
Yep, thx. --JuTa 22:10, 25 September 2018 (UTC)
Agreed, seems excellent. Thanks! -- Laddo (talk) 22:44, 25 September 2018 (UTC)
Sorry, but I now saw, that for surnames 1. The second surname cat is missing and 2. the defaultsort value is incorrect. Mike Peel: Have another look please - see Category:Alfredo Pérez Rubalcaba. Thx. --JuTa 22:48, 25 September 2018 (UTC)
@JuTa: In that case, there is a value for second family name in Spanish name (P1950), which the infobox uses, and which that's hy the defaultsort now looks odd. The issue with supporting multiple surnames is that you want a custom sort key for those surnames - I'm not sure that WikidataIB can cope with using a postfix value that depends on another WikidataIB call. @RexxS: any thoughts on that? E.g. from a QID that has "Bob" as the first name and both "Smith" and "Johnson" for the surname, we'd want to create something like [[Category:Smith (surname)|Bob]][[Category:Johnson (surname)|Bob]] - but only if those categories exist (and not relying on Commons category (P373)). Thanks. Mike Peel (talk) 22:59, 25 September 2018 (UTC)
@Mike Peel: WikidataIB is quite good at coping nowadays. You can indeed use the result of one call as a parameter in another call. Using Gabriel Gonzáles Videla (Q815):
  • {{wdib |rank=b |P734 |qid=Q815 |fwd=ALL |osd=n |noicon=y |linked=n |prefix="[""[:Category:" |postfix=" (surname){{!}}{{wdib|rank=b|P735|qid=Q815|fwd=ALL|osd=n|noicon=y|linked=n}}]]" |lang=en}}Gabriel
  • {{wdib |rank=b |P1950 |qid=Q815 |fwd=ALL |osd=n |noicon=y |linked=n |prefix="[""[:Category:" |postfix=" (surname){{!}}{{wdib|rank=b|P735|qid=Q815|fwd=ALL|osd=n|noicon=y|linked=n}}]]" |lang=en}}Gabriel
You'll have to jiggle with it to get what you want because I'm not sure just what is required. Just remember that you have to encode a pipe character "|" as {{!}} to pass it in a parameter. --RexxS (talk) 23:38, 25 September 2018 (UTC)
@RexxS: Wow, that's impressive! @JuTa: please give the latest version of the sandbox a spin, see how that looks. Thanks. Mike Peel (talk) 23:56, 25 September 2018 (UTC)

@Mike Peel: You may be as sick as I am with typing all those parameters in, so I've implemented "parameter sets" to store your favourite set of parameters. Parameter set 1 makes: rank="best"; fetchwikidata="ALL"; onlysourced="no"; noicon="true". Just use |ps=1

  • {{wdib |ps=1 |P734 |qid=Q815 |linked=n |prefix="[""[:Category:" |postfix=" (surname){{!}}{{wdib|ps=1|P735|qid=Q815|linked=n}}]]" |lang=en}}Gabriel
  • {{wdib |ps=1 |P1950 |qid=Q815 |linked=n |prefix="[""[:Category:" |postfix=" (surname){{!}}{{wdib|ps=1|P735|qid=Q815|linked=n}}]]" |lang=en}}Gabriel

Tell me if you like the idea. --RexxS (talk) 00:25, 26 September 2018 (UTC)

@RexxS: I'm ... hesitant, sorry. I like the compactness, but I'm worried that this makes it more difficult for others to make sense of what the module call is doing. I'm hoping that others will be maintaining this infobox in a year or so's time, and I'd like to keep it clear what call is doing what, as much as possible. Thanks. Mike Peel (talk) 00:38, 26 September 2018 (UTC)
Sure, Mike, you only need use features you're comfortable with, and I understand your thinking. However, on Commons  – unlike on enwp  – we're rarely concerned with opt-in/opt-out or with sourcing (which is often "sky is blue"), so the commonest setting for several parameters is going to be different. I want others to be able to use/maintain the modules as well, but my view is that they would be better concentrating on the important ones and not be distracted by irrelevant |rank=best |fwd=ALL |osd=no |noicon=yes in every call. But I won't worry over it. --RexxS (talk) 09:37, 26 September 2018 (UTC)
@Mike Peel, Category:Alfredo Pérez Rubalcaba look fine now using the sandbox. Thx a lot. --JuTa 06:54, 26 September 2018 (UTC)
I did another test with Category:Maria Cristina of Naples and Sicily which looks fine too. --JuTa 07:09, 26 September 2018 (UTC)
@Mike Peel, 2 other things I noticed when Im using the sandbox:
  1. People get sorted into Category:Uses of Wikidata Infobox with no family name thou they have a surname on WD.
  2. Sur- anf given name cats are getting set thou they are not existing yet. Which ich fine for me, but other people may complain about that.
Please have another look. Thx. --JuTa 23:37, 26 September 2018 (UTC)
@JuTa: The first should be fixed [8] - the code was also adding it where a second spanish name wasn't present. The second is more complicated - with the new code, I removed the ifexist checks. @RexxS: can you think of a good way to add them back - maybe the check could somehow be nested in the prefix parameter, or is that going to be too many layers of WikidataIB? Thanks. Mike Peel (talk) 22:05, 27 September 2018 (UTC)
@Mike Peel: Without an example, it's difficult for me to phrase solutions. However, it seems that you're asking to not add a category to a page if the category page doesn't yet exist, is that right? The checks can be expensive and may end up with spurious "What links here", so I tend to avoid them. If we actually get a complaint, is there any reason why we don't just create the relevant category page? --RexxS (talk) 22:34, 27 September 2018 (UTC)
As I said: I'm happy with that. As long we dont get complaints we can keep is as it is from my point of view. --JuTa 23:07, 27 September 2018 (UTC)
PS: please gimme a ping when you activate the new sandbox. I like to clean up my uses of it. thx. --JuTa 23:09, 27 September 2018 (UTC)
@RexxS: Any of the categories in Category:Uses of Wikidata Infobox missing surname category will probably have the problem - random example, Category:Hamid Amjad. There aren't as many as I expected of those now, though, so maybe it's not a bit issue. I guess adding the tracking category has the same computationally costly as identifying whether to show the category link or not... Thanks. Mike Peel (talk) 23:58, 27 September 2018 (UTC)
@JuTa, Laddo: This is now live. Note that Category:Uses of Wikidata Infobox missing surname category will be deprecated, but the redlinks will show so you can check Special:WantedCategories instead. Thanks. Mike Peel (talk) 21:54, 29 September 2018 (UTC)
Thx, I now removed the sandbox from any peoples cats. --JuTa 00:32, 30 September 2018 (UTC)

Another question: Is there a possibility not to use some WD name statements like on Category:Gustaf Wilhelm af Tibell and D:Q4457034 (family name "af Tibell"? I dont like to start (or continue) an edit war on WD. In this case the other surname is an alternative not a second surname. --JuTa 18:25, 30 September 2018 (UTC)

@JuTa: Set one to 'preferred rank' on Wikidata, and the other one shouldn't be used by the template. Thanks. Mike Peel (talk) 18:32, 30 September 2018 (UTC)
@Mike Peel, thx, but how? When I try to add a qualifier 'preferred rank' or 'rank' it tells me No match was found. --JuTa 18:39, 30 September 2018 (UTC)
@JuTa: See d:Help:Ranking - you use one of the buttons on the left of the value to change this setting. Thanks. Mike Peel (talk) 18:42, 30 September 2018 (UTC)
Ahh, I see. Thats working, thx. We never stop learning :) --JuTa 18:48, 30 September 2018 (UTC)

Integrating {{VN}}[edit]

@Liné1: I'm trying to embed {{VN}} into the infobox, but have run into a couple of problems. For the implementation, see [9]. However, at Hymenaster the VN module gives the error "Error: Incorrect parameter(s) "qid"" - can that be fixed? Also, for cases where there are many VNs, can you implement show/hide, like is done at Category:Iron Man (film) for "Cast member"? Also pinging @Christian Ferrer to be aware of this discussion. Thanks. Mike Peel (talk) 22:53, 24 September 2018 (UTC)

Hello Mike Peel
You needed an intermediary template like {{VNNoDisplay}} because Module:Wikidata4Bio reads the calling templates parameters.
I will see later if we can improve the display.
Regards Liné1 (talk) 20:02, 25 September 2018 (UTC)
Thanks! If possible, suppressing the "No common name has yet been provided in this user nor in wikidata 'Dytaster'" text would be good (that way the row just doesn't show in the infobox). Thanks. Mike Peel (talk) 20:55, 25 September 2018 (UTC)
I think {{VN}} or/and "common name" should be removed from the infobox, see User:Christian Ferrer/sandbox3. Christian Ferrer (talk) 12:35, 30 September 2018 (UTC)
@Christian Ferrer: I've added show/hide for that line in {{Wikidata Infobox/sandbox}}, which is set to be hidden by default. Does that improve things? Thanks. Mike Peel (talk) 13:37, 30 September 2018 (UTC)
Yes it does a lot, IMO you can replace by taxon common name (P1843) by this collapsible VNNoDisplay, but not the both in order to avoid the redundancy. Christian Ferrer (talk) 16:12, 30 September 2018 (UTC)
@Liné1, RexxS: There is still an issue here that when VN returns nothing, the line still shows in the infobox. Live example is at Hymenaster, where {{Wikidata Infobox/sandbox/line | Q502895 |2={{VNNoDisplay|useWikidata=Q3463442}}| showhide=y}} returns
Common name
Some sort of hidden character must be being returned in order to pass the if statements, which remains even using {{Trim}}. Any ideas? Thanks. Mike Peel (talk) 13:57, 19 October 2018 (UTC)
Aah, that actually returns values ... so something else is wrong here, potentially the inclusion of the template in the line template... More investigation needed. Thanks. Mike Peel (talk) 14:00, 19 October 2018 (UTC)
@Mike Peel: Is it the hidden category Category:Biology pages with wikidata item specified in VN or perhaps Category:Interwiki from wikidata - both of which are being generated by the {{VNNoDisplay|useWikidata=Q3463442}} in this section. Preferences → Appearance → Advanced options → Show hidden categories. Cheers --RexxS (talk) 16:32, 19 October 2018 (UTC)
That could be it ... it doesn't look like the 'nocat' parameter does much, sadly. I suspect the Lua code needs some work... Thanks. Mike Peel (talk) 17:21, 19 October 2018 (UTC)

Wikidata infobox in "categories"[edit]

Hi! When showing data from a "category item"... would it be possible borrowing a locator map image (P242) value from another item, linked in category combines topics (P971) (and displaying the map in the infobox, of course)?

Thus, maps such as these could be removed here in Commons. Strakhov (talk) 20:45, 10 October 2018 (UTC)

Pictogram voting comment.svg Comment Nah. I "semi"withdraw the proposal, since category contains (P4224) is apparently the way-to-go with regard to describing categories in Wikidata. Strakhov (talk) 13:16, 11 October 2018 (UTC)

Per above: Would it be possible showing category contains (P4224) instead of category combines topics (P971) in the infobox? Here, for example Category:Fountains in Paris / d:Q8470436. It would need displaying subject ("P4224 item") and predicate ("qualifier property name"+"qualifier value"). That would lead to...

"fountain" + "located in the administrative territorial entity" + "Paris"
"Fântână" + "situat în unitatea administrativă" + "Paris"
"fontanna" + "znajduje się w jednostce administracyjnej" + "Paryż"

...(sort of automatic category name translation). Strakhov (talk) 15:01, 13 October 2018 (UTC)

P669 implementation (and P969)[edit]

Hi, if I understand correctly, current located on street (P669) implementation is fetching label of the street only. I think it would be nice to have also link to a street category in a case of presence of located on street (P669) only, but even in a case of presence of both located on street (P669) and located at street address (P969). I am not sure about how to implement the second case, maybe real splitting "located at street address" row to "located at street address" and "located on street" can be the solution.--Jklamo (talk) 09:19, 17 October 2018 (UTC)

publication in which this taxon name was established (P5326)[edit]


1/ Is it possible to integrate publication in which this taxon name was established (P5326), just below taxon author (P405) in the infobox?

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

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

@Christian Ferrer: Currently, for Allostichaster palmula (Q2858131), Aporocidaris incerta (Q2343200):
{{wdib |qid=Q2858131 |P5326 |fwd=ALL |osd=n |lp=:}} → A new fissiparous micro-asteriid from southern Australia (Echinodermata: Asteroidea: Asteriidae) Edit this on Wikidata
{{wdib |qid=Q2343200 |P5326 |fwd=ALL |osd=n |lp=:}}Resultats du voyage du S. Y. 'Belgica' en 1897-1898-1899, sous the commandement de A. DE GERLACHE DE GOMERY; Zoologie, Échinides et ophiures Edit this on Wikidata
I'm not keen to have piped links to Wikidata because of the criticism I've had in the past that external links should be obvious, rather than potentially surprising the reader who isn't expecting to be taken to another site. However, if |noicon=false, then each publication's Wikidata entry can be reached via a click on the pen icon. Would that be an acceptable compromise? --RexxS (talk) 00:10, 6 November 2018 (UTC)
@Mike Peel: Great, thanks you, tested and approved in Aporocidaris incerta. As far as I am concerned, I put the infobox as soon as I create or modify a category, but not to disturb the historical way I always left {{Taxonavigation}} and {{VN}}. I can talk only for me, but yes, I am very much in favor of the infobox being added in all taxon categories, but below all content please, see previous example. Another good point for the infobox can be seen in Ophiura scomba, where Ophiura scomba is in fact an alternate accepted name (a habit taken for the sake of simplification by almost the entire community, I presume) and whose official name is Ophiura (Ophiura) scomba displayed in the Infobox. Christian Ferrer (talk) 05:16, 1 December 2018 (UTC)
@Christian Ferrer: OK, this is now live. The existing pi bot code adds the template below all other templates, and it's easy enough to run it through taxons. I've already suggested this a few times at Commons_talk:WikiProject_Tree_of_Life#Wikidata_Infobox_and_taxons without getting consensus, feel like having a go at re-suggesting it there? ;-) Thanks. Mike Peel (talk) 21:36, 3 December 2018 (UTC)
@Mike Peel: thanks you, I'd suggect that we wait the outcome of the property proposal that I made on Wikidata, and then, if successful, we will have to work a bit to retrieve the author citations in the Infobox, which is in the eyes of the specialists, very important. After that, and with all the effort and progress we have made since the creation of the taxontree, I think it will be more easy to get consensus. Christian Ferrer (talk) 05:53, 4 December 2018 (UTC)

location: country missing[edit]

At Category:Acaray Dam the only visible location info is "Acaray River", set by located on terrain feature (P706). The item Acaray Dam (Q3433454) also provides "Paraguay" for country (P17). I expect the country to be displayed in the infobox. Is the missing country bit in this case related to changes discussed at #Improvement to "location" field with hierarchical information perhaps? --Te750iv (talk) 12:25, 10 November 2018 (UTC)

@Te750iv: I've added located in the administrative territorial entity (P131) to the Wikidata item, which is what is used to show the location string. Ideally I guess P706 should be shown at the start as well, if @RexxS: wants to look into that. Thanks. Mike Peel (talk) 12:45, 10 November 2018 (UTC)
@Mike Peel: This is what the location function can return:
I can't understand what you want me to do. The function repeatedly looks first for located in the administrative territorial entity (P131), next for location (P276), then for located on terrain feature (P706), following the first one that exists at each step. I'm not sure I can offer a sensible alternative algorithm. The reason why nothing else was showing before is that Acaray River (Q4672121) has no link to any of those three possible higher level geographical entities. We don't look for country (P17) because it's often found at very low level entities and would short-circuit the location chain. --RexxS (talk) 13:38, 10 November 2018 (UTC)
Aah, I assumed there was more location info in Acaray River (Q4672121) that wasn't being picked up, sorry RexxS! Thanks. Mike Peel (talk) 13:45, 10 November 2018 (UTC)
Actually, having thought about it for a bit, would it be preferable to look for country (P17) as fourth choice? so that if none of the three usual upwards links in the chain exist, we could at least get the country (which would then terminate the chain). The disadvantage is that we would lose the ability to spot broken chains and fix them on Wikidata. What do folks think? --RexxS (talk) 23:10, 10 November 2018 (UTC)

Categorize award recipients[edit]

I recently created Category:Recipients of the Ernst Reuter Medal and it remains empty... It would be very useful if the infobox could categorize award recipients automatically.

Picking Ernst Reuter Medal (Q1357178) as an example, Wikidata already relates recipients (all these) to a recipient category in Commons. Say, for Tilla Durieux (Q78793) :

Tilla Durieux (Q78793) award received (P166) Ernst Reuter Medal (Q1357178)
Ernst Reuter Medal (Q1357178) category for recipients of this award (P2517) Category:Recipients of the Ernst Reuter Medal (Q9143958)
Category:Recipients of the Ernst Reuter Medal (Q9143958) links to Commons Category:Recipients of the Ernst Reuter Medal

Is it possible to use this scheme for Commons categorization?

-- Laddo (talk) 13:35, 8 December 2018 (UTC)

@Laddo: I can't think of a straightforward way to do this at the moment. It's complex in the single award case that you've described, but becomes more complex if the person has received multiple awards. @RexxS: Any thoughts? Thanks. Mike Peel (talk) 14:24, 10 December 2018 (UTC)
@Mike Peel, Laddo: yes, I can write a new function, let's call it getPropOfProp, that: finds the value(s) of property1; and if they are wikibase-entities, fetches the value(s) of property2 for each of them; then assembles the results into some sort of list. For Laddo's general case, property1=P166 and property2=P2517. That would produce categories for every award received that has a category for recipients of this award (P2517) set. Is that what is wanted, or is the intention to limit it to just one award at a time (such as Ernst Reuter Medal (Q1357178))? I'll make a start on the function while you're thinking about it. --RexxS (talk) 17:27, 10 December 2018 (UTC)
Obviously, you don't use the linkprefix (lp) if you want to set categories, rather than display them. --RexxS (talk) 19:18, 10 December 2018 (UTC)
@RexxS: Nice, thank you! @Laddo: It's in the infobox sandbox, please test {{Wikidata Infobox/sandbox}} and see if that works as expected. Thanks. Mike Peel (talk) 21:53, 10 December 2018 (UTC)

@RexxS, Mike Peel: Nice!! All items I tested are entered in the right categories... but for some reason they all end up listed under letter "C" in recipient categories (see this one and this one. Could you please double-check that their sort keys are their family names? Thanks! Laddo (talk) 23:55, 10 December 2018 (UTC)

@Mike Peel::
See if that supplies the family name as sort key accurately. --RexxS (talk) 01:03, 11 December 2018 (UTC)
@RexxS, Laddo: That's now in {{Wikidata Infobox/sandbox}}, but I'm not sure it's changed anything... Thanks. Mike Peel (talk) 17:24, 11 December 2018 (UTC)
@Mike Peel: Thinking about it, it probably won't, because the linking already uses a pipe character, so I can't insert a sort key into the linked text, only into the displayed text. I'll re-write the function later. --RexxS (talk) 18:02, 11 December 2018 (UTC)
@Mike Peel, Laddo: I had to re-write the code that displays a wikibase-entity. There's a new parameter |displaytext= (alieas |dt=). It's been worthwhile though, as it now allows us to display whatever we want for the links while retaining the link target. A category with a sort key looks like a piped link to the category with the sort key as the displayed text, like [[ Category:Catname | sortkey ]]. The first example below just shows the categories linked displaying a fixed piece of text, but the second gives the categories linked displaying the given name(s). If you remove the |lp=":" from the second example, we should get a link to each category using the given name(s) as sort key:
  • {{#invoke:WikidataIB/sandbox |getPropOfProp |prop1=P166 |prop2=P2517 |fwd=ALL |osd=n |noicon=y |qid=Q78793 |sep=" " |displaytext=Text |lp=":"}}Text Text Text Text
  • {{#invoke:WikidataIB/sandbox |getPropOfProp |prop1=P166 |prop2=P2517 |fwd=ALL |osd=n |noicon=y |qid=Q78793 |sep=" " |displaytext={{wdib|ps=1|P734|linked=n|qid=Q78793|sep=" "}} |lp=":"}}Durieux Durieux Durieux Durieux
Check that each of those links goes to a different category. I've previewed it without the |lp=":" and the page shows the appropriate categories, so I'm optimistic. Let me know how that goes. --RexxS (talk) 16:18, 12 December 2018 (UTC)
@RexxS: That seems to do the trick! @Laddo: Can you do some more testing of it please? Thanks. Mike Peel (talk) 17:01, 12 December 2018 (UTC)
@RexxS, Mike Peel: Sort is now fine, you may release the new feature! The only glitch I could identify is when the Commons page name is radically different from the person's name (Frauke Petry born Frauke Marquardt, gets sorted under the letter M). If you know of a scheme to pass the actual DEFAULTSORT key to the new "displaytext" function, let me know ;) Thanks for the speedy improvement! Laddo (talk) 23:08, 12 December 2018 (UTC)
Thanks for the fixes in the sandbox @Laddo! If no sort key is added, then the defaultsort would be used, which would probably be better - @RexxS: would that happen if displaytext was set to blank? I'm not sure yet whether to release a partial update of the infobox tomorrow (the new coordinate logic to handle non-earth coordinates isn't quite ready yet), or wait until Sunday or so to do a full update (I'll be unavailable for most of Saturday should any issues arise with the deployment). Thanks. Mike Peel (talk) 00:10, 13 December 2018 (UTC)
@Laddo: This is now live, let's see how it goes. We can continue making tweaks in the sandbox and update them in the next version (nominally next week, unless urgent changes are needed). Thanks. Mike Peel (talk) 11:37, 13 December 2018 (UTC)
@RexxS: I found an oddity, {{#invoke:WikidataIB/sandbox |getPropOfProp |prop1=P166 |prop2=P2517 |fwd=ALL |osd=n |noicon=y |qid=Q9960 |sep=" " |displaytext={{wdib|ps=1|P734|noicon=y|linked=n|qid=Q9960 }} |lp=:}} -> Reagan Reagan Reagan Reagan Reagan Reagan Reagan Reagan Reagan - that unlinked 'Reagan' then shows up in Category:Ronald Reagan. I think it's because Francis Boyer Award (Q5480301) has no category for recipients of this award (P2517) - is there a way to exclude cases like that? Thanks. Mike Peel (talk) 15:36, 13 December 2018 (UTC)
@RexxS, Mike Peel: Similarly, Category:Henry Kissinger has two "Kissinger" at the top of the page as a result of the same problem. Not clear to me if it's due to items not having category for recipients of this award (P2517) at all, like Francis Boyer Award (Q5480301) or Eric-M.-Warburg-Award (Q969644), or if it's related to awards having a WD recipient category with no matching Commons category, such as Order of Tomáš Garrigue Masaryk (Q1548060) having category for recipients of this award (P2517) pointing to Category:Recipients of the Order of Tomáš Garrigue Masaryk (Q8482348)... In the latter case, it would be nice for Wikidata infobox to display a red category link ;) -- Laddo (talk) 00:59, 14 December 2018 (UTC)
Slightly different: Category:Armand Dufrénoy displays "Category:Wollaston Medal winners" at the top. Laddo (talk) 01:53, 14 December 2018 (UTC)
That one went away with this edit to add the commons category - perhaps the enwp category link leaked through somehow? (Feel free to revert my edit for testing.) Thanks. Mike Peel (talk) 02:05, 14 December 2018 (UTC)
Noted. In Category:Jules-Napoléon Ney, the top of the page displays "Q7795935" in between two more categories having no Commons counterpart. No way to create a red link using a QID :) Laddo (talk) 02:21, 14 December 2018 (UTC)
OK, I've wrapped the category code with <div style="display:none;">...</div> - that hides the text, but the categories should still appear. That should do as a temporary solution until RexxS can have a look at this. Thanks. Mike Peel (talk) 10:34, 14 December 2018 (UTC)

@Mike Peel, Laddo: Right. I'm really sorry for the issues, but it's obvious that there are too many exceptions to categories using sort keys for a generic function to cope with all of them. So I've bit the bullet and wrote a bespoke function, just to do this job. I called it getAwardCat. It takes an extra optional parameter, |sortkey= (alias |sk=), which strips out quotes so it can contain spaces. If no sort key is provided, it looks for a family name and uses the sitelink (for preference) or the label for that. If those are not there, it has no sort key. The categories returned similarly prefer the sitelink to the label (for anti-vandalism reasons).

In the infobox code, you'll have to accept a |sortkey= and code it as something like {{#invoke:WikidataIB/sandbox |getAwardCat |fwd={{{fetchwikidata|ALL}}} |osd={{{onlysourced|no}}} |noicon=y |qid=whatever |sortkey={{{sortkey|}}} }}, so that on Category:Frauke Petry, you can use {{Wikidata Infobox |sortkey=Petry}}.

Sorry to have to ask you to do the testing again, but unfortunately it's above my pay grade. --RexxS (talk) 22:24, 14 December 2018 (UTC)

@RexxS: It's me who's sorry for using so much of your time, but this feature has pretty quietly categorized hundreds of thousands of people in award categories. I feel it's been worth it.
Indeed I much prefer that you use sitelinks rather properties when applicable! Don't worry with the testing, that's the easy part I'll be happy to take care of. Laddo (talk) 20:07, 15 December 2018 (UTC)
@RexxS: I'm afraid I preferred the more general function, sorry! There are also category of people buried here (P1791) and category for employees of the organization (P4195) that might be worth adding here in the same way in the future... Thanks. Mike Peel (talk) 18:26, 16 December 2018 (UTC)
@Mike Peel: I took the liberty of adding the call to the new function getAwardCat in the sandbox, though I have no idea about the purpose of parameters {{{fetchwikidata}}} and {{{onlysourced}}}. One side effect is that WikidataIB now supports an undocumented extra parameter {{{sortkey}}}. Please double-check my edit. I found nothing but positive improvements: red links for missing Commons categories (see Jules-Napoléon Ney), corrected sorts (either explicit like Frauke Petry or implicit like Kabayama Sukenori that was listed under letter C, like many others, in Grand Cordons of the Order of the Chrysanthemum and so on. The new service sounds OK to me. Laddo (talk) 18:56, 16 December 2018 (UTC)
@Mike Peel: unfortunately getPropOfProp shares a lot of code with getValue and therefore can't produce a category that has no sort key, so it will never be able to match the functionality of getAwardcat, which has bespoke code to generate categories. However, the code is capable of using other properties beyond award received (P166) and category for recipients of this award (P2517) as they are simply defined once in the opening lines. Instead we could pass a pair of parameters to an expanded function, if and when other auto-categorisations are requested, and turn getAwardCat into an alias to that in order to implement award categorisations. In the meantime, it's important to get the testing done on the new code because it differs significantly from getValue. --RexxS (talk) 20:08, 16 December 2018 (UTC)

Category:Sea cucumbers of the genus Stichopus Brandt, 1835 (Holothuroidea, Stichopodidae) in Straits of Malacca with description of a new species[edit]

Hello, I have two requests please

1/ add DOI (P356) and ZooBank publication ID (P2007) to the infobox
2/ there is a little issue, Sea cucumbers of the genus Stichopus Brandt, 1835 (Holothuroidea, Stichopodidae) in Straits of Malacca with description of a new species (Q22675045) has 5 authors, but only the one that have a wikidata item is quoted in the infobox. Can we fix that?

Regards, Christian Ferrer (talk) 11:28, 11 December 2018 (UTC)

@Christian Ferrer: Both are now in the sandbox, try {{Wikidata Infobox/sandbox}} to make sure that's working as you expect. Thanks. Mike Peel (talk) 17:22, 11 December 2018 (UTC)
Thanks you, for properties relating to "Authority control", that's good. For the authors, that should be ok too, though the display of the number "serie ordinal" is a bit boring in the Infobox IMO. Note that I just removed "stated as" otherwise the first author was quoted 2 times, but it is a bad solution because it would be necessary/better to find the way to avoid this redundancy without removing the property "stated as". Regards, Christian Ferrer (talk) 22:33, 11 December 2018 (UTC)
@Christian Ferrer: It's now live. With the series ordinal, these can be removed by not showing the qualifiers, but I'm reticent to do that as I'm not sure if they display useful information elsewhere. Shall we see how this goes and revisit it in the future? Thanks. Mike Peel (talk) 11:32, 13 December 2018 (UTC)
Ok, thanks you. Christian Ferrer (talk) 16:16, 13 December 2018 (UTC)


Hi! It would be great having BVPH ID (P2961) as identifier here. A hidden tracking category such as Category:Periodicals in the Biblioteca Virtual de Prensa Histórica would be nice too. Strakhov (talk) 22:23, 14 December 2018 (UTC)

@Strakhov: It's now in the sandbox, please test {{Wikidata Infobox/sandbox}} to see if that works as expected. Thanks. Mike Peel (talk) 16:54, 16 December 2018 (UTC)
@Mike Peel: tested twice through page preview+wikidata infobox sandbox, it worked great, both the infobox and the tracking category. Thank you. Strakhov (talk) 17:03, 16 December 2018 (UTC)
Great! Unless it's needed urgently, I'll move it to the main template sometime next week, along with other changes. Thanks. Mike Peel (talk) 18:20, 16 December 2018 (UTC)
No hurry! Strakhov (talk) 20:08, 16 December 2018 (UTC)

Removal of interwiki links[edit]

Hi everyone, there are several categories with WD-Infobox and interwiki links.[10]. Is it ok to remove them with a bot, if the same link comes from WD? --Arnd (talk) 07:27, 16 December 2018 (UTC)

@Aschroet: They should no longer be needed (and will only rot over time as pages elsewhere get moved around) so I'd say go for it. I know @Gabrielchihonglee: and @Zhuyifei1999: were working on this with Gabrielchihonglee-Bot, but I'm not sure if that's running at the moment. I guess if you can bot-work through the ones that you can, we can start working through the remaining ones manually using that search query. Thanks. Mike Peel (talk) 16:51, 16 December 2018 (UTC)
if there is maybe an already working bot in place i will wait. --Arnd (talk) 20:11, 16 December 2018 (UTC)
The bot seems hang since 2018-10-02 19:40:32. I restarted it. --Zhuyifei1999 (talk) 21:20, 16 December 2018 (UTC)
Zhuyifei1999, seems that it do not really run longer this time. Maybe something has to be fixed. --Arnd (talk) 06:10, 17 December 2018 (UTC)
@Aschroet: Could you clarify? It seems still running to me. It scans the dumps so each scan can take a long time (like a day). --Zhuyifei1999 (talk) 07:26, 17 December 2018 (UTC)
Zhuyifei1999, i just checked Special:Contributions/Gabrielchihonglee-Bot and saw the edits stopped and that only very few interwiki link edits took place. --Arnd (talk) 08:19, 17 December 2018 (UTC)
Hmm... Looking at the current situation, am I correct that this template {{Wikidata Infobox}} no longer calls {{Interwiki from Wikidata}}? The bot only works on pages that transcludes the latter, and with the current scheme, invocation of Module:Wikidata alone is not sufficient evidence that Module:Wikidata.interwiki is called, and very complex logic might have to be added to figure out the parameters that are used to invoke the Lua module. I can notify Gabriel to extend the bot, but I don't understand why this separation is done. CC @Mike Peel: --Zhuyifei1999 (talk) 18:06, 17 December 2018 (UTC)
@Zhuyifei1999: It now calls Module:Interwiki directly, which removes a dependency on the template, and means that the tracking category at Category:Uses of Wikidata Infobox providing interwiki links can be populated (to try to see which cases are using the infobox, and which aren't yet but could in the future). If you can check to see if Module:Interwiki is called, that should be sufficient. Thanks. Mike Peel (talk) 18:27, 17 December 2018 (UTC)
Ok I'll notify Gabriel. We are in different timezones so it'll probably be a few hours / tomorrow before I get a chance to catch him. --Zhuyifei1999 (talk) 19:09, 17 December 2018 (UTC)
@Aschroet: should be fixed for now. Updated the script to look for interwiki links provided by Module:Interwiki --Gabrielchihonglee (talk) 05:36, 18 December 2018 (UTC)
Gabrielchihonglee, seems to work fine. Thank you. However, can it be that your bot only considers interwiki links of languages with two letter codes. I ask because of the remaining links as for example here: [11]. --Arnd (talk) 15:09, 18 December 2018 (UTC)
@Aschroet: This is an old bug relating to some leftover inconsistent state in wikimedia configuration / database from the be-x-old -> be-tarask move. So as far as pywikibot is concerned, neither be-x-old nor be-tarask is an interlanguage prefix. --Zhuyifei1999 (talk) 18:14, 18 December 2018 (UTC)
As far as I know that is the only exception. Other codes should work fine (eg). --Zhuyifei1999 (talk) 18:16, 18 December 2018 (UTC)

The bot ran out of memory. I increased the memory threshold and reran it. @Gabrielchihonglee: FYI. --Zhuyifei1999 (talk) 23:19, 18 December 2018 (UTC)


Some WD items like Q1368093 have P373 (Commons category) which is not considered by the template. What is the reason behind it? --Arnd (talk) 17:02, 17 December 2018 (UTC)


Hi! It would be nice having the opposite of headquarters location (P159) (headquarters)... I mean -> occupant (P466) (occupant) displayed in the infobox. The dichotomy "organization vs building" would be way better managed. Thanks! Strakhov (talk) 22:42, 18 December 2018 (UTC)