Template talk:Wikidata Infobox

From Wikimedia Commons, the free media repository
Jump to: navigation, 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.


  • ✓ Done Display interwiki links to Wikipedia/Wikivoyage/etc. Mike Peel (talk) 11:44, 3 February 2018 (UTC)
  • ✓ Done Handle cases like 'human settlement' better, e.g., at Category:Paranapiacaba. Mike Peel (talk) 11:44, 3 February 2018 (UTC)
  • ✓ Done heritage designation (P1435) --Atamari (talk) 16:26, 4 February 2018 (UTC)
  • ✓ Done located on street (P669) (+ street number (P670) +postal code (P281)) --Atamari (talk) 16:26, 4 February 2018 (UTC)
    I see, p669 is not that easy. The road has to be created separately as an item, which requires a few thousand more. Alternative Property is located at street address (P969). --Atamari (talk) 21:03, 4 February 2018 (UTC)
    @Atamari: I've added a switch to display P969 where available. Can you test the version in the sandbox to see if that works as expected, please, and/or let me know some example cases? Thanks. Mike Peel (talk) 10:06, 5 February 2018 (UTC)
    Category:St. Michael (Limburg an der Lahn) Wikidata with P969 ("Domplatz 1"). Q1590425 is another example with P969. --Atamari (talk) 10:50, 6 February 2018 (UTC)
    @Atamari: OK, this is mostly working (and live in the main version). If P969 is present, then that is displayed; then if any of P669, P670 or P281 are available then they will be shown instead, otherwise nothing will be shown for that line. The template does not handle cases where one of those properties is a qualifier to another of the properties, though - so in the case of St. Michael it will not show the number, but it will show the street. It's probably possible to improve that at some point, but it's a bit complicated to do so right now. Thanks. Mike Peel (talk) 22:02, 6 February 2018 (UTC)

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

@Strakhov: Architect should now be included. Can you point me to a case where Wikiquote and Wikisource aren't working, please? Thanks. Mike Peel (talk) 22:42, 6 February 2018 (UTC)
Great! Uhmmm: Category:Ángel Ganivet: wikisource & wikiquote (Spanish). strakhov (talk) 22:48, 6 February 2018 (UTC)
Ah, sorry, I'm browsing in English so I didn't notice those links (yay, the checking code works? ;-) ). Will look into it! Thanks. Mike Peel (talk) 22:52, 6 February 2018 (UTC)
@Strakhov: It should now be fixed - can you check again, please? You might need to purge your cache (add "?action=purge" onto the end of the URL). For some reason it bounces through the English version of the project, but it should end up at the right place. Thanks. Mike Peel (talk) 23:00, 6 February 2018 (UTC)
Yep, it's all right. Apparently it uses the English version, but the prefix es: redirects the click to the right place. Thanks! ~~
Great! Please ping me if you spot any other issues! Thanks. Mike Peel (talk) 23:19, 6 February 2018 (UTC)
  • Category:Oval Office clock - inception issues. Mike Peel (talk) 20:55, 9 February 2018 (UTC)
  • 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)
  • Handle more film-related properties, e.g., Category:Kingsman: The Secret Service. Mike Peel (talk) 23:34, 13 February 2018 (UTC)
  • Dimensions, masses. Mike Peel (talk) 22:44, 21 February 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)

Width issue[edit]

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

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

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


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

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


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)

P856: Website display[edit]

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

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

Templates that the infobox should be added below?[edit]

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

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

Do we want to auto-remove other templates?[edit]

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

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

@Ghouston: For the main bot run, I'm leaning towards putting it below the last }} on the page, as that should avoid any problems even if it's not the ideal position. For Category:1985 births, I'm not sure what content could/should be shown in that case? The bot run will avoid adding the template to any category that is instance of (P31)=Wikimedia category (Q4167836) with no category's main topic (P301) to follow to a topic item. Thanks. Mike Peel (talk) 11:13, 11 March 2018 (UTC)
Possibly just a list of the topics that the category combines? --ghouston (talk) 11:18, 11 March 2018 (UTC)
@Ghouston: That's a good point. Something like [3] might do the job - try {{Wikidata Infobox/sandbox}} and see how that looks? Thanks. Mike Peel (talk) 11:31, 11 March 2018 (UTC)
Yes, I think that's useful for showing how the Wikidata item is set up. It also works if the the item is a bit confused, like Category:1986 births and other years, which have P301 and P971 together. --ghouston (talk) 11:42, 11 March 2018 (UTC)
@Ghouston: It's now in the main version. Thanks. Mike Peel (talk) 21:52, 11 March 2018 (UTC)
Checkmark This section is resolved and can be archived. If you disagree, replace this template with your comment. Mike Peel (talk) 12:21, 23 April 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 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 [4] - 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. [5]. 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
Instance ofradio telescope,
parabolic reflector
Part ofJodrell Bank Observatory,
European VLBI Network
Named after
LocationCheshire East, United Kingdom
Heritage designation
  • Grade I listed building
Service entry2 August 1957
  • 4560 square metre
official website
Authority control
National Heritage List for England number: 1221685
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 [6], 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)

Q-values leaking into DEFAULTSORT[edit]

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

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

Bot run[edit]

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

  1. Category:São Paulo (city) ✓ Done
  2. Category:Madrid Mostly ✓ Done - although the bot got quite distracted by the subcategories...
  3. Category:Greater Manchester ✓ Done
  4. Category:Brazil
  5. Category:Astronomical objects
  6. Category:United Kingdom
  7. Category:India  Doing… (first 5,000)
  8. Category:Jainism ✓ Done @Capankajsmilyo:
  9. Category:Spain
  10. Category:Art


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

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

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

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)

Errors at Category:War of the Fourth Coalition[edit]

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

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

Displayed template breaks Cat-a-lot[edit]

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

@Odysseus1479: Which browser are you using? I'm using catalot myself, on Firefox, and it seems to work OK for me... Thanks. Mike Peel (talk) 16:14, 24 April 2018 (UTC)