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.

Wishlist[edit]

  • 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)

P217[edit]

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

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

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)

Population[edit]

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)

(given name) category[edit]

Hi, I noticed my new category Category:Félix_Mesnil (for example) had the infobox added and now the automatically added "Category:Félix (given name)" precedes whatever other categories are there. As this is an arbitrary category (it has nothing to do with the person, it relays no information about them), would it be possible to move it to the end or hide it? I would even suggest to remove it altogether. If there is a discussion about this already, can you point me to it please? Thanks -- Deadstar (msg) 19:05, 11 June 2018 (UTC)

@Deadstar: Since the infobox is at the top of the page, the categories it adds end up at the start of the list. I can easily tweak the code to put it after the date of birth/death categories if that would help. Hiding or deleting the categories would probably be best done as a site-wide discussion, as I understand that some people find them useful, and that's a wider discussion than just this infobox. Note that the infobox also adds a family name category, such as Category:Mesnil (surname), where available - I guess that's more useful though since it groups families/relations? Thanks. Mike Peel (talk) 00:57, 12 June 2018 (UTC)
Thanks Mike - and after the birth/death would be a great improvement. (So birth/death/firstname/lastname/other cats?). As for usefulness... it's all in the eye of the beholder I guess! Thanks for your help & quick reply. -- Deadstar (msg) 07:40, 12 June 2018 (UTC)
@Deadstar: The order has now been swapped, how does that look? Thanks. Mike Peel (talk) 00:23, 13 June 2018 (UTC)
Great - that looks a lot better. Thanks so much! -- Deadstar (msg) 08:38, 13 June 2018 (UTC)
  • We must develop the "Births in (city, town etc)" subcats under "People of ..." cats and incorporate here. --E4024 (talk) 08:40, 13 June 2018 (UTC)
It will be a big progress again a time. And why not a categorisation with the place of burial. Jérémy-Günther-Heinz Jähnick (talk) 09:02, 13 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 {
     "P642",
   },
   ["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 {
     "P580",
     "P582",
   },
   ["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]

Hello,

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, Île-de-France, France. 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, Île-de-France, France. 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)

Media legends[edit]

  • When displaying an image with a media legend (P2096) value in the reader's preferred language, should we display that value? An example is Category:Her Benny (novel) / d:Q16842509#P18, which has a value in English. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 14:47, 1 September 2018 (UTC)
  • I think images in this infobox should have P2096 at least as an 'title' parameter of an image (if not as a real caption). Take a look at e.g. Category:Indolines: there is a structure of a chemical compound in the infobox, the category is about class of compounds, and the P2096 explains why this particular image of a compound is associated with the item about the class of compounds. Wostr (talk) 19:39, 2 September 2018 (UTC)
    • @Pigsonthewing, Wostr: I've merged the sections together as I think you're asking the same thing. The question is how to display it: we currently use the descriptions in the usual place of media captions. Maybe the description could move above the picture, what do you think? Thanks. Mike Peel (talk) 21:58, 3 September 2018 (UTC)
      • Caption below the image (and descriptions below the title) would be the most natural way of displaying this, but I don't know how this template is built and for how many situations is designed, so I'm not sure if this is the right way for this infobox. Wostr (talk) 21:00, 6 September 2018 (UTC)
  • @Pigsonthewing, Wostr: This is now in the sandbox, please try {{Wikidata Infobox/sandbox}} and see how that looks. Note that there's a known bug that the filename might appear if there is no media caption, which I've asked RexxS about below. Thanks. Mike Peel (talk) 20:09, 23 September 2018 (UTC)
    • This is now live. Thanks. Mike Peel (talk) 21:23, 25 September 2018 (UTC)
Checkmark This section is resolved and can be archived. If you disagree, replace this template with your comment. Mike Peel (talk) 21:23, 25 September 2018 (UTC)

Wikidata Infobox adds irrelevent categories to pages[edit]

Hello,

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)

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)

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)

Protected areas[edit]

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

Taxon[edit]

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

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

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

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

Testing code[edit]

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

1.

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

2.

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

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

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

genus (genus) genus (Q34740)

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

species (species) species (Q7432)

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

Taxon common name[edit]

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

Module Taxobox[edit]

  • @RexxS: I give just you this link in case you may find some thing interesting there : Module:Taxobox Christian Ferrer (talk) 17:55, 20 September 2018 (UTC)
    @Christian Ferrer: Thanks. I've seen it before and it's useful but is in need of a re-write to use the non-expensive calls to get statements, rather than fetching the entire entity every time. Something for the future. --RexxS (talk) 17:31, 23 September 2018 (UTC)

Links[edit]

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

Tweaks -- mobile behaviour + circa dates[edit]

(per request moving requested tweaks to talk page)

  • Would you please be able to make {{wikidata infobox}} behave better in mobile view. The categorised information should probably take priority over the infobox. People have come for the content, not the infobox. Noting that one does not get the option to hide the infobox in the mobile view. Thanks.  — billinghurst sDrewth 12:20, 23 September 2018 (UTC)
    @Billinghurst: My initial approach was to disable it completely, but having thought about it some more I think it's still useful on mobile, but has to be very minimalist. So I've made some modifications to the stylesheet to hide rows/infomation that aren't essential to make it a lot smaller. Please test {{Wikidata Infobox/sandbox}} to see how that looks - it's live at Category:Torbenfeldt Slot and Category:Alfredo Pérez Rubalcaba as examples. Thanks. Mike Peel (talk) 15:25, 23 September 2018 (UTC)
    ✓ works well.  — billinghurst sDrewth 21:44, 23 September 2018 (UTC)
  • Dealing better with circa dates. At Category:Alfred Odgers we see a person who was born sometime in late June or early July 1844, however, the use of circa there has thrown out the categorisation for birth.  — billinghurst sDrewth 13:01, 23 September 2018 (UTC)
    @RexxS: Is there a way to disable the 'circa'? E.g. {{#invoke:WikidataIB|getValue|rank=best|P569|qid=Q24646500|fwd=ALL|osd=no|noicon=yes|df=y}} -> c. 1844 but should just say '1844'. Thanks. Mike Peel (talk) 14:56, 23 September 2018 (UTC)
    @Mike Peel: I thought the whole point of having qualifiers for dates like "circa" was so that they would be displayed? I can, of course, add yet another parameter that turns off the code which looks for sourcing circumstances (P1480). See Module:WikidataIB/sandbox for a version that accepts |plaindate= (or |pd= as an alias). Setting that to true/yes/1 will suppress the circa:
    • {{#invoke:WikidataIB/sandbox|getValue|rank=best|P569|qid=Q24646500|fwd=ALL|osd=no|noicon=yes|df=y}} -> c. 1844
    • {{#invoke:WikidataIB/sandbox |getValue |rank=best |P569 |qid=Q24646500 |fwd=ALL |osd=no |noicon=yes |df=y |plaindate=yes}} -> 1844
    • {{#invoke:WikidataIB/sandbox|getValue|rank=b|P569|qid=Q24646500|fwd=ALL|osd=n|noicon=y|df=y|pd=y}} -> 1844
    What I can't do, however, is determine in advance whether circa is to be displayed or not, as the psychic extension is not yet enabled for Lua. Cheers --RexxS (talk) 16:23, 23 September 2018 (UTC)
    Thanks RexxS, that works nicely - testing at Category:Alfred Odgers the code now auto-adds the birth year category properly. @Billinghurst: That look OK to you? Thanks. Mike Peel (talk) 16:32, 23 September 2018 (UTC)
    yep working too. Samwilson has been playing with this categorisation for enWS for our author pages. Lots of combinations to work with.  — billinghurst sDrewth 21:44, 23 September 2018 (UTC)
    It's true, we've got dates and circa working, as well as floruit (P1317), and we're now looking at adding work period start and end (P2031 & P2032, to also be displayed as e.g. "fl. 1900–1910"). — Sam Wilson ( TalkContribs ) … 00:15, 24 September 2018 (UTC)
    @Billinghurst, Samwilson: The changes are now live. BTW, would an infobox like this one be useful on Wikisource? Thanks. Mike Peel (talk) 22:58, 24 September 2018 (UTC)
    I am not adverse to that, let me start a conversation at s:WS:Scriptorium  — billinghurst sDrewth 23:00, 24 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)

new bug with surnames[edit]

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

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

Request[edit]

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

@Asqueladd: I don't understand. Please can you point me to some practical examples? Thanks. Mike Peel (talk) 00:14, 26 September 2018 (UTC)
@User:Mike Peel. The idea is to remove the showing of coordinates from the "connects with" values of this infobox, for instance: Category:Calle de Padilla, Madrid. Regards.--Asqueladd (talk) 09:12, 26 September 2018 (UTC)