Template talk:Wikidata Infobox

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

Known bugs[edit]

(don't add 'section resolved' until bug is fixed)[edit]

misplaced captions[edit]

(workaround: make sure all images have captions in at least one language)

Wrong caption in Wikidata infobox[edit]

When there are more pictures of the same item in Wikidata, and not all of them have a media legend, the infobox sometimes chooses a different caption for a different image. The issue has recently been discussed at the Village Pump, when the infobox displayed a picture of Melanogaster tuberiformis but accompanied it with a caption of Melanogaster variegatus. That particular problem has been solved by adding the media legend to the picture of M. tuberifosmis in Wikidata, but there can be many more problems like this in Commons. I think the infobox should be fixed so that it was not allowed to choose a caption that is not relevant to the chosen image. --Jan Kameníček (talk) 08:36, 7 December 2020 (UTC)[reply]

Template pulling the wrong image description from Wikidata[edit]

In Category:Schmallenberg, the infobox shows File:Schmallenberg from above.jpg, which is the first image specified at Schmallenberg (Q5628). But below it, it shows the caption Casa de la vila (town hall), which does not fit the image. Took me a while to figure out that the template is pulling the caption from the Catalan media legend field associated with the second image linked at wikidata (File:Schmallenberg, stadhuis foto2 2010-08-12 11.51.JPG, which indeeed shows the town hall). Providing a media legend for the aerial photograph would probably fix that, but I'm going to leave it alone for the moment do demonstrate the problem. El Grafo (talk) 09:58, 25 February 2022 (UTC)[reply]

@El Grafo: It's a known issue, there's no easy fix on the template side right now, the best thing is to add the media legend for the first photo - or better, only have one image (P18) value and move the other one to aerial view (P8592). Thanks. Mike Peel (talk) 10:23, 25 February 2022 (UTC)[reply]
Yes, I was looking into cleaning that up, just didn't want to destroy the evidence. But if that's a known issue I guess I'll just go ahead. Anyway, thanks for having a look! -- El Grafo (talk) 10:34, 25 February 2022 (UTC)[reply]
Would it be possible to skip over any images that lack a caption in cases where there is at least one that has one? (ran into this with baby cry (Q109649419)) Arlo James Barnes 20:43, 19 June 2022 (UTC)[reply]

Removal of birth and death categories[edit]

Hello everyone, is it desired to remove birth and death year categories when the connected Wikidata item contains the related date? If so i would prepare a bot for cleanup. --Arnd (talk) 10:38, 13 April 2019 (UTC)[reply]

Moin Moin Arnd, sounds great, could the bot run for given name and surname too? And what I see too, was, that a lot wrote "Infobox Wikidata"/"Wikidata infobox"/"wikidata infobox" and not "Wikidata Infobox". Could we fix that with the run too? Regards --Crazy1880 (talk) 11:07, 13 April 2019 (UTC)[reply]
Sounds good to me. Crazy1880, Pi bot should now regularly change uses of the redirects to {{Wikidata Infobox}} - I wrote code for that but it wasn't regularly running until the configuration change I just made. Thanks. Mike Peel (talk) 16:13, 13 April 2019 (UTC)[reply]
Actually, I would prefer this NOT happen. If the infobox is ever removed in the future, the categories are lost. And Wikidata gets vandalized more than one might think. I think Some redundancy in categories is ok. Honestly, this infobox is really starting to become a bit of a annoyance, like its handlers want it to become an omnipresent entity controlling everything from on high in the gilded realm of Wikidata, to hell what peasant humans might think. --Animalparty (talk) 17:40, 13 April 2019 (UTC)[reply]
Presumably if the infobox is systematically removed in the future, the auto-included categories would be substituted, so I don't think the category information would be lost. If redundancy should be kept (and I'm not convinced it's actually useful), then I think it's better on Wikipedias (where the info can be referenced) then in Commons categories. Thanks. Mike Peel (talk) 18:00, 13 April 2019 (UTC)[reply]
Moin Mike Peel, thanks for Pi bot run. Could you fix "Infobox Wikidata" > "Wikidata Infobox" too? The rest from the run looks good. Regards --Crazy1880 (talk) 19:27, 13 April 2019 (UTC)[reply]
@Crazy1880: It's running through {{Wdbox}}, {{Wikidata infobox}}, {{Infobox Wikidata}}, {{Infobox wikidata}}, {{WI}}, {{Wdbox}}. There were more cases than I was expecting, so it may take a while. Thanks. Mike Peel (talk) 19:34, 13 April 2019 (UTC)[reply]
Moin Moin Arnd, There were no further objections now. How far are you? --Crazy1880 (talk) 12:58, 28 April 2019 (UTC)[reply]
i waited for other objections before starting to work on a script. I'll start with it now. --Arnd (talk) 18:02, 28 April 2019 (UTC)[reply]
Crazy1880 and others, i just started a test-run. Feel free to take a look (Special:Contributions/ArndBot). And, if something goes wrong please stop the bot and inform me. Thanks, --Arnd (talk) 18:10, 29 April 2019 (UTC)[reply]
Moin Moin Arnd, I noticed something else. There are still categories (People by name, Men by name, Women by name) which could also be removed. Also this information comes meanwhile from the properties from Wikidata. What do you mean? Regards --Crazy1880 (talk) 10:02, 1 May 2019 (UTC)[reply]
Crazy1880, doesn't it depend from the naming of the category or something else or can they generally be removed? --Arnd (talk) 19:19, 1 May 2019 (UTC)[reply]
Seems that category must have the name "given name" + "surname" or at least contain both, right? --Arnd (talk) 17:18, 2 May 2019 (UTC)[reply]
@Aschroet: It would be good to remove those at the same time. Check for instance of (P31)=human (Q5) for Category:People by name, sex or gender (P21)=male (Q6581097) for Category:Men by name and sex or gender (P21)=female (Q6581072) for Category:Women by name. Thanks. Mike Peel (talk) 17:43, 2 May 2019 (UTC)[reply]

Crazy1880, am i right that Category:Deceased people by name can be removed when there is a date of death? --Arnd (talk) 13:32, 10 May 2019 (UTC)[reply]

Moin Moin Arnd, yes, thats correct. PS.: Special Thanks for your doing, its great. Regards --Crazy1880 (talk) 17:00, 10 May 2019 (UTC)[reply]

Crazy1880, can i generally ignore the sortkey of the birth/death year category as for example in Category:Alex Cousseau which has [[Category:1974 births|Cousseau, Alex]]. --Arnd (talk) 21:14, 19 May 2019 (UTC)[reply]

@Aschroet: Check to make sure given name (P735) and family name (P734) are set - in this case they aren't, so it's probably best not to remove it, or to move the sort key to a defaultsort tag before removing the year category. Thanks. Mike Peel (talk) 06:47, 20 May 2019 (UTC)[reply]
Mike Peel, in what way the Infobox adds the sortkey? surname, given name? So i would only remove in this case. --Arnd (talk) 09:13, 20 May 2019 (UTC)[reply]
I think the DEFAULTSORT itself can also be removed with there is a surname, given name as key. --Arnd (talk) 12:36, 27 May 2019 (UTC)[reply]
@Aschroet: I think you're right, just make sure that both surname and given name are set. That is the order they are added. Note that there are discrepancies that need to be investigated in Category:Uses of Wikidata Infobox with defaultsort suppressed (set by defaultsort=no), it's probably best to avoid those for now. Thanks. Mike Peel (talk) 18:55, 27 May 2019 (UTC)[reply]
In case the sur- or given name(s) containing Umlauts or similar like é, ò please keep (or set) the |defaultsort=no in the wikidata box and add (if possible) a DEFAULTSORT without those Umlauts. Thx --JuTa 15:08, 27 May 2019 (UTC)[reply]
Moin Moin JuTa, ich glaube das ist der falsche Weg, die Infobox sollte das regeln und zwar korrekt. @RexxS and @Mike Peel, is it fixable, thats the DEFAULTSORT sets the right words, or is that so wanted? Regards --Crazy1880 (talk) 18:51, 27 May 2019 (UTC)[reply]
@JuTa: That's an interesting request, can I ask why? I'd have thought we'd want to include accents etc. in the sortkey? Thanks. Mike Peel (talk) 18:55, 27 May 2019 (UTC)[reply]
They don’t work—that is, they are sorted after non-accented letters: e.g. Ádám is after Zoltán in Commons. —Tacsipacsi (talk) 19:25, 27 May 2019 (UTC)[reply]
Belated re: I'm wondering if this could be resolved by passing the sort key through en:Template:Remove_accents. @RexxS: Any thoughts on a better way to remove accents from a string? Thanks. Mike Peel (talk) 17:41, 21 June 2019 (UTC)[reply]
No, Mike. The code used in en:Module:Latin and thence in en:Template:Remove accents is fine. As there are probably other use cases for that functionality, I'd recommend importing both of them into Commons (you may need to set some level of protection for obvious reasons). Having the module here would also allow other Lua modules to call and use its functionality directly. That seems the best way to me. --RexxS (talk) 19:58, 21 June 2019 (UTC)[reply]
Postscript: Mike, I've remembered that I'd written a module to do similar things at en:Module:Diacritics. On enwiki, we can use:
  • {{#invoke:Diacritics |stripDiacrits | Núñez Cabeza de Vaca, Álvar }} → Nunez Cabeza de Vaca, Alvar
So you could import that instead if you wanted. Naturally, you can create a wrapper template for the call if you prefer. --RexxS (talk) 14:17, 22 June 2019 (UTC)[reply]
Hi, any news according this case? Would be rather helpfull by categorizing people. --JuTa 21:50, 17 July 2019 (UTC)[reply]
@Mike Peel: Any updates, any plans? --JuTa 06:14, 15 August 2019 (UTC)[reply]
@JuTa and Tacsipacsi: Can you give {{Wikidata Infobox/sandbox}} a spin please? It should now remove accents from the DEFAULTSORT. Thanks. Mike Peel (talk) 07:53, 15 August 2019 (UTC)[reply]
Hi Mike, I tried the sandbox in Category:Ferenc Ács and Category:İnci Özdil. The first looks fine, but for the second: She is still sorted with Accent within Category:Özdil (surname). Perhaps you didn't used "remove accent" trick for the sorting in Surname-cats (according the given name). Cheers --JuTa 14:42, 15 August 2019 (UTC)[reply]
Ping Mike... --JuTa 16:07, 21 August 2019 (UTC)[reply]
@JuTa: OK, I've tweaked it some more, try again now. Thanks. Mike Peel (talk) 16:14, 21 August 2019 (UTC)[reply]
Hi Mike. Now it looks good in Category:Özdil (surname). Can you make it productive? Thx. --JuTa 16:26, 21 August 2019 (UTC)[reply]
I have a bunch of changes I want to release at once, but they need a bit more testing first. I should be able to make it live by the weekend. Thanks. Mike Peel (talk) 16:29, 21 August 2019 (UTC)[reply]
Thx Mike, I just made another test with Category:Əvəz Mahmud Lələdağ (a double given name). It looks like the sorting in Category:Lələdağ (surname) is still incorrect, should be under A or perhaps E but not under Ə. Cheers. --JuTa 16:40, 21 August 2019 (UTC)[reply]
@JuTa: That's because Ə isn't included at the moment - what should it be replaced with, and does it have a lower case version? Thanks. Mike Peel (talk) 16:48, 21 August 2019 (UTC)[reply]
As far as I know it should be replaced by A and the lower case is ə. I tried now Category:Čolak-Anta Simeonović and it looks fine in Category:Simeonović (surname). Cheers. --JuTa 16:53, 21 August 2019 (UTC)[reply]
áàâäǎăāãåąəćċĉčçďđḍðéèėêëěĕēẽęẹġĝğģĥħḥıíìîïǐĭīĩįịĵķĺŀľļłḷḹṃńňñņṇŋóòôöǒŏōõǫọőøŕřŗṛṝśŝšşșṣťţțṭúùûüǔŭūũůųụűǘǜǚǖŵýŷÿỹȳźżž. Thanks. Mike Peel (talk) 17:03, 21 August 2019 (UTC)[reply]
Looks fine, thx. In case more characters would be required, I'll give you a ping. --JuTa 21:42, 21 August 2019 (UTC)[reply]

@Mike, next weekend coming soon. Any plans? --JuTa 10:38, 29 August 2019 (UTC)[reply]

@JuTa: OK, the new version is now live, and I've disabled the bot code that resolves defaultsort conflicts. Let's see how this goes over the next few days (and please keep an eye on Category:Pages with DEFAULTSORT conflicts in particular!) Thanks. Mike Peel (talk) 18:11, 30 August 2019 (UTC)[reply]
Thanks a lot. --JuTa 18:18, 30 August 2019 (UTC)[reply]

According to i.e. Category:Mạc Thái Tông the character seems not to be sorted correctly. @Mike Peel: Can you have a look please. --JuTa 00:15, 15 October 2020 (UTC)[reply]

copyright license (P275)[edit]

Hello, is it possible to add copyright license (P275) to the infobox?

Example of use in Commensal Leucothoidae (Crustacea, Amphipoda) of the Ryukyu Archipelago, Japan. Part I: ascidian-dwellers (Q21192014) retrieved in Category:Media from White and Reimer 2012 - 10.3897/zookeys.163.2003. Regards, Christian Ferrer (talk) 15:20, 8 May 2019 (UTC)[reply]

@Mike Peel: copyright license (P275) is ideal information in the template for Pixabay ({{Pixabay}}), now with non-free license (see the Wikidata Infobox use in Category:Pixabay without the license data).BoldLuis (talk) 00:48, 1 June 2020 (UTC)[reply]

Display P1343?[edit]

Would it be possible to display described by source (P1343)? It was recently added to a lot of danish churches (example: Old Haderslev Church (Q11999538)) and I know of at least one user who would appreciate this a lot. Thanks. --Hjart (talk) 21:27, 4 November 2019 (UTC)[reply]

It's probably possible, but I would argue against it. Wikidata Infoboxes should concisely present only the most relevant, essential information on a subject rather than indiscriminate, tangential, or trivial data of interest to only a relatively small number of people. Any famous person or place may be described by dozens if not hundreds of sources (e.g. encyclopedias, databases, books, scholarly articles, etc.). An exhaustive list of described by source (P1343) would be, exhausting. We don't need to regurgitate the entirety of Wikidata on every Commons page. --Animalparty (talk) 03:08, 5 November 2019 (UTC)[reply]
I understand, but then again I would argue that Danmarks Kirker (Q11964713) can hardly be labeled "trivial" or "tangential". Almost all danish churches are represented in wikidata, but far from all of them in any wikipedia and in those cases the mentioned user would add links to Danmarks Kirker (Q11964713) to the associated Commons page, rather than click the wikidata link. I basically want to remove his (perceived) need to do that. --Hjart (talk) 14:38, 5 November 2019 (UTC)[reply]
It looks like there should probably be a Wikidata eternal-ID property for that source. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 11:05, 12 November 2019 (UTC)[reply]
@Hjart: Would an external-ID property work here? I think that would be a better solution than trying to display described by source (P1343), if possible. Thanks. Mike Peel (talk) 06:30, 15 November 2019 (UTC)[reply]
@Steenth: is responsible for the current situation and I think it would be better to have him answer that question. --Hjart (talk) 07:46, 15 November 2019 (UTC)[reply]
@Steenth and Hjart:  ? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 11:23, 8 August 2021 (UTC)[reply]

Alternate image[edit]

Is the alternate image, d:Property:P6802 meant to display in the Wikidata infobox if the primary image is missing? It currently does not. I thought the idea was that if we do not have an image of the person or thing something closely related was meant to display, like a cover of a book they wrote or a work of art they created. Currently we display images of gravestones and coats of arms if no primary image is available, and we have the option of displaying all of them by ticking a box in the infobox even when the primary image is present. For instance at Robert Ensko (Q7344166) since we have no image of him, the image of his book would display. --RAN (talk) 18:58, 20 January 2020 (UTC)[reply]

  • This is a question probably better asked at Commons:Template talk:Wikidata Infobox. In my opnion, infoboxes should not display tangential images, which can easily attract cruft and trivia. Some people would rather have infoboxes display every conceivable iota of information imaginable. Looks matter. Less is more. And in the case of Mr. Ensko, I'd argue it's better to have no image than an image of a book. Inboxes should display only the most exemplary images, not any old image available. -Animalparty (talk) 21:38, 20 January 2020 (UTC)[reply]

Please defaultsort without tussenvoegsel[edit]

I'm disabling the defaultsort quite often because Dutch family names aren't sorted by their "tussenvoegsel", tussenvoegsel (P7377). If we did the D and V would be 40% of the Dutch phone book. Please consider automating this. Vera (talk) 08:43, 9 February 2020 (UTC)[reply]

This may need proper data setup and coding for the P7377 property in Wikidata. --ghouston (talk) 06:48, 10 February 2020 (UTC)[reply]
how/where can this be done/requested? Vera (talk) 14:58, 10 February 2020 (UTC)[reply]
Does it need any further work on the Wikidata side? The setup seems already possible on surname items, e.g., as used on Q7913878. But that's not enough to fix the sort order, e.g., on Category:Nick van der Velden. Presumably the infobox template would need modication to support it, and this is the right place to request it. --ghouston (talk) 04:24, 11 February 2020 (UTC)[reply]
  • Maybe for each prefix (or each family name) one needs to add a statement that the prefix should be ignored for sorting (sample: "has quality" = "ignore for Commons sorting") . Jura1 (talk) 14:07, 11 February 2020 (UTC)[reply]


@Verdy p: Re [1] - can you point to some examples of the problem please, and I'll investigate it? Thanks. Mike Peel (talk) 11:54, 23 April 2020 (UTC)[reply]

Look at the categories by years or by country. The recursion breaks, and then generates many false categorisatrions in all the 14 types on categories for dominical type of years (common/leap years starting on Monday/Tuesday..) or multiple categories for multiple incorrect countries (e.g. all the ~50 countries in Europe simultaneously).
When this change was applied, many categories exploded, overpopulated with thousands of incorrect subcategories listed. And these subcategories contain dozens of bold-red messages saying that the maximum script execution time was overflowed. The infoboxes also included these messages, and various kinds of error messages, and many incorrect wikidata selected. verdy_p (talk) 15:46, 23 April 2020 (UTC)[reply]
See for example those incorrect categoies now added in Category:Leap years starting on Sunday (they were still not updated with the propagation of my revert): this should have contained only simple numeric years. Look at any one of them, you'll see these bold-red messages; now force an update now with my revert, they are now correctly displayed (without the broken recursion, and without the false categorisations, and this category disappears instantly from the 14 categories for years by dominical letters and from many other unrelated categories where it was added (but still their listed members are also incorrect as they were added also by other categories using the broken recursion.
Recursion is not checked at all for the supposed containment and can sometimes enter in infinite loops (this may be caused by some subtle bug in wikidata where there's a confusion between classes and instances or "part of". The recursion is not limited in terms of parents (some categorisation have very high depths, and not necessarily finite with some loops).*
So I think it's simply impossible to perform such recursion safely. There are too many bugs in Wikidata modelisation to fix before such thing is attempted, and fixing the Wikidata data will take years or will never terminate (there are lot of complex cases and ambiguities not resolved). So keep the data lookup simple, looking into basic properties of a single object and not generalizing that to any property value that points to other objects to recurse. The complex cases are those topics related to geography (there are lot of exceptions everywhere in the world, various exceptions being limited by contraint qualifiers, like for historic places, or because of conflicting political claims, or uncertainty of some properies with only a likely range of property values, but your new automated recursion ignores these constraints completely or is extremely unlikely to unterpret them correctly like what humans do). verdy_p (talk) 15:57, 23 April 2020 (UTC)[reply]
@Verdy p: Thanks, I think it's mostly due to the time-outs (they then mean that the checks whether to add the later categories aren't run right, so they're always included in them). I think it's because of the heavy-weight country items more than anything else. I'll have a think and see if there's a straightforward way of avoiding those (either a blacklist of QIDs or a check of P31 of the sub-items perhaps). Thanks. Mike Peel (talk) 16:05, 23 April 2020 (UTC)[reply]
If you think that some infoboxes should list other properties collected from other items, this should be done in Wikidata by adding some of these properties, but Wikidata maintainers won't appreciate such massive denormalisation of the data model they attempt to build and cleanup progressively, item by item, model by model (which in lot of cases is still not complete and cleaned up, as it requires lot of searches and lot of validations and patience (look at the many contraints reports that list tons of problems to solve). A passive unbounded recursion in the infobox simply cannot work at all with how Waikidata is structured, and managed (with various incomplete changes in the model that your recursion is unable to track).
Recursion should then be strictly limited in scope, and never by using "blacklists" (which will ignore lot of complex cases), but only "whitelists" and a maximum depth (your first try should have not attempted to perform more than one level of recursion on these "whitelisted" properties). verdy_p (talk) 16:15, 23 April 2020 (UTC)[reply]
Note: there is more important things to do in infoboxes, notably when you format the list of qualifier added between parentheses after a property value: we would like to be able to kwow not just the value of the qualifier, but also its type, for example to distinguish the starting date from the ending date when they are both listed, and distinguish them also from a quantity; using a basic comma-delimeted list of qualifier values, possibly with their own link, does not help a lot interpreting the displayed result.
So instead of adding such recursion in infobox, consider investing time in the data modelisation in Wikidata (and you'll see that this can never stop: it's very hard (or most probably impossible) to correctly modelize all the human knowledge in a way that is fully and recursively automatable with correct inferences. In all cases in Wikidata the scope of recursions by transitive properties has to be limited in depth. Even only the mathematical concepts have their own ambiguities (so infinite inference on transitive properties is simply wrong after very few steps, where there may be some approximations that cumulate rapidly: the transitive properties are only correct with a margin of error/approximation for example 99% of cases, then on the second step this becomes <98% right, then <95% right, then <85% right, then only correct in one case on two, then they are just completely random guesses).
See notably the Theorems of Gödel on incompleteness: there cannot exist any model of inference which is "complete" without introducing self-contradictions; this is a wellknown paradox, proving that infinite transitive inference is wrong; any correct inference cannot be complete, and so transitive inference MUST be finitely bounded, otherwise it will unavoidly returns ALL possible assertions for all aspects of the universe, all wrong assertions and all true assertions. And wikidata does not just attempt to model a purely binary logic, it also models a largely fuzzy logic for human/social/philosophical concepts where assertions are only true within a limited margin of certainty, which is almost never 100% but depends on lot of unspecified/unknown factors and conditions. These factors/conditions/constraints are also impossible to express "completely" with a non-contradicting set of axiomatic rules, also as a consequence because of Gödel's theorems. Uncertaintity really exists everywhere, and it is impossible to avoid (so the pure binary logic is fundamentally flawed, it is proven that there exists "undecidable" assertions, I'm not saying "unprovable" which is a different problem, and attempting to decide a certain true or false value for these undecidable assertions by adding an axiom to the system will instantly introduce self-contradictions; this also has consequences on "computability", notably here with this unbounded recursion of infoboxes).
And adding more time allowed for scripts will not solve this problem. The time limitation is needed and largely sufficient, if you don't recurse without any bound on depths and scope. verdy_p (talk) 16:19, 23 April 2020 (UTC)[reply]
Also if you make any whitelisted recursion (on a strictly limited depth and scope), the added info should only add info into the infobox, and exclude all kind of autocategorization of the page containing the infobox (this creates overcategorization in all cases into the correct parent category and all the incorrect grandparent categories that you've recursed). verdy_p (talk) 16:43, 23 April 2020 (UTC)[reply]
@Verdy p: That's a lot of text. All I'm trying to do here is to follow category combines topics (P971) to display extra information about the topic, in a similar way to how the infobox follows category's main topic (P301) for single-topic items. It seems to fail for country items as they are simply too big to handle, I'll try to figure out a way to avoid them. Thanks. Mike Peel (talk) 20:22, 23 April 2020 (UTC)[reply]
@Verdy p: } I think this edit should have fixed the problem, please let me know if it didn't. Thanks. Mike Peel (talk) 20:14, 24 April 2020 (UTC)[reply]
It seems to work. However the presentation of the multiple agregated infoboxes into a single one is confusive; there's no clear separation between the related topic that you add to the same infobox, so all info seems to be mixed together to the same parent topic. At least there should be a stroke separating them, or separate boxes, one below each other...
I see in fact little or no benefit to add all these extra info on the same page, when the related topics listed in the parent have a link pointing to a page (with the same info but in its own infobox). This looks like unnecessary duplication and just makes the pages even more confusive and unnecessarily polluted.
You've noted that this made the search of these info really slow and now many more category pages have to be recomputed and cached, causing lot of unnecessary work on the server, or most of the related info added will be out of sync, most of the time: the info can be fixed in wikidata and refreshed in its associated page on Commons, but not at all in all the many member pages where they were collected (and it's simply undoable to force the refresh all children pages citing the parent topic as a related topic, each time one info is changed in the related topic in Wikidata: keeping only one link from the parent topic to the related topic avoids all that work (with still the hige risk of seeing many of these pages broken again and not fixed for long if ever this was caused by a single incorrect data in the related topic, that was propagated into tons of subtopics associated with other subtopics.)
What you made created a huge combinatorial problem: all Commons pages using such combo-infoboxes will not longer be up to date and will be inconsistantly updated for long (and the number of combinations between topics is really huge in Commons). Keep things simple: just keep the links to related topics, don't even try to detail the info they contain when you can simply visit pages for these topics directly, via a single click on their link, and with low efforts and little and no maintenance for pages in the server to refresh them to have consistant results !
Such combo-infobox is a confusive tool made only for lazy people that don't want to point and click a link and may want all the details at once on the same page (and frequently there's lot of redundancy between the infos of the related topics and the infos of the subtopic in which you've placed the combo). And when it's not redundant, it may now display contradicting statements, that won't be easy to fix (fixing it in the related topics in Wikidata will not propagate to the subtopic pages where the combo is placed and still displays the old info; so this will confuse a lot of editors that will wonder how and where to fix the incorrect or contradicting info, while a single link to a related parent topic gives an immediate location where the infos can be fixed). Note as well that now we have several "pen" isons to fix the data, these pens are not evident to discriminate or locate (when there were conventiently only one at the bottom right corner of the infobox, easy to locate visually).
  • 1. Such "combo infoboxes" do not add any value, they are only confusive for many readers, create many maintenance problems for contributors, and cause severe performance impact on the server: rendered pages with these combo will now no longer be in sync with the actual source data from which they were generated, they will alway be late now (for very long time, it's impossible to propagate every change in data for one topic to all the subtopics in which they were associated; imagine the number of combinations with just the number of countries and the number of years, then add the country divisions, populated places; then associate more than 3 topics such as types of objects in a given country and a given date; and each data change requires now refreshing hundreds of pages; make only two changes in Wikidata items, and almost all pages in Wikidata will have to be regenerated due to combinatorial effect of each "crossed" topics). And with 3 associated topics, now we've got 4 infoboxes combined, that's a lot of pollution with info that was already seen when visiting one of pages for the related topics and that will be repeated again and again in all the associated pages (but inconsistantly due to the refreshing problem which is simply impossible to perform at once, or that would force the server to disqualify completely its page caches, forcing each visit to perform a now very slow refresh before the users sees anything in the page)...
  • 2. It's highly preferable to invest time to fix how property qualifiers are displayed: only the qualifier value, nothing allwing to discriminate the type of qualifiers (e.g. when there are start/end qualifiers with dates, quantity qualifiers: the value alone for the listed qualifiers after the property value does not helps to say if this is a start date or an end date, a geographic location or a political/administrative location (these qualifier values alone have lot of homonymic uses, especially those that look like numbers, dates, place names, people names) as the type (role) of the qualifier is invisible. When there are multiple qualifiers, their presentation in a list is also in arbitrary order.
Suggestion: if the related topics have a suitable link that is visitable (note that these links are already generated in the property values for "related topics"), assume this link will go to a page already having the necessary infobox for these details, then don't add this extra infobox into the combo ! That's simple, efficient, fast. It will also respect the users that can click instantly this link to get the details only on demand (if they need it)! (This suggestion also handles the case where you just had to exclude adding infoboxes for countries into the combo, because coutries also have lot of details and they all have a visitable link which is already generated in the list of "related topics" citing these countries).
What you did is the equivalent of repeating into all articles citing an item the definition of every occurence of that item that has a link to its definition page. We don't do that, we just use a link and centralize the details elsewhere (we even avoid repeating the link at each occurence of the cited item). Otherwise this pollutes the text of the article, this distracts the visitors and this makes the article unreadable and dificult to summarize at a whole (the only useful info to add is the only info strictly necessary to disambiguate instantly the linked items, but never all its details) and makes the navigation into the content almsot impossible to perform consistantly without being lost in all the added details.
The situation for the category combines topics (P971) property (which associates two or more topics in a Commons subcategory and for which you created this "combo" feature for infoboxes) is radically different from the situation for the category's main topic (P301) property (where only 1 topic is listed): importing the parent infobox to display it may be useful in that later case; but we normally avoid repeating this info as properties of the subtopic itself (such info is generally already removed from properties of subtopic items in wikidata as they are unnecessary, denormalized duplicates and also cause maintenance problems when the info is better suited for the parent topic defining it once for all subtopics, i.e. once for a class instead of every instance, or once for a parent item for all its parts, because all these instances or parts inherit from this identical property from the parent item). And because of that, the infobox for the subtopic having a category's main topic (P301) property will generally contain no details about the single related item cited... except that it can also be visitable by a link, and there's also no need to import the infobox when users can just follow the link and in my opinion the same rationale should be used: don't import that in a combo also for category's main topic (P301), even if it cites a single item, when this item is linked and visitable on demand!
All your efforts to create these combo infoboxes are needless
And if you're still not convinced, try using the external tools that do that in Wikidata, notably Reasonator: look at all the dummy info that it can collect at bottom of its reports for "related topic", including related medias showing other locations, or samples of other completely unrelated items that are just weakly linked as another example of a property for a parent generic topic but no relations at all with the currently visited subtopic of that parent.
And even if you choose to import only a "significant part" of the info for the parent topic, you will unavoidly create an arbitrary bias (for not presenting the parent topic completely and making arbitrary choices on parts to show and parts to hide, possibly creating a situation of edit wars to select what is important to show for some users and not others). As we want to avoid bias, we necessarily have to presetn lot of info for the parent topic, and thus all this should not be added again into subtopics that just need to give a link to their parent/related topic(s).
verdy_p (talk) 22:57, 24 April 2020 (UTC)[reply]

Machine-readable language for auto-hyphenated words[edit]

After introducing hyphens:auto in the infobox (or, rather, before doing so), the language of the output should be precisely marked, as hyphenation rules differ from language to language. So every single output label, description etc. should be wrapped in <span lang="LANG">...</span>, or, even better, <bdo lang="LANG" dir="DIR">...</bdo>, LANG and DIR being the language of the text chunk and the directionality (ltr or rtl) of that language, respectively. I don’t know how the module works, but it’s a must-have IMO, as without this extra markup, browsers can only guess how the word should be hyphenated, and failed guesses may produce really weird output. If the second form is used, it also helps a lot for users of right-to-left languages like Arabic or Hebrew, because in addition to their right-to-left language, there are inevitably left-to-right English labels where no translated label is available, sometimes completely mixed up. Specifying languages (either way) also helps users of assistive technologies like screen readers that can pronounce text in the right language. —Tacsipacsi (talk) 21:51, 23 April 2020 (UTC)[reply]

@RexxS: Is this something that could be incorporated in WikidataIB? Thanks. Mike Peel (talk) 18:55, 24 April 2020 (UTC)[reply]
@Mike Peel and Tacsipacsi: You want every single piece of text returned from WikidataIB for every call to be wrapped in <bdo lang="LANG" dir="DIR">...</bdo>? Wouldn't that make a mess of the way we auto-generate categories? Also, don't you think that will give the Wikidata-haters great ammunition to scrap the use of the module on enwp? Or am I going to have to start maintaining two different versions of the module?
I have a couple of alternative suggestions:
  • Use a template (similar to {{Wdib}}) to add the markup to WikidataIB's output. This has the advantage that the template can have language and direction hard-coded when exported to single-language wikis.
  • Write a module that calls WikidataIB, simply passing the calls and parameters to it, then wrapping the text returned in the desired markup and then returning it to the calling page.
Can you see any other solutions? --RexxS (talk) 19:54, 24 April 2020 (UTC)[reply]
@RexxS: Good points. I don't think a wrapper would work, as WikidataIB may return multiple languages for a single call (e.g., if it's returning the labels from 4 items for a property, and 2 of them are available in Arabic, but the other 2 have fallen back to English, so they need different markup). If it can't be done by default, I'd suggest adding an optional parameter... Thanks. Mike Peel (talk) 20:02, 24 April 2020 (UTC)[reply]
There's a more important point to lok at than considering the way hyphenation is performed for line wraps: look at labels shown in mixed language and notably those that may contain parts in parentheses or other punctuation or mirrorable characters: if you don't embed each translated label into a <bdi>...</bdi> element, the punctuation will go to various places or will be incorrectly mirrored and parts of the label may be separated by other unrelated items anywhere elsewhere in the list of items.
And please, don't use the deprecated <bdo>...</bdo> elements, as these old "Bidi overrides" (defined early in HTML4 at a time when the old deprecated overrides were defined in Unicode as control characters but the Bidi algorithm was still not finalized and was demonstrated to be broken and was later modified to use newer controls and a much better algorithm) will break the order of lists (the direction of the content is propagated to the content placed **after** these overrides, so the separators (like commas) or terminators (like periods ending sentences), or any additional info at end (like precisions added in parentheses, like qualifiers) may be incorrectly placed on the wrong side in the reading order of the main element containing the whole list.
Only <bdi>...</bdi> is suitable (it was added in late updates of HTML4 and is part of HTML5 since the begining, as a safer replacement for past overrides; it has the "bidi-isolation" behavior that was standardized in the second major version of the Unicode BiDi algorithm, and also added and standardized in CSS along with the preparation work for HTML5 and tests in HTML4). "bdi" mimics the behavior of "bidi-isolation" in Unicode, which has also defined equivalent Bidi controls (to be used in plain text also instead of the deprecated "override" Bidi controls). Using "bdo" element in HTML is only suitable if you have perfect and complete knowledge of what is included inside them (its initial and final directions) *and* just before *and* just after them, so "bdo" is only for old static content where you can freely add other overrides where needed; this necessary condition is not satisfied with translatable labels that can have arbitrary values (and are not necessarily in the default script that you expect most of the time for a translated language). The "bidi-isolation" mode is also different from "bidi-embedding" mode. As well "right-to-left marks" (RLM) and "left-to-right marks" (LRM) should be avoided as they are also "overrides" (they may only be used inside the static plain-text value of the translated labels themselves, where they will be added appropriately for the language and script these translated labels are targeting, when it is not suitable to insert HTML code in these plain-text labels).
With "bdi" you don't even need to specify a dir="rtl/ltr" attribute for the content (only the lang="" attribute may be relevant to indicate from which language the translated label comes from): the embedded label should already be correctly ordered as is in isolation, in its default reading order, that will be used unchanged without affecting the direction of contents placed before or after the "bdi" (the "bdi" element itself has NO direction, it is "transparent/neutral" and does not break the direction of the outer content, it perfectly isolates its inner content that will be never be splitted in several parts like with all other bidi modes). verdy_p (talk) 01:02, 25 April 2020 (UTC)[reply]
@RexxS: I don’t know how categorization by this template works. Of course it should be taken care of, but most user-visible texts of this template may potentially include wiki links, which is not suitable for categorization in the first place, so I don’t think the two purposes use the same endpoints as of now. This change makes no sense on the English Wikipedia, but that’s the only such language. It makes sense not only on Commons, but also on any monolingual wiki where that single language is different from English—when it comes to Wikidata, Arabic Wikipedia faces the same issues as Commons with Arabic interface language. This can be turned off automatically if the user language (content language in case of monolingual wikis) is English if you wish so, but should be on on non-English monolingual wikis as well.
@Verdy p: Where has <bdo> been deprecated? Mozilla Developer Network lists <bdo> as a valid, non-deprecated element, with perfect browser support. In contrast, <bdi> is also a valid, non-deprecated element, but has much poorer support: no IE, no legacy Edge (EdgeHTML), no Safari, no iOS support (on iOS every browser should use Safari’s engine, which doesn’t support it). So I don’t think time has come to use <bdi>. —Tacsipacsi (talk) 02:06, 26 April 2020 (UTC)[reply]
Deprecation of overrides is from Unicode itself that admitted that Bidi-overrides had bad effects and created Bidi-isolation especially for this purpose.
But as overrides still have some valid use (only for **static** content where you know exactly which texts is inside, and immediately before it and immediately after it) so that the effective direction is known) and there were lot of preexisting documents using overrides, this possibility has been maintained in the Bidi algorithm.
But Unicode, CSS, and HTML specs strongly recommand using isolates rather than overrides, espacially when the contents is generated and you don't know what text may be before, inside or after the embedded text. The really bad effects of overrides (including LRM and RLM controls) are wellknown and documented since long and could not be solved without the introduction of "Bisi-isolation", which was finally standardized in the second major version of the Bidi algorithm (this is the only version that everyone uses today, the former version is effectively deprecated, exactly because of multiple serious problems for punctuations, mirroring, and the absence of support isolates). "bdo" has been kept in HTML only for compatibility with former contents where its bad "propagating" effect is what was really intended by the initial content creators (and it's no easy to fix it: replacing overrides by isolates would revert these effects inside contents which "seemed" correct, and then will change the layout and the interpretation of the content).
If you are still not aware of the many problems that Bidi-overrides cause in multipart-generated contents, please document yourself. All these problems are cleanly solved by isolates which is the ONLY safe thing to do in Wikimedia for all generated contents (including notably templated lists).
verdy_p (talk) 02:30, 26 April 2020 (UTC)[reply]
Also you're wrong: isolates (and the second major version of UBA, the Unicode Bidi Algorithm which standardized isolates) is fully supported in Safari, iOS... I don't know any OS or browser that does not support isolates (and "bdi" in HTML4 or HTML5), except very old softwares created many years ago before the publication of the UBA and that were not updated at all since then (old versions of IE? their support is now ended since long).
The UBA version that added isolates was in Unicode 6.3, published on 30 September 2013, but isolates were already described in an annex before and have been requested, discussed since even longer. I can't beleive that Apple would refuse to integrate isolates in Safari or keep Safari to an antique Unicode version. The UBA is one of the most important part of the Unicode standard that cannot be ignored (even if implementing other parts may be delayed), especially by an international corporation like Apple that cannot ignore the large Arabic and Hebrew speaking markets.
In reality the only bidi mode that Apple does not support in Safari and iOS, is the "isolate-override" mode (coming from preliminary works in CSS and in Unicode before the finalization of UBA v2) which is useless, and which is different from the "isolate" and the "override" modes, by being a strange mixup initially requested but that prove to be completely ill-defined (I can't understand why Mozilla kept this experimental mode). "isolate-override" is also different from the "embed" mode (which is also part of the older Unicode standard and used by RLE/LRE control characters). The "embed" mode however works with a required explicit "direction" that propagates inside the embdded element, but unfortunately also after it, so it was also a failure but it has been kept for compatibility (Apple chose to not support that ill-defined mode too).
"bdo" (which requires and explicit rtl or ltr direction) in HTML maps to the old "override" mode (also used by RLM and RLM control characters), and the "bdi" element in HTML maps to the "isolate" mode (unlike "bdo", the "bdi" element does not require any explicit direction as its default direction is "auto").
Apple's Safari for iOS (since Safari 6, published on 30 July 2012) has full support of the "isolate" mode of CSS (from where it originated) and of the UBAv2 (that adopted the CSS definition, and that was then integrated into Unicode 6.3 standard in 2013). Are we really "too early", or is it just Apple late to change Safari to recognize the "bdi" HTML tag, when it already supports UBA2 in CSS? We can do one thing on iOS: just add a CSS stylesheet definition for iOS, stating that missing rule that Apple forgot: bdi { unicode-bidi: -webkit-isolate; } (you could add a first style with the "embed" value for old versions of iOS using Safari before v6 still not having UBAv2, but I bet almost all these old iPhones with iOS 3.1-5.1 or before sold before 2012 are dead today! Some MDN measurements indicated already they represented less than... 0.01% of the market in 2018, only for version 5.1, and all other versions before 5.1 were already undetectable). Reports indicate however that the "-webkit-" prefix is still needed (only in iOS with Chrome or Safari) for the "isolate" value in CSS, but it works !
In addition, since iOS 10 (and macOS 10.12), the API "String localizedStringWithFormat()" automatically inserts Unicode isolate controls <FSI>...<PDI> (i.e. U+2068...U+2069) around all placeholders (like the "%@" in "%@ has the highest score!" in translatable and formatable messages, that will be replaced by the arbitrary name of a user, which may be written in Arabic, but as well this message is translatable in Arabic and will allow user names in Latin; for such case, using Bidi overrides would never work at all as the inner direction of the placeholder is compeltely independant of the outer direction). The "%@" placeholder in localizable format strings, is in fact equivalent to "\u2068%s\u2069" in classic format strings (and this already worked with the text renderer in the iOS and MacOS API since mid-2012 and even earlier before with a specific API of the text renderer to support this "isolate" mode in CSS)...
See this presentation in video: "https://developer.apple.com/videos/play/wwdc2016/232/".
This is a higher level way to format strings with mixed language direction, without manually inserting directional marks (and another proof that UBAv2 of Unicode 6.3 was already integrated but here this is enforced in a more practical way so that most applications using translation templates will benefit from it, without having to encode these controls in translation units). Even though this is an improvement in the UI layout support API for iOS/MacOS, the UBA support for isolates was already present since several years in the text rendering engine itself. It was already integrated in CSS with Safari for iOS and MacOS; only the HTML renderer forgot initially to predefine the appropriate CSS style for the "bdi" element (which is still parsed correctly by Safari in the HTML DOM)...
verdy_p (talk) 02:42, 26 April 2020 (UTC)[reply]
Thanks for the detailed explanation, then let’s use <bdi lang="LANG">...</bdi>. (Actually I just noticed that the mentioned override—in a more complete form—is already present in MediaWiki:Common.css, although it isn’t loaded in mobile view, so maybe it needs to be moved into a mobile-ready gadget.) But do use it, as without that we end up with really annoying results sometimes, even with the recent widening of the box. —Tacsipacsi (talk) 23:08, 1 July 2020 (UTC)[reply]

Roman names[edit]

Hi, could the wikidata properties Roman cognomen and Roman praenomen be used for the sorting into correspongding given and surname categories (and perhaps as DEFAULTSORT as well)? Thx and regards --JuTa 07:54, 18 June 2020 (UTC)[reply]

@Mike Peel: Any comments or opinions? --JuTa 13:07, 12 July 2020 (UTC)[reply]

Suppress display on file pages[edit]

I've just removed an instance of this template from File:Mecodema dux (2).jpg. Can we wrap the template code in the necessary markup to stop it displaying in the File: namespace? Should we do so for other namespaces? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 21:25, 28 October 2019 (UTC)[reply]

Maybe better than just suppressing a maintenance category and a reference to the new lua-enabled depicts templates your building @Mike Peel? Sadads (talk) 21:51, 28 October 2019 (UTC)[reply]
  • Why? It's a basic principle in software engineering that you don't ever rule out some potential feature just because you can't think of a use for it. Before excluding this so bluntly, we'd have to show that either there could never be (not merely isn't currently) a valid use for it, or that such a use would be positively harmful.
Secondly, we shouldn't ever exclude features from a general aspect because of one use of it. Maybe it's not appropriate to use the Infobox on this image (Why?), certainly it doesn't work as it has a duff ID. But that's no reason to remove it from all possible File: pages. Andy Dingley (talk) 23:37, 28 October 2019 (UTC)[reply]

The vertical format of the infobox definitely doesn't work well on file pages. However, I'm currently working on {{Structured Data}}, which is the equivalent to this template for files (via structured data on commons), and I haven't ruled out reusing this template in that one yet (with formatting tweaks). So can we hold off on this for a short time until we figure out what the optimal solution for file pages is, please? (And please leave feedback on the new template if you can think of ways to improve it!) Thanks. Mike Peel (talk) 20:55, 29 October 2019 (UTC)[reply]

@Mike Peel: Any news? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 14:17, 11 February 2020 (UTC)[reply]
@Mike Peel: Nudge... Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 10:57, 28 June 2020 (UTC)[reply]

disable use in File namespace[edit]

Can we disable use of this template in File namespace? for some reason I see more of those lately. Sometimes it is added directly an sometimes by intentionally or accidentally transcluding category page. --Jarekt (talk) 03:21, 22 June 2020 (UTC)[reply]

See #Suppress display on file pages, above. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 15:33, 22 June 2020 (UTC)[reply]

@Pigsonthewing, Jarekt, Sadads, and Andy Dingley: It's clear that it's not appropriate to use this infobox on file pages. Last year, I was hoping that it might be possible to modify it so it would work well there by including different code in that namespace, but now I think it's better if that is a completely separate template (like {{Structured Data}}), particularly given the performance issues that have been raised.

My preference would still be to keep the status quo, though. It's easy to spot uses of the infobox in file namespace by looking at Category:Wikidata infobox maintenance, and there aren't too many of them, so they can be manually resolved. The alternative is that we add a namespace check to the template that disables the display of the infobox, and adds it to a maintenance category. However, that check would have to be done on every use of the template, which adds to the performance issue. Thoughts? Thanks. Mike Peel (talk) 18:02, 1 July 2020 (UTC)[reply]

My preference would be to just disable it in other namespaces by wrapping the whole template in a IF statement checking the namespace. We often have such statements when adding "problem" categories to some pages but not the others. I do not know why but I see lately much more categories added manually with {{}} brackets instead of [[]] brackets which transclude the category page with {{Wikidata Infobox}}, which then has weird interaction with SDC and creates errors. --Jarekt (talk) 18:12, 1 July 2020 (UTC)[reply]
@Jarekt: Is there another way of identifying the incorrect brackets issue apart from infobox mis-transcludes? Thanks. Mike Peel (talk) 18:34, 1 July 2020 (UTC)[reply]
One can create SQL query to find transcluded category pages. The problem is that at some point we had some crazy scheme of adding Artwork template to a category and than transclude the category. It was always a bad idea and we still have plenty of it around. We would have to exclude those from the query. --Jarekt (talk) 21:07, 1 July 2020 (UTC)[reply]
Do you have any examples of File: pages with these infoboxes? There don't seem to be any at present.
I find it slightly hard to imagine when this would be useful (the canonical image of a clear topic for which there's a WD entry?), but still can't see a reason to break the infobox from ever being used like this. If a particular use is inappropriate, then a better (and simpler) solution would be to simply remove it from that page. Andy Dingley (talk) 20:24, 1 July 2020 (UTC)[reply]
Andy I am spending a lot of my time simply removing it from pages, which I would rather spend doing other things. To me it seems like a sanity check: the template was not designed to be used that way so lets prevent it from being used that way. --Jarekt (talk) 20:59, 1 July 2020 (UTC)[reply]
  • OK then, OPPOSE
If you can't give a reason for, or even an example of, how awful such use of this template is, then don't expect me to support a blanket ban on anything. Andy Dingley (talk) 23:21, 1 July 2020 (UTC)[reply]
"can't see a reason to break the infobox from ever being used like this" Nothing would be "broken", and especially not for "ever"; this being a wiki, any edit can be reverted or changed. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 22:20, 1 July 2020 (UTC)[reply]
is there some similar template for the use in the file-name-space. If yes this can replace WIKIDAT INFO template. Altough I do not understand that it should not used in the file-namespace.--Hfst (talk) 15:35, 15 October 2020 (UTC)[reply]


I added a located in/on physical feature (P706) to Vestmannabjørgini (Q1425782) and now the infobox in Category:Vestmannabjørgini looks rather weird. The island Streymoy is subdivided in 4 administrative areas. What do? --Hjart (talk) 16:02, 23 June 2020 (UTC)[reply]

Width of the infobox[edit]

I've just noticed that @Verdy p: changed the infobox style yesterday to make the infobox wider (250px rather than 210px) and to remove "table-layout: fixed;". Has this caused any problems? I was trying to keep the width of the infobox as narrow as possible, but if this new width is OK then I'll make the images and map a bit larger in the next version. Thanks. Mike Peel (talk) 21:31, 24 June 2020 (UTC)[reply]

@Mike Peel: Yes it caused problems: the fixed layout notably is wrong: it cannot be infered correctly from the first row (which is taking 100% of the width: it is frequently an image spanning the two columns; so the fixed table layout is then 50%/50% independantly of everything that is below), so all the headings below take 50% of the total width, leaving a very narrow column for the values (and with 210px, values could be only 105px wide: too many linewraps or truncated values, or sometimes even a larger infobox).
And 210px is too narrow for German. In wikimedia, floatting images are 250px wide, we can use that default so they line-up correctly with infoboxes.
250px does not cause problems given it is the default for floatting images, and they align perfectly vertically. Given that "fixed" layout does not work and has bad effects, it's best to remove it, and allow columns to be flexible: in many cases the heading columns will be adaptative: not be 50% but lower, giving ampler space for the valuesin the second columns.
This is also needed for other languages than German, like Thai (that don't use any space between words, and have weak unexplicit linewraps opportunities in most browsers, as they depend on complex dictionnary lookups); this is not a problem for Chinese or Japanese where linewraps are allowed everywhere between each sinogram; in Korean, there are whitespace separations between words written in Hangul syllables and they use standard Latin punctuation. Basically this is needed for languages that use word-agglutination (German, Finnish) when Wikidata frequently does not include any soft-hyphen in the labels to allow break opportunities. And in a 105px column, this does not fit so well. Now it can be 125px or a bit larger, taking some space from the underused heading columns which is now flexible). The result is much more readable, and we no longer have very tall columns of values after each heading, and a very tall infobox: we need less linewraps to correctly render the values, adn the infobox still remains constrained in the 250px flexible width (most of the time): this was almost never the case with 210px only and with fixed layout.
You should know that the "fixed" table lyout requires that the table has ALL its columns sized in its 1st row (this is never the case for infoboxes, as the 1st row contains the object's label/description spanning all columns.
And on Mediawiki we still cannot use the standard "column" HTML element to size them with styles; as well there's still no support for standard columns-groups with "colgroup" or row groups with "thead", "tbody" and "tfoot"... I think this is a stupid limitation of Mediawiki which consider them as "unsafe" HTML elements, which is obviously wrong; May be we'll have in some future addition HTML elements from HTML5; but the HTML4-inherited "column", "colgroup", "thead", "tbody" and "tfoot" elements, preserved in HTML5 and still recommended, they should have been supported since very long, not causing any security problem if they were treated like "div" or "li" block elements for row groups, or like "span" for "column" and column groups).
Note that I have NOT changed the image sizes in the infobox, but thery are properly centered, and increasing their size could make the infoboxes unnecessarily taller. verdy_p (talk) 21:37, 24 June 2020 (UTC)[reply]
It looks very awkward with image and map size not matching infobox size. I don't particularly care what size, but it should match. Pi.1415926535 (talk) 00:09, 25 June 2020 (UTC)[reply]
I agree. It doesn't look nice now. Strakhov (talk) 14:20, 25 June 2020 (UTC)[reply]
I'm glad to see the width has been increased. It would be good to increase the image width, and cap the heights. Perhaps 250x300, or even 250x250? Huntster (t @ c) 23:03, 26 June 2020 (UTC)[reply]
@Verdy p, Pi.1415926535, Strakhov, and Huntster: Can you try {{Wikidata Infobox/sandbox}} please? This incorporates the CSS changes and also widens the image and map widths. Thanks. Mike Peel (talk) 18:32, 1 July 2020 (UTC)[reply]
We can enlarge maps, but I don't think we need to enlarge images at top, which are properly centered and displayed in an area which has enough margins. Extending the image width at top could make the infobox taller... For OSM maps, there's no problem: we can set it a bit larger without increasing their height.
The sandbox version however still does not change these image/map widths. Let's first start with the map... verdy_p (talk) 18:37, 1 July 2020 (UTC)[reply]
Mike Peel, at first glance and checking miscellaneous location categories, I see nothing abnormal for the two properties in question. What did you specify for maximum height? However, property P2716 (collage image) should probably be added to the list of new sizes, since a lot of cities use that field rather than "image", and I can imagine a limited number of other such properties at https://www.wikidata.org/wiki/Special:WhatLinksHere/Q26940804 might also qualify for treatment. Huntster (t @ c) 05:39, 2 July 2020 (UTC)[reply]

Infoboxes on disambiguation pages[edit]

I complained at Mike Peel’s talk page about adding the infobox on disambiguation categories, and he directed me here to have more opinions on the topic. For those who don’t want to read through the discussion over there, I summarize the opinions:

  • In Mike’s view the infobox is useful on disambiguation categories, as it may provide disambiguation links that aren’t listed elsewhere, and its categorization feature helps finding disambiguation categories connected with non-disambiguation items or vice versa.
  • In my view the infobox is completely unnecessary on disambiguation categories, at least on clear ones (i.e. ones that are marked as disambiguation both on Commons and Wikidata). I think the infobox is not a natural place to search disambiguation links at; they should be rather added to the main list. In clear cases, the maintenance categories don’t help either, as there’s nothing to fix. In my opinion adding these infoboxes is a plain waste of server resources (albeit not a huge one thanks to the low number of disambiguation categories).

Thoughts? —Tacsipacsi (talk) 23:29, 1 July 2020 (UTC)[reply]

I share you view that the infobox for that type of categories is completely unnecessary and without any added value.Jklamo (talk) 07:31, 2 July 2020 (UTC)[reply]
I'm more with Mike Peel here. I find it useful for users to see that there is a corresponding Wikidata item, linking it to articles in various languages. I very often look at corresponding articles in various languages to better understand differences and commonalities of the various meanings of a term in those languages. And - even if you see little value for yourself, does it do any harm to have those boxes? -- H005 14:04, 10 August 2020 (UTC)[reply]
The interlanguage links appear in the sidebar even without the infobox. (The infobox provides interlanguage links only when the category page is connected to a category item (i.e. the item has instance of (P31): Wikimedia category (Q4167836)), which I can hardly imagine to happen in case of disambiguation categories.) I don’t find it harmful, though, apart from seeing it as a plain waste of resources (both bot/server and human resources—the unnecessary page history/watchlist entries need to be scanned and understood.) —Tacsipacsi (talk) 20:17, 10 August 2020 (UTC)[reply]

IMO for ships[edit]

Can we bring {{IMO}} and {{IMOcat}} into this template, using IMO ship number (P458)? The latter is verbose, but needlessly so IMO. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 23:57, 5 August 2020 (UTC)[reply]

Why would IMOcat help? It's just a pointer to an IMO category, which can be done with a simple link. Carl Lindberg (talk) 03:44, 6 August 2020 (UTC)[reply]
@Pigsonthewing and Clindberg: I'm not sure how best to integrate this. If you look at Category:Hanseatic (ship, 1930), the link to the IMO category is under 'Category combines topics', although perhaps it's not too obvious. But does it really need to be made very obvious using IMOcat? Also, the P458 link (and other authority control) isn't currently shown in these 'category combines' categories for performance reasons. Thanks. Mike Peel (talk) 18:42, 7 August 2020 (UTC)[reply]
I don't see how integrating these would help either -- I do see the links to the IMO cat, and that seems enough to me. Well it might be nice to have the IMO number displayed -- it currently uses the Wikidata title for its IMO entry, which is usually an arbitrary one of the ship names over its history, and may be a little confusing given there is likely another Commons category with that other name but that's not where the link goes. IMOcat is fine standalone, I think. And I would definitely want to fix the performance before expanding the template's scope :-) Carl Lindberg (talk) 05:01, 8 August 2020 (UTC)[reply]

Non-terrestrial coordinates[edit]

Coordinates on Category:Gale Crater, which is about a feature on Mars, are not displaying correctly; compare with those on Gale (Q622221). Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 18:36, 27 August 2020 (UTC)[reply]

@RexxS: I've been trying to find the cause of this, see my recent edits in Template:Wikidata Infobox/core/sandbox, but it's weird. The problem is in the code {{#invoke:Coordinates | GeoHack_link | lat={{#invoke:WikidataIB | getPreferredValue | P625 | qid={{{qid}}} | fwd={{{fwd|ALL}}} | maxvals=1 | osd=no | noicon=yes | format=decimal | show=lat}} | lon={{#invoke:WikidataIB | getPreferredValue | P625 | qid={{{qid}}} | fwd={{{fwd|ALL}}} | maxvals=1 | osd=no | noicon=yes | format=decimal | show=long}}|globe={{#invoke:WikidataIB|getLabel|{{#invoke:WikidataIB |getGlobe|{{{qid}}}}}}}}}. However, if you substitute the qid for Q622221, then it works fine: 5° 22′ 12″ S, 137° 48′ 36″ E. The problem seems to be with the WikidataIB calls, which aren't returning values that are passed to Coordinates. Can you see what's going on? The only thing I can think of it some sort of whitespace bug? Thanks. Mike Peel (talk) 17:01, 3 September 2020 (UTC)[reply]
Before I do any more detective work, can you confirm that replacing each {{{qid}}} with {{{qid|}}} does not fix the problem?
These are the results of the calls:
  • >{{#invoke:WikidataIB | getPreferredValue | P625 | qid={{{qid|Q622221}}} | fwd={{{fwd|ALL}}} | maxvals=1 | osd=no | noicon=yes | format=decimal | show=lat}}< → >-5.37<
  • >{{#invoke:WikidataIB | getPreferredValue | P625 | qid={{{qid|Q622221}}} | fwd={{{fwd|ALL}}} | maxvals=1 | osd=no | noicon=yes | format=decimal | show=long}}< → >137.81<
  • >{{#invoke:WikidataIB|getLabel|{{#invoke:WikidataIB |getGlobe|{{{qid|Q622221}}}}}}}< → >Mars<
All of those look right to me. But the code {{{qid}}} will be set to {{{qid}}} literally if the parameter is not supplied, whereas it needs to be set to blank for WikidataIB to use the qid associated with the page. --RexxS (talk) 17:22, 3 September 2020 (UTC)[reply]
Forgot to ping Mike Peel. --RexxS (talk) 17:23, 3 September 2020 (UTC)[reply]
@RexxS: Yes, I removed the | in {{{qid|}}} as part of my debugging attempt, it didn't make a difference. The starting code was {{#invoke:Coordinates | GeoHack_link | lat={{#invoke:WikidataIB | getPreferredValue | P625 | qid={{{qid|}}} | fwd={{{fwd|ALL}}} | maxvals=1 | osd=no | noicon=yes | format=decimal | show=lat}} | lon={{#invoke:WikidataIB | getPreferredValue | P625 | qid={{{qid|}}} | fwd={{{fwd|ALL}}} | maxvals=1 | osd=no | noicon=yes | format=decimal | show=long}}|globe={{#invoke:WikidataIB|getLabel|{{#invoke:WikidataIB |getGlobe|{{{qid|}}}}}}}}}. Thanks. Mike Peel (talk) 17:28, 3 September 2020 (UTC)[reply]

Coordinates for other planets[edit]

@ArthurPSmith: pointed out at d:Wikidata:Property proposal/planetary coordinates that the coordinates for Category:Olympus Mons don't display properly - this need investigation. Thanks. Mike Peel (talk) 20:16, 16 October 2020 (UTC)[reply]

@ArthurPSmith and Mike Peel: Note the above. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 21:57, 30 October 2020 (UTC)[reply]

Incorrect display in the infobox[edit]

Wenn die Infobox auf Category:Dutch-language surnames eingeblendet wird, zeigt sie statt den Inhalt von Category:Dutch-language surnames (Q7886503), den Inhalt von family name in the Netherlands (Q22813575) an. Wird der Parameter category's main topic (P301) aus Category:Dutch-language surnames (Q7886503) entfernt, zeigt sie den korrekten Inhalt von Category:Dutch-language surnames (Q7886503) in der Infobox an. Am Beispiel von Category:English-language surnames kann man sehen, wie es ohne den Parameter category's main topic (P301) auf Category:English-language surnames (Q7598401) korrekt in der Infobox angezeigt wird.

(When the infobox on Category:Dutch-language surnames is displayed, it shows the content of family name in the Netherlands (Q22813575) instead of the content of Category:Dutch-language surnames (Q7886503). If the parameter category's main topic (P301) is removed from Category:Dutch-language surnames (Q7886503), it shows the correct content of Category:Dutch-language surnames (Q7886503) in the infobox. Using the example of Category:English-language surnames, you can see how it is correctly displayed in the infobox without the parameter category's main topic (P301) to Category:English-language surnames (Q7598401).)

--HarryNº2 (talk) 14:22, 8 September 2020 (UTC)[reply]

@HarryNº2: Yes, this is the normal operation of the template, it looks OK to me? If the category's main topic (P301) value is incorrect, would category combines topics (P971) be better? Thanks. Mike Peel (talk) 19:09, 29 September 2020 (UTC)[reply]
@Mike Peel: Hi Mike, please have a look at the content of the German Infobox and the content of the Dutch Infobox. Both show different content. The Dutch infobox shows the wrong result (family name in the Netherlands). Only when I delete the parameter category's main topic (P301) on Wikidata (as in the example of the German Infobox) will the correct content be displayed (Category:German-language surnames). You are also welcome to have a look at the other info boxes (e.g. Danish, English, French etc.) for comparison, which always show Category:Xxxxx-language surnames, but only if parameter P301 is not set. I hope you understand what i mean. --HarryNº2 (talk) 18:29, 5 December 2020 (UTC)[reply]

Death date before[edit]

The death date on Category:Dnyaneshwar Atmaram Turkhud is showing as "death: Unknown (before 1944)", whereas it is actually recorded on Wikidata as "unknown value; latest date: January 1944". Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 12:46, 14 September 2020 (UTC)[reply]

More recently, on Category:Kyle Heller, his DoB of "1980s; earliest date: 1980; latest date: 1981" in Wikidata is shown on Common as "1980s (before 1981, after 1980)". @Mike Peel: . Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 17:50, 6 October 2020 (UTC)[reply]

Switch around "before" and "after" for inception dates[edit]

Some Wikidata items, like Mictlantecuhtli (Q109928629) have an inception date with 'earliest date' and 'latest date' qualifiers. Now these are rendered in the reversed order ("before 1502, after 1430"). I think it would make more sense to reverse that order, so: "after 1430, before 1502". See Category:Mictlantecuhtli, Templo Mayor for an example. Huskyoog.jpg Husky (talk to me) 22:55, 7 December 2021 (UTC)[reply]

See also Death date before, above. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 13:47, 8 December 2021 (UTC)[reply]

Identifiers for monuments in France[edit]


I have three requests (by decreasing order of importance) about identifiers for monuments in France:

Thanks in advance.

Cheers, VIGNERON (talk) 10:33, 17 September 2020 (UTC)[reply]

@VIGNERON: The first one is straightforward, it's in {{Wikidata Infobox/sandbox}} for testing. The second is more tricky, as the current {{Wikidata ID}} code only supports one value per ID and it would need a complete rewrite to support multiple values. The third is also tricky, as the code fetches all information about the property from Wikidata, is there a property that could be added to the property pages to link to icons? Thanks. Mike Peel (talk) 18:57, 29 September 2020 (UTC)[reply]
Thanks @Mike Peel: ,
I've tested (in preview) the first, it works perfectly.
For the second, that's a bummer. Would this rewrite be possible in a not-too-far future? (let's say less than a year, for WLM 2021?)
I've been bold and tested to add d:P:P2910 on d:P:P481 and d:P:P380 (it was already done on d:P:P496 and d:P:P1793). I'll leave a message on the Project Chat to see if there is any objections or comments.
Cheers, VIGNERON (talk) 19:28, 29 September 2020 (UTC)[reply]
@Mike Peel: FYI, one week later, 2 people said my idea of adding icons was good (see d:Wikidata:Project_chat#Icons_for_properties). And for the first point, I did some more check, I've seen no problem; could this be applied to the real-not-sandbox template? Cheers, VIGNERON (talk) 11:29, 6 October 2020 (UTC)[reply]

Display of the language under the audio files[edit]

It would be helpful if the language would be displayed under the audio file, especially if there are several audio files in different languages. For an example see Category:Moritz (given name). --HarryNº2 (talk) 12:27, 8 October 2020 (UTC)[reply]

Is it a problem to mention the language under the audio file in the infobox? --HarryNº2 (talk) 19:10, 29 October 2020 (UTC)[reply]
@HarryNº2: You should only see one audio file, selected based on your language settings - e.g., I don't see any audio file there as I'm browsing in English, and there are only audio files in German (Q188) and Austrian German (Q306626). Which language do you have set? @RexxS: possibly this is a bug in getValueByLang. Thanks. Mike Peel (talk) 16:26, 5 December 2020 (UTC)[reply]
@Mike Peel: The language setting is mainly set to German. Nevertheless, it would be helpful if the language of the audio file were displayed, especially in cases where three audio files such as German, Austrian German and Swiss German are available on Wikidata. --HarryNº2 (talk) 17:09, 5 December 2020 (UTC)[reply]
@HarryNº2: Just to check, you only see one audio file here, correct? It should be the German version if it's working right, if you're browsing in German. If we added the language of the audio file, it should only display the language that you're browsing in, which I don't think it too useful. Thanks. Mike Peel (talk) 17:22, 5 December 2020 (UTC)[reply]
@Mike Peel: If I have set German, only the German audio file is also displayed. However, you cannot set Austrian German or Swiss German at all. The same is the case with English, British English, and Canadian English. --HarryNº2 (talk) 17:35, 5 December 2020 (UTC)[reply]
@HarryNº2: Are you sure? I can see those options in the language selector (top of the screen, to the left of your username). Thanks. Mike Peel (talk) 18:00, 5 December 2020 (UTC)[reply]
(Edit conflict) @Mike Peel and HarryNº2: I can see the point of the question. If I browse Category:Moritz (given name) with my language set to Deutsch, I get a male voice pronouncing Moritz (File:De-Moritz.ogg). If I browse set to Österreichisches Deutsch, I get a female voice (File:De-at Moritz.ogg) with a noticeably different accent (Berlin vs Vienna). That's working as intended. If I browse set to Schweizer Hochdeutsch or Alemannisch, I don't get an audio file. That's because I deliberately didn't implement language fallback in getValueByLang as it was specifically designed to only return the property value (e.g. filename) that has a direct match with the given language. At present, the language of the file you see is always the language you have set, so there should be no need for repeating that under the audio file.
Nevertheless, if you want to implement language fallback, then we're going to need another function to achieve that (another editor re-wrote getValueByLang and getValueByQual to use common code, and that prevents a simple implementation of language fallback). If we go down that route, then the German variants without an audio file would see the German version, and it would make sense to add the language code for the file underneath, which would require more coding to perhaps add a hidden comment containing the language code used to the returned filename, which could then be stripped off in the template code and used separately. That seems like a fair bit of work to achieve language fallback and I have to ask how much of a priority it is? --RexxS (talk) 18:04, 5 December 2020 (UTC)[reply]


Where the category is about places, or things in places, can we find a sensible way to embed {{Geogroup}} at the foot of the infobox? Or can we have a manual switch, such as {{Wikidata Infobox|geo=y}}, which bots could then set for relevant sets of catgories? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 22:28, 14 October 2020 (UTC)[reply]

@Pigsonthewing: Rather than including the template, the links are included under the map and coordinates within the infobox. The bing link in geogroup doesn't work (I've just been testing adding it to the infobox, but no luck). OSM is there in the current version, but might be upgraded per the discussion just above, testing code is in the sandbox. Would the KML link be useful or add clutter? Thanks. Mike Peel (talk) 15:54, 5 December 2020 (UTC)[reply]
@Mike Peel: I think we're at cross purposes; please take a look at Category:Public art in Birmingham. The map links in {{Geogroup}} do not appear in the infobox, which has no map and no coordinates. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 17:36, 5 December 2020 (UTC)[reply]
@Pigsonthewing: OK, I get it. The OSM link was only being displayed if there was a coordinate. I've changed it so that the link is now displayed at the bottom, regardless of whether there is a coordinate, so that should work in your case. Could you try {{Wikidata Infobox/sandbox}} please? Thanks. Mike Peel (talk) 17:56, 5 December 2020 (UTC)[reply]
Yes, that works, but it needs more explanation, since the link is not to "OpenStreetMap" (Geogroup uses "Map of all coordinates on OSM", but could be shortened to, say, "coordinates (OSM)"). And we do need a KML download option. If the Bing link is not working, then of course drop it, but please bear in mind it might be fixed, and other services my become available. Also, it adds the OSM link to pages like Category:SuperTinyIcons where there is no Geographic metadata, and never will be. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 20:15, 5 December 2020 (UTC)[reply]
@Pigsonthewing: The label has to be multilingual. Using the label of OpenStreetMap (Q936) does that automatically, anything beyond that becomes a lot more complicated. I can add the KML link easily, but I need to be able to point to a reason why it's needed if someone objects to its inclusion. Bing can similarly be linked to easily if it starts working. Thanks. Mike Peel (talk) 20:52, 5 December 2020 (UTC)[reply]
BTW, @Hjart: we talked about this a bit via a mini edit war / discussion on my talk page back at the start of November, can you check the sandbox version and see what you think? Also, if you have any comments about the Bing and KML links, please share them. Thanks. Mike Peel (talk) 18:19, 5 December 2020 (UTC)[reply]


Was the use of P373 deprecated for this template? Apparently it no longer fetches the Commons category from this property, only from site link. I don't understand why we have to add a category to both P373 and site link, it seems redundant. —capmo (talk) 15:00, 25 December 2020 (UTC)[reply]

One reason is that the multiple wikidata items may point to same commonscat category using P373. (ie. technically sitelinks are One-to-one relations and P373 values are Many-to-many) --Zache (talk) 16:48, 25 December 2020 (UTC)[reply]
Also commons sitelink may also not point to category but to gallery page in example. --Zache (talk) 17:05, 25 December 2020 (UTC)[reply]
This needs a change in WikidataIB, @RexxS: could you look into it please? I think it just needs line 660 of Module:WikidataIB ("mw.wikibase.getBestStatements(id, "P373")[1]") changing to use getCommonsLink, and ideally any mention of P373 should just be removed now. Thanks. Mike Peel (talk) 19:40, 25 December 2020 (UTC)[reply]
Why it needs to change? I think that based on usecases the wikidata<->commonscat will be always 1:M relations and it will be impossible to normalize them to 1:1 ones without problems. --Zache (talk) 20:21, 25 December 2020 (UTC)[reply]
@Zache: I've been working on synchronizing Commons and Wikidata for several years now, and cases where there aren't 1:1 links are really rare (many of the 1:many links aren't useful, or can be solved by improving Commons categorisation and/or the Wikidata items). I'm hoping that P373 will be deprecated soon, and deleted sometime in 2021, see d:Wikidata:Properties_for_deletion#Property:P373. Thanks. Mike Peel (talk) 20:46, 25 December 2020 (UTC)[reply]
I've changed the line in Module:WikidataIB/sandbox to use _getCommonsLink, but I don't think that will give the results you want, because it will always create a category now. I honestly don't know what algorithm you want to use for the link, so I can't be certain what to implement. WADR, I usually find it better for someone to tell me the results they want and let me sort out what is the best way to implement it. Merry Xmas --RexxS (talk) 20:30, 25 December 2020 (UTC)[reply]
@RexxS: Thanks! I'll set up the infobox sandbox to check things. Ideally everything at e.g., Category:South Pole Telescope would work the same, but without using P373. It shouldn't add categories, it should just link to them, but using the sitelinks (following category's main topic (P301) etc.) rather than P373. Thanks. Mike Peel (talk) 20:46, 25 December 2020 (UTC)[reply]
@RexxS: "Lua error in Module:WikidataIB/sandbox at line 669: attempt to call global '_getCommonsLink' (a nil value).". Thanks. Mike Peel (talk) 20:53, 25 December 2020 (UTC)[reply]
@Mike Peel: it seems I called the function _getCommonslink, so that's fixed now. I still don't see how it's ever going to return a gallery. --RexxS (talk) 20:58, 25 December 2020 (UTC)[reply]
@RexxS: I tried to prefix the links with ":", but it doesn't look like it worked, as it now returns 'Category:Category:Blah'. {{Wikidata Infobox/sandbox}} now uses Module:WikidataIB/sandbox, see examples at Special:WhatLinksHere/Template:Wikidata_Infobox/core/sandbox. Thanks. Mike Peel (talk) 21:05, 25 December 2020 (UTC)[reply]
@Mike Peel: That's more or less what I expected. How about you tell me what output you want from the different cases and I'll try to sort out the logic? --RexxS (talk) 21:09, 25 December 2020 (UTC)[reply]
I've made a guess at what you want and made some amendments. Does that fit the bill? --RexxS (talk) 21:14, 25 December 2020 (UTC)[reply]
@RexxS: That's a step forward. In these cases, the link should never add the category to a parent category, it should just display the link. E.g., at Category:Anubis, the new version tries to add it to categories, while the main version just shows the links. Thanks. Mike Peel (talk) 21:21, 25 December 2020 (UTC)[reply]
Sorry, Mike. That's just too opaque for me. I think we need a bunch of test cases like we did for CiteQ, so that I can try to make sense of what is required. I suggest that we pause changing the code until I can get a better idea of the algorithm needed. --RexxS (talk) 21:27, 25 December 2020 (UTC)[reply]
@RexxS: OK, lets come back to this another day. I thought it was a straight swap, we just stop using P373 to provide inline links to other categories, and use the sitelinks insead. But clearly we're not connecting somewhere here. Thanks. Mike Peel (talk) 21:33, 25 December 2020 (UTC)[reply]
Thanks for the explanations, Zache. That's fair enough. —capmo (talk) 17:20, 26 December 2020 (UTC)[reply]

@RexxS: following up on this with some test cases. National Institute for Astrophysics - this works OK, but if you try the sandbox then it includes the page in the category rather than displaying the link. Same for radio telescope . However, Italy seems to work OK in both cases, which is good. Thanks. Mike Peel (talk) 18:03, 29 December 2020 (UTC)[reply]

Doctoral student[edit]

Can "Doctoral student" be made collapsable and collapse automatically if there are more than 3 students?

Someone on Wikidata is working on importing a lot of mathematics doctoral advisor/student information and it's making some infoboxes very unwieldy because most doctoral students don't have categories. See Category:H. Blaine Lawson as an example. --William Graham (talk) 04:57, 2 January 2021 (UTC)[reply]

I second this request. Infoboxes of any kind are not intended to display all possible information but to succinctly display select relevant info. --Animalparty (talk) 19:24, 10 January 2021 (UTC)[reply]

Collapsible-collapse vs Hide[edit]


There is an issue with how this template works: When it's loaded, it initially shows the message "Collapsible-collapse" (Collapse) at the top next to the title, and as the page is loaded, it is replaced with the message "Hide" Hide.

It may look correct in English, but actually it is wrong. "Hide" is intended for use in compound messages on Recent Changes, such as "Hide transclusions". In other languages, such as Hebrew, it is shown incorrectly.

Can this be fixed?

If you really want the word "Hide" and not "Collapse" to be shown, the easiest current solution that will work well across (hopefully) all languages is probably to use "Hidetoc" (hide). Some time in 2021, when Translatable modules (hopefully) become available, it will be easy to create a message just for this. (It may seem unintuitive, but reusing messages in different contexts is usually not great, and it's better to create new ones even if they are identical to existing messages.) --Amir E. Aharoni (talk) 13:10, 6 January 2021 (UTC)[reply]

Taxa categories and "Search depicted"[edit]

Hi, there is a link "Search depicted" in the infobox. When you are in a taxon category and that you click on this link, then only are shown the pictures which show strictly the depicted items, e.g.:
However a more accurate result woult comprises all the child taxa, e.g.:

#shows files that depict Hummingbirds 
SELECT ?file ?image
  SELECT ?item 
    SERVICE <https://query.wikidata.org/sparql>
        ?item wdt:P171/wdt:P171* wd:Q43624.
} AS %get_items
  INCLUDE %get_items
  ?file wdt:P180 ?item .
  ?file schema:contentUrl ?url .
  BIND(IRI(CONCAT("http://commons.wikimedia.org/wiki/Special:FilePath/", wikibase:decodeUri(SUBSTR(STR(?url),53)))) AS ?image)

Try it!

I think it is the likely the same thing for many other subjects than taxa, however the relationship parents/child taxa is always the same and known (parent taxon (P171)). Is there a chance that when we visit a taxon category we can have a link that lead such results? Christian Ferrer (talk) 12:44, 9 January 2021 (UTC)[reply]

Lua memory error[edit]

in the Infobox with Category:COVID-19 pandemic in Austria. And (as a consequence?) a lot of unplausible categories. @Mike Peel: best --Herzi Pinki (talk) 05:51, 22 January 2021 (UTC)[reply]

@Mike Peel: any idea? --Herzi Pinki (talk) 20:50, 31 January 2021 (UTC)[reply]
@Herzi Pinki: The problem is that COVID-19 pandemic in Austria (Q86847911) is 3,771,486 bytes, and the infobox can't handle an item that is that big. It's #4 on d:Special:LongPages! Perhaps @RexxS: might have ideas for optimising the code, but a better solution would be to move all of the COVID data into tabular data rather than storing it in the Wikidata item. Pinging @TiagoLubiana: as the bot operator that's added most of the data to that item. Thanks. Mike Peel (talk) 12:06, 4 February 2021 (UTC)[reply]
Thanks for analysis and for calling possible problem-solvers. In general, Covid sucks. As far as I suppose, it is due to category's main topic (P301) in Category:2020 coronavirus pandemic in Austria (Q88805825). Isn't it the wrong topic anyway? The pandemic has much more aspects than just a list of daily figures. --Herzi Pinki (talk) 12:20, 4 February 2021 (UTC)[reply]
It looks like it is the right topic. I thought of a work-around for now, I've pointed the infobox to COVID-19 pandemic (Q81068910) to use info from that instead. It's not ideal, and will need to be undone at some point in the future when the infobox is more efficiently coded, but it avoids the brokenness for now... Thanks. Mike Peel (talk) 12:24, 4 February 2021 (UTC)[reply]
Hi Mike I'm sporadically working on a 'lite' version of WikidataIB without all of the extra functionality that is demanded on enwiki, so that it can be used as a 'drop-in' replacement in performance critical applications to reduce both the number of entities called and the memory footprint. However, trying to optimise performance is often a balancing act between memory and speed, and it's time-consuming to test what effect any particular change might have. In the long run, we're going to have to re-write the Wikidata Infobox completely in Lua to eliminate the overheads of so many #invokes, but let's see what the Summer Outreachy brings, as that may be a big help. --RexxS (talk) 16:24, 4 February 2021 (UTC)[reply]

Disambigs in 'different from'[edit]

Infobox should ignore statements 'different from (P1889)' = '... (Q...)' if qualifier is set to 'criterion used (P1013)' = 'descriptive page and disambiguation page have to be in different items (Q24005632)'. Such statements in Wikidata Infobox are really useless and use too much space. Wostr (talk) 20:25, 22 January 2021 (UTC)[reply]

Agreed. With few exceptions (such as qualifying dates with "circa", or start & end dates of significant events), qualifiers should not be displayed. It's utterly trivial, unhelpful detritus that clutters what should be a succinct box with useful links and/or data. --Animalparty (talk) 20:39, 22 January 2021 (UTC)[reply]
As far as I understand, the question is not whether we want to display the qualifiers, but rather whether we want to display such statements at all. I agree we shouldn’t. —Tacsipacsi (talk) 21:18, 22 January 2021 (UTC)[reply]

Error displaying images with filenames beginning with an asterisk[edit]

If a filename begins with * (an asterisk), the template thinks it is wikitext for an unordered list. See Category:April Greiman for example. Senator2029 23:23, 4 February 2021 (UTC)[reply]

MediaWiki’s too smart here:
[[File:{{#invoke:WikidataIB|getValue|rank=best|P18|name=P18|qid=Q4782033|spf=|fwd={{#invoke:Wikidata Infobox|preloadWikidataProperties|Q4782033}}|osd=no|noicon=yes|maxvals=1}}|200px]]
results in a code so broken that I couldn’t even insert it here. :( (But you can put it on any page and preview it to see the result.) If a template/module output starts with a code that has special meaning at the beginning of a line (e.g. asterisk), it automatically inserts a newline before it, and as far as I know, there’s no way to circumvent this—apart from not putting special codes at the very beginning of the output, for example by putting the [[File: in the Lua module as well (or by generating the whole infobox with Lua, see #Lua memory error). —Tacsipacsi (talk) 23:57, 5 February 2021 (UTC)[reply]
  • Perhaps make a module just for this expression? --ghouston (talk) 02:31, 6 February 2021 (UTC)[reply]

first family name in Portuguese name[edit]

Hi, guys! ㋡
There is a new property for surnames, but it does not add surname categories yet because it is not included in this template. I will be grateful if any of you can add it.
first family name in Portuguese name (P9139) Minerva97 (talk) 13:08, 20 February 2021 (UTC)[reply]

Bad handling of only deprecated official website[edit]

I've found a bug where [ official website] appears in the output if the only value for official website (P856) is deprecated. An example can be currently seen on Template:Wikidata Infobox/sandbox (archive), which I've linked to Wikidata Sandbox (Q4115189) (archive) for now. Perhaps this also affects other properties, but this one in particular generates odd wikitext. --Pokechu22 (talk) 19:17, 26 March 2021 (UTC)[reply]

Anything with an end date qualifier should probably not be displayed. --- Jura1 (talk) 08:55, 7 April 2021 (UTC)[reply]
It looks like the current behavior ignores end date (if it's deprecated, the broken output occurs regardless of whether end date is present or not, and if it's at normal rank, it's displayed with correct formatting even if end date is present). --Pokechu22 (talk) 19:10, 7 April 2021 (UTC)[reply]
In Wikidata, it's frequently an error if deprecation is used (instead of the addition of an end date). --- Jura1 (talk) 11:53, 14 April 2021 (UTC)[reply]


Category:Scribner's Magazine/Volume 47 is one of several volumes of journal which were published 2/yr for many years.

The infobox is displaying only the year, which looks kind of funny. In the example, it is 1910 (1910-1910) where a display of 1910 (July-Dec.) is more accurate and interesting.

Thanks for your attention!--RaboKarbakian (talk) 13:00, 6 April 2021 (UTC)[reply]

qualifier with datatype "wikibase-form"[edit]

Minerva97 noticed that qualifiers with that datatype aren't supported.

e.g. Category:Sérgio Sette Câmara showing "(unknown data type: wikibase-form)"
trying to display generational suffix (P8017) from Q18195633#P1477.

--- Jura1 (talk) 09:00, 7 April 2021 (UTC)[reply]

  • It's a lexeme, that's something new for a property value. --ghouston (talk) 05:02, 8 April 2021 (UTC)[reply]

follows and followed by as qualifiers[edit]

I have been working with serialized fiction, (novels preesented over several issues and even volumes of a magazine) each new "has part" (P567) would get its own follows (P155) and followed by (P156). Many of our greatest and most well known novels began life this way, and many other lesser known novels....

Infobox displays these P155, 156! This was a happy surprise for me! Maybe they can be migrated to the usual location in the box?

Display example at Category:Sleepy Hollow (1839, Irving), Category:Vincent Eden (1839, Deacon) and now that I look at it, maybe the qualifiers just need to be labeled or not shown at all.

If (when is more accurate) the journal is available at any wikisource, it would be also nice if followed by and follows could show that link if the category/gallery is not here.

Even without these improvements/differences, Infobox is sure beautiful.--RaboKarbakian (talk) 13:27, 27 April 2021 (UTC)[reply]

Strange errors and categories at Category:COVID-19 pandemic in Colombia[edit]

Category:COVID-19 pandemic in Colombia has a bunch of “not enough memory” Lua errors, and also a large list of seemingly arbitrary categories, from “Common years starting on Sunday” to “LGBT people by name”. Does anyone know what’s going on? Lucas Werkmeister (talk) 16:28, 12 June 2021 (UTC)[reply]

@Lucas Werkmeister: The categories are an artefact of the error messages messing up the template expansion (error messages are non-empty and therefore evaluate as truthy in the {{#if:}} parser function). As for the out of memory error itself, a likely large contributor to that would seem to be that the item that Category:COVID-19 pandemic in Colombia ultimately backs on to is massive, meaning that loading it in its entirety using mw.wikibase.getEntity() (or mw.wikibase.getEntityObject()) in Lua modules several times would cause the Lua VM to run out of memory. This function is used during infobox generation, such as in preloadWikidataProperties in Module:Wikidata Infobox (called from Template:Wikidata Infobox) and getAllLabels in Module:WikidataIB (called from Template:Wikidata Infobox/core). GreenComputer (talk) 05:04, 13 June 2021 (UTC)[reply]
@GreenComputer: Can you solve this problem? @Mike Peel: ? It's a pretty awful problem. --Animalparty (talk) 16:02, 15 June 2021 (UTC) Update: I just removed the template. Modern times call for simple solutions. --Animalparty (talk) 16:05, 15 June 2021 (UTC)[reply]

Add "Births in" category?[edit]

I did not find a similar existing question. Is it possible to add "Births in" category automatically based on place of birth (P19) property. Entering the property, the dedicated Commons category can be retrieved using category for people born here (P1464) then Commons category (P373) or declared here as Commons site. I don't know if the path is too complicated to be integrated in this template.
Jgui (talk) 14:50, 1 July 2021 (UTC)[reply]

@Jgui: If I recall correctly, @Harmonia Amanda: was auto-adding categories like this at one point, not sure if that's still happening. We talked about how to implement it automatically via the infobox, but it wasn't clear - since the granularity on Wikidata may be higher than the existing category structure here. It sounds like a good thing to implement, I'm just not sure how it would work in practice. Thanks. Mike Peel (talk) 18:43, 20 August 2021 (UTC)[reply]
I've not done this for a while, but it may be time to do it again if a backlog built up. There are too many granularity problems between Commons and Wikidata right now for it to do it automatically I think, not even speaking of the disambiguation problems (Wikidata has a lot of items sharing labels, but Commons can't do that for categories, and setting up a consistent disambiguation system that could be automated… would be a lot of work. I basically worked from Commons existing categories, run the corresponding SPARQL query for people born there, and then added the category if it was missing using QuickCategories. It should not be hard to replicate. --Harmonia Amanda (talk) 03:42, 30 August 2021 (UTC)[reply]

Time problem[edit]

Please see the infobox at Paleozoic, where the ages are given in millennia instead of millions of years, therefore a thousand-fold too young. The WD page whence the figures purport to come has millions of years, so I can only guess some sort of wrong conversion or translation is occurring when the infobox is generated. Please fix.—Odysseus1479 (talk) 22:45, 6 October 2021 (UTC)[reply]

The infobox at Cenozoic is also wrong; at Mesozoic the correct starting epoch is shown (albeit weirdly, in millennia) but the ending is wrong like the others mentioned.—Odysseus1479 (talk) 08:18, 11 October 2021 (UTC)[reply]

Zoom level, area[edit]

I think I read somewhere the zoom level used in the map was related to the area of the item (when this data has been included in the Wikidata item, of course). Nevertheless, the infobox does not behave differently whether units are km² (pretty good with these ones) or ha (not that good, it would be nice zooming in these maps). I mean, I understand taking into account every area unit could be too complex, but would it be possible selecting different zoom level at least when units are "hectares"? (a pretty common unit). Strakhov (talk) 17:59, 13 October 2021 (UTC)[reply]

Actually I don’t think supporting any area unit would be too complex, as long as these units have conversion to SI unit (P2370) statements, the conversion to square kilometers can be deduced from it. —Tacsipacsi (talk) 21:29, 13 October 2021 (UTC)[reply]
Yep, you are right. As long as these conversion factors (I didn't notice they existed) are included in Wikidata, I guess supporting every unit area should not be too complex. Strakhov (talk) 12:04, 23 October 2021 (UTC)[reply]

Cultivar template[edit]

Can we merge {{Cultivar}} (see for example Category:Chrysanthemum 'Dance') into this template? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 12:01, 12 November 2021 (UTC)[reply]

Template:Date navbox[edit]

{{Date navbox}} would be another merge candidate. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 18:17, 21 November 2021 (UTC)[reply]

located on street (P669) missing[edit]

Somehow the property seems to be missing from the infobox when street address (P6375) is present.

I don't think this is desirable as

  • many streets have categories and links to these could be displayed.
  • Also, the content between the two can differ. The text property should include the city and ZIP codes.


--- Jura1 (talk) 13:20, 30 December 2021 (UTC)[reply]

@Jura1: If I remember right, this was a deliberate coding choice - when we have street address (P6375), then that supersedes located on street (P669) and P969 (P969) (although that latter needs to be removed from the code now). What behaviour would you lik eto see - if we have values for both properties, what should we display? Thanks. Mike Peel (talk) 22:21, 30 December 2021 (UTC)[reply]
Personally, I'd display both. Maybe first P669, then the string of P6375. --- Jura1 (talk) 22:32, 30 December 2021 (UTC)[reply]
Interestingly, addresses are searchable on Commons, but not anymore on Wikidata (see d:Property_talk:P6375#value_is_not_indexed_for_string_search). --- Jura1 (talk) 20:44, 13 March 2022 (UTC)[reply]

Polish National Library ID[edit]

I would like to suggest a replacement of P1695 (NLP) with P7293 (PLWABN) in the authority control section of the template. I fully understand that there can be just one "Polish" ID in the template (and anyway, if there would be space for more, I would see P1207 as much better candidate to take the second spot). My proposal is in line with the policy of the National Library of Poland itself, which has now fully implemented PLWABN as their main authority ID. Powerek38 (talk) 18:05, 30 December 2021 (UTC)[reply]

Good idea! Let's change it! Gower (talk) 20:05, 30 December 2021 (UTC)[reply]

@Powerek38 and Gower: Is there a plan to deprecate NLP ID (old) (P1695) on Wikidata? There's no problem with including multiple IDs from Poland, so I've added both PLWABN ID (P7293) and NUKAT ID (P1207) to the sandbox at {{Wikidata Infobox/sandbox}} - please check that this is working as expected. Thanks. Mike Peel (talk) 22:29, 30 December 2021 (UTC)[reply]
@Mike Peel: It seems to be working perfectly fine with the sandbox, thank you! At the moment the National Library is still keeping its NLP database online, so the links on Wikidata (and here) are still working. That's why I don't think it should depracated just yet. It has been marked in WD descriptions in many languages that it's the old ID. As far as I know, they don't develop it any more, don't expand the database, don't train people in using it etc. On top of that, PLWABN has been uploaded to Mix'n'match, so if you don't want to create Polish biographical WD elements from scratch and you prefer to have Mix'n'Match preset some properties and labels for you, PLWABN is now probably the most comprehensive source. Powerek38 (talk) 22:45, 30 December 2021 (UTC)[reply]

additional media properties[edit]

The following were created only a while ago. Maybe some could be included as well:

Full list is at d:Special:ListProperties/commonsMedia. --- Jura1 (talk) 11:59, 31 December 2021 (UTC)[reply]

Memory/timeout issues cause pages to get added to Category:LGBT people by name??[edit]

I've discovered a bit of an odd issue. I was looking in Category:LGBT people by name and noticed a number of pages that clearly didn't belong there, such as Category:1906 in Connecticut, Category:Earthquakes of 2008, Category:COVID-19 pandemic in Argentina. It appears the rogue category was caused by {{Wikidata Infobox}} bugging out, but each time in slightly different ways:

  • On Category:1906 in Connecticut (and several other "YEAR in Connecticut" categories), the infobox template was accidentally transcluded twice, and the second instance of it had caused "The time allocated for running scripts has expired." to appear in big red letters about 50 times. Interestingly, "LGBT people by name" did not appear in the list of categories at the bottom of the page (even though the page appears in that category).
  • On Category:Earthquakes of 2008, the infobox was also used twice, although there are no visible error messages. "LGBT people by name" doesn't appear in the category list here either.
  • On Category:COVID-19 pandemic in Argentina (and a few other "COVID-19 pandemic in COUNTRY" categories), it appears that the infobox was only used once. However, the page is covered in red bold "Lua error: not enough memory." messages. Curiously, on this page, "LGBT people by name" DOES appear in the list of categories at the bottom.

My big question is, why would this random category get added just because a template crashed?? I see some logic in Template:Wikidata Infobox/core that adds Category:LGBT people by name, but it clearly requires certain values of sex or gender (P21); none of these items had P21 set at all. (Possibly unrelated, but I also happened to notice that Category:COVID-19 pandemic by country has the "The time allocated for running scripts has expired." red error message spam, but it does not appear in Category:LGBT people by name.) Can anyone figure this one out? Thanks, IagoQnsi (talk) 04:56, 22 January 2022 (UTC)[reply]

@IagoQnsi: The problem is that when Lua stops, it stops doing the checks, and returns the categories despite the logic. I've just implemented a work-around for this - the categories are now added through a simple Lua function, so if Lua stops then the categories won't be added. It's in {{Wikidata Infobox/sandbox}} at the moment, hopefully that should solve this from the next infobox version (will deploy it soon). Thanks. Mike Peel (talk) 12:39, 2 February 2022 (UTC)[reply]
@Mike Peel: This solution is an awful hack IMHO. I think a much cleaner solution would be checkProplist to return 1 instead of true if the property is present, and maybe 0 instead of the empty string if it isn’t, and test if we get a number greater than zero by concatenating the numbers. If Lua has timed out, the result won’t be a number, and depending on the exact implementation an expression error may show up, but no category is added. And this solution doesn’t require an extra Lua call, which would make even more pages to time out/run out of memory. —Tacsipacsi (talk) 19:45, 3 February 2022 (UTC)[reply]
@Tacsipacsi: I'm all for a better solution. I'll think through what you're suggesting and see what I can do - or if you want to demo it in the sandbox, please go for it? (see [2] for the Lua code). Thanks. Mike Peel (talk) 20:14, 3 February 2022 (UTC)[reply]
The code I wrote doesn't seem to work when made live, and I don't understand why that's happening. So for now this is still an open issue. Thanks. Mike Peel (talk) 19:16, 19 February 2022 (UTC)[reply]

'none' values in Wikidata break this template[edit]

Some properties in Wikidata cause this template to break if their value is set to 'none'. I've seen this happen with logo image (P154) and official website (P856), but it may also affect other properties. You can see the 'logo image' breaking at Category:RIT News and Events (the text "[[File: | 110px]]" appears where the logo would normally be). I don't have an example link on hand for 'official website', but as I recall, the text "[ official website]" appears. –IagoQnsi (talk) 20:48, 15 February 2022 (UTC)[reply]

@IagoQnsi: So don't use 'none' values, they don't make sense. Thanks. Mike Peel (talk) 23:32, 15 February 2022 (UTC)[reply]
It makes sense to me that an entity might not have a logo or a website. Both of these properties have a constraint that requires that a single best value be set. If an entity had multiple logos/websites in the past but none of them are current, it's necessary to add a 'none' value with a preferred rank so that old values are not incorrectly displayed as a current/best value.
I just checked: for logo image (P154), there are 12 'none' values and 56 unknown values. For official website (P856), there are 340 'none' values and 140 unknown values.
It seems to me that the template should hide the logo/website if they are set to none, rather than expecting that these properties will never be set to none. IagoQnsi (talk) 23:40, 15 February 2022 (UTC)[reply]

Exact dates not displayed[edit]

See Category:Loggia am Stadthaus. For the topping out the exact date (which is stated on Wikidata) should be displayed, not only the year. How can this be changed?--2003:E5:173E:7248:A0FC:C31D:B54E:6DFC 18:47, 11 March 2022 (UTC)[reply]

Quickload option[edit]

Someone (perhaps @Jarekt: ?) suggested at today's Data Reuse Days presentation that we have a parameter that reduces what the infobox loads, so it can handle more tricky cases. I've implemented this as a "quickload=yes" parameter in the sandbox, which seems to work. For example, see Category:COVID-19 pandemic in Colombia, which finally works again. Please test - I'll deploy this in the next release if it works OK. Thanks. Mike Peel (talk) 20:31, 18 March 2022 (UTC)[reply]

Doesn't work for me. No links, no files were displayed - all links are red with text "Lua error: not enough memory" GeorgHHtalk   21:55, 18 March 2022 (UTC)[reply]
Thanks Mike. Yes it was my suggestion. Once it is stable we could add it to pages in Category:Pages with script errors (I can do that). I will test it on some pages. --Jarekt (talk) 00:54, 19 March 2022 (UTC)[reply]
Itested it on a single page Category:1871 in Austria-Hungary and it seems to work. --Jarekt (talk) 15:43, 19 March 2022 (UTC)[reply]
Seems to work for English only (at least at Category:COVID-19 pandemic in Colombia), after switching to another language lua errors are back.Jklamo (talk) 23:56, 19 March 2022 (UTC)[reply]

Mike, Let me know when Quickload option is live, as I would like to add it to categories in Category:Pages with script errors. --Jarekt (talk) 02:52, 14 April 2022 (UTC)[reply]

Near someplace[edit]

Hi, I see that the template put a place located with d:P:P276 always as in the says place (like for Category:Pete Kitchen Ranch, even if the building is located in proxiomity of the town, like it's indicated in d:Q20714854#P276. Can you indicate in brackets the sourcing circumstances (d:P:P1480) when a location is entered with P276? Fralambert (talk) 17:33, 27 March 2022 (UTC)[reply]

Might still be dependent on P373[edit]

Category:Pipa was recently moved to Category:Pipa (frog), but wdib still pointed the genus to the old page, so i deleted the p373 values from Pipa (Q2351631) and Category:Pipa (genus) (Q8763208). now wdib shows no link for the genus. RZuo (talk) 09:43, 1 April 2022 (UTC)[reply]

I suspect that might be a caching thing? — Martin (MSGJ · talk) 20:36, 2 April 2022 (UTC)[reply]

Expression error[edit]

On all pages of celestial objects (stars, galaxies), such as c:Category:NGC 7061 appears in the infobox a message 'Expression error: Unrecognized punctuation character' when setting the language to one different from English (e.g. Dutch, French) which use decimal comma's instead of dots. Apparently this happens for the Right Ascension. Hobbema (talk) 11:18, 8 April 2022 (UTC)[reply]

The issue seems to be in {{#expr:{{#invoke:WikidataIB | getValue | rank=best | fetchwikidata=ALL | onlysourced=no | noicon=yes | P6257 | qid=Q1149326 | showunits=no}}/15}}: 21.457454446667
In English it results in the value 21.457454446667, but in Dutch it results in 'Expression error: Unrecognized punctuation character'. It could be releted ot the latest change in Module:WikidataIB HenkvD (talk) 17:59, 9 April 2022 (UTC)[reply]
This can be fixed by adding |lang=en to the WikidataIB invocation, see this sandbox edit. Note that the numbers and units for the link title are still localized, only the numbers used to generate the URL need to be in English format. LennardHofmann (talk) 11:34, 10 April 2022 (UTC)[reply]
Thanks. So I suppose one should make an edit request {{Edit request}} in order that someone is making this change? Hobbema (talk) 20:09, 12 April 2022 (UTC)[reply]
This looks good, I'll include it in the next release. Thanks. Mike Peel (talk) 17:50, 29 April 2022 (UTC)[reply]

Malformed official website link[edit]

Category:Juweihui has a special error. its official website is fetched from Residents Committee (Q12808731). it's a deprecated value, and i think this causes the malformed link. (the Q12808731 value is wrong. i will remove it soon, but now i leave it there for you to see the error it causes.) RZuo (talk) 13:23, 21 April 2022 (UTC)[reply]

Template translation[edit]


@Père Igor: is asking (on Wikidata) where to translate the "show all" option of this template (underneath the images). @Mike Peel: could you help?

Cheers, VIGNERON (talk) 14:55, 26 April 2022 (UTC)[reply]

@VIGNERON: I'm not sure it's possible. It's currently hard-coded in English in MediaWiki:Gadget-Infobox.js... Thanks. Mike Peel (talk) 15:27, 26 April 2022 (UTC)[reply]
Then probably it should be. Since the infobox already has non-Wikidata-based localization at Template:Wikidata Infobox/i18n, it’s just the matter of adding a new localization string and passing it somehow to the gadget (e.g. using a hidden <div> or a data-* attribute). —Tacsipacsi (talk) 08:36, 2 May 2022 (UTC)[reply]
@Tacsipacsi: I'd be happy to see it internationalised, I just can't figure out the "passing it somehow to the gadget" bit! Happy to help implement this if you can figure it out, though. Thanks. Mike Peel (talk) 18:08, 2 May 2022 (UTC)[reply]

Mapy.cz ID etc.[edit]

Hi User:Mike Peel, could we go back to this attribution which was archived without any reaction?

  • I would appreciate Mapy.cz ID (P8988) in the Infobox template. This connection is very relevant especially for Czech geographical items. Possible other relevant on-line maps with linkable described objects (points of interest) can be treated in a similar way.
  • The correct output format of (postal) adresses according to standards of the respective country is a challenge for the future, especially for the system of dual numbering in cities of Czechia and Slovakia.

Thank You. --ŠJů (talk) 13:24, 27 April 2022 (UTC)[reply]

@ŠJů: I've added Mapy.cz ID (P8988) to {{Wikidata Infobox/sandbox}}, please test that and see if it works as expected? Formatting of addresses is a bigger problem for the future, sorry. Thanks. Mike Peel (talk) 17:50, 29 April 2022 (UTC)[reply]

@Mike Peel: Thank You. In the infobox, the ID diplays correctly, but in the link, it is incomplete. E.g. the parameter "base&id=2222420" is shortened to "2222420" and thus doesn't work (the resultant link is https://mapy.cz/zakladni?source=2222420 instead of the correct https://mapy.cz/zakladni?source=base&id=2222420). --ŠJů (talk) 21:32, 29 April 2022 (UTC)[reply]

Hi Mike Peel, within one month, the error was not corrected. --ŠJů (talk) 23:35, 27 May 2022 (UTC)[reply]

Omit "hide/show" for authority control in common case[edit]

I think the usability and design of the infobox would be improved if the "Authority control" section rendered without being collapsible, for the common case where there is only a few entries, especially when there is only the one default entry for Wikidata itself.

Note, I'm not suggesting to remove the section from any situation, rather to remove the collapsible buttons in some cases.

I tried doing this myself, but couldn't find the right place to make this change. It seems non-trivial due to the nested use of Wikidata queries. As I understand it, we'll need a way within this structure to get a boolean result, and/or move some of the layout into a Lua module in order to more easily re-use and aggregate the same information multiple times. Krinkle (talk) 14:37, 4 May 2022 (UTC)[reply]

Map of coordinate locations[edit]

I wonder if this might be a useful query to add as a link from categories (or, at least, from geographical categories): Commons:SPARQL_query_service/queries/examples#Camera_location_of_files_in_a_category ? Jheald (talk) 12:06, 17 May 2022 (UTC)[reply]

Or would relevant categories already use template {{Geogroup}} ? (Category:River Ravensbourne does, which may make for an interesting comparison; but most categories probably don't). Jheald (talk) 12:57, 17 May 2022 (UTC)[reply]

Update needed for showing currently valid P131 values[edit]

On Category:Kapileswarapuram,_Konaseema, the Infobox is showing P131 values for districts which are outdated, as the administrative boundaries of districts were changed extensively for Andhra Pradesh in April 2022. Wikidata is updated for the affected entities, with end date qualifier for old P131 values and start date qualifier for new P131 values. (Example: wikidata:Q59939794). The template code needs to be changed to pick only the currently valid value, by checking for P131 entries without end date set. Arjunaraoc (talk) 04:44, 21 May 2022 (UTC)[reply]

@Arjunaraoc: You should do this on Wikidata by setting the latest value to 'preferred', e.g., [3]. Thanks. Mike Peel (talk) 08:33, 21 May 2022 (UTC)[reply]
@Mike Peel, Nice to connect with you again. Setting a value as preferred for hundreds of entities is not easy in Wikidata, as there is no tool. To my knowledge, only some bots set that flag. I learnt that using current flag with wikidata template on wikipedia can easily produce the currently valid value. (code:{{wikidata|properties|normal+|current|eid=Q59939794|P131}}) I did not find that feature on Commons template. It may be better to add such a feature for the template. Arjunaraoc (talk) 01:37, 22 May 2022 (UTC)[reply]
@Arjunaraoc: I am currently rewriting the infobox in Lua as part of Google Summer of Code. Excluding values based on the presence of the end time (P582) qualifier is trivial with Lua and other properties (such as official website (P856) or logo image (P154)) could benefit from it as well. So expect this to be fixed by July 3. Setting the latest values to 'preferred' is still a good idea but unfortunately QuickStatements does not support setting ranks. LennardHofmann (talk) 06:32, 22 May 2022 (UTC)[reply]


Please consider to display partially coincident with (P1382) in the infobox.

--ŠJů (talk) 00:08, 28 May 2022 (UTC)[reply]

Lua rewrite[edit]

I am currently rewriting this infobox as part of Google Summer of Code 2022. You can read about my progress here. I promise it's an interesting read if you are into technical things. LennardHofmann (talk) 14:02, 6 June 2022 (UTC)[reply]


Hello. Can we make sure train depot (P834) is displayed? It would be super useful for categories such as Category:Paris Métro Line 5, that would now link to Category:Bobigny metro and tramway workshop. Thierry Caro (talk) 17:22, 22 June 2022 (UTC)[reply]