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)

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

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

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)

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)

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)

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)

Doc-page: usage section

Hello, in "usage" section of the doc-page the copy paste text for the template with all parameters look like this:

{{Wikidata Infobox |qid= |defaultsort= |interwiki= |autocat= |trackingcats= }}

Actually it is not so important, cause we usually only use {{wikidata infobox}}, but if we have to use more parameters than I propose the following layout:

{{Wikidata Infobox
 |qid          =
 |defaultsort  =
 |interwiki    =
 |autocat      =
 |trackingcats =
}}

If you agree, I propose to change parameter print to value infobox (line 67 in doc page, at the moment it is empty so default one)

Regards --W like wiki ^{good to know} 16:29, 31 January 2023 (UTC)

@W like wiki: Be bold! Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 17:26, 24 February 2024 (UTC)

@ Andy Mabbett ok, done! Thx and best Regards! -- W like wiki  ^{Please ping me! • Postive1 • Postive2}  23:25, 24 February 2024 (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)

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)

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)

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)

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)

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 or archaea. Since 2024, the domain 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)

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)