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.

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)[reply]

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

@Mike Peel and Tacsipacsi: You want every single piece of text returned from WikidataIB for every call to be wrapped in <bdo lang="LANG" dir="DIR">...</bdo>? Wouldn't that make a mess of the way we auto-generate categories? Also, don't you think that will give the Wikidata-haters great ammunition to scrap the use of the module on enwp? Or am I going to have to start maintaining two different versions of the module?

I have a couple of alternative suggestions:

Use a template (similar to {{Wdib}}) to add the markup to WikidataIB's output. This has the advantage that the template can have language and direction hard-coded when exported to single-language wikis.
Write a module that calls WikidataIB, simply passing the calls and parameters to it, then wrapping the text returned in the desired markup and then returning it to the calling page.

Can you see any other solutions? --RexxS (talk) 19:54, 24 April 2020 (UTC)[reply]

@RexxS: Good points. I don't think a wrapper would work, as WikidataIB may return multiple languages for a single call (e.g., if it's returning the labels from 4 items for a property, and 2 of them are available in Arabic, but the other 2 have fallen back to English, so they need different markup). If it can't be done by default, I'd suggest adding an optional parameter... Thanks. Mike Peel (talk) 20:02, 24 April 2020 (UTC)[reply]

There's a more important point to lok at than considering the way hyphenation is performed for line wraps: look at labels shown in mixed language and notably those that may contain parts in parentheses or other punctuation or mirrorable characters: if you don't embed each translated label into a <bdi>...</bdi> element, the punctuation will go to various places or will be incorrectly mirrored and parts of the label may be separated by other unrelated items anywhere elsewhere in the list of items.

And please, don't use the deprecated <bdo>...</bdo> elements, as these old "Bidi overrides" (defined early in HTML4 at a time when the old deprecated overrides were defined in Unicode as control characters but the Bidi algorithm was still not finalized and was demonstrated to be broken and was later modified to use newer controls and a much better algorithm) will break the order of lists (the direction of the content is propagated to the content placed **after** these overrides, so the separators (like commas) or terminators (like periods ending sentences), or any additional info at end (like precisions added in parentheses, like qualifiers) may be incorrectly placed on the wrong side in the reading order of the main element containing the whole list.

Only <bdi>...</bdi> is suitable (it was added in late updates of HTML4 and is part of HTML5 since the begining, as a safer replacement for past overrides; it has the "bidi-isolation" behavior that was standardized in the second major version of the Unicode BiDi algorithm, and also added and standardized in CSS along with the preparation work for HTML5 and tests in HTML4). "bdi" mimics the behavior of "bidi-isolation" in Unicode, which has also defined equivalent Bidi controls (to be used in plain text also instead of the deprecated "override" Bidi controls). Using "bdo" element in HTML is only suitable if you have perfect and complete knowledge of what is included inside them (its initial and final directions) *and* just before *and* just after them, so "bdo" is only for old static content where you can freely add other overrides where needed; this necessary condition is not satisfied with translatable labels that can have arbitrary values (and are not necessarily in the default script that you expect most of the time for a translated language). The "bidi-isolation" mode is also different from "bidi-embedding" mode. As well "right-to-left marks" (RLM) and "left-to-right marks" (LRM) should be avoided as they are also "overrides" (they may only be used inside the static plain-text value of the translated labels themselves, where they will be added appropriately for the language and script these translated labels are targeting, when it is not suitable to insert HTML code in these plain-text labels).

With "bdi" you don't even need to specify a dir="rtl/ltr" attribute for the content (only the lang="" attribute may be relevant to indicate from which language the translated label comes from): the embedded label should already be correctly ordered as is in isolation, in its default reading order, that will be used unchanged without affecting the direction of contents placed before or after the "bdi" (the "bdi" element itself has NO direction, it is "transparent/neutral" and does not break the direction of the outer content, it perfectly isolates its inner content that will be never be splitted in several parts like with all other bidi modes). verdy_p (talk) 01:02, 25 April 2020 (UTC)[reply]

@RexxS: I don’t know how categorization by this template works. Of course it should be taken care of, but most user-visible texts of this template may potentially include wiki links, which is not suitable for categorization in the first place, so I don’t think the two purposes use the same endpoints as of now. This change makes no sense on the English Wikipedia, but that’s the only such language. It makes sense not only on Commons, but also on any monolingual wiki where that single language is different from English—when it comes to Wikidata, Arabic Wikipedia faces the same issues as Commons with Arabic interface language. This can be turned off automatically if the user language (content language in case of monolingual wikis) is English if you wish so, but should be on on non-English monolingual wikis as well.

@Verdy p: Where has <bdo> been deprecated? Mozilla Developer Network lists <bdo> as a valid, non-deprecated element, with perfect browser support. In contrast, <bdi> is also a valid, non-deprecated element, but has much poorer support: no IE, no legacy Edge (EdgeHTML), no Safari, no iOS support (on iOS every browser should use Safari’s engine, which doesn’t support it). So I don’t think time has come to use <bdi>. —Tacsipacsi (talk) 02:06, 26 April 2020 (UTC)[reply]

Deprecation of overrides is from Unicode itself that admitted that Bidi-overrides had bad effects and created Bidi-isolation especially for this purpose.

But as overrides still have some valid use (only for **static** content where you know exactly which texts is inside, and immediately before it and immediately after it) so that the effective direction is known) and there were lot of preexisting documents using overrides, this possibility has been maintained in the Bidi algorithm.

But Unicode, CSS, and HTML specs strongly recommand using isolates rather than overrides, espacially when the contents is generated and you don't know what text may be before, inside or after the embedded text. The really bad effects of overrides (including LRM and RLM controls) are wellknown and documented since long and could not be solved without the introduction of "Bisi-isolation", which was finally standardized in the second major version of the Bidi algorithm (this is the only version that everyone uses today, the former version is effectively deprecated, exactly because of multiple serious problems for punctuations, mirroring, and the absence of support isolates). "bdo" has been kept in HTML only for compatibility with former contents where its bad "propagating" effect is what was really intended by the initial content creators (and it's no easy to fix it: replacing overrides by isolates would revert these effects inside contents which "seemed" correct, and then will change the layout and the interpretation of the content).

If you are still not aware of the many problems that Bidi-overrides cause in multipart-generated contents, please document yourself. All these problems are cleanly solved by isolates which is the ONLY safe thing to do in Wikimedia for all generated contents (including notably templated lists).

verdy_p (talk) 02:30, 26 April 2020 (UTC)[reply]

Also you're wrong: isolates (and the second major version of UBA, the Unicode Bidi Algorithm which standardized isolates) is fully supported in Safari, iOS... I don't know any OS or browser that does not support isolates (and "bdi" in HTML4 or HTML5), except very old softwares created many years ago before the publication of the UBA and that were not updated at all since then (old versions of IE? their support is now ended since long).

The UBA version that added isolates was in Unicode 6.3, published on 30 September 2013, but isolates were already described in an annex before and have been requested, discussed since even longer. I can't beleive that Apple would refuse to integrate isolates in Safari or keep Safari to an antique Unicode version. The UBA is one of the most important part of the Unicode standard that cannot be ignored (even if implementing other parts may be delayed), especially by an international corporation like Apple that cannot ignore the large Arabic and Hebrew speaking markets.

In reality the only bidi mode that Apple does not support in Safari and iOS, is the "isolate-override" mode (coming from preliminary works in CSS and in Unicode before the finalization of UBA v2) which is useless, and which is different from the "isolate" and the "override" modes, by being a strange mixup initially requested but that prove to be completely ill-defined (I can't understand why Mozilla kept this experimental mode). "isolate-override" is also different from the "embed" mode (which is also part of the older Unicode standard and used by RLE/LRE control characters). The "embed" mode however works with a required explicit "direction" that propagates inside the embdded element, but unfortunately also after it, so it was also a failure but it has been kept for compatibility (Apple chose to not support that ill-defined mode too).

"bdo" (which requires and explicit rtl or ltr direction) in HTML maps to the old "override" mode (also used by RLM and RLM control characters), and the "bdi" element in HTML maps to the "isolate" mode (unlike "bdo", the "bdi" element does not require any explicit direction as its default direction is "auto").

Apple's Safari for iOS (since Safari 6, published on 30 July 2012) has full support of the "isolate" mode of CSS (from where it originated) and of the UBAv2 (that adopted the CSS definition, and that was then integrated into Unicode 6.3 standard in 2013). Are we really "too early", or is it just Apple late to change Safari to recognize the "bdi" HTML tag, when it already supports UBA2 in CSS? We can do one thing on iOS: just add a CSS stylesheet definition for iOS, stating that missing rule that Apple forgot: bdi { unicode-bidi: -webkit-isolate; } (you could add a first style with the "embed" value for old versions of iOS using Safari before v6 still not having UBAv2, but I bet almost all these old iPhones with iOS 3.1-5.1 or before sold before 2012 are dead today! Some MDN measurements indicated already they represented less than... 0.01% of the market in 2018, only for version 5.1, and all other versions before 5.1 were already undetectable). Reports indicate however that the "-webkit-" prefix is still needed (only in iOS with Chrome or Safari) for the "isolate" value in CSS, but it works !

In addition, since iOS 10 (and macOS 10.12), the API "String localizedStringWithFormat()" automatically inserts Unicode isolate controls <FSI>...<PDI> (i.e. U+2068...U+2069) around all placeholders (like the "%@" in "%@ has the highest score!" in translatable and formatable messages, that will be replaced by the arbitrary name of a user, which may be written in Arabic, but as well this message is translatable in Arabic and will allow user names in Latin; for such case, using Bidi overrides would never work at all as the inner direction of the placeholder is compeltely independant of the outer direction). The "%@" placeholder in localizable format strings, is in fact equivalent to "\u2068%s\u2069" in classic format strings (and this already worked with the text renderer in the iOS and MacOS API since mid-2012 and even earlier before with a specific API of the text renderer to support this "isolate" mode in CSS)...

See this presentation in video: "https://developer.apple.com/videos/play/wwdc2016/232/".

This is a higher level way to format strings with mixed language direction, without manually inserting directional marks (and another proof that UBAv2 of Unicode 6.3 was already integrated but here this is enforced in a more practical way so that most applications using translation templates will benefit from it, without having to encode these controls in translation units). Even though this is an improvement in the UI layout support API for iOS/MacOS, the UBA support for isolates was already present since several years in the text rendering engine itself. It was already integrated in CSS with Safari for iOS and MacOS; only the HTML renderer forgot initially to predefine the appropriate CSS style for the "bdi" element (which is still parsed correctly by Safari in the HTML DOM)...

verdy_p (talk) 02:42, 26 April 2020 (UTC)[reply]

Thanks for the detailed explanation, then let’s use <bdi lang="LANG">...</bdi>. (Actually I just noticed that the mentioned override—in a more complete form—is already present in MediaWiki:Common.css, although it isn’t loaded in mobile view, so maybe it needs to be moved into a mobile-ready gadget.) But do use it, as without that we end up with really annoying results sometimes, even with the recent widening of the box. —Tacsipacsi (talk) 23:08, 1 July 2020 (UTC)[reply]

@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)[reply]

@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)[reply]

@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)[reply]

@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)[reply]

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)[reply]

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)[reply]

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:

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
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)[reply]

@קיין ומוויסנדיק פּרעפֿערענצן: 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)[reply]

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

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:

there should be an anchor to acces the "Authority control" directly
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)[reply]

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)[reply]

@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)[reply]

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)[reply]

Volume as quantity and vertical depth

I have an item Preston Resevoir - 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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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

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)[reply]

@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)[reply]

@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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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

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)[reply]

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)[reply]

@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)[reply]

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

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)[reply]

@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)[reply]

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)[reply]

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

@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)[reply]

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

@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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]
- @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)[reply]
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)[reply]

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)[reply]

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)[reply]

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

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

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

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)[reply]

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)[reply]

surname miss

Having an issue that the template is just appending "_(surname)" rather than the target surname from the category. Example Category:Mihály Kada which should be categorising to category:Kada (Hungarian surname) — billinghurst sDrewth 12:38, 26 April 2024 (UTC)[reply]

Fixed in the sandbox. The change will be visible in a few weeks. LennardHofmann (talk) 21:26, 28 April 2024 (UTC)[reply]

@Billinghurst and LennardHofmann: Now live, I also added Category:Uses of Wikidata Infobox with no surname sitelink, let's see how that goes. Thanks. Mike Peel (talk) 22:40, 30 April 2024 (UTC)[reply]

Done working from my perspective. Thanks. — billinghurst sDrewth 23:45, 30 April 2024 (UTC)[reply]

Hmm, I may have jumped the gun. There may be some sort of lag in the processing, however, Category:Kada no Azumamaro hasn't updated. Purging at WD and here doesn't shift the assumptions. — billinghurst sDrewth 01:04, 1 May 2024 (UTC)[reply]

That seems to be because Kada no Azumamaro (Q1334955) links to Kada (Q125253600), which doesn't have a sitelink, Category:Kada (Japanese surname) is linked to from Kada (Q125253572). So the code is falling back to appending "_(surname)" in this case. Thanks. Mike Peel (talk) 17:08, 12 May 2024 (UTC)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

Ä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)[reply]

Ä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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

@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)[reply]

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)[reply]

@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)[reply]

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)[reply]

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

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)[reply]

Where to request the inclusion of P11557

Where should the inclusion of a new property be requested? I think it would be useful to show Barcelona City Council Heritage Catalog ID (P11557) when present. Pere prlpz (talk) 10:45, 25 May 2024 (UTC)[reply]

You've come to the right place for such requests. I added the property here. The change will be visible in a few weeks. LennardHofmann (talk) 19:24, 25 May 2024 (UTC)[reply]

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)[reply]

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: [6]. Enhancing999 (talk) 08:24, 7 June 2024 (UTC)[reply]

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)[reply]

~~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)~~[reply]

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

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)[reply]

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

Canonicalize lang code in interwikilink

{{Edit request}} Proposed change: This will fix duplicate interlang links of yue in pages such as Category:Iao Hon. emk (talk) 10:13, 7 June 2024 (UTC)[reply]

I've turned off the edit request template since we make edits to this template in batches, let's see how this goes for a little while in the sandbox so we can combine it with other edits. Thanks. Mike Peel (talk) 17:31, 7 June 2024 (UTC)[reply]

@Emk Thanks, I filed phab:T350163 for this bug but didn't bother to workaround it yet. @Mike Peel: Remember to also remove {{#invoke:Interwiki from P460|InterwikiP1420}} from this template in the next batch. LennardHofmann (talk) 08:05, 8 June 2024 (UTC)[reply]

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)[reply]

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)[reply]

@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)[reply]

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)[reply]

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

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)[reply]

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)[reply]

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)[reply]

Infobox on files

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

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)[reply]

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

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

Display satellite views (P11832), like aerial views

{{Edit request}} Is it possible to include P11832 (satellite view) in the image switches, like we do for P8592 (aerial view)? Example where it would be useful: Category:Bank of America Stadium vip (talk) 08:35, 18 August 2024 (UTC)[reply]

@Don-vip: It's now in {{Wikidata Infobox/sandbox}} - please try that and see if it looks OK. Thanks. Mike Peel (talk) 18:10, 27 September 2024 (UTC)[reply]

It works, thank you! vip (talk) 00:56, 28 September 2024 (UTC)[reply]

Show film poster instead of image

If a Wikidata item of a category is Instance of film then it should show the film poster first instead of the image if both are set. Example: Category:Four Sons (1928 film). Prototyperspective (talk) 18:59, 20 August 2024 (UTC)[reply]

Why? Isn't it better if the infobox has a standard order for showing images? Other projects also show image (P18) rather than other images, so the best image should normally be in that property, and it might be worth exploring better modelling options on Wikidata if that's not the case. Thanks. Mike Peel (talk) 19:31, 21 August 2024 (UTC)[reply]

Because for films in specific, the default image that should be shown is the film poster not some other image and it wouldn't be good to add the film poster to both the film poster property and the image property (including if it's automatically set once the film poster prop is set). I'll ask on WD. Prototyperspective (talk) 20:11, 21 August 2024 (UTC)[reply]

I agree and I just edited the sandbox module. We don't need to check instance of (P31) since having a value for film poster (P3383) already implies being a film. LennardHofmann (talk) 22:29, 21 August 2024 (UTC)[reply]

When will this be deployed / on WMC? Prototyperspective (talk) 10:21, 26 October 2024 (UTC)[reply]

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)[reply]

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)[reply]

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)[reply]

Uncategorized_categories,_except_infobox (see VP)

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

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)[reply]

Changes to which properties are showing in the infobox

How can one request changes to which properties in Wikidata are showing in the Wikidata infobox on Wikimedia Commons?

I'd like to request these changes and maybe there will be more later, could these please be shown?:

Showing the significant event property (example)
Showing links to the "Multilingual sites" like meta.wikimedia.org (example)

Prototyperspective (talk) 12:57, 30 August 2024 (UTC)[reply]

@Prototyperspective: You've come to the right place. I've implemented your requests in Module:Wikidata Infobox/sandbox. --LennardHofmann (talk) 10:58, 3 September 2024 (UTC)[reply]

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)[reply]

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)[reply]

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

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)[reply]

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)[reply]

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)[reply]

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

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)[reply]

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

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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

@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)[reply]

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)[reply]

@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)[reply]

Proposal for gender categories

Although we categorize all male humans under "men by name" and female humans under "women by name", I think this is not a proper approach for people aged below 18, because the terms "men" and "women" are defined as adult humans in almost all dictionaries, Wikipedia, and Wikidata. My proposal is to categorize only adult humans under "men by name" and "women by name" categories, while categorizing people aged below 18 under "boys by name" and "girls by name" categories. If the exact age is unknown, such people will be categorized under "male humans by name" and "female humans by name" instead. Sbb1413 (he) (talk • contribs • uploads) 13:01, 17 September 2024 (UTC)[reply]

Agree but this 1) is already done except for a few exceptions (one of which I recently started to address) 2) seems unrelated to the infobox so I wonder why you ask about it here. Prototyperspective (talk) 15:14, 17 September 2024 (UTC)[reply]

Personally I'd go with 'male' and 'female', but I just used what already existed here. If you want a change, I think it has to be discussed elsewhere first, and then if there's consensus it can be implemented here. Thanks. Mike Peel (talk) 18:00, 27 September 2024 (UTC)[reply]

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)[reply]

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)[reply]

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)[reply]

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

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)[reply]

@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)[reply]

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)[reply]

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)[reply]

@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)[reply]

This was discussed here: Template_talk:Wikidata_Infobox/Archive_5#Add "Births in" category?. Strakhov (talk) 12:37, 28 September 2024 (UTC)[reply]
@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)[reply]
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)[reply]
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)[reply]
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)[reply]
Item with instance of sth that is subclass of city. It isn't. Prototyperspective (talk) 21:04, 30 September 2024 (UTC)[reply]
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)[reply]
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)[reply]

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)[reply]
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)[reply]

Wikidata is removing all labels for last names and first names, creating some bugs

Hi there. So as you can see in this discussion here, the removal of all language-specific labels in favor of a unique "mulitlingual" one in Wikidata creates issues in Commons, especially categories using this current infobox. I would have like to propose a fix (even temporary while we find a better solution), this infobox being protected. I proposed an edit here. It's probably not a good long-term solution but it will fix it temporary. Probably the best approach would replace all occurence of "mw.wikibase.getLabelByLang( x, 'en' )" by a custom method, where we do a logic checking for the existence of 'mul' and default to 'en'. Thanks. --Deansfa (talk) 17:17, 26 September 2024 (UTC)[reply]

@Deansfa: I can't see the problem, can you link to a category where it's currently happening, please? getLabelByLang should fall back to mul if en is not set - or if it doesn't, that should be fixed. Thanks. Mike Peel (talk) 17:18, 27 September 2024 (UTC)[reply]

Hi @Mike Peel: . This category has the issue: Category:Jean-Éric Branaa, because the wikidata element of the first name (Jean-Éric) has all its label as blank except the mul. When I fill all the labels, the category "Jean-Éric" appears. I just noticed though that if I change to the sandbox version of the Infobox, the category does show up. --Deansfa (talk) 01:38, 28 September 2024 (UTC)[reply]

Wrong categorization for living people

The templates currently categorizes people as Deceased people by name even with a Qid date of death (P570) no value statement (meaning the person is still living). Can that be fixed? MB-one (talk) 11:42, 20 October 2024 (UTC)[reply]

@MB-one: I don't think that statement makes sense - they will never die? The infobox checks to see if the property exists for adding into this category, it could also check the value, but in general it's better to not set the property in the first place. Thanks. Mike Peel (talk) 17:58, 20 October 2024 (UTC)[reply]

@Mike Peel There has been a discussion about the utility of this but it ultimately was never decided in one way or the other. So there are currently a few items of living people with such a P570 statement and a Commons category (see https://w.wiki/BcC6). MB-one (talk) 20:54, 20 October 2024 (UTC)[reply]

"ultimately was never decided in one way or the other" More precise, I think, to say "there has never been consensus to use "no value" for the death date of living people. Such data should be removed. If "a few items of living people" have it, then they are a tiny, tiny minority. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 13:37, 21 October 2024 (UTC)[reply]

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)[reply]

Mixup at Wikidata

What's a good way to fix infoboxes when the category displays information from the wrong Wikidata item, without editing Wikidata?

If there is another Wikidata item, one could just add "qid=". What if there is none? At Category:Fronti nulla fides, I commented out the infobox [8], also at [9]. "qid=-" throws an error.
∞∞ Enhancing999 (talk) 12:48, 1 November 2024 (UTC)[reply]

The solution is to edit Wikidata. Defining qid is a temporary workaround, commenting it out is really bad. Thanks. Mike Peel (talk) 20:41, 6 November 2024 (UTC)[reply]

Infobox width too large

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

Edit request: displaying video language

Could you please make it so that the infobox displays the language qualifier (P407) for videos? Maybe just by showing a small (de) before the file caption if one is set or in place of file caption is none is set (in this example if the file was in German). Example: Category:Nuclear meltdown.

Missing captions for media files in Wikidata and thereby also in the WD infobox are also a (related) problem – I think it would be best if files without caption instead displayed the file title in the WD infobox (until a caption is added in WD); the file captions in Commons could maybe also be used but often they haven't been set or are just some undescriptive/other-context metadata. I think ideally all media files should have a caption in the Wikidata item for the language it's in (maybe also English in addition). Related proposal: Suggest media set in Wikidata items for their Wikipedia articles. Prototyperspective (talk) 18:32, 7 November 2024 (UTC)[reply]