Template talk:Wikidata Infobox

	SpBot archives all sections tagged with {{Section resolved|1=~~~~}} after 1 day. For the archive overview, see Special:PrefixIndex/Template talk:Wikidata Infobox/Archive.

Archives 1, 2, 3, 4, 5, 6

Template:Wikidata Infobox has been protected indefinitely because it is a highly-used or visible template. Please propose changes below, and if possible add them to Module:Wikidata Infobox/sandbox for testing. Changes are implemented in batches every few months to keep edits to a minimum.

Machine-readable language for auto-hyphenated words

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)

@RexxS: Is this something that could be incorporated in WikidataIB? Thanks. Mike Peel (talk) 18:55, 24 April 2020 (UTC)

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

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

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)

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

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)

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)

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)

@Mike Peel 114.10.153.14 13:42, 29 July 2025 (UTC)

@Tacsipacsi and Verdy p: I'm closing this as not done, since I still think it needs to be implemented in WikidataIB, not the infobox (since the infobox doesn't necessary know the language of the wording, and @RexxS: isn't around to help with that any more. Thanks. Mike Peel (talk) 17:50, 31 October 2022 (UTC)

@Mike Peel: I don’t care in which module is this resolved, I care only it gets resolved. Since this is the template that’s broken, this is a perfectly valid place to track it. And if no one will set the language machine-readably, then the auto-hyphenation should be removed. —Tacsipacsi (talk) 22:31, 1 November 2022 (UTC)

@Tacsipacsi: OK. One thing that's puzzling me is that this should probably be handled natively by MediaWiki when it's rendering a page in a given language, is that not currently happening? There are edge cases where the infobox is displaying in a mix of languages - but then there's the work-around to just add more language labels to Wikidata where there is a problem. Thanks. Mike Peel (talk) 21:58, 7 November 2022 (UTC)

@Mike Peel: The MediaWiki core parser has no knowledge about the language of the text. (Except for the page language, but that doesn’t depend on the UI language and is hardly if ever anything else than English in the category and gallery namespaces.) It sees a bunch of characters, of which it can interpret the wikitext syntax, but it cannot determine whether the string van means a type of automobile in English, a name prefix in Dutch, or the translation of “be” in Hungarian. This is why we need to tell it (or, rather, the browsers) by using appropriate markup. And by marking up the individual bits that have a language, there’s no issue with cases where some labels are in the UI language and others in some fallback language – and these are not the edge cases; even in English, there are many labels missing, not to mention “smaller” languages like French or Russian.

Wikibase, in turn, does know the language of the text in many cases (except for strings stored with data types that don’t allow setting the language), but it doesn’t include HTML markup in the returned value – and this is good this way, as the users may want to do fancy things with the result (e.g. using it in a tooltip), where HTML markup may cause issues. —Tacsipacsi (talk) 22:01, 10 November 2022 (UTC)

15 months since the last post; are we able to resolve this? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 17:13, 24 February 2024 (UTC)

If you mean whether {{Section resolved}} can be added to this section right now: no, it’s still broken. If you mean whether we can get to a point where {{Section resolved}} can be added to this section: I guess so. —Tacsipacsi (talk) 22:53, 25 February 2024 (UTC)

Any chance of an update on this? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 10:30, 17 November 2025 (UTC)

Template:Wikidata Infobox issues

hi Mike, my name is Reinhardt WIEWE. 2006 i was involved in the internationalization of the MediaWiki interface ^{Betawiki Nike} and used the nickname Gangleri. my task was faultfinding related to BiDirectional environments.
during the last year I added nearly ten thusend of links beween wikidata and [LibraryThing]. actual P7400 counter is 14,042 i focused on identities of authors and recently dikscovered the utility of Wikidata Infobox.

https://www.librarything.com/author/societiesinternation

https://www.librarything.com/author/nationsunited

https://www.librarything.com/author/smersh

https://www.librarything.com/author/akademiodeesperanto

all these items about organisations contain Authority Control links. https://www.librarything.com/author/meerbaumeisingerselm is a link about a person. it contains a link labeled "persondata.toolforge.org gnd 118579894" to [1]. i will ask that the tool should contain also Commons category (P373).

---

please help:

1. can you please include the LibraryThing author ID (P7400) value in the infobox?
   1. for persons where GND ID (P227) is present please include a link of the form https://persondata.toolforge.org/p/gnd/GND ID value labeled "persondata.toolforge gnd"
   2. for non-persons (as organisations, groups etc. ) normaly thereis a wikidata item involved please include a link of the form persondata.toolforge.org/p/wikidata/wikidata itam value
2. can you please display "YouTube video ID (P1651)" it will help to add emotions to the side

---

some years ago i was involved with Magnus authority control tool; see [2]. the number of Authority Control parties and the number of wikidata identifiers has exploded. do you have some ideas how to use a custom configuration file to select specific identifiers? some pleople would like language related links, some chess players chess rlated values, some would like music, entertainment related utems atc.

---

https://www.wikidata.org/?curid=65288749# contains some primitive querries.
[3] and [4] and LT group shmiletant

greetings from munich, germany

no bias — קיין אומוויסנדיקע פּרעפֿערענצן — keyn umvisndike preferentsn ^{talk contribs} 15:08, 16 November 2022 (UTC)

@קיין ומוויסנדיק פּרעפֿערענצן: Please could you post these at Template talk:Wikidata Infobox, which is where we keep track of requests like this. Thanks. Mike Peel (talk) 15:10, 16 November 2022 (UTC)

(Now moved here from User talk:Mike Peel [5] Mike Peel (talk) 07:26, 17 November 2022 (UTC))

adding some show cases:

https://www.librarything.com/author/aristotle

with an imprssive https://viaf.org/viaf/7524651/#Aristotle and

https://commons.wikimedia.org/wiki/Category:Aristotle

https://www.librarything.com/author/singerisaacbashevis

with https://commons.wikimedia.org/?curid=9515157

with links to many w:en:Yiddish sites

comments:

1. there should be an anchor to acces the "Authority control" directly
2. to be continued

regards 13:10, 19 November 2022 (UTC) no bias — קיין אומוויסנדיקע פּרעפֿערענצן — keyn umvisndike preferentsn ^{talk contribs}

@קיין ומוויסנדיק פּרעפֿערענצן: Do you have anything to add? @Mike Peel: Can we add the suggested anchor? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 17:16, 24 February 2024 (UTC)

@קיין ומוויסנדיק פּרעפֿערענצן and Mike Peel: Bumping this. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 12:40, 13 April 2025 (UTC)

Taxon pages with wikidata, but without Taxonavigation

Hello together,

I'm working on taxon categories at the moment and I noticed that there are a lot of taxon categories with a Wikidata item associated (and Wikidata infobox), but with a missing Taxonavigation bar. If the wikidata is there, it would in most cases be easy to also add the Taxonavigation bar. So it might be helpful to add a category like "Taxon pages with wikidata, but without Taxonavigation" in those cases, so that a Taxonavigation bar could be added. I know it's a bit redundant, but the Taxonavigation adds a bit of functionality, that the Wikidata infobox doesn't. Like adding categories in the style of "Genera of Family".

What could make this a bit more difficult is that there are a couple of templates like Template:Lepidoptera that are derived from Template:Taxonavigation. Also here are two examples:

• One category with the bar Category:Agriocnemis gratiosa
• One without: Category:Agriocnemis pinheyi

Same could be done for templates like Template:VN of course.

Best, FlocciNivis (talk) 12:34, 19 December 2022 (UTC)

@FlocciNivis: The information that {{Taxonavigation}} and {{VN}} include should already be shown in the infobox, so adding them as well is redundant - and makes it more difficult to use categories since those templates take up space at the top of the category that you have to scroll past. If there are things that aren't included, then we could look at adding them into the infobox. Thanks. Mike Peel (talk) 06:01, 20 December 2022 (UTC)

Hello @Mike Peel, thank you for your answer. What the Wikidata infobox at the moment not inlcudes are certain categories that are added by the Template:Taxonavigation.

If one category is for example for a species the template will add a Category in the style of Species of Family to it, if this Category exists. The same goes for Genera as well. And I think, although I'm not sure, they will be added for all the higher-ranking taxons that have a Category in this style.

Best, FlocciNivis (talk) 21:45, 20 December 2022 (UTC)

@FlocciNivis and Mike Peel: Where are we with this? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 12:42, 13 April 2025 (UTC)

@Andy Mabbett Form my side: Nowhere. After I didn't get any positive feedback back then, I didn't start to work on this. Is this something you would find useful?

Best, FlocciNivis (talk) 13:16, 13 April 2025 (UTC)

While I agree with what is said above, I'm simply trying to see which sections on this page can be archived; and to prompt some form of resolution for those that cannot. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 13:42, 13 April 2025 (UTC)

Volume as quantity and vertical depth

I have an item Preston Reservoir - WS172 (Q116214651) which is a water resevoir, basically a cylinder. Helpfully, Sydney Water has given the volume and vertical height of the water source, which I have entered but it's not showing Volume as quantity and vertical depth. Does anyonw know why this is? Chris.sherlock2 (talk) 10:02, 16 January 2023 (UTC)

More userfriendly WikiMap-Link... and maybe no need for Geogroup

{{Edit request}} Hello, I love the functionality of {{Geogroup|level=1}} but since today I didnt know that the functionality of Geogroup is included in Wikidata Infobox. I think it is too well hidden and I think for the most people the content of the wikidata infobox stops at the wikidata-Link or even earlier. The links beneath are very small and looking quite technically. Compared to them the Map of all coordinates link in combination with this small earth logo catches your eye and tell you what you get. (a good example to try this amazing functionality wheather from the small WikiMap link or from Geogroup is City of London Dragon boundary marks)... So I would apreciate to mark the corresponding WikiMap link in the infobox a bit more, for example with a small earth logo before the link. And generally maybe make them in normal font size OR keep them small and write a bit more in combination with a small logo, eg.:  WikiMap with all coordinates. After this there is maybe no need for {{Geogroup}} anymore. Regards --W like wiki ^{good to know} 21:57, 22 January 2023 (UTC)

 Weak support the  WikiMap with all coordinates proposal; I also link this should be more visible. In Category:Drone videos from unidentified countries one can see the geogroup template and how this could be used.

However, I think to be truly or much more useful, the geogroup tool should also consider the coordinates of location categories of files to when enabled e.g. display files in countries if they are in country-specific categories. Currently, it only shows a tiny fraction of geolocated files: the ones with specific coordinates set. See Template talk:Geogroup#Also include files geolocated to countries/places via subcategories but not coordinates.

It would also be good if the Export as KML feature was add to the tool (the map view) and it really needs to enable the user to specify subcategory depth from the map view – it loads at level 1 but one can't configure that at the map view. It's also reasonable to wait before making this link more visible and descriptive until at least either of these two things get improved. Prototyperspective (talk) 11:09, 13 November 2025 (UTC)

@Prototyperspective: consider the coordinates of location categories of files to when enabled: is that "consider the coordinates of location categories of files, too, when enabled" (and, if so, when enabled where or by what?) or something else I couldn't guess? - Jmabel ! talk 18:27, 13 November 2025 (UTC)

Yes, thanks for the correction. That part is indeed unclear so thanks for the question as well: I meant when one for example presses a toggle button like 'Include location categories' it would also show files with no geocoordinates on the map if they are in a category like [Name of city] or Videos from [natural reserve xy] etc. If the toggle is set to disabled, it would show only files with coordinates. The setting or button would be on the toolforge map page, maybe in a corner or in a burger menu or sidebar. Prototyperspective (talk) 19:27, 13 November 2025 (UTC)

Doc-page: usage section - code position of the template

Hello, at the moment the position of the template box text {{wikidata infobox}} is found sometimes in first line before all other templates (like {{MetaCat}}, {{catseealso}}, {{en}},...) or sometimes in last position (just above the categories). I think the latter version is the more recommended: it is more often used and it looks a bit better, compare for example Category:Coloring agents 1st version and 2nd version.

So I propose to add a note regarding this recommendation in the usage section of the template doc. Regards --W like wiki ^{good to know} 17:11, 31 January 2023 (UTC)

Author citation for taxa

Hello, I noticed 3 bugs with the author citations as it is currently rendered with the infobox. 1/ when there are several authors, only the first is displayed (exemple), 2/ when the species names is a recombination the citation should be with brackets (exemple) 3/ only the surname by default (or the "author citation" https://www.wikidata.org/wiki/Property:P835 when it exist) should be displayed.

The Wikidata module "Taxobox" address quite well those issues https://www.wikidata.org/wiki/Module:Taxobox (line 457 to 490 and 528 to 644).

Regards, Christian Ferrer ^(talk) 20:45, 1 March 2023 (UTC)

Should the relevant code not be split of into a separate module, that can be used by both templates, and any others needing to do this? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 11:28, 9 April 2023 (UTC)

@LennardHofmann and Mike Peel: Do you have a view? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 19:36, 20 April 2025 (UTC)

Any news on this? I realized at least the first bug is still there, see e.g. Category:Leurocyclus tuberculosus and Leurocyclus tuberculosus (Q13400356). Einsenkungsmarke (talk) 15:41, 11 February 2026 (UTC)

@Christian Ferrer and Einsenkungsmarke: It would be great if someone made a version of Taxobox that can be embedded into the infobox instead of Module:Taxontree. --LennardHofmann (talk) 19:25, 11 February 2026 (UTC)

• Sorry I can't help, see also this similar topic below in this page. Christian Ferrer ^(talk) 08:35, 12 February 2026 (UTC)

  While I do know how to develop, I never have done LUA coding. And I don’t know the intricacies of the taxonomic rules. So while in the midterm I might add the additional authors (if/when I find the time), I‘m not in a good position to do the full requirements. Sorry. :-( Einsenkungsmarke (talk) 11:31, 12 February 2026 (UTC)

  Probably others know that already, but there’s taxon author citation (P6507) to provide the fully formatted author citation. So while automatically creating the citation certainly is a good idea, one can use taxon author citation (P6507) in the meantime. Einsenkungsmarke (talk) 12:23, 14 February 2026 (UTC)

Taxonomic Author abbreviation

I noticed that the template pulls the name of the first author listed on Wikidata, for example, the Category Theobroma cacao, which uses the template, shows this in the property Taxon author:

Carl Linnaeus, 1753

And ommits the rest of the authors if there are, shouldn't it show the botanical abbreviations like this?

L., 1753

We already have the abbreviation contained in the identifier botanist author abbreviation on Wikidata (P428). Or at least list the other authors? The exact same result happens with the Taxonxonavigation template.

JaimeDes (talk) 00:54, 6 April 2025 (UTC)

@Christian Ferrer: thoughts? If I remember right, you implemented this part? Thanks. Mike Peel (talk) 05:09, 6 April 2025 (UTC)

• @Mike Peel: I already noticed this issue 2 years ago [6], the message is still in that page a bit above, I have not the ability to fix it myself. I see 2 possible solution, 1/ the field is removed from our infobox, in that way we are sure we don't display something incomplete 2/ someone with the right abilities add to our module something inspired from the Wikidata module "Taxobox" which address quite well those issues https://www.wikidata.org/wiki/Module:Taxobox (it seems at lines 457 to 490 and 528 to 644). If someone decide to works on that subject, I think the Wikidata infobox is a good exemple to follow because as far I see it works quite well regarding the citation of authors, and it follow well the needed complex nomanclatures (different in zoology and botany) regarding the display of the citations. Sorry, I can't help much more, if not corrected I think the field should be removed. Christian Ferrer ^(talk) 11:01, 6 April 2025 (UTC)

Wikipedia Links

It appears that a corresponding Wikipedia page ist only presented and linked in the Wikidata infobox if such a page exists on the English Wikipedia. Would it be possible that other Wikipedia pages could be listed if no English page exists?

This makes sense especially for objects, buildings and places specific to one country. In these cases a corresponding article will often only exist in one Wikipedia language version.

If several language versions exist the task of using the right article to link is a little harder to automate. Ideally maybe a procedure like this could be established:

• if only one article is connected via Wikidata choose that one
• if the object has a geographic affiliation choose the corresponding language version
• otherwise choose the largest Wikipedia version.

Or, to circumvent this possibly rather complicated procedure, why not simply list all affiliated Wikipedia articles?

thanks,

KaiKemmann (talk) 11:35, 17 April 2023 (UTC)

@KaiKemmann could you plz give an example link where the problems you describe exist? RZuo (talk) 21:55, 17 April 2023 (UTC)

Sure, RZuo. The infobox on Category:Goethegymnasium Weimar offers no Wikipedia-link as no English page exists. It should therefore display the link to the German page de:Goethegymnasium Weimar.

(Sorry for the late reply.) KaiKemmann (talk) 00:38, 10 May 2023 (UTC)

@KaiKemmann: The link is language-based, if you browse in German then you see the link to de-wiki. Thanks. Mike Peel (talk) 05:55, 10 May 2023 (UTC)

@Mike Peel: Oho, the box is more sophisticated than I had anticipated. Still, many ordinary users would probably assume that no corresponding Wikipedia article exists if no Wikipedia link is presented in the infobox. I really had no clue that the contents of the infobox could adapt to the language setting. I still think it would be quite helpful to indicate that a corresponding article exists in another Wikipedia language version instead of simply not displaying the "Wikipedia"-link in the Wikimedia Commons language version I am using.

KaiKemmann (talk) 20:15, 10 May 2023 (UTC)

 Support If the user language is unknown/fallback/default or English and no English Wikipedia article exists, it would be good to show a non-English Wikipedia article in the infobox like (German) Wikipedia in the case of the example.
However, it's still unclear what to do if there is more than one Wikipedia article in another language – which one to show? I don't know if it's possible (yet) for logged-in users to specify multiple languages they speak in which case it should show the Wikipedia article of another language instead of their primary language they speak (not all users should be assumed to be fully monolingual) if it exists. If that's not possible or the user has not configured that or no language version article exists for any of these configured languages or the user is not logged-in, the problem is still there. How do people propose this problem is solved?

Maybe one could use quality indicators of the article to show the one most likely to be of good quality. Or one could do this for now only for those cases where there's only one Wikipedia article (as with the example). For all cases, consider that the language could be entirely cryptic to the user without any usefulness if they don't speak it. However, many browsers by now for many languages have a machine translation feature by which also those articles could be useful. Thus, I think this could be really useful. Note that these machine translated articles could contain uncorrectable errors and media files in other languages (and can't be found by people searching the Web in their own language) – the wish m:Community Wishlist/Wishes/Wikipedia Machine Translation Project is about that and if it was implemented one could show the version translated to the user language. As that is currently not possible, showing the link to the article in another language they may not understand but could machine translate is a good idea at least until then and maybe also if it becomes possible as a second wikilink. Prototyperspective (talk) 11:27, 13 November 2025 (UTC)

Or you could display multiple languages (up to some limit) like "Dan Hatmanu [es] [fr] [ro]". - Jmabel ! talk 18:38, 13 November 2025 (UTC)

Good idea! However, that ultimately probably runs into the same problem for items with Wikipedia articles in lots of languages but the one of the user's configured language (e.g. it's not a good idea to display 200 wikilinks like that in the box as there's about 300 Wikipedias now). It would be easier if one could pin a set of language / specify a set of language as being second or third choice options. I think there was a Community Wishlist wish and/or phab task about pinning languages or something similar and I planned to look for it and will maybe bring this up there too if I find it. Prototyperspective (talk) 19:31, 13 November 2025 (UTC)

Having an explicit list of language preferences is good for logged-in users, but probably unworkable for those who aren't logged in. We could just sequence in terms of size of the respective Wikipedias, with top 3-5 that have an article provided in the box; we'd certainly be giving them what they want a high percentage of the time. - Jmabel ! talk 00:05, 14 November 2025 (UTC)

Would probably be better than what's currently the case. However, all of this thread made me wonder about how it used to be: I think Commons used to have a design with a panel on the left that included all the Wikipedia links with the different languages or was it just Wikipedia?

The Wikipedia article is still linked but essentially no user will see or find – even if they'd look for it which most don't do – it. It's under [top left burger menu]->section "In Wikipedia":

• Maybe the better approach here would be to do something about the UI/design to make the Wikipedia links visible by default again on Commons instead of changing the Wikidata infobox. I'm completely not sure about whether it would be as good or not (or even better) and whether that's something that may be feasible and if so how. Maybe a new thread would be best to be started about this at some other place like Commons:Village pump/Technical.

Prototyperspective (talk) 00:31, 14 November 2025 (UTC)

List of articles in different languages is just for categories, not files. And where you see it is going to depend on what skin you use. I use Vector 2022 (the default) and I get a list at the bottom of the left nav. - Jmabel ! talk 04:14, 14 November 2025 (UTC)

List of articles in different languages is just for categories, not files ? What do you mean? Where was there any talk about file pages in this thread? And I was talking about category pages, as in the example, Category:Goethegymnasium Weimar. I have the main menu hidden instead of a sidebar with the default Vector2022 skin and think maybe half of users hide it or have it hidden if not more. If it's visible, the Wikipedia link in the infobox is not much needed as the link is already in the sidebar. Prototyperspective (talk) 14:43, 14 November 2025 (UTC)

Sorry, you are right about the context, I was wrong. Yes, if you are hiding things that would matter more. But if it's info that you want, why do you hide it? - Jmabel ! talk 19:07, 14 November 2025 (UTC)

Because the sidebar takes up a lot of space. And because it's not useful, I don't need these links and texts that are in it:

"Main menu

Main page

Welcome

Community portal

Village pump

Help center

Participate

Upload file

Recent changes

Latest files

Random file

Contact us

Special pages

In Wikipedia"
but only this short link (in the example) "Deutsch".
Showing the giant sidebar for it is unreasonable. And I think many users quickly hide the two panels when they start browsing a wikisite and then don't click the burger menu to see whether it has Wikipedia article links and also don't know/remember those are there. Moreover, half or so if not more of users view the mobile site which has it collapsed. Prototyperspective (talk) 16:59, 15 November 2025 (UTC)

I also think that we should rely on the existing language links instead of reinventing the wheel. (I’d maybe even remove the existing Wikipedia link, i.e. not show the link even if one in the current user language exists.) I see two ways to make the language links easier to discover:

• Add a button in the infobox that shows the sidebar if collapsed and then scrolls to the language links section. This would likely require a gadget, and not solve the problem on category pages without infobox (or pages in other namespaces: gallery, Commons etc.).
• Move the language links to where it is on Wikipedia. This would require a configuration change, so it’d require community consensus (preferably on a village pump). This would also overturn the decision made in phab:T281968, so we would need to convince developers. (To be honest, I don’t entirely understand their reasoning, so I can’t say how that argument is.)

Tacsipacsi (talk) 15:56, 16 November 2025 (UTC)

• I don't think it would be good to remove the existing language link in the infobox and the button to show the sidebar would only be useful if it only displayed when there is a Wikipedia link there but not otherwise.
• I don't think one needs to scroll to see the language links – do you? I don't and it's just a few links above the Wikipedia links so I don't see how one needs to scroll.
• Showing the link where most users would expect it and where's quite clearly visible and which uses the already-used language dropdown (e.g. incl search) which is made for this purpose sounds best. It would probably need to show something like "In Wikipedia" instead of "In other languages". Could you create a VP discussion about it assuming there are no objections here?

Prototyperspective (talk) 22:45, 16 November 2025 (UTC)

I don't think one needs to scroll to see the language links – do you? It depends. On my default ~1000px tall screen with the sidebar open, neither do I. However, if the sidebar is collapsed and temporarily shown, on a shorter screen (below 600-700px), the language links are in the overflow area and thus not visible immediately. It may also be possible with an open sidebar that the infobox has so many images that the Wikipedia link is below the end of the language links: e.g. try clicking Show all in the infobox of Category:Thuringia. So it’s possible; and even if it’s unlikely, we should care about it, as the lack of scrolling would be very confusing for the affected people (and the presence of scrolling not problematic for others).

It would probably need to show something like "In Wikipedia" instead of "In other languages". That would require extra development, and, more importantly, extra translator work. It may be worth it, but the costs should be considered (which are primarily volunteer work, not financial costs).

Could you create a VP discussion about it assuming there are no objections here? I don’t have the time for that right now, but I can do it if/when I have time. If someone beats me on it, feel free to. —Tacsipacsi (talk) 10:59, 17 November 2025 (UTC)

Thanks for explaining. I think scrolling can be disruptive and problematic and it doesn't really highlight the links so the user doesn't know/see where they are. Ideally, it would always highlight the "In Wikipedia" header (e.g. blue background) and scroll only if it's not visible on the screen when the sidebar is opened.

Those are two words. The effort for translation is thus negligible. The benefit is tremendous as the Wikipedia link is very useful to many visitors of the Commons page, especially as these don't include the article's lead as an explanation for what the subject is about. And if preferred or considered too much work, I'm willing to enter these two words into a machine translator and paste the accurate result for all languages so no translation work is needed for the translation itself. Yes, obviously development would be required to display the "In other languages"-type "In Wikipedia" button at the top and it thus needs to be considered but that's self-explanatory.

Well then I'd create the thread in the near future if I don't forget it and get back to the task. Would like to wait for if there's more input on this and/or the other ideas in this thread. Prototyperspective (talk) 18:35, 17 November 2025 (UTC)

i can see the link to dewp. my ui lang is english and i dont have babel on my user page.

another example: Category:Wetten, dass..?, i can see "Deutsch English Español Français Italiano Nederlands 中文" and "5 more". RZuo (talk) 09:36, 10 May 2023 (UTC)

I presume you are referring to the language links in the column on the left hand side of the screen?

I feel a little clumsy now as I mostly don't remember to look for the interwiki-links at this position of the screen on Commons even though I use them frequently on de-Wikipedia to switch to en-Wikipedia and vice versa. This just may be good example, though, of how the infobox monopolises our attention and makes us ignorant to the fact that alternative functionality may exist.

How about making these interwiki-links available in the infobox by displaying the (hyperlinked) country codes like this

Wikipedia: de en es fr it nl 中文

for example?

KaiKemmann (talk) 20:15, 10 May 2023 (UTC)

sorry about my mistake. i thought you were talking about the left sidebar. i never paid attention to the wikipedia links in the infobox. in fact, i just realised there are links after you mention them.😂

United States Constitution the box actually links to all projects in the same lang.

i suppose it would be too unrealistic to list all projects in all langs. RZuo (talk) 18:12, 11 May 2023 (UTC)

That is true when Wikipedia articles exist in many languages. Still, in the most relevant case where no article exists in the English Wikipedia (because the category contains images of buildings in a particular street in a French town for example), it is unlikely that there is more than one related language article (in the French Wikipedia in this case) that should be offered in the infobox.

Also a limit of perhaps the six largest Wikipedia language versions (or more if space permits ..) could be implemented.

KaiKemmann (talk) 11:17, 22 May 2023 (UTC)

I think there's a misunderstanding here about how the link works. The link shown depends on your language setting - if it's English, you'll see the English links. If it's German, you'll get German links, etc. It's meant as an addition to the main sitelinks, not as a replacement. Thanks. Mike Peel (talk) 21:05, 17 November 2025 (UTC)

Due to the nesting I can't see to which comment you're replying so if you're referring to the entire thread: this is well known. This is about cases when the Wikipedia article in your own language does not exist but it does exist in other languages. People may speak more than one language or may be able to use machine translation tools so in that case there should still be a or multiple WP wikilinks well-visible. Prototyperspective (talk) 22:19, 17 November 2025 (UTC)

It was a general reply. I think what you're describing is the role of the language selector in MediaWiki. The infobox link is there to show you whether an article exists in your chosen language - and the absence of a link is also a subtle way of encouraging people to create new articles. I'm not sure it's possible to access Babel information via Lua, but I believe the language selector can do that, and that's also more in common across multiple wikis (although I'm not sure the latest version is used here yet). Thanks. Mike Peel (talk) 08:27, 18 November 2025 (UTC)

what you're describing is the role of the language selector in MediaWiki I wasn't but that's so far the outcome of this discussion, see the latest comment above. So it seems like that's also what you'd prefer/support/consider. The difference to the language selector is that the text in it says "In other languages" while here on Commons for Wikipedia links it would need to say sth like "On Wikipedia". If that's done or planned, then I think the request / this thread could be considered solved since it's about using the Wikidata infobox to provide something that the default MediaWiki of Commons doesn't provide. Prototyperspective (talk) 12:40, 18 November 2025 (UTC)

Can Work_period_(start) and Work_period_(end) be combined in the infobox?

Work period (start)=1926 Work period (end)=1970 Can they be combined in the display as Work_period=(1926-1970)to save room in the infobox, they take up a lot of room, and the eye is drawn to them. RAN (talk) 22:57, 24 April 2023 (UTC)

feature request: small icon

the 'small icon' property should display at a small size to best display the relevant use for images linked to the data item with the property. i propose: centered and just above the label header Arlo James Barnes 04:29, 25 June 2023 (UTC)

I'm not sure I understand this request. small logo or icon (P8972) is already used for the authority control in the Infobox, do you mean that it should be displayed elsewhere too? Thanks. Mike Peel (talk) 13:31, 13 August 2023 (UTC)

test case: category:Wikimedia Sustainability Initiative does not show the icon specified by the Sustainability Initiative (Q119929627) p8972 statement. Arlo James Barnes 13:39, 13 August 2023 (UTC)

Thanks, that's clearer. small logo or icon (P8972) is very similar to logo image (P154) here, though, do both need to be displayed? Particularly worrying about compactness of the Infobox. Thanks. Mike Peel (talk) 13:42, 13 August 2023 (UTC)

I think it would be fine to only show it when missing another logo statement (I'd count official symbol (P2238) in that group too perhaps, which I suppose would link to a dedicated category, circumstances allowing). But just because they are similar here doesn't mean for other items they might not be quite different. My main point was that these are images for which there is the presumption that they look good at this compacter scale, so the manner of display of the image should be commensurate with that. Arlo James Barnes 13:54, 13 August 2023 (UTC)

Template inserting page name as plain text on every page

See earlier discussion at Commons:Village pump#Extra text in category. The template is currently inserting c:[Name space]:[Page name] on every page it is used. The example version on this template is showing c:Template:Wikidata Infobox. I am not familiar with the coding structure for this template and I can't see where it is coming from. Any ideas? From Hill To Shore (talk) 18:51, 1 September 2023 (UTC)

That must be due to the recent changes to Module:Interwiki from P460. @Verdy p: Please make sure that no visible links are inserted like "d:Template:Wikidata Infobox" as seen on Template:Wikidata Infobox. --LennardHofmann (talk) 17:17, 2 September 2023 (UTC)

Using Module:Interwiki from P460 is actually redundant in this template since it has the functionality builtin—albeit in a less sophisticated way. @Verdy p: do you have feedback on the implementation of function interwikis() in Module:Wikidata Infobox? Should we move the langlist and iwprefers tables to a new module so that oder modules can use them? LennardHofmann (talk) 18:16, 2 September 2023 (UTC)

This is already fixed, before you even posted those messages above (this was caused by the partial parsing of the current page, trying to locale interwiki links, there was a extra entry recognizing "c:, but I disabled it ans commented it, the code was the same as on Wikidata). So refresh the pages on Commons, it should already be OK without any change, if caches have not been automatically purged: I had already detected and fixed this bug before your posts and this occured in a minority of pages, just for a few hours when they were automatically refreshed, but not in almost all pages as there was not enough time for them to get them purged).

That code was extensively tested on Wikidata (which is the documented reference source), befiore I reimpored it in Commons, without seeing the defect imemdiately,, but I detected it a couple of hours of later and fixed it; it may have affected a few pages on commons that just need a manual refresh (or automatic refresh after cache time expiry).

If you still see this extra text, just purge the page (you can use the optional "UTC clock" gadget to force it in one click before cache expiration, which seems to be one week on Commons for most categories).

Note that the module instructs to make updates on Wikidata and porting/adapting the code on other wikis (like Commons). There was a missing adaptation for Commons; another version is also used in Polish Wikipedia (but I've not checked it and modified it, however it should be easy to adapt it; ùmay be there's a way to autodetect this adaptation, which is now simpler to do in only one commented line of code).

This all was part of work trying to unify this module which behaves a bit differently depending on which wiki uses it).

Note that there's a comment about why this parsing of the current page may be costly (and may still forget interwiki links because thz parsing is partial and ignores transcluded links). I had optimized that code, and allowed it to recognize more languages and interwiki links, but "c:" in Wikidata must be treated differently than other interwiki links; the same logic is used not for "d:" on wikidata. However I did not remvoe the local parsing of the current page (according to existing comments, this is used to override wikidata interwiki links). I've not made any other insclusion, may be that parsing of the local page (which is still enabled by default), is now redundant, there's a flag about that (which as already implement on the wikidata version of that module). Basically the code is now wimilar between Wikidata and Commons (except on one line), and on two extra functions that are used exclsuively on Wikidata for reports in Wikidata talk pages, and that generates command-separated lists of links instead of interwiki links metadata, and that I have kept "as is"). verdy_p (talk) 19:34, 2 September 2023 (UTC)

Thanks for the detailed response. If I understand correctly, Module:Interwiki from P460 looks for interwiki links in the wikitext (*gasp*) so that it doesn't produce interwiki links that override them (since MediaWiki ignores subsequent interwiki links with the same prefix). Or is there another reason? @Verdy p: I think "d" should be completely removed from knownLanguages since [[d:Something]] always turns into a visible hyperlink, not a sitelink. Removing "d" fixes the inserted "d:Template:Wikidata Infobox" seen on Template:Wikidata Infobox at least. LennardHofmann (talk) 07:39, 3 September 2023 (UTC)

Phillippe, is this a long-winded way to say «Oops, sorry!»…? -- Tuválkin ✉ ✇ 02:14, 6 September 2023 (UTC)

The recognition of "c:" is already disabled explicitly (see line 76: knownLanguages['c'] = nil -- disable local project: it was the fix (and the only difference with the version on Wikidata, where "d:" is also disabled there instead if "c:" on the same line of code). The dependency in the Infobox is not mine, it preexisted. Basically, it was done apparently so that interwikis could be added on pages that could be different from what is in interwikis stored in Wikidata items: this worked with a (partial) parsing of the current page (ignoring transclusions, notably infoboxes); full parsing with a full expansion is currently not possible (doing that would already cause an infinite recursion, notably caused by infoboxes present in pages). I just optimized a bit that partial parsing (also fixed some code to ignore "includeonly" sections in the current page being parsed, as well as HTML comments, as they produced "fake" or non-relevant interwiki links in various pages). May be there are other things to do for this partial parsing (see the FIXME comment). But I've not removed anything from the Infobox that is still using this Module (possibly also because not all interwikis are stored in Wikidata items, but in the MediaWiki content on the current page: this still occurs quite often in many pages, even if usually bots are removing these links from pages when they are redundant but keep them if they are different from what is in Wikidata items). On Wikidata, there's also a use of that module on items talk pages, where lists of interwikis are listed in the page content rather than in the navigation sidebar, to display some reports: all that is kept in a couple of additional functions in the version used in Wikidata). Note also that I augmented the list of known languages (but I'm still not sure that it is complete; as well some existing interwiki language code aliases are now recognized as well, and I documented all of them, as their relevance may change over time; there are still missing interwikis for localized Wiktionary/Wikivoyage/Wikinews/Wikibooks/Wikisource that may eventually be added to the sidebar, but this requires firther checks: Wikidata itself is not always using interwikis lists of items but item properties from some of them, sometimes by an URL, and this is somethginh to decide and cleanup in Wikidata). verdy_p (talk) 11:11, 3 September 2023 (UTC)

Migrating to local function

I would like to remove the dependency on Module:Interwiki from P460 in this infobox. What advantages does that module have over function interwikis() in Module:Wikidata Infobox? LennardHofmann (talk) 07:39, 3 September 2023 (UTC)

@LennardHofmann: If this does the same as the existing module, then I support it, particularly to reduce dependencies and make the template easier to install. @Verdy p: any thoughts? Thanks. Mike Peel (talk) 18:55, 8 September 2023 (UTC)

@LennardHofmann: Is this resolved? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 17:23, 24 February 2024 (UTC)

The original bug is resolved, but we should still get rid of the Module:Interwiki from P460 dependency. LennardHofmann (talk) 10:47, 1 April 2024 (UTC)

@Mike Peel: The next time you edit the Infobox, please remove {{#invoke:Interwiki from P460|InterwikiP1420}} from Template:Wikidata Infobox. I previewed 300 pages with and without that line to check it doesn't make a difference. LennardHofmann (talk) 16:15, 2 April 2024 (UTC)

@LennardHofmann, Verdy p, and Mike Peel: Asking again: Is this resolved? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 12:45, 13 April 2025 (UTC)

Coach of sports team displayed in the Infobox

Hello! Could you display coach of sports team (P6087) in the infobox in addition to member of sports team (P54). That would be really helpful, especially when you want to add categories to the activity as a sport coach or sport manager like e.g. Category:Jürgen Klopp oder Category:Julian Nagelsmann. --Quick-O-Mat (talk) 09:11, 28 October 2023 (UTC)

@Quick-O-Mat: Added to {{Wikidata Infobox/sandbox}}, will make it live shortly. Thanks. Mike Peel (talk) 10:12, 28 October 2023 (UTC)

@Mike Peel: Great, thank you very much for the quick processing. Have a nice day! --Quick-O-Mat (talk) 10:19, 28 October 2023 (UTC)

Now live. Thanks. Mike Peel (talk) 10:47, 28 October 2023 (UTC)

@Mike Peel: Could the position be changed so that coach of sports team (P6087) appears after member of sports team (P54) in the infobox? Everyone was a player first and then a coach. The infoboxes on Wikipedia also follow this order. --Quick-O-Mat (talk) 20:16, 28 October 2023 (UTC)

@Quick-O-Mat and Mike Peel: Is this resolved? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 12:47, 13 April 2025 (UTC)

Conjunction i18n

Using this template with flags, I noticed that the conjunction "and" doesn't get translated to other languages (e.g. Category:National flag of Norway, section "Depicts"). Please, substitute "and" with Template:Conj-and. Daniele Fisichella 19:15, 14 November 2023 (UTC)

P54 (member of sports team) revisited

The use of this property has been briefly discussed here in 2019. There's a small disagreement at Wikidata, case in point Category:Kieran Trippier - d:Q1083432. As per Wikidata guidelines, the current team should be marked with rank=preferred. However, in that case, this template no longer lists all the teams. In order to work around this, User:Mattythewhite is removing the preferred rank, which is a misuse of Wikidata, and causes problems in other wikis that rely on the documented meaning of ranking Wikidata. The solution should be for this template to not just pull the best statements of P54 from Wikidata, but all statements with rank>=normal.  —Andrei^talk 09:02, 15 November 2023 (UTC)

Treat "human whose existence is disputed" like "human"?

Hi everyone, should the template also display the surname category etc. also for categories with a connected WD items of instance "human whose existence is disputed", such as Category:San_Calcedonio? In this case i find it reasonable but maybe there are arguments no to do so. Regards, --Arnd 🇺🇦 (talk) 08:25, 19 November 2023 (UTC)

Spf parameter and numerous statements

• Does spf parameter work as an hiding parameter ? {{Wikidata Infobox|qid=Q2069820|spf=P1889}} still shows the P1889 values.
• Is there possibility to ask for a "group"/semi-hide/collapse/decollapse" of P1899 if there are numerous P1889 statements ? --Bouzinac (talk) 15:15, 8 December 2023 (UTC)

  • @Bouzinac: spf can be used to hide things, but it doesn't work on certain properties (more specifically, it doesn't work if the property is associated with a function in the property_logic table that doesn't use WikidataIB under the hood; getDifferentFrom is one such function). Yes, that's not ideal, but it's a rather niche problem.
  • No, you cannot configure this. However, P1889 shows up to 30 Wikidata statements of best rank, so you could mark a few Wikidata statements as preferred if you want to show only those.

  LennardHofmann (talk) 17:25, 9 December 2023 (UTC)

  Thanks. Reading the code https://commons.wikimedia.org/w/index.php?oldid=816129088#L-577, I wonder if it would it be possible to ask for a collapse if, say, >= 5 P1889 statements ? I can understand it might be bothersome to read many "identical" P1889 statements in Commons whilst they are still needed in Wikidata.

  Another surprise : both their wikidata have only one P1889 preferred statement. Yet, their infobox does not show same result: Category:Beleg van Venlo (1830) and Category:Beleg van Venlo (1793) Bouzinac (talk) 17:35, 9 December 2023 (UTC)

P1191 & P4647 for plays

Maybe it would be nice having date of first performance (P1191) and location of first performance (P4647) included in the infobox for categories related to plays (play (Q25379)). Strakhov (talk) 10:38, 10 December 2023 (UTC)

Multiple P131 values

The template inconsistently treats multiple P131 values.

• if the multiple P131 value is stated directly in the current item, the template lists all values in parallel, but omits the tree of higher territorial units. Instead of the tree, it display P17 (country) value (or values if also multiple). The template does not attempt to find the nearest common parent.
• if some of the items from the division tree (linked through P131 (located in the administrative territorial entity) or P276 (location)) has multiple P131 values, the template takes only the first value and ignores all other values.

Since the template prefers P276 (location) to P131 (located in the administrative territorial entity), in many cases it ignores the correct territorial unit from P131 and returns a tree based on an incorrectly selected value of P131 from P276 linked item.

Typically, a bridge or a mountain is divided by an administrative border into two units or even countries. The item of the bridge or a mountain has multiple P131 (or also P17) values. A statue on the bridge or on the mountain has P131 and P17 values of a specific administrative unit and country. In parallel, it has also P276 value (the bridge, the mountain). The infobox completely ignores the direct P131 and P17 value, and instead states incorrect location tree based on incorrectly selected P131 value from the bridge/mountain item linked by P276.

E.g. Masarykova chata is a mountain hut located at the Czech side of the Šerlich mountain. It has correct P131 (Deštné v Orlických horách), correct P17 (Czechia) and correct P276 (Šerlich). However, infobox displays incorrect location "Šerlich, Kłodzko County, Lower Silesian Voivodeship, Poland", because it selects incorrect P131 from the Šerlich item. This error can only be suppressed by deleting P276 statement.

Would it be possible to solve this problem somehow? ŠJů (talk) 16:55, 22 January 2024 (UTC)

Нет сепаратора в списке "Не путать с"

Нет сепаратора в списке "Не путать с", поэтому возникают неоднозначности между словосочетаниями.

Halfcookie (talk) 12:17, 3 February 2024 (UTC)

Google translates the above as: "There is no separator in the "Do not confuse with" list, so there are ambiguities between phrases.", Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 20:40, 3 February 2024 (UTC)

Domain + kingdom

На время подписи шаблон неверно ведёт себя, если объект категории - таксон бактерий, архей или вирусов. С 2024 года в этих доменах узаконены ранги домена (реалма) и царства, поэтому оба эти ранга должны быть отражены в карточке. Online translation: At the time of the signature, the template behaves incorrectly if the object of the category is a taxon of bacteria, archaea or viruses. Since 2024, the domain (realm) and kingdom ranks have been legalized in these domains, so both of these ranks should be reflected in the card. Compare: Category:Dictyoglomi vs. Category:Actinomycetota. -- VladXe (talk) 05:40, 21 February 2024 (UTC)

Image priority

Apparently the infobox now displays first the montage image (P2716) instead of the image (P18). Why? Was this a premeditated change? If there was a formal proposal, can someone pinpoint that thread (I searched and found nothing)? Thanks! Strakhov (talk) 15:11, 12 May 2024 (UTC)

It has for a long time, I think I coded it that way when I first added montage image (P2716). The rationale is that Wikipedias tend to use collages for big topics where there are many photos and different aspects (like, major cities), and in those cases it's probably also good to show multiple images here as well, with the click-through to image (P18). Thanks. Mike Peel (talk) 17:03, 12 May 2024 (UTC)

Well, IMHO it was not a good idea. Leaving aside other considerations, P18 is generally a better curated property than these montages (when used in Wikipedia, many of these "mosaics" are created by means of templates, that do not need a "single merged image" in Commons; and the ones hosted in Commons are pretty crappy). Also, Quality or featured images are usually stand-alone images, not montages. But if people here in Commons think the montage priority is OK, then... Strakhov (talk) 05:58, 18 May 2024 (UTC)

Wrong municipality

On Category:Tullportsbron, the template claims that the bridge at hand is located in Båstads kommun (Båstad Municipality), which is incorrect. On the wikidata page, the only municipality I can find is Ängelholms kommun, which is correct. Is there someone out there who can find out why the template shows Båstad, and how to fix this? /Dcastor (talk) 07:38, 20 May 2024 (UTC)

Ängelholm (Q54755) is claimed to be located in Ängelholm Municipality (Q255206) and Båstad Municipality (Q499464), so if this is incorrect you should edit Ängelholm (Q54755) — Martin (MSGJ · talk) 10:15, 20 May 2024 (UTC)

Ängelholm is located in both, but not this bridge. It is in the part of Ängelholm that is located in Ängelholm Municipality. /Dcastor (talk) 10:26, 20 May 2024 (UTC)

So, as far as I understand, the municipality which is included in the template is not fetched from the wikidata object for the category itself, but from the one for the locality. And when the locality is divided between more than one municipalities, the template picks one (randomly?). Am I right? If so, is there a way to "force the pick"? (I personally think that the municipality given in the wikidata object itself should be used.) /Dcastor (talk) 20:11, 21 May 2024 (UTC)

I'll just remove the template from the category for now. If the issue is resolved, someone can replace it, but as long as it is incorrect it shouldn't be there. /Dcastor (talk) 18:54, 22 May 2024 (UTC)

The code follows the location (P276) in the item (or, if there isn't one, located in the administrative territorial entity (P131)), then it follows the located in the administrative territorial entity (P131) properties until it gets to a country, using the preferred or normal values as appropriate. You should tweak the Wikidata items rather than removing the infobox (it will automatically be added back by bot tomorrow). Here, maybe in Ängelholm (Q54755), Ängelholm Municipality (Q255206) should be the preferred value for located in the administrative territorial entity (P131)? Thanks. Mike Peel (talk) 19:03, 22 May 2024 (UTC)

That worked, and I hope that the template is not used anywhere for an object in the Båstad kommun part of Ängelholm. This must cause loads of errors in larger cities, covering several municipalities. /Dcastor (talk) 19:22, 22 May 2024 (UTC)

@Dcastor If the template is used in the Båstad kommun part, you simply leave out the Ängelholm (Q54755) part and just use Båstad Municipality (Q499464). That's what we commonly do in larger cities. Hjart (talk) 05:46, 23 May 2024 (UTC)

Thanks. I checked some out and found what you say to be the case. Most of the time, the "place" parameter is set to a specific part of the city, entirely within the correct municipality. It makes less sense in smaller cities and towns, though. A building in the outskirts of Ängelholm is propably more thought of as being located in the town of Ängelholm than in the Municipality of Båstad. I still think it would be better if the municipality given for this object would override the municipality given for the town object. But I guess we have to do with workarounds and omissions for now. Thank you for your advice on the matter. /Dcastor (talk) 07:07, 23 May 2024 (UTC)

@Dcastor A reasonable option could of course be to create a separate Ängelholm wikidata item for the part of the town wich is in the Municipality of Båstad. That of course makes things more complex, but works. Hjart (talk) 13:52, 23 May 2024 (UTC)

You should tweak the Wikidata items rather than removing the infobox – no, you shouldn’t mess up the data on Wikidata just because a random module can’t handle the fact that the reality is not always as simple as it expects. —Tacsipacsi (talk) 07:42, 24 May 2024 (UTC)

@Tacsipacsi This infobox is no longer a "random module". Hjart (talk) 15:49, 24 May 2024 (UTC)

Individual painting categories and title

When adding Category:Individual painting categories, the infobox could also add Template:Italic title with the title it knows. Enhancing999 (talk) 11:59, 23 May 2024 (UTC)

some cache issue?

Category:University of Wisconsin–Milwaukee alumni has a population for WD for 3 cats, though most populate in Category:Alumni of the University of Wisconsin-Milwaukee.

Cannot see an issue in the respective data, and I cannot get the cache to update University of Wisconsin–Milwaukee (Q1755318) and Category:University of Wisconsin–Milwaukee alumni (Q9653073). What am I missing?  — billinghurst sDrewth 22:10, 6 June 2024 (UTC)

Same problem with Cat:University of Wisconsin–Eau Claire alumni. It currently has two subcategories: Cat:Pat_Kreitlow and other. Even switching the item there didn't help: [7]. Enhancing999 (talk) 08:24, 7 June 2024 (UTC)

Did you check if the category is directly in wikicode? (if I understood problem correctly, the categories are coming from wikicode and not from wikidata infobox template) --Zache (talk) 08:39, 7 June 2024 (UTC)

For the sample Cat:Pat_Kreitlow, I think it comes from d:Q16195639#P69 → d:Q3551771#P3876 → d:Q8884928#P373. Enhancing999 (talk) 08:43, 7 June 2024 (UTC)

Actually no. good point. &ndash ; messed it up. Enhancing999 (talk) 08:45, 7 June 2024 (UTC)

Ouch. Now there is a fault that needs to be mentioned for HotCat to fix. It killed the +/- markers. <ugh>  — billinghurst sDrewth 01:28, 10 June 2024 (UTC)

Maybe Russbot could attempt some normalizations (such as this) in cases of "x found, 0 moved". Enhancing999 (talk) 08:50, 10 June 2024 (UTC)

source of categorisation

Commons:Village pump/Archive/2024/06#RFC: Automatic categorisation both bane and gain; work needed to identify source of categorisation

Flagging for your information.  — billinghurst sDrewth 01:25, 10 June 2024 (UTC)

See also Help talk:FastCCI#Not loading, showing offoptic images, and proposal for a forked gadget that shows the cat-path why a file is in cat which may solve this as well. Prototyperspective (talk) 10:23, 26 October 2024 (UTC)

@Billinghurst and Prototyperspective: Is this still an issue? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 12:51, 13 April 2025 (UTC)

Yes, it's still a very large issue causing all kinds of problems throughout the site such as breaking deepcategory views, flawed petscan results, and generally making it hard to spot and fix miscategorizations. I'm not sure how it relates to the infobox though. Prototyperspective (talk) 12:59, 13 April 2025 (UTC)

Enabling collapsed templates for multiple subcat columns

{{Edit request}} Could you please add a parameter for configuring the template to be auto-collapsed? E.g. |collapsed=y

This parameter could be deactivated again at a later point if there are some design/technical changes to MediaWiki that makes it possible to show multiple columns of subcategories even when there is a Wikidata Infobox.

Currently, it's often a problem that the template makes the page only show one columns of subcategories where it would be much more overseeable if there were multiple columns. In many of those cases, the Wikidata Infobox doesn't even add anything useful to the page. For an example, see Category:Videos of science where I removed the template which was subsequently restored by a bot. Prototyperspective (talk) 18:03, 13 June 2024 (UTC)

@Prototyperspective: This is partly already supported on a per-user basis, see 'Customisation' at Template:Wikidata Infobox. You should see multiple subcategory columns by default, though - looking at your example, I see three? The Infobox should appear on the right of the page to minimally disrupt the rest of the page content. Thanks. Mike Peel (talk) 21:29, 13 June 2024 (UTC)

I see just one column there and two columns when collapsing the infobox. Yes I'm aware it's possible for the 0.05% of reader that are both registered and for some reason came here and read the info on the page to configure the infobox to be collapsed whenever they use the site while logged in. This is about the default, displayed to all readers and users. Maybe there other readily implementable approaches such as making it show at the bottom of the page beneath the columns via some other parameter, a parameter to collapse just seems to be the easiest to implement and could be undone/replaced once there is something better. Prototyperspective (talk) 21:47, 13 June 2024 (UTC)

On the right is how it looks like with Wikidata Infobox and with collapsed wikidata infobox. --Prototyperspective (talk) 21:56, 13 June 2024 (UTC)

Another idea is to automatically hide WD infoboxes that are as empty as that one. One could also make it so that at least all that white space below the infobox is filled with another column by default but that would require some small UI changes and hence probably take very long. --Prototyperspective (talk) 23:16, 13 June 2024 (UTC)

Prototyperspective I agree that in Category:Videos of science wikidata infobox does not offer much, but in most categories I find them quite useful, and would not want one user viewing preferences to change it for everyone else. For example Category:Videos of science category shows for me in 2 columns, since I guess I have wider screen. So I would vote  Not done on this one. --Jarekt (talk) 22:52, 6 July 2024 (UTC)

Yes, even nearly empty WD-infoxes can be useful, e.g. by providing a quickly-accessible link to "statistics" (even though I doubt many users know about it / click it but I'll make a separate section about that below later).

Tracked in Phabricator
Task T369459

If I zoom out more, it also shows two columns on my side. The issue is more that the space below the infobox is not used by columns (or that may be a better alternative anyway if it is not to be moved to the left sidepanel altogether). Since it seems it won't get done here, I created a code issue asking for the space below infoboxes to by default be used for subcategory columns (linked on the right). I hope some developer can implement this relatively soon. Prototyperspective (talk) 14:35, 7 July 2024 (UTC)

Infobox on files

Interesting that it works: File:Font de la Mercè (Martorelles).jpg Enhancing999 (talk) 15:43, 9 August 2024 (UTC)

Yes, but it's not designed for file pages (layout etc.). I started working on something more suited for there at Template:Structured Data, but that was the early days of SDC, and I haven't found time to get back to it since. I normally recommend Template:Art photo at the moment, for good integration of Wikidata on file pages. Thanks. Mike Peel (talk) 16:11, 9 August 2024 (UTC)

Can it be changed so nothing is displayed? Enhancing999 (talk) 11:13, 10 August 2024 (UTC)

+1. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 12:53, 18 August 2024 (UTC)

Auto-collapse the Wikidata Infobox when browsing Commons on Mobile

Just to note the former phabricator ticket at phab:T199931 - we could implement this, but I'm not sure if it's needed. Thanks. Mike Peel (talk) 19:29, 21 August 2024 (UTC)

The category pages should be overhauled for mobile view (this is not limited to the infobox, parent categories are missing).

As Nokia is gone, I think most users would want to have more information displayed. Enhancing999 (talk) 21:37, 21 August 2024 (UTC)

I'm definitely in favor of having more information displayed. This would also resolve some issues that are currently discussed at Commons:Village pump#Coordinates and Commons:Village pump#Creator template. Nakonana (talk) 00:32, 18 September 2024 (UTC)

Uncategorized_categories,_except_infobox (see VP)

Please see Commons:Village_pump#Uncategorized_categories,_except_infobox
 ∞∞ Enhancing999 (talk) 11:31, 28 August 2024 (UTC)

This new report shows categories with no categories but an empty infobox (not linked to any Wikidata item). I think it (also) needs a report for Categories without any categories except metacategories like Category:Uses of Wikidata Infobox set by the Wikidata Infobox as requested here. Prototyperspective (talk) 12:54, 30 August 2024 (UTC)

Error: interwiki for "als:" inserted twice

See Category:Local elections in Baden-Württemberg: 2 identical interwiki links to als:Kategorie:Kommunalwahle z Bade-Wirttebärg. Same for numerous other categories using the Wikidata Infobox template. 2003:E5:3709:BF00:543D:2EBB:24B1:34DE 04:36, 10 September 2024 (UTC)

There are two problems:

• The infobox adds interlanguage links twice – both Alemannic and (standard) German appears both before the main infobox code and after it. I don’t know why this happens, but I hope this is easy to fix.
• The MediaWiki software deduplicates the German link, but not the Alemannic one – this bug probably has to do with the fact that als is a deprecated language code (the correct one is gsw).

Tacsipacsi (talk) 06:31, 12 September 2024 (UTC)

This has been fixed in the sandbox with Special:Diff/881886065, see this discussion. --LennardHofmann (talk) 18:04, 1 October 2024 (UTC)

I wouldn’t call it a fix: it works around phab:T350163, i.e. the second problem. And it doesn’t solve the first one at all. —Tacsipacsi (talk) 22:47, 6 October 2024 (UTC)

Inconsistent linking by category infobox

Internal links of the infobox when used on categories seem inconsistent. Sometimes links point to galleries, sometimes to categories. Logically, I'd expect categories to point to categories and galleries to galleries. Can this be fixed?
 ∞∞ Enhancing999 (talk) 16:01, 14 September 2024 (UTC)

Which "internal links" are you referring to? I think it depends on which WMC page is linked on the respective item. Prototyperspective (talk) 17:28, 14 September 2024 (UTC)

The problem seems to affect all internal links. Possibly it's getting worse lately.
 ∞∞ Enhancing999 (talk) 22:35, 14 September 2024 (UTC)

So you are requesting that when infoboxes are used on category pages, they should point to the Commons category even if a gallery is set in the Wikidata item under "Multilingual sites"? It's important people make things clear and consider what has been said, in this case "it depends on which WMC page is linked on the respective item". Prototyperspective (talk) 22:45, 14 September 2024 (UTC)

I don't understand the relevancy of your comments. Please chat somewhere else.
 ∞∞ Enhancing999 (talk) 23:46, 14 September 2024 (UTC)

I don't know if you have some issues that make it difficult to see the relevance and ignore my comment and continue to talk about other things instead of considering what I said but that could be the case. It's disrespectful and not constructive which makes me wonder why you even started this thread. Mike Peel just said the same and additionally proposed to keep it as is and using that to clean out of date/unnecessary galleries. Mike, I think there's too many of such galleries, one could start by deleting galleries with just one image but with wikidata item as I've proposed. Prototyperspective (talk) 10:51, 15 September 2024 (UTC)

The logic currently follows that at d:User:Mike Peel/Commons linking. If a gallery is sitelinked in the main item, that will be linked to first, otherwise it looks for the category link to use that. The ideal solution is that we have a good clean-out of old/unnecessary galleries... Thanks. Mike Peel (talk) 08:00, 15 September 2024 (UTC)

These are the technical details of the bot maintaining sitelinks at Wikidata, but within Commons categories what is displayed shouldn't depend on that.

When clicking on the location in the infobox of an object (building, statue, etc), this shouldn't be leading me to a (randomly maintained) gallery in some, but the actual location category in others. Within categories, consistency would be to link categories. Categories always include galleries as pages, so these are present anyways.
 ∞∞ Enhancing999 (talk) 11:20, 15 September 2024 (UTC)

 Support at least until only galleries that are of well-selected sufficiently high-quality are linked. within Commons categories what is displayed shouldn't depend on that the question is why: this shouldn't be leading me to a (randomly maintained) gallery in some, but the actual location category in others was the info/point missing and I agree with that. Within categories, consistency would be to link categories it would also be consistent if always the commons link set on the Wikidata item was linked, but galleries are quite often not of high quality and effectively hiding media about the subject that can be found through the category and its subcategories – e.g. many only contain one image or were only created by one editor and last updated a decade ago. Prototyperspective (talk) 11:31, 15 September 2024 (UTC)

There seem to be four ways to improve consistency of internal links on category infoboxes:

• 1. better align sitelinks on content items to categories at Commons
• 2. change code of infobox to determine a consistent link
• 3. use "Commons category" for internal links
• 4. improve item model at Wikidata to link Commons categories and galleries as sitelinks

(4) would probably need a lot of development by WMF and is unlikely to happen. (2) and (3) needs ome changes in the infobox code, one more than the other. (1) would need some changes at Wikidata.
 ∞∞ Enhancing999 (talk) 08:13, 18 September 2024 (UTC)

@Mike Peel which approach do you prefer? Do you need help implementing it?
 ∞∞ Enhancing999 (talk) 19:57, 27 September 2024 (UTC)

@Enhancing999: My vote would be to nuke all galleries, since I think categories are always better in practice. (1) doesn't work well with the general setup (see d:User:Mike Peel/Commons linking), (2) might be a possibility but needs someone with Lua expertise to implement, (3) if you mean Commons category (P373) then that should also just be deleted for reasons I extensively gave at d:Wikidata:Properties for deletion/P373. (4) is unlikely and also breaks d:User:Mike Peel/Commons linking. Thanks. Mike Peel (talk) 20:08, 27 September 2024 (UTC)

There is currently a discussion about that at Commons talk:Galleries#Galleries with only one image and Commons:Village pump/Proposals#Redirect undermaintained Species Galleries to Category pages. Prototyperspective (talk) 21:40, 28 September 2024 (UTC)

@Mike Peel: there is a need for some cleanup following the "species" discussion, wouldn't you want attempt to improve the model at Wikidata by opting for (4.)?

The discussion at Commons:Deletion requests/Marktgasse (Bern) leads to me to believe that some users creating new galleries might deliberately break category connections.
 ∞∞ Enhancing999 (talk) 12:52, 1 November 2024 (UTC)

Infobox should also show when only Commons category is set

See Category:SVG Translate – there the infobox doesn't show the item despite that the Wikidata item (d:Q105955520) does have the Commons category set in the Commons category property (it has the Commons help page set under Multilingual links). Could things please be changed so that the item also shows on such category pages if they are set in the Wikidata item? See also #Inconsistent linking by category infobox above. Prototyperspective (talk) 14:23, 18 September 2024 (UTC)

There are technical reasons why this cannot be done. So you have to create new item for the category, add the sitelink to commons, and then link from the other item using topic's main category (P910) — Martin (MSGJ · talk) 15:28, 18 September 2024 (UTC)

What would be the technical reasons? Since there already is the Commons cat set I think it must be possible somehow. If I'm wrong on that or it would require some changes at Wikidata that are unlikely to happen or to happen any time soon, could a script do what you described for all items that have a WMC category set but an empty infobox on WMC? Prototyperspective (talk) 23:06, 18 September 2024 (UTC)

In Scribunto-library there is no direct Lua function for fetching Wikidata id using property id and property value. So it would be need to be done using first fetching the P910 value and then use that for getting the correct entity using mw.wikibase.getEntityIdForTitle( 'Berlin' ) [8]. I don't have idea if it is tested if this is too slow to be used in large scale. -- Zache (talk) 09:21, 19 September 2024 (UTC)

Could a call for this particular property be made specifically in cases of uses of Wikidata infobox on WMC that are empty? I think that would be the optimal solution. Alternatively, some script/tool could show all items that have a WMC category set but an empty infobox on WMC and then (could be a separate tool/script) create new item for the category, add the sitelink to commons, and then link from the other item using topic's main category? Maybe some page on Wikidata is a better place to ask about this. Prototyperspective (talk) 11:18, 19 September 2024 (UTC)

@MSGJ: Did you use some script to move this link and if so is this issue solved? Prototyperspective (talk) 19:57, 19 September 2024 (UTC)

@MSGJ and Prototyperspective: Is this resolved? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 12:55, 13 April 2025 (UTC)

Automatic adding of "place of birth and death" categories

Hi

Regarding my request on Wikidata, please edit this infobox, so, whenever a value is allocated to Property P19 (place of birth) and Property P20 (place of death) in Wikidata, a category gets added to the category of the subject. Like "date of birth" and "date of death" properties, that add "Category:**** births" or "Category:**** deaths".

Cheers Shkuru Afshar (talk) 21:11, 21 September 2024 (UTC)

 Support Yes, please do this. Maybe some query should show all items with such cats set manually but not set in Wikidata so people can import them to there. Prototyperspective (talk) 22:18, 26 September 2024 (UTC)

@Harmonia Amanda: I'd appreciate your input here, if I remember right you were against this when the idea came up before? Thanks. Mike Peel (talk) 17:55, 27 September 2024 (UTC)

• This was discussed here: Template_talk:Wikidata_Infobox/Archive_5#Add "Births in" category?. Strakhov (talk) 12:37, 28 September 2024 (UTC)

  @Harmonia Amanda: What are the granularity problems you spoke of? I think it should also add redcategories and then either create these automatically or just leave them there as redcats. However, I think the much better alternative to scripts semi-manually importing these from Wikidata for syncing is to have them automatically added by the infobox as proposed here. It would only not work on WMC cats for which there is no Wikidata item but for people there's afaik few of these and one could have a script show all of these so WD items can be created. Prototyperspective (talk) 12:46, 28 September 2024 (UTC)

  Prototyperspective: I guess there are people that may think having "Category:Births in Casa Masó" is not appropiate (too granulated?), and they would prefer categorizing Category:Narcisa Fuster Cargol in a broader Category:Births in Girona" (already there). Imagine Category:Births in Birthplace Louis Pasteur (not in Wikidata yet, though). Those born-in-a-building cases would be solved not adding red links, but only already existing categories. Regards. Strakhov (talk) 16:42, 30 September 2024 (UTC)

  Makes sense but it doesn't contradict anything I said or what is asked for here. The solution would be to decide on and specify the level of granularity of the category the infobox sets.

  I propose it should set the Births in {country} cats when a {Births} in city cat does not exist or add both in such cases (one being a redcat). Nothing more granular than city would be set. If the Wikidata item has something more granular set as birthplace, it would set the parent city cat (and/or the country cat if that cat doesn't exist yet on WMC). Prototyperspective (talk) 16:51, 30 September 2024 (UTC)

  Maybe determining the "city level" (what's a city by the way?, because administrative territorial organisation is pretty heterogeneous around the world) is computationally expensive. Strakhov (talk) 19:31, 30 September 2024 (UTC)

  Item with instance of sth that is subclass of city. It isn't. Prototyperspective (talk) 21:04, 30 September 2024 (UTC)

  There are hundreds of items with a "Births in" category that are not instances of something that is a subclass of the item "Q515". I. e. every commune in France, every municipio in Spain, every comune in Italy, let alone provinces, regions, Q486972, Q3257686,.... It seems a pretty poor choice. IMHO taking this into account and searching through P131 is computationally more expensive (how much, the people doing maintenance in the template will say) than simply adding the category if it already exists and it's linked in properties such as P1464, which also does not have the problem of having to select a proper name for the categories in red (from the English label as with the surnames? ... uf: names of surnames and first names are unique in Wikidata, place names are not). Regards. Strakhov (talk) 18:43, 2 October 2024 (UTC)

  Alright, city may not be the term term and too narrow and I don't know if 'populated place' is better, e.g. it also shouldn't set villages. But why not keep it simple at first and just set city cats and later think about what to do with communes etc. If done right it would not be computationally expensive, it would be calculated once and then changed every time that property is changed for the WD item if ever. If the infobox doesn't set it then a script could sync the wikidata to WMC and vice versa by adding a category or a wikidata property value. I care more about it being automatically in sync than the details of how. Prototyperspective (talk) 21:25, 2 October 2024 (UTC)

  But hey, if people here design a Wikidata infobox that properly add red-births-deaths-in-categories for populated-places-that-are-not-a-instance-of-a-building-or-so, and if so search through P131 until reaching the proper "populated place" item (or "city" item, or...), and properly disambiguate them too when they are called the same, congratulations. Hooray. Strakhov (talk) 18:52, 2 October 2024 (UTC)

  Would it not be simpler to have the infobox follow the person's P19/P131 tree until it finds an existing "Births in" category? Trying to do anything beyond that just doesn't really make sense, I wouldn't think. KISS principle and all. — Huntster (t @ c) 02:59, 3 October 2024 (UTC)

Displaying "Also known as" names from Wikidata

Is there a way to be able to display the "Also known as" names from Wikidata in the infobox? This is especially useful for Commons categories that currently use the short or colloquial/informal name. For example, Guiuan Church is officially known as "Immaculate Conception Parish Church", but this vital information is not displayed in the Wikidata infobox. Sanglahi86 (talk) 09:53, 26 October 2024 (UTC)

Infobox width too large

Please fix Category:Universe, probably by making numbers have linebreaks. Prototyperspective (talk) 16:32, 5 November 2024 (UTC)

Please fix this, thanks. Prototyperspective (talk) 10:57, 13 November 2025 (UTC)

Misleading country

The infobox on Category:Santorini gives "Aegean Sea, Turkey" as its location. I guess the infobox only takes the second value Turkey (Q43), not the first one from Aegean Sea (Q34575) country (P17) Greece (Q41). The result is pretty misleading and the infobox should probably take all values of country (P17) statements into account. Best, --Marsupium (talk) 18:31, 13 November 2024 (UTC)

The problem is that for some reason the template prefers (vague) location (P276) P1 to (clearly defined) located in the administrative territorial entity (P131). In location (P276) the Aegean Sea (Q34575) was filled in, which then had two country (P17) values, of which the template for some reason chose Turkey (Q43). Both are rather strange behaviours. But as the Aegean Sea (Q34575) is already filled in located in or next to body of water (P206), I just deleted the excess vague location (P276). Jklamo (talk) 08:58, 28 November 2024 (UTC)

I agree to your analysis. Your change fixes this specific case here on Commons, but not the underlying problem of the template. I hope we can fix it!? --Marsupium (talk) 17:22, 28 November 2024 (UTC)

I had checked a few other bodies of water, but they didn't seem to have an issue.
 ∞∞ Enhancing999 (talk) 13:38, 5 December 2024 (UTC)

getLabel function ignores P1448 (official name)+P585 (point in time)

In cases of e.g. football matches, where it may be required to display different team name than its label (if the team was renamed after the match), it would be very beneficial if the module could pick up values from P1448 statement (e.g. in the case of football matches, when getLabel is called on values of P1923 (participating team) or P1346 (winner), the time for P1448 can be extracted from P585 statement on the match). Well very well (talk) 11:02, 5 December 2024 (UTC)

For an example, see Category:2021 Ukrainian Women's Cup Final. Mitte27 (talk) 11:13, 5 December 2024 (UTC)

Not sure if this can be resolved easily.

I guess an another argument could be made that the label should be the category name at Commons and not the label from Wikidata. But this would be a different issue.
 ∞∞ Enhancing999 (talk) 13:40, 5 December 2024 (UTC)

Request to add several fields to the infobox

Hello @Mike Peel and others who work on this infobox (much appreciated!). Would it be possible to add the following "fields" to the infobox so that the data from Wikidata appears there? I am actively working on those topics, adding lots of referenced statements to Wikidata:

• designed by (P287)
• has works in the collection (P6379) (this list can become long, so an option to make this collapsible would be good)
• archives at (P485)

Categories to test the appearance of these fields include: Piet Zwart; Bruynzeel kitchen (Piet Zwart, Kunstmuseum Den Haag). Thank you! Spinster (talk) 19:50, 21 February 2025 (UTC)

I've added designed by (P287) to the sandbox but I'm hesitant to add more properties to infoboxes on categories about humans as those infoboxes tend to be very crowded already. LennardHofmann (talk) 15:52, 27 March 2025 (UTC)

Hello @LennardHofmann and @Mike Peel, thanks! Is there anything I can do to help further this?

I would still like to argue for also including has works in the collection (P6379) and archives at (P485). They can be made collapsible. This data IMO fits the purpose of Wikimedia Commons quite well, as Wikimedia Commons contains many images / files that were uploaded from collections and archives. In addition, it is data that is rarely shown in other Wikimedia projects (sometimes incompletely on Wikipedias, but it's spotty). I must also say that the kind of people I usually edit on Commons usually don't have very crowded infoboxes at all; on the contrary (e.g. women, less known artists), and showing where to find more resources of them is very useful there IMO. Thank you! Spinster (talk) 16:24, 19 April 2025 (UTC)

I'm inclined to agree with @Spinster: that it's worth adding these. Are there good examples where we could test cases of a few and many uses to figure out the collapsible point? Thanks. Mike Peel (talk) 18:53, 19 April 2025 (UTC)

Hi @Mike Peel. Testing categories - how about these (see Tabernacle list to pick a larger sample to test with):

• has works in the collection (P6379) lots (10+) Category:W.H. Auden
• has works in the collection (P6379) medium (5+) Category:Edgar Brandt
• has works in the collection (P6379) few (less than 3) Category:Marthe Abran
• archives at (P485) lots (it's very rare to have many here) Category:Angelique Rockas
• archives at (P485) medium Category:Ted Hughes
• archives at (P485) few Category:Enzo Mari

Thanks! SFauconnier (talk) 18:59, 29 May 2025 (UTC)

Logo automatic scheme selection

With the new light-on-dark color scheme is it possible that this template select which logo/image view based on actual color scheme mode?

On Wikidata side the logo image (P154) (but also maybe for other image properties) could be filled with two (also more, but for two images only the preferred rank will not be necessary for selection) different images. Each of them will have the for color scheme (P8798) attribute compiled with dark-on-light color scheme (Q101608434) and light-on-dark color scheme (Q6545942) values. -- ZandDev (talk) 18:47, 24 February 2025 (UTC)

@ZandDev: Potentially yes, but I think you'd need to establish consensus/a common approach to this on Wikidata first, then if it's widely used we could incorporate it here. Thanks. Mike Peel (talk) 18:42, 19 April 2025 (UTC)

It’s a bit tricky, but should be doable (once there’s an established convention on Wikidata for marking them up): the output of the infobox (HTML) cannot change based on the color scheme, but the infobox can output both logos, and then Template:Wikidata Infobox/styles.css (which does have access to the color scheme) can hide the wrong one. —Tacsipacsi (talk) 20:37, 2 May 2025 (UTC)

@Mike Peel: I see no relevant changes either in Module:Wikidata Infobox or in Template:Wikidata Infobox/styles.css, so I suspect nothing has been resolved here. —Tacsipacsi (talk) 21:45, 28 September 2025 (UTC)

@Mike Peel, @Tacsipacsi This would indeed be a nice addition, particularly in cases where the default logo is entirely white. --Iketsi (talk) 13:42, 20 November 2025 (UTC)

Is there a consensus on Wikidata yet about how this is being implemented? The infobox changes would follow after that. Thanks. Mike Peel (talk) 13:48, 20 November 2025 (UTC)

X of birth

Is there a reason this infobox groups Date of birth, Place of birth, and birth name in one line labelled "Date of birth"? It fits for the first item, but not the rest. If the aim is to have everything about birth combined, even "Birth" would be better. CMD (talk) 06:00, 4 May 2025 (UTC)

Placement: At the top of the page

I must come back to this topic, discussed already once here [9]. There is still the problem, that for humans (for other non-living things it is not really relevant, because there are mostly generated by the infobox also useful categories) there appear relatively useless (often also red - uncreated) categories as first category (example Category:David Sossenheimer, where the "red" category Sossenheimer is listed first). That the infobox must appear on the top of the viewable page is fine, but that the wikidata infobox template puts the most unuseful categories as first ones (for humans) - this is really unhelpful for everybody (as well as readers as well as contributors). The mentioned white space I never seen, when the template was put as last line after the manually added categories. So my wish is, to add in the documentation to the 2018 added line Placement: At the top of the page something like: If no page disturbance occur, a placement after the manually added categories is also possible for humans to have the categories ordered by a better relevance. Florentyna (talk) 06:16, 8 May 2025 (UTC)

I think category sorting on Commons currently is very trivial and basically nearly nobody takes any care to sort them in any particular way. Many may read the categories starting at the last category first. Instead, something to consider would be whether categories like Category:David (given name) should be hidden categories. There could also be some technical development to enable categories to be grouped in useful ways (relevant link). Prototyperspective (talk) 11:22, 8 May 2025 (UTC)

P131 display problem, infobox behaviour changed?

1. Please see Category:Swayambhu Sri Abhista Gnana Ganapathi Temple. When using the default Commons interface (English), the location is only given as "KUR", which is of no use (no higher administrative entities, no country, and not even linked).
2. Then see Swayambhu Sri Abhista Gnana Ganapathi Temple (Q48727304). The country is correctly set (P17 = India), as well is the administrative location (P131 = Kurnool district).
3. I expect the infobox to display the temple's location as "Kurnool district, Andhra Pradesh, India".
4. Now see Kurnool district (Q15381). It seems "KUR" is fetched from the short name statement there (P1318), instead of using the full district name from the label field. Multiple P131 statements there should make no problem, because the currently valid value (Andhra Pradesh) is set with preferred rank. Commons gallery/category links are present in all known ways (sitelink, P373, and via P910).
5. I can't find a structural difference e.g. to Category:Konetirayala Temple, Keelapatla (location in infobox as expected), and to the respective Wikidata items (district also with short name statement, multiple P131 statements with Andhra Pradesh preferred).

So where are the problems? And how could they be fixed? 2003:E5:3728:FE00:95BD:C9FE:42F3:B839 03:35, 10 May 2025 (UTC)

Perhaps because Kurnool district (Q15381) short name (P1813) KUR, with no name property defined? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 18:09, 10 May 2025 (UTC)

Thanks for the idea, but I don't think so, see the above example at 5., where the infobox works as expected, with Chittoor district (Q15213) short name (P1813) CHI, also no name property defined. 2003:E5:3728:FE00:1004:233F:7B6F:6F72 19:52, 10 May 2025 (UTC)

Same/similar problem at Category:Ranbirpura (location = Patiala tehsil, PTL – instead of Patiala tehsil, Patiala district, Punjab, India). 2003:E5:371B:4B00:70AB:D371:DBC7:A7F8 00:06, 19 May 2025 (UTC)

Bridges

It seems that if the bridge WD has both structural engineer (P631) and architect (P84) in place, the template displays architect alone. Doesn't look right. Architect's role is secondary at best, all important design choices are made by the lead engineer. Retired electrician (talk) 11:34, 19 May 2025 (UTC)

Lua error

Hi, Category:Pedro María Egea Bruno, which we already discussed here, still or again has a lua error. Jarekt (talk) 16:44, 19 May 2025 (UTC)

Fixed. (By removing all statements with invalid values) --Tkarcher (talk) 07:31, 20 May 2025 (UTC)

Tkarcher, adding start time (P580)/end time (P582) qualifiers to statements with "unknown value" is not invalid. For example an artwork might have an owned by (P127) statement to indicate that in the past it was owned by someone. Adding end time (P582) qualifier with "unknown value" means that it is no longer owned by that person, but we do not know the year when that ownership ended. Those qualifiers are quite standard and should not be removed in order to "fix" limitations of out software. @LennardHofmann and Mike Peel: can you alter the code so it does not crash in case of start time (P580)/end time (P582) qualifiers with "unknown value"? --Jarekt (talk) 12:20, 22 May 2025 (UTC)

It is broken for the third time. Please fix. --Jarekt (talk) 12:27, 5 June 2025 (UTC)

I commented out still broken {{Wikidata Infobox}} template. --Jarekt (talk) 14:17, 11 July 2025 (UTC)

This is not a correct fix: the template should be there, but the Wikidata module is still wrong in these lines:

                   if k1 == "P1326" then
                        local ts = v1[1].datavalue.value.time
                        local dp = v1[1].datavalue.value.precision
                        qlist[k1] = dateFormat(ts, dp, args.qdf, args.bc, pd, "", lang, "before")
                    elseif k1 == "P1319" then
                        local ts = v1[1].datavalue.value.time
                        local dp = v1[1].datavalue.value.precision
                        qlist[k1] = dateFormat(ts, dp, args.qdf, args.bc, pd, "", lang, "after")

because they assume that the presence of a P1326 or P1219 qualifier implies that there's an effective date specified for them, and there's no test for the possiblity of "unknown value" there; here we get a nil value for "datavalue", so "datavalue.time" (and "data.value.precision") throws the fatal error. The module still needs a fix there to format the statement correctly. Changing the category page to hide its infobox is definitely not a solution; and dropping statements in Wikidata gives a false information for a statement that was valid after some date but has been terminated (at unknown date here; it may be confirmed by another statement, such as the fact that there's a new owner of an object, with including with references, but no reference for the previous owner which remains unknown; such case occurs frequently for artworks or buildings that are owned by various people over time without knowing completely the complete history of successive owners, only a few "famous" ones...). verdy_p (talk) 05:26, 23 September 2025 (UTC)

Note that rather using an "unknown value" for such history, there' should be at least an estimation and the starting/ending date, even if it is just a decennial with a "circa" qualifier; this is allows correct partial ordering of events by date, where there are possible partial overlaps between them due to lack of precision. The "unknown value" for such dates introduces a too large overlap when there are known dates when the overlap is no longer valid. verdy_p (talk) 05:50, 23 September 2025 (UTC)

Category:Uses of Wikidata Infobox topic missing Commons Category statement

We have Category:Uses of Wikidata Infobox missing Commons Category statement for when the connected item doesn't have Commons category (P373) on it. We also have cases like Category:Rap rock which link to a category item (Category:Rap rock (Q7215169)) which links to the actual topic (rap rock (Q877693)). In this case the topic is missing Commons category (P373). I see about 25.000 items currently to fix (https://w.wiki/ESMy ). Adding a tracking category is more stable than a SPARQL query (which tends to time out). Multichill (talk) 18:18, 10 June 2025 (UTC)

smarter recursion handling

Hi, stumbled across Infobox in Category:Flattnitzbach-Hochmoor, with multiple entries of location (P276) of Flattnitz (Q875523) and Flattnitzer Höhe (Q21874151). The underlying data problem is that both items are referring to each other via location (P276) (I leave it that way for now to keep the test case). Can you skip such recursions when the first repetition pops up? best --Herzi Pinki (talk) 22:17, 20 August 2025 (UTC)

WIkidata Infobox question

For Category:Canalul Mila 35, is there any way we can prevent the Wikidata Infobox from falsely saying that the canal is in the Ukrainian portion of the Danube Delta? Danube Delta (Q184429) accurately states that the Delta is partly in Tulcea County, Romania and partly in Izmail Raion, Ukraine. Canalul Mila 35 is entirely in the Romanian part (it ends right at the border). I gather that when we have "applies to part", {{Wikidata Infobox}} arbitrarily picks the earlier addition to the Wikidata item. In this case, that is dead wrong. Is there any way to override this? It's very misleading. This can't be the only time something like this comes up. - Jmabel ! talk 02:51, 30 August 2025 (UTC)

@Jmabel: I've moved this question from my user talk page to the Infobox talk page in case others have ideas here, hope that's OK. Thanks. Mike Peel (talk) 19:01, 30 August 2025 (UTC)

Preferred value of P131 not being prioritized

Hello, sorry if this has already been addressed. There are instances where a building (such as Saint Anthony the Great church (Q89334407)) is located in a different administrative territorial entity than it was before, because municipalities have merged (or other reasons I guess); in this case located in the administrative territorial entity (P131) property on 'data may have two values for both the municipalities, the current one being flagged as "preferred" (and with end time (P582) and start time (P580)). This however doesn't seem to be picked up by the infobox, which still lists both the old and the new municipality, followed by the country; see Category:Sant'Antonio Abate (Alano di Piave, Setteville) (here an example of how it should look instead). Can this be fixed? Syrio posso aiutare? 10:42, 1 September 2025 (UTC)

@Syrio: The infobox already shows best statements only. The unwanted "Alano di Piave" value is taken from location (P276) instead. You probably want to remove that statement. LennardHofmann (talk) 07:19, 2 September 2025 (UTC)

@LennardHofmann: I did a couple of checks and you are partially correct. The "Alano di Piave" is indeed taken from location (P276) but it is not unwanted; however the infobox should list the place as "village, municipality, province, region, country", like it does in Category:San Bartolomeo (Lamen, Feltre), where "Lamen" is P276 and "Feltre" is P131. What I think it's happening is that the infobox has troubles interpreting the data when there are two values of located in the administrative territorial entity (P131), even if one of them is preferred (like Category:Sant'Antonio Abate (Alano di Piave, Setteville) or Category:Sant'Ulderico (Campo, Setteville)) or deprecated (like in Category:Castello di Quero). -- Syrio posso aiutare? 08:01, 2 September 2025 (UTC)

PS: it has nothing to do with location (P276), because there's the same problem with Category:Sappada VS, say, Category:Osoppo.

Isn't there anyone that can take a look at this issue? -- Syrio posso aiutare? 12:33, 15 September 2025 (UTC)

Area displayed in the map

Hello everyone, what is the rationial behind that for Category:Schloss Gebesee it shows the area in the map while in Category:Wasserburg Markvippach it is not shown although the connected Wikidata item has the property "OpenStreetMap way ID". Where does the info come for the first case? Thank you, --Arnd 🇺🇦 (talk) 08:37, 1 October 2025 (UTC)

@Aschroet: I think this is because Schloss Gebesee (OSM way 204248799) is tagged with wikidata:Q19308648 while Wasserburg (way 510129982) is not (you can click the OpenStreetMap link at the bottom of the Wasserburg infobox to see that OSM does not link to Water castle Markvippach (Q136032443)). The infobox simply gives the Wikidata Qid of the Commons category to Kartographer and asks it to display the geoshape from OSM, which is only possible if OSM links to the given Qid. The presence of OpenStreetMap way ID (P10689) does not matter at all. LennardHofmann (talk) 09:38, 1 October 2025 (UTC)

Lua error

Lua error at Category:Toy Story. Jarekt (talk) 03:07, 22 October 2025 (UTC)

Fixed somehow --Jarekt (talk) 03:05, 26 October 2025 (UTC)

Another error at Category:Futari wa Pretty Cure --Jarekt (talk) 03:05, 26 October 2025 (UTC)

Fixed too by deleting on Wikidata links to deleted items. This code should be able to survive that. --Jarekt (talk) 03:11, 26 October 2025 (UTC)

Auto-setting cats for people by birth & death year BCE

@LennardHofmann: Could you (or somebody else who can) please edit the template so that categories about people with a Wikidata item automatically get a category for birth years that are before 0 BCE?

• So far, there are only two categories for such at Category:Births by year and those years shouldn't be set by hand when the data is already in Wikidata and when that has been used for all years 0+.
• People may need to go through the years though and create the categories since it would only add redcategories. A tool that iterates through categories and creates those which have at least one file or subcategory would be very useful here – please comment if there is a tool/script/bot for this. (If nobody here knows, I'll probably pass it on to the Bot task requests board.)
• Context: I noticed the lack of this autocategorization after my template edit request about {{Birthcat}} at the new page Commons:Template requests was implemented here.
• For a concrete example: Category:Tutankhamun should be put into Category:1341 BCE births per d:Q12154#P569. This example is a special case since the birth year has a qualifier for circa – it would be even better if something special was done for those items with that qualifier but for now I don't think it's important to implement (just something to keep in mind or to implement if you can think of a readily implementable way).

Prototyperspective (talk) 13:45, 3 November 2025 (UTC)

Do not display duplicate images

Would it be possible that if an image is set multiple times, it only displays it once? This is most useful for people who have the Show all option enabled in the Wikidata infobox. So far, I think more or less this only happens for logo image (P154) & icon (P2910)

Background: For many items, the logo is also the icon. Setting both is useful and should be done rather more often because sometimes logos are also the icons (like app icons on a phone) and sometimes they are wide banner-like logos as for example with d:Q19718090#P154 and d:Q50938515#P154. If one would then query with logic get icon, and if no icon set get the logo that would result in mixed data of both these small more or less rectangular icons and other types of logos. When using that in a table column for example it would make the column much wider and having varying images in the column. For an example in practice, see d:Wikidata:List of free software accounts on Mastodon – the icon is used and useful there.

An alternative to checking whether the same image is set for logo and icon would be to always just show one of them if they're both set. Prototyperspective (talk) 00:22, 22 November 2025 (UTC)

If we weren't on Commons, then I'd agree with you. However, part of the point of the Infobox is to show what media content is and isn't available on Wikidata, to encourage Commons editors to improve it. In this case I think it's useful to show the duplicate images, so Commons users can see if there are (or could be) more suitable ones available that could be used in place of one or both of them. Thanks. Mike Peel (talk) 06:34, 22 November 2025 (UTC)

Synonym

Can we have "qid="and "wikidata=" both work in this template? For instance the Creator template uses "wikidata=". That way a bot will catch both types of usage. RAN (talk) 00:50, 22 November 2025 (UTC)

Certainly technically easy: just replace {{#invoke:WikidataIB |getQid |qid={{{qid|}}} }} with {{#invoke:WikidataIB |getQid |qid={{{qid|{{{wikidata|}}}}}} }}. But I wonder: does the qid parameter even get used much? Overwhelmingly, I see this template used without parameters, or where the qid is present but redundant. - Jmabel ! talk 01:42, 22 November 2025 (UTC)

That's a good catch. Ideally the manual QIDs should never need setting, as we should have the sitelinks, however people do seem to use them for ease of editing. The bot scripts actually already support both qid and wikidata - if you use either then they will be auto-linked to Wikidata where possible and the manual parameter removed - but the template currently doesn't. Thanks. Mike Peel (talk) 06:39, 22 November 2025 (UTC)

• Also "Wikidata=" {{Wikidata infobox|Wikidata=Q89107202}}. Can we search to see how many use "Wikidata=" and "wikidata=" so they can me converted to "qid=". --RAN (talk) 17:06, 10 January 2026 (UTC)

  My Pywikibot script params_all.py can list all parameters a template is used with, including |Wikidata=, |wikidata= and anything else people have come up with. However, it’s not heavily optimized, and it would likely take ages to run it over the 6.5 million pages transcluding the template. (I’ve so far used it on templates with up to a few tens of thousands of transclusions as far as I remember.) If someone has enough computing capacity (and preferably a dump, to avoid bringing down the servers), they may give it a try though. —Tacsipacsi (talk) 16:13, 11 January 2026 (UTC)

It would be better to update the Creator template to use |qid=. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 12:37, 12 January 2026 (UTC)

Atlanta multi-county P131 handling in Wikidata Infobox leads to county misidentification

The problem

• Many Atlanta items only have P131 = Atlanta.
• Atlanta’s own P131 includes both Fulton and DeKalb, so {{Wikidata Infobox}} ends up displaying DeKalb even when the subject is entirely in Fulton.

Desired global behavior in Module:Wikidata Infobox

• If an item itself has a county-level P131 (e.g. “Fulton County”), prefer and display that.
• If it does not, and the city (Atlanta) spans multiple counties, then skip showing a county at all instead of guessing or inheriting from the city’s mixed P131

Example: Ebenezer Baptist Church

• Wikidata item: Ebenezer Baptist Church (Q77240068)
• Commons category: Ebenezer Baptist Church, Atlanta
• Notice that the Infobox displays location as Atlanta, DeKalb County even though the item is located entirely in Fulton, County.

Workaround

• The location can be corrected by explicitly adding Fulton County to Atlanta as an "administrative territory" where appropriate.
• This is inadequate not only because of the large number of current "Atlanta" items involved whose Infoboxes display DeKalb County erroneously, but also because new additions indicating Atlanta as the sole administrative territory will induce similar errors, at least for items lying entirely in Fulton County.

Marc Merlin (talk) 22:15, 24 November 2025 (UTC)

Organisations based in location

Could the infobox set these categories? For example, Farm Transparency Project (Q136786233) has instance of (P31):nonprofit organization (Q163740) and country (P17):Australia (Q408) set which could be used to set Category:Non-profit organizations based in Australia. Properties location (P276) headquarters location (P159) could also be used. Moreover, the year in inception (P571) could be used to set a cat like Category:Organizations established in 2014.

Asking about organization data because, unlike e.g. novels, there's categories for lots of organizations with lots of media in them AND Wikidata for the organization items that it does have, has quite good data in many cases. The latter in part due to work by User:NGOgo who may be interested in this. Prototyperspective (talk) 18:23, 25 November 2025 (UTC)

Please add P7937 (form of creative work)

Some years ago (2000 to be precise) all opera items have been moved from instance of (P31) opera (Q1344) to dramatico-musical work (Q58483083) with the additional property form of creative work (P7937) opera (Q1344) (example). The latter is still missing from the infobox. It would be nice if it could be added. --Rodomonte (talk) 09:27, 2 December 2025 (UTC)

@Rodomonte: this project didn't exist in 2000. What did you mean to write? - Jmabel ! talk 19:15, 2 December 2025 (UTC)

Sorry, of course I meant 2020 as in the example. --Rodomonte (talk) 22:42, 2 December 2025 (UTC)

@Rodomonte: I don't think displaying form of creative work (P7937) is necessary as the short description will most likely mention the type of work. For a similar reason, we don't display instance of (P31) human (Q5) on Douglas Adams as this is obvious from context. Is there a specific reason you want this to be displayed? LennardHofmann (talk) 16:11, 3 December 2025 (UTC)

Well, the type of work was displayed before, but now it isn't any more. But you are right. In most cases it is also part of the description. --Rodomonte (talk) 18:54, 3 December 2025 (UTC)

The description may not be available in all item and/or all languages. It might be better to show form of creative work (P7937) instead of the abstract instance of (P31) dramatico-musical work (Q58483083) in this case. So users get see the same information as before the change. --Rodomonte (talk) 08:08, 4 December 2025 (UTC)

There is even a bot which moves related Properties from instance of (P31) to form of creative work (P7937): [10]. This should really be reflected here. --Rodomonte (talk) 08:26, 5 December 2025 (UTC)

Exempt Wikidata Infobox images from mediaviewer

When browsing category images with the media viewer, it includes the images embedded in the wikidata infobox. This results either in some images appearing twice, or unrelated-to-category content in the viewer; for example if a category combines different topics and the WikidataIB has media with regard to the individual topics.

Example: Category:Ponds in Baden-Württemberg – the media viewer should show the category media on topic 'ponds in Baden Württemberg', but it will also show the parliament, coats of arms image, etc. of Baden Württemberg, because these are part of the Wikidata Infobox therein.

Fixing this is simple as a css class noviewer already exists to exempt images from being shown in the mediaviewer. The proposed patch below should be applied at Module:Wikidata Infobox. In result, the images in the infobox will not open in the mediaviewer, clicking them will rather open the resp. file description page. (which means that the image in the infobox will still be accessible in full resolution, just not by means of the mediaviewer on the cat page)

{{Edit request}}

@@ -2181,7 +2181,7 @@
 
 	if file then
 		local panoramalink = (pid == 'P4640') and '|link=https://panoviewer.toolforge.org/#'..mw.uri.encode(file, 'WIKI') or ''
-		local img = '<span class="wpImageAnnotatorControl wpImageAnnotatorCaptionOff">[[File:'..file..'|'..config.imagesize..panoramalink..']]</span>' -- equivalent to {{ImageNoteControl | caption=off | type=inline}}
+		local img = '<span class="wpImageAnnotatorControl wpImageAnnotatorCaptionOff">[[File:'..file..'|'..config.imagesize..panoramalink..'|class=noviewer]]</span>' -- equivalent to {{ImageNoteControl | caption=off | type=inline}}
 
 		local captionPrefix = ''
 		if pid == 'P10' then -- video

~2025-36610-11 (talk) 08:43, 3 December 2025 (UTC)

I like being able to view the infobox images in MediaViewer. Yes, it often makes the image appear twice, but in larger categories, one would have to hunt down the other instance. Or it’s not even directly there, e.g. Category:Baden-Württemberg doesn’t directly contain any of the images in the infobox. I’d instead question the value of repeating information from Category:Baden-Württemberg on Category:Ponds in Baden-Württemberg – the category combines topics (P971) row of the infobox already directly links to Category:Baden-Württemberg, information on the state itself is just one click away. If this repetition was removed, the images would only appear in categories where they are relevant (and thus would also appear in MediaViewer only there).

Given that there are now two quite different opinions in this thread, I’m disabling the edit request for now. —Tacsipacsi (talk) 12:58, 6 December 2025 (UTC)

Showing aliases

Could you please make the infobox also show the connected item's aliases?

This would make it

• easier to understand the concept and help disambiguate, especially if some people only understand or know the concept under a different term or if there's slight difference in focus/scope/emphasis per term
• increase views of useful category pages which include the Wikidata infobox
• provide somewhat of a substitute for the usually absent category description (usually these are not needed because of the category title + infobox)
• make categories easier to find within Commons
• make categories easier to find from Web search engine like Google

For example, instead of editing the new Category:Doctor's visit to add the terms "medical consultation" and "consultation", the infobox should show the aliases. Currently it shows "medical visit" while the English Wikipedia article is called "Doctor's visit" (it's debatable which is better or more fitting/appropriate). Prototyperspective (talk) 17:46, 4 December 2025 (UTC)

Note that the aliases are already hidden inside the Commons page source using HTML comments (which are indexed by Special:Search). I would like to hear other people's thought about this before showing aliases in the infobox. LennardHofmann (talk) 19:02, 4 December 2025 (UTC)

This would need to cater for the few extreme cases with dozens or hundreds of aliases. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 12:35, 12 January 2026 (UTC)

Good point – I suggest the solution of just showing the first 5 aliases if there are more than 6. One could also include all inside a collapsed template that one first needs to click to expand – I think that would be the ideal solution but that may be better to implement later on after first showing up to a certain number of aliases. Prototyperspective (talk) 17:17, 12 January 2026 (UTC)

Inscriptions (P1684) for commemorative plaques

It would be useful to show inscriptions for commemorative plaques. Long texts could be truncated with the option to expand. C1614 (talk) 21:25, 4 December 2025 (UTC)

@C1614: Even in the absence of SDC support, you are always welcome to add these either through an image annotation or in the description. We have {{Inscription}} for this purpose. There is also some additional relevant apparatus under Category:Inscription templates. Or you can use a more informal approach with ImageNotes, as I did at File:Seattle - work in progress building 2nd Avenue South Extension looking southeast from 2nd and Yesler, 1928 (40028879095).jpg (though those are signs, not plaques).

Structured data is nice, but since these are text, anyway, these Wikitext approaches should work equally well for almost all purposes. - Jmabel ! talk 21:58, 4 December 2025 (UTC)

Thanks. Pulling the inscription directly from Wikidata to a plaque's category page would be useful for when there are several images of a plaque.

In the meantime, it would be simple enough to copy and paste the text into the category page. Adding the Inscription template to each file would be a bit more time consuming. C1614 (talk) 22:08, 4 December 2025 (UTC)

Yes. Sorry, I wasn't thinking so much in terms of the plaque itself having a category, I was thinking SDC rather than infobox, my apologies. I'm not sure if doing this in an automated way with infobox is a uniformly good thing (the text can be awfully long for the infobox), but it is probably worth considering. - Jmabel ! talk 00:31, 5 December 2025 (UTC)

Unit of measurements missing

In the Infobox is the amount of Powerplants shown but not a unit of measurement - e.g. Category:Kárahnjúkar Hydropower Plant 690 is shown whithout more, so the Megawatt or only MW would be helpfull in the box. Perhaps is possible to add this. thx -- K@rl (talk) Diskussion 14:31, 12 December 2025 (UTC)

@Karl Gruber: I don't see this problem. It says "Nominal power output: 690 megawatt" in English and "Installierte Leistung: 690 Megawatt" in German. Can you check again? LennardHofmann (talk) 12:39, 15 December 2025 (UTC)

@LennardHofmann: Ah sorry, in German it's also showing, but not in the Austrian German (this is my choice usual ;-) ---- K@rl (talk) Diskussion 13:34, 15 December 2025 (UTC)

NS: Also the other missing words are not including so not the german description will shown, but the english. ---- K@rl (talk) Diskussion 13:37, 15 December 2025 (UTC)

Moin K@rl, magst du bitte nochmals schauen? Danke --Crazy1880 (talk) 18:14, 15 December 2025 (UTC)

Hallo @Crazy1880: , danke jetzt funkts, super - lg -- K@rl (talk) Diskussion 19:16, 15 December 2025 (UTC)

Lua error (again)

Category:Videos from Polissons et galipettes has lua errors, possibly due to original language of film or TV show (P364) = novalue to signify silent movie in The Good Old Naughty Days (Q779598). Jarekt (talk) 14:04, 17 February 2026 (UTC)