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)

property links[edit]

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

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

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

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

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

Do we want to have a horizontal display option?[edit]

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

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

Mike Peel - the shortest answer for me is: YES, of course!
Both options have advantages and disadvantages. An argument that something was always don't mean that it should be always and - Wikipedia (is for reading; most of text with some illustrations) is something else as Commons (is for watching; contains near only pictures), so simple comparison is unjustified.
Personally, I prefer the horizontal variant and there is many arguments to support it, but not in every situation, nor for every category. So, we must decide which variant will be default and, regardless of result - possibility to switch H <-> V form will be very needful. Mike, if it's not a big problem, maybe we can try the both versions together and see how it looks like in the real situations, without guessing? --Jasc PL (talk) 02:32, 17 April 2018 (UTC)
@Jasc PL: As a test, try {{Wikidata Infobox/sandbox|horizontal=yes}}. The main issue is probably that the column breaks might not be in the right place in different categories, as it depends on how much content is available. I can try to tweak them if need be. Here's how it looks for Category:Lovell Telescope. Thanks. Mike Peel (talk) 23:05, 17 April 2018 (UTC)
Lovell Telescope 
Lovell Telescope 5.jpg
radio telescope at Jodrell Bank Observatory, Cheshire in the north-west of England
Wikipedia
Instance ofradio telescope,
parabolic reflector
Part ofJodrell Bank Observatory,
e-MERLIN,
European VLBI Network
Named after
LocationCheshire East, United Kingdom
Heritage designation
Service entry2 August 1957
Area
  • 4,560 square metre
official website
Authority control
National Heritage List for England number: 1221685
Wikidata
I was so excited before first try @Mike Peel and still I am, but some things goes wrong in the first test version - examples are at the dedicated sandbox. Feel free to use it anywise you need, I 'll put there some more examples I find:
  • Width is now limited to 635px only (Raspberry Pi); my proposal is to offset to the left (about -13px; padding-left 0px) and set max width dynamic to 100% or (no less than ?) 770px - if e.g. {{TOC right}} or something similar is used on gallery pages
  • logo image (P154) and image (P18) together in one place - it's not a good idea :)
  • The problem is, when the bigger image (e.g. collage) is used - example Category:Gdańsk --Jasc PL (talk) 02:26, 18 April 2018 (UTC)
  • There are also some problems with "clear" in the horizontal version, or both? (I will test it further). --Jasc PL (talk) 18:41, 18 April 2018 (UTC)
    • @Jasc PL: I've moved this into a separate sandbox at {{Wikidata Infobox/horizontal}} - I suspect it'll take a while before it's ready. I've also made some tweaks that make the Lovell Telescope example look worse, but the others should look better, so on average it's an improvement. The ideal would be something like [3], but that doesn't seem to work in Firefox. :-( Thanks. Mike Peel (talk) 21:20, 18 April 2018 (UTC)
@Mike Peel, there are also tons of ready javascripts for every situations, but it consuming extra time, we haven't now of course. I feel that work with horizontal version should not stop deployment of "classic" vertical variant what will be more appropriate for most categories, so default. By the way:
  • mascot (P822) need to be scaled down in the same way as logo image (P154)
  • There is a small bug (probably not concerned with infobox directly) with the link under map: when the mouse is from the left over "Wikidata: Qxxx, Wikimedia maps" rolling out element is blinking, when you try from the right - all is as should be. Tested with FF 56 (Gecko), Iron (Chrome) 65, Opera 50
  • I see that some qualifiers need to have the rank set to preferred, otherwise we have a long list of values with normal rank (e.g. Raspberry Pi - operating system = 15 :) --Jasc PL (talk) 21:56, 18 April 2018 (UTC)
@Jasc PL: This is definitely a bonus feature, so shouldn't hold up the deployment, and if we want to convert a given topic to use the horizontal version in the future then it should be simple to write a bot to do that. Javascript would work, but that will cause a two-stage loading problem, and I want to avoid that. Maybe something could be done using Lua to count elements that will be shown and divide them up into rows accordingly, but fully Lua-using this is still a way off (and probably isn't something I'll be doing, since I don't know Lua). We're not using P822 at the moment, want me to add it? I can't reproduce the bug using FF 59, but see it in Chrome 65; that must be a bug with Kartographer, so I suggest you take that to phabricator. Normal rank values will show up when there's no preferred rank value, that's the expected behaviour. Thanks. Mike Peel (talk) 22:14, 18 April 2018 (UTC)
Thanks for your answer @Mike Peel:; I don't know how many items use mascot (P822), but it's popular by Linux categories, e.g. Slackware, so - YES. --Jasc PL (talk) 22:34, 18 April 2018 (UTC)
I was expecting it to be an image, but it turns out to be a link. Anyhow, now added to the sandbox for testing. Thanks. Mike Peel (talk) 22:49, 18 April 2018 (UTC)
Sorry @Mike Peel, my mistake, and the effect of work in the nights; at the Slackware Category there is a Linux mascot (Slackware-mascot.png), but it's a regular image (P18). --Jasc PL (talk) 23:42, 19 April 2018 (UTC)
@Mike Peel:, @Jasc PL: I'm exited for the option of a horizontal display which works a lot better for some applications. The work so far looks promising. One of the advantages of a horizontal format is that the fields can be wider and there doesn't have to be so much uncomfortable word wrapping going on, so freeing it up to . Right now if there is no image, you get a lot of white space on the left which could be put to better use. One thing I'm thinking is that we can maybe have a couple of options for how it is oriented. Maybe instead of merely thinking of it as a boolean horizontal option, it could be a general 'orientation' or 'style' option ('vertical' (force the vertical choice), 'horizontal' (force horizontal), 'horizontal-noimage' (optimized for those that may not need an image displayed), etc.) which would default to vertical but allow possibly a few different options to best meet editors' needs. Anyway, looking forward to working on it going forward. Josh (talk) 22:28, 25 May 2018 (UTC)

Unnecessary links[edit]

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

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

error?[edit]

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

@Te750iv: Should be gone now, with this edit on Wikidata. I'll have a think about how to better catch that oddity. Thanks. Mike Peel (talk) 20:06, 1 May 2018 (UTC)

Default hide?[edit]

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

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

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)

Maps of categories[edit]

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

@Jim.henderson: It looks like the maps are working OK, but the coordinates are in the middle of nowhere so there's nothing to show in them. In both cases the coordinates were imported from Wikipedia (en and da respectively). I'm not sure if they should be removed from Wikidata or if they are useful coordinates to have... Thanks. Mike Peel (talk) 12:22, 30 May 2018 (UTC)

Errors at Category:Meryl Streep[edit]

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

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

grayed out map[edit]

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

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

wide infobox[edit]

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

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

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

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

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

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

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

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. [4]), 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)

Width at 210px is too narrow[edit]

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

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

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

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)

Far too many incorrect locations[edit]

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

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

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)

Wikimania poster[edit]

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

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

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

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 [6]. 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)

Mapshape inverted for certain locations[edit]

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

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