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



  • Link to create a new Wikidata item is English-only, is there a translated text that could be used instead? Mike Peel (talk) 20:55, 9 February 2018 (UTC)
  • What's the best zoom level to use for the map? How should it depend on the type of object that the category is about? Mike Peel (talk) 21:15, 9 February 2018 (UTC)
  • How to handle long strings for IDs, e.g., Category:Monumento Pedro Álvares Cabral (Parque do Ibirapuera). Mike Peel (talk) 23:19, 13 February 2018 (UTC)
    • Is not a good solution to shorten (xxx...) names longer than x signs (keeping - or not, last word entirely)? Whole names could be visible as a tooltip. --Jasc PL (talk) 17:13, 15 April 2018 (UTC)
    • Could we have the Title in the smaller font size, but in bold - as in the Wikipedia infoboxes? This way we will have more place for long titles and better look. --Jasc PL (talk) 22:08, 18 April 2018 (UTC)
  • If we really need the Authority control in Commons - OK, but must it be always visible with our tools also? Why not to keeping it hidden by default, having the only [linked WD icon] [Authority control title] [Show/Hide swith] on one bar, or - clickable [Authority control title] as a show/hide switch? --Jasc PL (talk) 22:08, 18 April 2018 (UTC)
  • Could we add a link to Crotos for artworks? (see Sadads (talk) 13:28, 23 May 2018 (UTC)
  • Auto-categorisation should handle multiple possible dates, e.g. at Category:Mary Somerville. Mike Peel (talk) 23:36, 1 June 2018 (UTC)
  • A field for "Former name" with qualifiers: "Start time", "end time" and "named after".-- Darwin Ahoy! 23:37, 20 June 2018 (UTC)
  • Check BC birth categories, e.g. Category:Galba. Mike Peel (talk) 17:53, 24 July 2019 (UTC)

publication in which this taxon name was established (P5326)Edit


1/ Is it possible to integrate publication in which this taxon name was established (P5326), just below taxon author (P405) in the infobox?

2/Is it possible for both publication in which this taxon name was established (P5326) and taxon author (P405) to have by default the links to the Wikimedia Commons categories when they exist (I think it is already the case), but in addition, and as a replacement for when there is no category available, to have the link to the Wikidata item. Indeed the items displayed via those properties can have very useful infos (and links). (note for me : to be tested there and there)

Regards, Christian Ferrer (talk) 12:11, 5 November 2018 (UTC)

@Christian Ferrer: Currently, for Allostichaster palmula (Q2858131), Aporocidaris incerta (Q2343200):
{{wdib |qid=Q2858131 |P5326 |fwd=ALL |osd=n |lp=:}} → A new fissiparous micro-asteriid from southern Australia (Echinodermata: Asteroidea: Asteriidae)  
{{wdib |qid=Q2343200 |P5326 |fwd=ALL |osd=n |lp=:}}Resultats du voyage du S. Y. 'Belgica' en 1897-1898-1899, sous the commandement de A. DE GERLACHE DE GOMERY; Zoologie, Échinides et ophiures  
I'm not keen to have piped links to Wikidata because of the criticism I've had in the past that external links should be obvious, rather than potentially surprising the reader who isn't expecting to be taken to another site. However, if |noicon=false, then each publication's Wikidata entry can be reached via a click on the pen icon. Would that be an acceptable compromise? --RexxS (talk) 00:10, 6 November 2018 (UTC)
@Mike Peel: Great, thanks you, tested and approved in Aporocidaris incerta. As far as I am concerned, I put the infobox as soon as I create or modify a category, but not to disturb the historical way I always left {{Taxonavigation}} and {{VN}}. I can talk only for me, but yes, I am very much in favor of the infobox being added in all taxon categories, but below all content please, see previous example. Another good point for the infobox can be seen in Ophiura scomba, where Ophiura scomba is in fact an alternate accepted name (a habit taken for the sake of simplification by almost the entire community, I presume) and whose official name is Ophiura (Ophiura) scomba displayed in the Infobox. Christian Ferrer (talk) 05:16, 1 December 2018 (UTC)
@Christian Ferrer: OK, this is now live. The existing pi bot code adds the template below all other templates, and it's easy enough to run it through taxons. I've already suggested this a few times at Commons_talk:WikiProject_Tree_of_Life#Wikidata_Infobox_and_taxons without getting consensus, feel like having a go at re-suggesting it there? ;-) Thanks. Mike Peel (talk) 21:36, 3 December 2018 (UTC)
@Mike Peel: thanks you, I'd suggect that we wait the outcome of the property proposal that I made on Wikidata, and then, if successful, we will have to work a bit to retrieve the author citations in the Infobox, which is in the eyes of the specialists, very important. After that, and with all the effort and progress we have made since the creation of the taxontree, I think it will be more easy to get consensus. Christian Ferrer (talk) 05:53, 4 December 2018 (UTC)
Ugh, more clutter. I personally remove the wikidata template from taxon articles, if they lack {{Taxonavigation}}: It's more unwanted data dumpage imposed from Wikidata, and the essential links are redundant to {{Taxonavigation}}. But I suspect I'm fighting losing battle, and that the "small" Wikidata-enabled infoboxes initially proposed will soon rival short novels on every category in length and level of intricate detail. --Animalparty (talk) 01:32, 25 January 2019 (UTC)

location: country missingEdit

At Category:Acaray Dam the only visible location info is "Acaray River", set by located on terrain feature (P706). The item Acaray Dam (Q3433454) also provides "Paraguay" for country (P17). I expect the country to be displayed in the infobox. Is the missing country bit in this case related to changes discussed at #Improvement to "location" field with hierarchical information perhaps? --Te750iv (talk) 12:25, 10 November 2018 (UTC)

@Te750iv: I've added located in the administrative territorial entity (P131) to the Wikidata item, which is what is used to show the location string. Ideally I guess P706 should be shown at the start as well, if @RexxS: wants to look into that. Thanks. Mike Peel (talk) 12:45, 10 November 2018 (UTC)
@Mike Peel: This is what the location function can return:
I can't understand what you want me to do. The function repeatedly looks first for located in the administrative territorial entity (P131), next for location (P276), then for located on terrain feature (P706), following the first one that exists at each step. I'm not sure I can offer a sensible alternative algorithm. The reason why nothing else was showing before is that Acaray River (Q4672121) has no link to any of those three possible higher level geographical entities. We don't look for country (P17) because it's often found at very low level entities and would short-circuit the location chain. --RexxS (talk) 13:38, 10 November 2018 (UTC)
Aah, I assumed there was more location info in Acaray River (Q4672121) that wasn't being picked up, sorry RexxS! Thanks. Mike Peel (talk) 13:45, 10 November 2018 (UTC)
Actually, having thought about it for a bit, would it be preferable to look for country (P17) as fourth choice? so that if none of the three usual upwards links in the chain exist, we could at least get the country (which would then terminate the chain). The disadvantage is that we would lose the ability to spot broken chains and fix them on Wikidata. What do folks think? --RexxS (talk) 23:10, 10 November 2018 (UTC)

Problem with various people.Edit

Hi, I got a dispute with a wikidata user about how to use family anf given names on wiidata. See reverted several of my edits. He the deiscusion under wikidata:User talk:JuTa#Given names. His current conclusion: the Commons infobox should not be using Wikidata to produce these categories.. This would break a very lot of cats und prior work. Any other idea how to solve this problem? --JuTa 02:12, 17 January 2019 (UTC)

I've replied there - basically it needs some way to store diminutive (Q108709) as a property/qualifier, and then we (probably RexxS) could modify the infobox to use that where available. Thanks. Mike Peel (talk) 10:54, 17 January 2019 (UTC)
I suggest that it should be possible to override the Wikidata value with a locally supplied value. There's just no sensible way to programmatically decide which of a number of possible aliases to use for a particular field. If template code such as:
  • {{#invoke:WikidataIB |getValue |rank=best |P735 |qid={{#invoke:WikidataIB |getQid |qid={{{qid|}}} }} | name=givenname | |fwd=ALL |osd=no |noicon=yes | linked=n | spf={{{suppressfields|}}} | lang=en | sep=" "}}
were to be replaced by:
  • {{#invoke:WikidataIB |getValue |rank=best |P735 |qid={{#invoke:WikidataIB |getQid |qid={{{qid|}}} }} | name=givenname | |fwd=ALL |osd=no |noicon=yes | linked=n | spf={{{suppressfields|}}} | lang=en | sep=" " |{{{given-name|}}}}}
then the parameter |given-name= could be used in a particular article to take precedence over what is on Wikidata. --RexxS (talk) 00:22, 18 January 2019 (UTC)

It could be an idea similar to the |defaultsort=no doing the same with |givenname=no and |surname=no. In these cases these wikidata values will be ignored by the infobox and the persons categories they have to be set manually like in old times. That could be easier to get implemented as the suggestion above. regards. --JuTa 18:13, 24 January 2019 (UTC)
Now I have a current example where this would be usefull: Category:Anthony of Sourozh. It is because of wikidata and the infobox in Category:Bloom (surname) and Category:Andrei (given name). This leaves most readers clueless why. I tried to fix this by editing the wikidata item and got reverted. Then I tried t fix it by moving the commons category to the names set in wikidata and got reverted again by another user. To fix at least something I added Category:Sourozh (surname) and Category:Anthony (given name) nmanualy now. But it would be realy helpfull if there is any possibility to surpress the name categories coming out of the infobox in such cases. regards. --JuTa 17:39, 4 March 2019 (UTC)
@JuTa: I think this needs to be recorded better on Wikidata. I can't see how having a local override in the infobox here would help resolve this issue in the long run. Thanks. Mike Peel (talk) 00:27, 5 March 2019 (UTC)
Hmm, If you look i.e. to my wikidata talk page people wikidata seems to be the opinion that this is a commons problem. :( --JuTa 07:52, 5 March 2019 (UTC)

Replacing P969 by P6375Edit

The property P969 (located at street address (DEPRECATED)) is deprecated and is to substituted by the property P6375 (located at street address). Main cause is the change of the property type from string to multilingual text. --RolandUnger (talk) 09:31, 20 January 2019 (UTC)

At the moment the usage located at street address (P6375) is 597 and usage of located at street address (DEPRECATED) (P969) is 849,422 and there is no even proposed migration plan, so it is a bit premature to reflect this in template.--Jklamo (talk) 11:57, 20 January 2019 (UTC)
@RolandUnger, Jklamo: Is this being discussed somewhere? (was there a property proposal for it?) Thanks. Mike Peel (talk) 13:14, 20 January 2019 (UTC)
I am afraid all we have (850,000 usage, 50+ templates in various languages) is this Wikidata:Wikidata:Properties_for_deletion#located_at_street_address_(DEPRECATED)_(P969).--Jklamo (talk) 18:03, 20 January 2019 (UTC)
@RolandUnger, Jklamo: OK, thanks for the background. {{Wikidata Infobox/sandbox}} should now support both properties depending on what's available. Please test that to make sure it's working OK, I'll probably make it live this weekend. Once the migration's complete I can tidy it up to just use the new property. Thanks. Mike Peel (talk) 21:52, 22 January 2019 (UTC)

Please have a look at Category:Redemptoristenkloster Bonn. Why is located on street (P669) (not located at street address (DEPRECATED) (P969)) supposed to be deprecated?--Leit (talk) 21:48, 21 January 2019 (UTC)

@Leit: That's because the located at street address (DEPRECATED) (P969) label was being used for the label for the line, but the line combines the different address properties. I've updated the label to located at street address (P6375) now, so the deprecated label should stop showing. Thanks. Mike Peel (talk) 21:45, 22 January 2019 (UTC)
The discussion to delete the property located at street address (DEPRECATED) (P969) and to migrate it to a new monolingual property can be found in the archives. We know that we have to migrate about 800.000 items which will take time. The change was discussed several times in the past because in several countries addresses are (sometimes only regionally) used/accepted in several languages. But I think the migration can be done by a bot copying the property data and taking the language property from P407 or from P37. Meanwhile we analyze at the German Wikivoyage both properties favoring located at street address (P6375).
We are also comparing the given languages with the wiki language by analyzing writing system and direction to select an optimal variant. For instance, in case of Egypt we are giving the English address (at the German Wikivoyage) for readability and the Arabic one in parenthesis to show it to the inhabitants. At least in Cairo both addresses are shown at the street signs. --RolandUnger (talk) 05:55, 23 January 2019 (UTC)

Links to BHL pagesEdit

Hello, I remember very well that you want to be careful with external links. Howether I ask if by chance you can integrate a link to a BHL page. Example in Category:Ophioplocus bispinosus, in the field "Publication in which this taxon name was established" you can read "Brittle-Stars, New and Old (30093893)", the number 30093893 is in fact a BHL page ID, retrieved as qualifier of publication in which this taxon name was established (P5326), as you can see in the wikidata item Ophioplocus bispinosus (Q61443488). I wonder, in the extend that we already have the number, if you can make the link available in the infobox. This kind of link can be used to lead to the exact page where the taxon name was published.

Otherwise, in case that is not possible to give us the link, you could try to prevent the appearance of this number...that few people, except me and you now, know what this is.

Thanks you, regards, Christian Ferrer (talk) 19:05, 3 February 2019 (UTC)

There are two options:
  1. @RexxS: would you be able to modify the qualifier function so that it uses formatter URL (P1630) (if available) to link the qualifier value if it is for an identifier?
  2. @Christian Ferrer: we could stop displaying qualifiers for that property, or to only display the qualifier if it is volume (P478) or page(s) (P304).
Thoughts? Thanks. Mike Peel (talk) 20:52, 4 February 2019 (UTC)
@Mike Peel: First thoughts: You can easily separate the value and the qualifier, but I can't guarantee that it will always work with multiple values if one of them doesn't have a qualifier:
  • {{wdib |ps=1 |P5326 |qid=Q61443488}} → Brittle-Stars, New and Old
  • {{wdib |ps=1 |P5326 |qid=Q61443488 |qual=P687 |qualsonly=y}} → 30093893
I could write another bespoke function, but for now, we could fabricate it using hard-coded values like this:
  • {{wdib |ps=1 |P5326 |qid=Q61443488 |qual=P687 |qualsonly=y |qprefix=[ |qpostfix=]}}[1]
To generalise that, we could use the fact that WikidataIB can read property entities just like Wikidata entities:
Then use Module:String to replace the $1:
However, as I don't know what sort of display you want, I can't be more specific. Given a little time, I'll write the general function to handle qualifiers that are identifiers by looking for a formatter URL (P1630), but that will have to go on the "to-do" list for now. Cheers --RexxS (talk) 23:43, 4 February 2019 (UTC)
I would have like something a bit more friendly, such as BHL page, or something similar, but I take the proposition above, thanks you very much. If it's possible go ahead, integrate that link in the infobox please. Christian Ferrer (talk) 05:54, 5 February 2019 (UTC)
@Mike Peel: I can't edit the infobox. --RexxS (talk) 22:41, 7 February 2019 (UTC)
@RexxS: Template:Wikidata Infobox/sandbox and Template:Wikidata Infobox/core/sandbox should be editable and up-to-date. Thanks. Mike Peel (talk) 22:46, 7 February 2019 (UTC)
@Mike Peel: I don't do templates :P --RexxS (talk) 22:48, 7 February 2019 (UTC)
@Christian Ferrer: Sorry, I only just spotted that:
  • [{{#invoke:String|replace|{{wdib |ps=1 |P1630 |qid=P687}}|$1|{{wdib |ps=1 |P5326 |qid=Q61443488 |qual=P687 |qualsonly=y}}|1|true}} BHL page]BHL page
Is that what you want? --RexxS (talk) 23:20, 7 February 2019 (UTC)
@RexxS: yes exactly, very great, thanks you. Christian Ferrer (talk) 05:28, 8 February 2019 (UTC)
  • @RexxS:, @Mike Peel:, The ideal would be that the Wikidata Infobox/line can integrate two things, the publication name and the link :
{{wdib |ps=1 |P5326 |qid=Q61443488}} [{{#invoke:String|replace|{{wdib |ps=1 |P1630 |qid=P687}}|$1|{{wdib |ps=1 |P5326 |qid=Q61443488 |qual=P687 |qualsonly=y}}|1|true}} (BHL page)] → Brittle-Stars, New and Old (BHL page)

Regards, Christian Ferrer (talk) 17:37, 16 February 2019 (UTC)

  •   Done I managed to do it. Christian Ferrer (talk) 22:37, 17 February 2019 (UTC)
  • With this code I manage to have the BHL link I wanted (example) :
{{#if:{{#property:P5326| from={{#invoke:WikidataIB |getQid |qid={{{qid|}}} }}}}|<tr {{#ifeq:{{{mobile|n}}}|y||class="wdinfo_nomobile"}}><th class="wikidatainfobox-lcell">{{ucfirst:{{#invoke:WikidataIB |getLabel |Q55155646}} }}</th><td {{#ifeq:{{{wrap|n}}}|y| style="white-space: nowrap"}}><div class="mw-collapsible mw-collapsed">{{#invoke:WikidataIB | getValue | rank=best |qid={{#invoke:WikidataIB |getQid |qid={{{qid|}}} }} |P5326 |fwd={{{fwd|ALL}}} |osd={{{osd|no}}} |linkprefix=":"|qlinkprefix=":"}} [{{#invoke:String|replace|{{wdib |ps=1 |P1630 |qid=P687}}|$1|{{wdib |ps=1 |P5326 |qid={{#invoke:WikidataIB |getQid |qid={{{qid|}}} }} |qual=P687 |qualsonly=y}}|1|true}} (BHL page)]</div></td></tr>}}<!--

However, with that code, a BHL link is given even when it is not given in the item, logic, (example). How to write a condition for that...

[{{#invoke:String|replace|{{wdib |ps=1 |P1630 |qid=P687}}|$1|{{wdib |ps=1 |P5326 |qid={{#invoke:WikidataIB |getQid |qid={{{qid|}}} }} |qual=P687 |qualsonly=y}}|1|true}} (BHL page)]

... to be displayed only if :

the property publication in which this taxon name was established (P5326) has BHL Page ID (P687) as qualifier, inside the concerned item?

@RexxS: and @Mike Peel:? Christian Ferrer (talk) 12:08, 18 February 2019 (UTC)

@Christian Ferrer: You can test the difference like this:
Is that enough for you to write the #if: test? --RexxS (talk) 17:50, 18 February 2019 (UTC)
@RexxS: No I don't manage to write it, however I managed to have the result with : {{wdib |ps=1 |P5326 |qid={{#invoke:WikidataIB |getQid |qid={{{qid|}}} }} |qual=P687 |qualsonly=y |qprefix=[ |qpostfix=" (BHL page)"]}} from what you wrote a bit abobe. Christian Ferrer (talk) 19:28, 18 February 2019 (UTC)
@Christian Ferrer: For reference, the test for having the property publication in which this taxon name was established (P5326) with BHL Page ID (P687) as qualifier would be:
  • {{#if:{{wdib |fwd=ALL |osd=n |noicon=true |P5326 |qid={{#invoke:WikidataIB |getQid |qid={{{qid|}}} }} |qual=P687 |qualsonly=y}} | put the code here for when it has the property with the qualifier | put the code here for when it doesn't (if needed) }}
But what you've done is fine. You just have to remember to change the hard-coded url if the site ever changes its structure (not likely, I guess). --RexxS (talk) 23:23, 18 February 2019 (UTC)
Ok thanks you Christian Ferrer (talk) 05:30, 19 February 2019 (UTC)


@RexxS, Animalparty: Following up on d:Wikidata:Project_chat#Question_regarding_Commons_Categories, it might be better to use getCommonsLink instead of the P373/sitelink value when making the link. That way, we also get the commons category if it's on a category item, and we're less dependent on P373 values (ideally we'd drop support for P373 at some point, but we're not quite there yet). Do you think that would be feasible? Thanks. Mike Peel (talk) 09:38, 12 February 2019 (UTC)

Sorry, Mike, that's too abstract for me. Can you give a concrete example of where the result would be improved? The _getCommonslink function returns the Commons sitelink, if it's a category and |onlycat=true; otherwise the Commons sitelink of the first best topic's main category (P910), if it exists; otherwise the first best Commons category (P373), if |fallback=false; otherwise nothing. --RexxS (talk) 16:00, 12 February 2019 (UTC)
@RexxS: I can't find an example offhand, I'll let you know if I find one. The basic idea is that instead of using P373 you use _getCommonslink. Thanks. Mike Peel (talk) 21:03, 12 February 2019 (UTC)

Uncertain dates and overly specific locationsEdit

I have some comments/requests regarding the less-than-ideal format that some dates are displayed. First, see Category:Lawrence S. Harris: there are redundant reminders of what "circa" means (c. 1873 (circa)). Personally, I think linking to circa is pointless as a mere dictionary definition (we should not assume all readers are children who have never seen the word "circa" before, abbreviated or not)." Approximate dates should be rendered simply as "c. 1873" or "circa 1873". Second, see Category:Fred W. Wright: the year of death is uncertain (should read as after 1933), yet the infobox awkwardly displays "1933 (1933)" (the corresponding creator template correctly displays "after 1933").

The last falls into the category of "technically true but missing the point" category: see Category:William Ely Hill. When birth or death locations are displayed as hospitals, addresses, or sub-city locales, this flies in the face of standard biographical conventions (I mean elsewhere in the real world, not the Wiki universe). This same observation applies to the death location in {{Creator}} templates. A refined creator template should indicate nationality, life span, and major locations with respect to the creator's work and life (e.g. city of birth/death, cities/countries where work was produced), being no more specific than necessary. The building in which one was born or died is of negligible to zero value for determining provenance, copyright, or gleaning much other realistically useful information beyond trivia. If it's possible to "round up" to display the city (or at least the smallest administrative entity encompassing a building), that'd be nice. Alternatively, if it's possible to customize/override the infobox locally to substitute the city in place of hospital, that'd be nice too. I don't like the prospect of every decision on 2 million+ infoboxes being forced by Wikidata alone: issues like aesthetics, relevance, and common sense involve more than mere data. --Animalparty (talk) 02:04, 14 February 2019 (UTC)

The problem with the circa dates is that Wikidata uses a qualifier to designate circa, and although the code can read that and convert it to a compact abbreviation, it then repeats it again if we ask for |quals=ALL.
For Lawrence Harris (Q61711437), date of birth (P569):
  • {{#invoke:WikidataIB |getValue |ps=1 |P569 |qid=Q61711437}}c. 1873
  • {{#invoke:WikidataIB |getValue |ps=1 |P569 |qid=Q61711437 |qual=ALL}}c. 1873
I've amended the sandbox to suppress a qualifier value of "circa" in favour of the abbreviated form:
  • {{#invoke:WikidataIB/sandbox |getValue |ps=1 |P569 |qid=Q61711437}}c. 1873
  • {{#invoke:WikidataIB/sandbox |getValue |ps=1 |P569 |qid=Q61711437 |qual=ALL}}c. 1873
That should fix the problem at Category:Lawrence S. Harris and similar when the main module is next updated from the sandbox.
We already handle qualifier latest date (P1326), so it shouldn't be difficult to also handle earliest date (P1319) as well.
For Fred W. Wright (Q61714940), date of death (P570):
  • {{#invoke:WikidataIB/sandbox |getValue |ps=1 |P570 |qid=Q61714940}} → 20th century
  • {{#invoke:WikidataIB/sandbox |getValue |ps=1 |P570 |qid=Q61714940 |qual=ALL}} → 20th century (after 1933)
The problem at Category:Fred W. Wright needs more work, as there are other cases where both earliest and latest dates are present (Julius Caesar (Q1048) date of birth (P569)), as well as cases where the latest date (P1326) qualifies something that's not a date (France (Q142), highest point (P610)).
Being "no more specific than necessary" is quite difficult to write programmatically, but I'll think about it. Perhaps we can examine the instance of (P31) for the place of birth (P19) and place of death (P20) and if it's not some sort of geographical location, then use its location (P276) or located in the administrative territorial entity (P131) if it has either. It may take a while to figure out all the possible types of geographical location, so I'll return to this when I've made some progress. --RexxS (talk) 00:38, 24 February 2019 (UTC)

original combination (P1403)Edit

Hello, I would want the original combination of a taxon, but not the label of the value stored within this property statment, but the value of a property of the element which is itself the value of this property. Example:

for Ophioderma teres (Q2245699) the value of original combination (P1403) is Ophiura teres (Q61818290)

The issue is I dont want to have as value in the infobox the label of Ophiura teres (Q61818290), because a signifiant number of species have for label another thing that the species name, such as a common name. And original combination (P1403) is specifically about the taxon name.

What would be ideal would be to display in the infobox:

for Ophioderma teres (Q2245699)
the value of original combination (P1403) is Ophiura teres (Q61818290)
what to display is the taxon name (P225) of Ophiura teres (Q61818290) written in italic, a space, followed the taxon author citation (P6507) of Ophiura teres (Q61818290) written in normal
in summary → Original combination : Ophiura teres Lyman, 1860

Regards, Christian Ferrer (talk) 10:29, 25 February 2019 (UTC)

@Christian Ferrer: For Ophioderma teres (Q2245699) the label is returned like this:
  • {{#invoke:WikidataIB |getValue |fwd=ALL |osd=n |lp=: |noicon=y |P1403 |qid=Q2245699}} → Ophiura teres (the label)
I think we can build your request from two calls. For Ophioderma teres (Q2245699):
  • {{#invoke:WikidataIB |getPropOfProp |fwd=ALL |osd=n |lp=: |noicon=y |prop1=P1403 |prop2=P225 |qid=Q2245699}} → Ophiura teres (the taxon name of the original combination)
  • {{#invoke:WikidataIB |getPropOfProp |fwd=ALL |osd=n |lp=: |noicon=y |prop1=P1403 |prop2=P6507 |qid=Q2245699}} → Lyman, 1860 (the taxon author citation of the original combination)
Here's the result. For Ophioderma teres (Q2245699):
  • ''{{#invoke:WikidataIB |getPropOfProp |fwd=ALL |osd=n |lp=: |noicon=y |prop1=P1403 |prop2=P225 |qid=Q2245699}}'' {{#invoke:WikidataIB |getPropOfProp |fwd=ALL |osd=n |lp=: |noicon=y |prop1=P1403 |prop2=P6507 |qid=Q2245699}}Ophiura teres Lyman, 1860
Is that what you need? --RexxS (talk) 00:50, 27 February 2019 (UTC)
@RexxS: Yes exactly, the issue is that in the infobox we can't call directly "Q2245699", as it comes itself from a value taken from a property of the first item. Christian Ferrer (talk) 04:31, 27 February 2019 (UTC)
And that, of course, is the reason I wrote the function getPropOfProp which allows you to fetch a property from second entity where that entity is a property of a first entity.   --RexxS (talk) 17:37, 27 February 2019 (UTC)
@RexxS: Oh sorry. I do not really have any skills. I hack a bit sometimes by copying, but many things are beyond my comprehension. In fact I missed that the qid you used was Q2245699 and not Q61818290! → my fault. That's great, it's exactly that, thanks you very much. I will try to integrate that to the sandbox! Christian Ferrer (talk) 17:54, 27 February 2019 (UTC)
  Done copied to the infobox Christian Ferrer (talk) 13:36, 2 March 2019 (UTC)

Original publication of original combination (P1403)Edit

  • @RexxS: When you have time, can you check the code below, please? it don't work and I'm not able to go further.

{{#if:{{#property:P5326| from={{#invoke:WikidataIB |getPropOfProp |fwd=ALL |osd=n |lp=: |noicon=y |prop1=P1403 |prop2=P5326 |qid={{#invoke:WikidataIB |getQid |qid={{{qid|}}} }} }} }}|<tr {{#ifeq:{{{mobile|n}}}|y||class="wdinfo_nomobile"}}><th class="wikidatainfobox-lcell">{{ucfirst:{{#invoke:WikidataIB |getLabel |Q55155646}} }} (of ''{{#invoke:WikidataIB |getPropOfProp |fwd=ALL |osd=n |lp=: |noicon=y |prop1=P1403 |prop2=P225 |qid={{#invoke:WikidataIB |getQid |qid={{{qid|}}} }} }}'')</th><td {{#ifeq:{{{wrap|n}}}|y| style="white-space: nowrap"}}><div class="mw-collapsible mw-collapsed">{{#invoke:WikidataIB |getPropOfProp |fwd=ALL |osd=n |lp=: |noicon=y |prop1=P1403 |prop2=P5326 |qid={{#invoke:WikidataIB |getQid |qid={{{qid|}}} }} }}</div></td></tr>}}

I want to retrieve publication in which this taxon name was established (P5326) from the item quoted in original combination (P1403), same principle as above
Example:for Ophiactis savignyi (Q2766693)
the value of original combination (P1403) is Ophiolepis savignyi (Q61792100)
in Ophiolepis savignyi (Q61792100) the value of publication in which this taxon name was established (P5326) is System der Asteriden (Q51393288)
Of what I want to have at the end is:
Original publication (of Ophiolepis savignyi) = System der Asteriden (BHL page)

In summamy I would want to have the same thing,which work well, than:
{{#if:{{#property:P5326| from={{#invoke:WikidataIB |getQid |qid={{{qid|}}} }}}}|<tr {{#ifeq:{{{mobile|n}}}|y||class="wdinfo_nomobile"}}><th class="wikidatainfobox-lcell">{{ucfirst:{{#invoke:WikidataIB |getLabel |Q55155646}} }}</th><td {{#ifeq:{{{wrap|n}}}|y| style="white-space: nowrap"}}><div class="mw-collapsible mw-collapsed">{{#invoke:WikidataIB | getValue | rank=best |qid={{#invoke:WikidataIB |getQid |qid={{{qid|}}} }} |P5326 |fwd={{{fwd|ALL}}} |osd={{{osd|no}}} |linkprefix=":"|qlinkprefix=":"}} {{wdib |ps=1 |P5326 |qid={{#invoke:WikidataIB |getQid |qid={{{qid|}}} }} |qual=P687 |qualsonly=y |qprefix=[ |qpostfix=" (BHL page)"]}}</div></td></tr>}}

but where publication in which this taxon name was established (P5326) is from another item, as we did just above. Christian Ferrer (talk) 13:36, 2 March 2019 (UTC)

Maps ofEdit

Hello. With MisterSynergy's MsynBot's recent work, there now are about 13,000 Wikidata items using Commons maps category (P3722). I'm not exactly sure how everything works but I guess this template here can probably backtrack those uses and use that to generate content in categories such as Category:Maps of Široki Brijeg, where there is none for the moment (even if Široki Brijeg (Q391729) has a Commons maps category (P3722) statement pointing to this categry). Give this some thoughts. Maybe we could display something? Like a map-oriented version of what already shows up in Category:Široki Brijeg for instance? We may use route map (P15), locator map image (P242) and the likes to display stuff there. Thierry Caro (talk) 00:31, 4 March 2019 (UTC)

@Thierry Caro, MisterSynergy: This means that Široki Brijeg (Q391729) now has Commons maps category (P3722)=Category:Maps of Široki Brijeg - however, that category does not have a sitelink on Wikidata, which means that there's no way for the infobox to get from Category:Maps of Široki Brijeg to Široki Brijeg (Q391729). Another case is England (Q21), where Commons maps category (P3722)=Category:Maps of England, and that category does have a sitelink to Category:Maps of England (Q8607358), but that item does not then link to Q21 in any way. Perhaps I'm misunderstanding things here (@RexxS: any comments?), but linking to Commons using a 'string' datatype seems to be completely useless, you need to use an 'item' format as the topic's main category (P910)/category's main topic (P301) pair does. Thanks. Mike Peel (talk) 00:11, 5 March 2019 (UTC)
OK. You did a great job explaining the problem. We are not going to have a lot of Maps of categories with dedicated Wikidata items, which means not much can happen eventually. Thierry Caro (talk) 01:09, 5 March 2019 (UTC)
@Thierry Caro: Technically, it's quite straightforward to go through all of the categories that Commons maps category (P3722) links to, and to bot-create new Wikidata items for those categories (where they don't exist already), while adding something like category's main topic (P301) to link them to the main item. It's a community issue, not a technical one. Thanks. Mike Peel (talk) 01:34, 5 March 2019 (UTC)

Incorrect award categoryEdit

Category:Best Actress German Film Award winners contains lots of people who may have won a German Film award, but I'm quite sure that none of the men listed there have received the Best Actress award. It should be Category:German Film Award winners instead. --Sitacuisses (talk) 20:26, 5 March 2019 (UTC)

Category:Gerd Baumann is associated with Gerd Baumann (Q1510407), which has the property award received (P166). The value of that is Deutscher Filmpreis (Q708731), which has the property category for recipients of this award (P2517). That has two values: Category:Best Actress German Film Award winners (Q8298321) and Category:German Film Award winners (Q7818235). The logic in the infobox is only doing what it is supposed to. I've deprecated the value Category:Best Actress German Film Award winners (Q8298321) on Wikidata, and commented on the talkpage, but I doubt that the locals will see the problem in the way that we have. --RexxS (talk) 22:08, 5 March 2019 (UTC)
I've made some more changes [2] [3] to Deutscher Filmpreis (Q708731) and Category:Best Actress German Film Award winners (Q8298321). I don't actually know how subcategories are modelled in Wikidata, but the current situation seems more logical to me. The effects are soaking through very slowly: Half a day later, less than 10% of the affected categories have moved.
Also, in Category:German Film Award winners the subcategory Best Actress German Film Award winners‎ should be separated from the individual names. --Sitacuisses (talk) 12:42, 6 March 2019 (UTC)
Corrected the latter here. Laddo (talk) 13:44, 6 March 2019 (UTC)
@Sitacuisses, Laddo: Thanks both of you. I think the Wikidata structure is much clearer now, and it looks like we will soon be back to normal with the categories. --RexxS (talk) 22:19, 6 March 2019 (UTC)
@Sitacuisses, Laddo, RexxS: I've run through those categories making null edits, Category:Best Actress German Film Award winners is now empty, and Category:German Film Award winners has 140 subcategories that should be up-to-date. Is that the expected outcome? Thanks. Mike Peel (talk) 22:38, 8 March 2019 (UTC)
@Mike Peel, Sitacuisses, Laddo: thanks Mike. Comparing Category:German Film Award winners with en:Category:German Film Award winners (which is manually maintained) gives me the impression that all is well now. Cheers --RexxS (talk) 23:09, 8 March 2019 (UTC)
Thanks, but not all is well. Now we have a category tree with the top level defined in Wikidata, but the subcategories still need to be added at Commons. This is confusing at least and could lead to overcategorization. And Cat-a-lot won't move actresses from "German Film Award winners" to "Best Actress German Film Award winners‎". --Sitacuisses (talk) 13:29, 9 March 2019 (UTC)
@Sitacuisses: I think this needs better modeling on Wikidata. Ideally each type of award would have its own Wikidata entry, rather than just one, and those then use category for recipients of this award (P2517) to link to the appropriate commons category item. @GerardM: is this something you might be interested in helping sort out? Thanks. Mike Peel (talk) 17:00, 9 March 2019 (UTC)

Display title?Edit

Would it be possible to implement control over the infobox top caption or title so as to be able to properly display ships' names in italics, for example? Jay D. Easy (talk) 18:28, 15 March 2019 (UTC)

@Jay D. Easy: are you looking for a parameter that would control the display manually, or do you want to have it done automatically? Could you give me any actual examples of infoboxes where you want a different styling for the caption, please? --RexxS (talk) 00:23, 16 March 2019 (UTC)
@RexxS: manually seems most feasible to me. Maybe with a parameter that takes "y" or "1". Category:USS Polaris (ship, 1871) is one example. Jay D. Easy (talk) 00:28, 16 March 2019 (UTC)
@Jay D. Easy: I don't think it's easy to ascertain which part of the title is to be italicised, as I assume books, etc. will have a similar requirement, but with different rules, so a yes/no parameter seems insufficient. I've implemented instead a title parameter that allows you to manually specify the title, and I've replaced
  • {{Wikidata Infobox}}
  • {{Wikidata Infobox/sandbox|title=USS ''Polaris'' (ship, 1871)}}
in Category:USS Polaris (ship, 1871) as a demonstration. See what you think. --RexxS (talk) 11:05, 16 March 2019 (UTC)
@RexxS: yours is a better idea, I have to admit. Simple but effective. And it looks good. So, thank you for you effort! You have my vote (in case we're looking for consensus). Jay D. Easy (talk) 18:34, 16 March 2019 (UTC)
Yes, seems quite robust, and mimics the familiar idiom of piped links (except for the parameter ID). Parsing such names to identify non-italicized parts would seem pretty unfeasible in many cases unless the naming system at the source allowed for various ‘prefix’, ‘disambiguator’, &c. fields as separate components of a title.—Odysseus1479 (talk) 20:00, 16 March 2019 (UTC)
@RexxS: and all: this isn't going to work as currently coded, as it is not multilingual. E.g., see 1871)?uselang=ja compared with 1871)&oldid=342819691&uselang=ja. I think it's more important to keep the multilingual support than it is to tweak the English label formatting. Thanks. Mike Peel (talk) 10:53, 17 March 2019 (UTC)

Small favourEdit

I use this template a lot and I'm tired of writing every time "Wikidata Infobox" between the double {} signs. Is there any special aid to do that more easily? I mean when we are editing a cat, at the bottom of the page where I took the { sign, where it says "Standard" etc, could we not have a full written form of this to copy into the cat? Or at least make it possible to write WI instead of the whole two words? BTW at that area I refer to there is no "cat see also" thingy either, every time I need to use it I employ the "cat redirect" thing and change the letters. Am I too lazy to ask for these gadgets? Or in fact they all exist somewhere and I'm too stupid to find and enjoy them? Quedo atento a sus comentarios. --E4024 (talk) 00:35, 16 March 2019 (UTC)

@E4024: I've created Template:WI as a redirect to Template:Wikidata Infobox, as the simplest solution. Changes to the toolbars, etc. are a hassle to get consensus for, but redirects are cheap and easy. See if that helps. Cheers --RexxS (talk) 10:36, 16 March 2019 (UTC)
P.S. Don't use {{Wi}} or {{Wi}} as they already exist as shortcuts for the interlanguage links to the Italian Wikipedia. --RexxS (talk) 11:11, 16 March 2019 (UTC)
@E4024: Yes; see: Using AutoHotKey macros to make typing – and life – easier. I add the template by typing just three characters: "\wx". Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 22:15, 9 April 2019 (UTC)

"upload media" in WD Infobox--really annoyingEdit

When/how did "upload media" appear in the Infobox? It's really annoying when:

  • a) the WD infobox is providing data to the user, which is a different user function than a request for images, and
  • b) "upload media" it appears right below an exiting image, and
  • c) "upload media" appears in conjunction with numerous images already on the commons page.
  • Thanks. Prburley (talk)
I agree. Simpler is better. --Animalparty (talk) 13:44, 3 April 2019 (UTC)
That was Special:Diff/343385140. Jean-Fred (talk) 15:13, 3 April 2019 (UTC)
@Prburley, Animalparty, Jean-Frédéric: The link is there to let you upload an image directly to the category, rather than having to upload and then find a category to add the uploaded file to. I'd rather not lose the functionality if possible, but I'd be happy to move it to a less prominent position in the infobox, or do you have other suggestions for improving it apart from just removing it? Thanks. Mike Peel (talk) 17:40, 3 April 2019 (UTC)
@Mike Peel: I'd vote to remove it completely in order to not mix user functions. Otherwise, I'd put it in a tiny font next to the "edit infobox" pencil at the bottom of the box. Thanks! Prburley (talk)
I had experimented a while ago with something a bit similar at {{Upload picture from category}} (which I just updated to the latest Wikimedia style guide design).
I think if we want something like that, then it should be on all categories, not just the ones with the infobox (although, granted, that’s a pretty good start for coverage ;-))
Alternatively, it could be added by the infobox, but not made part of it − could be moved in a similar fashion to {{Top icon}} − just made {{Upload picture from category icon}} and added it to Category:Foreground flowers as an example.
Some thoughts :) Jean-Fred (talk) 08:28, 4 April 2019 (UTC)
Including {{Upload picture from category icon}} sounds good. I've demo'd that in {{Wikidata Infobox/sandbox}} at Category:Andromeda Galaxy - @Prburley, Animalparty: what do you think? @Jean-Frédéric: the aim is to have the infobox in all categories, so hopefully a separate roll-out of the upload template wouldn't be needed (unless it can be added in a non-template way). Thanks. Mike Peel (talk) 17:15, 4 April 2019 (UTC)
@Mike Peel: Oh, I would definitely get that rolled-out in a non-template way − what I have in mind would be something akin to the auto-banner we have on all article talk pages on French-language Wikipedia (eg fr:Discussion:Victor Hugo, make sure your interface is in French), where it’s included via system messages. Jean-Fred (talk) 18:03, 4 April 2019 (UTC)
@Jean-Frédéric: I just discovered an issue with this: the box does not appear on mobile. Can you fix that somehow please, as that's one of the elements that should be shown in the mobile view? Thanks. Mike Peel (talk) 06:31, 16 April 2019 (UTC)
Ah, indicators are not supported on mobile >_> (per phab:T75299). Geez, what’s the point of using such built-in syntax… Anyone knows of a If mobile syntax ? :-þ Jean-Fred (talk) 08:16, 16 April 2019 (UTC)
@Jean-Frédéric: You can set separate css for mobile devices, see "wdinfo_nomobile" in Template:Wikidata Infobox/styles.css. Perhaps something can be done with that? Also, for a specific skin, see [4]. Thanks. Mike Peel (talk) 08:28, 16 April 2019 (UTC)
@Prburley, Mike Peel: I don't see the difference at the sandbox or Andromeda page. My suggestion is to put "Upload media" in a tiny font on the line below "Reasonator Scholia Statistics" at the bottom of the infobox. Better yet, I like Jean-Frédéric's suggestion of placing the Upload media at the top of the page and removing it from the infobox--which you may have done with that blue "upload a file" button. Thanks! Prburley (talk)

Removal of birth and death categoriesEdit

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

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

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

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

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

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

Commemorative plaqueEdit

If there is no image of a tombstone can we have the template display any commemorative plaque instead? I added the plaque image as if it were a tombstone here to show what it would look like: Category:Annemarie_Loepert. RAN (talk) 05:53, 24 April 2019 (UTC)

Personally I'm in favor of keeping the infobox simpler, rather than overloaded. If a plaque image is added, then a tombstone image later, we'd have at least three images (and really, why do we need to show a grave image at all)? Where does it stop? Why not a flag of the nationality? Why not a photo of a person's house? Why not a link to where I can buy tickets to a movie about the subject? The more bloated the infobox becomes, the poorer the overall quality across Commons: for every nicely composed plaque or gravestone image there are handfuls of clunky photographs of crumbling stone with little to no information value. This is Commons, not Wikipedia, the infobox doesn't have to do and be everything. And since there's still no way of locally customizing or overriding the raw data from the almighty but unthinking Wikidata, we can't pick and choose. --Animalparty (talk) 17:47, 24 April 2019 (UTC)
I partially agrees with Animalparty: including several images probably clutters too much this thing. Nevertheless I consider interesting knowing "from Commons" when a Wikidata property to link to Commons (Q18610173) is filled in wikidata and when not (tomb image, night image, winter image, location map image, indoor image, collage imagen, plan view image...) but maybe that could be better achieved through others means (more indirect ones) than in fact "showing" these images in the infobox when they are linked in wikidata. Cheers. Strakhov (talk) 18:18, 24 April 2019 (UTC)

license (P275)Edit

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

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

...and main subject (P921)? Despite of being already included, it isn't transcluded in the infobox :) Strakhov (talk) 15:30, 8 May 2019 (UTC)
@Strakhov: Are you looking at categories about people or things? It's currently not included for people. Thanks. Mike Peel (talk) 18:36, 8 May 2019 (UTC)
@Mike Peel: I'm thinking about works/editions mostly. I don't know if it's just me, but I don't see "main subject".. here nor here, despite each of them having this property filled with several wikidata values. Strakhov (talk) 18:43, 8 May 2019 (UTC)
@Strakhov: Aah, I see, there's a bug. It should show in {{Wikidata Infobox/sandbox}} now, I'll roll that out soon. Thanks. Mike Peel (talk) 18:52, 8 May 2019 (UTC)
Yes now main subject (P921) works in the sandbox. Christian Ferrer (talk) 20:08, 8 May 2019 (UTC)
Yep, now it's OK (sandbox-wise). Thanks. Strakhov (talk) 15:38, 9 May 2019 (UTC)
Why? --Animalparty (talk) 17:11, 8 May 2019 (UTC)

Non-administrative entity in multiple administrative entitiesEdit

Category:Víziváros Office Center (Budapest) shows Víziváros, Budapest I. District etc. This is wrong: the building is in the 2nd district of Budapest. The Víziváros is split between the two districts, but it’s obvious from Wikidata which one applies: Víziváros Office Center (Q63952979) has both location (P276): Víziváros (Q1415725) and located in the administrative territorial entity (P131): Budapest II. District (Q1068701). In this case, the infobox should choose the administrative entity that is also listed on the item as P131. —Tacsipacsi (talk) 14:53, 19 May 2019 (UTC)

@RexxS: Perhaps you could modify the location code to handle this? Although I'm not sure how standard this approach is on Wikidata. Alternatively, @Tacsipacsi:, would it make sense to have two Wikidata items, one for the part of Víziváros in the 1st district, the other for the part that's in the second district? Thanks. Mike Peel (talk) 06:58, 20 May 2019 (UTC)
@Mike Peel, Tacsipacsi: If both location (P276) and located in the administrative territorial entity (P131) are present in a given entity, the algorithm has to decide on whether to follow the chain on one or the other. Please see Template talk:Wikidata Infobox/Archive 2 #Displaying of non-administrative locations, where I was asked to restore precedence to location (P276), which I did. I don't think I can alter that logic. So in the case of Víziváros Office Center (Q63952979), the code will ignore located in the administrative territorial entity (P131)=Budapest II. District (Q1068701) and follow location (P276)=Víziváros (Q1415725). The entity Víziváros (Q1415725) then has two alternatives for its property located in the administrative territorial entity (P131) and the problem is how to decide on which one to choose. At present, the code searches each alternate for a qualifier applies to part (P518) and scans those for a match to the previous location. So now, you want the code to also check if that previous location had a located in the administrative territorial entity (P131) that matches one of the alternatives. Is this a common case? Anyway I've sandboxed a possible solution:
You may want to test it further. Cheers --RexxS (talk) 18:38, 20 May 2019 (UTC)
Thanks! I hope it’s not too common, but I don’t think it’s the only such situation on Earth. Creating multiple entities is not an option, as the Víziváros is one single entity (as defined in the relevant decree 94/2012 (XII.27.) Főv. Kgy. rendelet). This approach (remembering previous P131) is exactly what I imagined, thanks! —Tacsipacsi (talk) 19:30, 21 May 2019 (UTC)


SELIBR ID (P906) is going to be depreciated and instead we have Libris-URI (P5587) please update - Salgo60 (talk) 18:30, 30 May 2019 (UTC)

Health infobox for countriesEdit

Is there a way to display

on categories for "health in <country>" (see Special:EntityUsage/Q64027457)?

At d:Wikidata:WikiProject Medicine/health by country, I listed current categories/values. The idea is to eventually add more indicators (only a few currently have data at Wikidata).

These categories should have a category's main topic (P301) with a value that has instance of (P31)=health by country or region (Q64027457).

The P2250/P4841 would be in the item with linked from location (P276) (or, if not present, country (P17)). I could add P276 everywhere if that simplifies it.

Eventually, something similar could be done for healthcare by country or region (Q64027602) (Special:EntityUsage/Q64027602). Jura1 (talk) 13:53, 17 June 2019 (UTC)

  • I added the first two properties in the sandbox. Seems to work. --Jura1 (talk) 10:37, 24 June 2019 (UTC)

{{Edit request}} Please add these changes from the sandbox. Note also Template_talk:Wikidata_Infobox#Health_infobox_for_countries.

@Jarekt: may I ask you here too? Jura1 (talk) 23:06, 1 July 2019 (UTC)

Jura1, I do not know much about ((tl|Wikidata Infobox}}, so I would prefer to leave edits to that template to User:Mike Peel. --Jarekt (talk) 02:27, 2 July 2019 (UTC)
@Jura1: I've been on vacation, I'll try to have a look at this later this evening. Thanks. Mike Peel (talk) 06:18, 2 July 2019 (UTC)
  • I also added check for economy and education, but with the most recent sandbox edit all three appear in all three. The idea is to display health indicators in health by country, economic ones in economy by country, etc. --Jura1 (talk) 16:52, 2 July 2019 (UTC)
@Jura1: This is interesting! I thought you were just including the properties only in given cases, but you're actually fetching them via qid={{#invoke:wd | property | raw | P276 |eid={{#invoke:wd | property | raw | P301}} }}. At the least we should do that using WikidataIB (@RexxS: is that possible?). But in general, I'm hoping that we can follow category combines topics (P971) to add information like this, and I wonder if there's a more general solution. Mind if I think about this for a few days? Thanks. Mike Peel (talk) 17:02, 2 July 2019 (UTC)
@Mike Peel: I think it would be nice if it already displayed. I don't particularly care how it's coded. I suppose as long as nothing breaks, it should be fine.Jura1 (talk) 17:15, 2 July 2019 (UTC)
@Mike Peel: Does this depend on the behaviour of |eid= in Module:Wd? That is, the function returns nothing if the parameter exists but is blank? I've implemented a |eid= that should mimic that behaviour in Module:WikidataIB/sandbox if you want to test it when you have time. --RexxS (talk) 20:17, 2 July 2019 (UTC)
BTW, that part is only loaded if check for health by region -->{{#if:{{#invoke:WikidataIB|checkvalue | val=Q64027457 | P31 | qid={{#invoke:WikidataIB |getQid |qid={{{qid|}}} }}}} | <!-- is true. Checking for P971 might work too. The economy one might need some work, as currently there isn't much consistency. Jura1 (talk) 05:27, 3 July 2019 (UTC)
  • @Mike Peel: as the suggested version works, would you mind adding it for now and optimizing the code later? Jura1 (talk) 16:25, 4 July 2019 (UTC)
    @Jura1: That sounds reasonable - done. Thanks. Mike Peel (talk) 17:19, 4 July 2019 (UTC)

P996 as alternative image locationEdit

Module:Artwork uses scanned file on Wikimedia Commons (P996) as an alternative to image (P18). Maybe {{Wikidata Infobox}} do the same. Also if there is title page number (P4714) qualifier used than it should be used as well. For example: [[File:{{#property:P996|from=Q19669696}}|thumb|page=9]] gives image on the right. I was trying to look up the page number (9) through {{#invoke:WikidataIB |getQualifierValue |qid=Q19669696 |1=P996 | pval={{#property:P996|from=Q19669696}} |qual=P4714}} but did not get it to work: "". --Jarekt (talk) 12:54, 24 June 2019 (UTC)

Normalize areas?Edit

Is there a chance areas in the infobox map could be normalized? See for example Category:Samsølabyrinten vs Category:Lysbro Skov vs Category:Enø --Hjart (talk) 18:39, 29 June 2019 (UTC)

following redirects on wikidataEdit

Hi, it seems that if name items on wikidata are links through redirects the box does not follow them. There is i.e. the red category Category:Q28053272 (given name). The content is because all the cats, like Category:Auguste Pattberg, within it are using d:Q28053272 (Auguste) which is a redirect to d:Q18010311 (Auguste) (I merged male and female names to unisex names some days ago). This is a bug in my eyes and should be fixed. Thx. --JuTa 16:32, 7 July 2019 (UTC)

The same applies for Category:Q18220903 (given name) for unisex given name Category:Jan (given name). --JuTa 17:12, 7 July 2019 (UTC)
  • If you would avoid merging items on Wikidata, this wouldn't happen. Jura1 (talk) 18:22, 7 July 2019 (UTC)
Yes, but isnt that sensefull? These are unisex names and should be handeled together, shouldnt they? --JuTa 18:45, 7 July 2019 (UTC)
  • Currently, you seem to be merging merely for a category problem at Commons. Please avoid doing that.
The first is similar to "Jean": it's a male given name in French and female one in English, but that doesn't make it a unisex given name. Jura1 (talk) 20:29, 7 July 2019 (UTC)
So the unisex commons category on commons should be connected to the male item on wikidata, but not the the female one. Hmmmm --JuTa 20:31, 7 July 2019 (UTC)
I have no opinion on this. Maybe you need to link manually or with different code. Jura1 (talk) 16:41, 10 July 2019 (UTC)
PS: Even in case my merges on wd are incorrect, the box should follow redirects on wikidata anyhow. There are and will be correct merges on wikidata. --JuTa 20:35, 7 July 2019 (UTC)
@JuTa, Jura1: Shouldn't links to Wikidata redirects be shortlived? They should really be automatically moved over to the new destination, as they can cause a variety of issues if they aren't. I'm not even sure that the Wikidata interface follows them automatically. But @RexxS: perhaps this could be handled by WikidataIB anyway? Thanks. Mike Peel (talk) 19:01, 9 July 2019 (UTC)
@Mike Peel: I don't understand how you expect WikidataIB to "follow" a redirect. The code reads the contents of the database for a given entity-ID. How would it know that is a redirect? Can you give me some examples to work from? --RexxS (talk) 23:31, 9 July 2019 (UTC)
@RexxS: The original example seems to have been reverted, so here's an alternative: Q65098513 (Q65098513) redirects to Category:Culture in Pescara (Q26204988), so if WikidataIB found a property value that's Q65098513, then it should 'follow' that and display information, such as the label, from Q26204988 instead. Thanks. Mike Peel (talk) 07:03, 10 July 2019 (UTC)
@Mike Peel: for Q65098513 (Q65098513) and Category:Culture in Pescara (Q26204988), reading property Commons category (P373):
  • {{wdib|ps=1|qid=Q65098513|P373}} → Culture of Pescara
  • {{wdib|ps=1|qid=Q26204988|P373}} → Culture of Pescara
So it looks like WikidataIB already "follows" the redirect for properties. However the underlying code doesn't do the same for the label:
  • {{#invoke:WikidataIB|getLabel|qid=Q65098513}} → Q65098513
  • {{#invoke:WikidataIB|getLabel|qid=Q26204988}} → Category:Culture in Pescara
That's an issue for the mw.wikibase.getLabel call in the Wikibase Client Scribunto interface. Only thing I can suggest is to file a Phabricator ticket, sorry. I simply don't have any means of recognising when a page is a Wikidata redirect, in order to create a work-around. --RexxS (talk) 14:12, 10 July 2019 (UTC)
At Wikidata, eventually redirects get replaced by the new value by bot. An odd thing I encountered at Category:Twr_Mawr_Llanddwyn_Lighthouse is that "different from" points to the category that had been linked previously to that item. I tried various edits on Wikidata, but that didn't help. Jura1 (talk) 16:41, 10 July 2019 (UTC)
Aah, this is phab:T157868. It looks like an issue that's been around for quite a while. I've changed it to high priority on phabricator. Thanks. Mike Peel (talk) 17:57, 10 July 2019 (UTC)
Query Server doesn't either. The bot takes care of it. Category:Twr_Mawr_Llanddwyn_Lighthouse is a more complex problem. Somehow the new sitelink doesn't get loaded. Jura1 (talk) 18:46, 10 July 2019 (UTC)
@Jura1: That was a different issue, you had updated the sitelink but not Commons category (P373). removing the P373 value has fixed it. Thanks. Mike Peel (talk) 19:16, 10 July 2019 (UTC)

sort spouses chronologicallyEdit

Currently, when a person has multiple spouses in Wikidata, it appears they are listed here by order of entry in Wikidata (see e.g. Category:Elizabeth Taylor or Category: Jo Davidson). Where dates are given, can the infobox be changed to more intuitively display them chronologically? Also, in my opinion, rounding off to year of marriage would be sufficient and preferable to exact date, which tends to make the infobox overly crowded. --Animalparty (talk) 22:50, 14 July 2019 (UTC)

@RexxS: How difficult would this change to the ordering be to implement in Module:WikidataIB? It would be a useful modification to make, since the entries aren't necessarily stored on Wikidata in date order. Reformatting dates would be a lower priority though. Thanks. Mike Peel (talk) 18:32, 17 July 2019 (UTC)
@Mike Peel: There already exists a parameter |qsorted= which should sort qualifiers when set to true, but unfortunately it only does an alphanumeric sort at present. That doesn't actually help this case anyway, as there are only single values of each date qualifier, and I don't have a means at present of sorting property values by their qualifier values. Sorting dates is a pain unless I do a large re-write to also return the timestamp, use it to sort the dates and then discard it, especially as the calls to complex date will return all manner of character sets when internationalisation takes place.
The other part would be to create the ability to truncate dates to a year independently for qualifiers, which ought to be relatively easy if we add yet another parameter like qualifierdateformat (alias qdf), which can be set to "y" when needed, because the code to handle all of that is already in the module.
I've sandboxed that to try it, and set the default qualifier format to 'year'. That may have unforeseen consequences elsewhere, so we'll need to think about whether to leave the default at dmy and just use |qdf=y when needed. Anyway, for now, Elizabeth Taylor (Q34851), spouse (P26):
We may need to put sorting on the back-burner and come back to it while I do the research; perhaps I can find some time at the Wikimania hackathon to sort it out. --RexxS (talk) 00:11, 18 July 2019 (UTC)

Edit request - cleanupEdit

{{Edit request}}

Hi. Can I request that

.taxontree-rcell {

.taxontree-row {

be changed to

.taxontree-row {

or removed entirely, since the rules are empty? Also, can

.wdinfobox_hide {
	display: none;

#wdcreator {
	display: none;

be combined to

#wdcreator {
	display: none;

which has the same result but removes the extra lines? Thanks, --DannyS712 (talk) 17:12, 12 July 2019 (UTC)

@DannyS712: I've moved your question here from the style talk page, I hope that's OK. I'd prefer to keep the formatting as it is, as it's more human-friendly, unless there's a reason why making these changes is good? Thanks. Mike Peel (talk) 08:37, 28 July 2019 (UTC)

Display P1559?Edit

I have a suggestion, let the box display name in native language (P1559) if it's available. It may help users using non-Latin and non-Cyrillic scripts a lot. (I am Chinese but I use English interface.)--Roy17 (talk) 17:04, 6 August 2019 (UTC)

@Roy17: It's in the sandbox, please give it a go. Thanks. Mike Peel (talk) 16:32, 21 August 2019 (UTC)
@Mike Peel: thx a lot! I just tried previewing Category:Alan Li Tung Sing and Vladimir Vysotsky using different UI languages. I'm sorry to say, it doesnt look very good. The change is gonna add a row name in native lang and a line below date of birth? The row looks bad for languages that have a long name label for P1559, because for example in English the width of the box makes the four-word phrase break into three rows, resulting in a tall row. IMHO the additional line beneath DoB is good enough.
Unless, the infobox is widened a bit. It seems to be way too narrow in its current form. Long entries often break into lines of one to three words. See Vysotsky for example. The property label column and the entries column are equal in width. The Spouse entry is broken into lines of single words. So I'd suggest a wider infobox, and the ratio of property label column to entries column should be 2:3, 1:2, or 1:3. Examples from frwp and yuewp.--Roy17 (talk) 17:07, 21 August 2019 (UTC)
@Roy17: I don't want to widen the infobox as that leaves less space for the media in the category, which is the main content of Commons. A tall infobox isn't too much of a problem here, though, particularly if there are lots of media files. It looks like @Laddo: added the line below the date of birth without me noticing - but I don't like that solution as it implies that name in native language (P1559) is the name at birth, which is often wrong. So I've removed that, and kept it as a separate row for now, let's see how that goes. Thanks. Mike Peel (talk) 17:24, 21 August 2019 (UTC)
Sorry Mike I should have mentioned that test here. Indeed name in native language (P1559) is not related to birth :S Thanks - Laddo (talk) 21:46, 21 August 2019 (UTC)
@Mike Peel: well, keeping it as a row and removing the line under DoB are good. Check Vysotsky or Category:Rachel Weisz for the infobox. It currently takes up more than one but less than two media files' width. A little bit wider would not leave less space.--Roy17 (talk) 17:42, 21 August 2019 (UTC)
I assume it depends on users' screen resolution too... I'm using a browser in full screen and my screen is 1366 X 768. The infobox takes up roughly 1.2 columns.--Roy17 (talk) 17:45, 21 August 2019 (UTC)

Two suggestions:

  • Checking sandbox output on Benyamin Netanyahu, I suggest to use |qual=NONE to avoid displaying pointlessly the associated language;
  • Also "Name in native language" is quite long and not that useful, since the value is pretty self-explanatory; that name could be centered across the infobox, just like the English name (in bold) gets centered at the top.

Laddo (talk) 22:24, 21 August 2019 (UTC)

I had thought about Laddo's suggestion, to put the native name beneath the title, but then it would look rather strange to Latin users (the largest group here) when they look at any entities with a Latin native name (again the largest group). They just show up as two identical or very similar lines. But I support a label either way, in a row entry or as a line beneath the title.
It would also be quite beneficial if title (P1476) or native label (P1705) is displayed for books, music albums, movies, etc. For example, a Chinese-literate user would immediately understand what the long pinyin name Category:Chong sheng hai cao di si ji wei ti sheng wu qun ji qi di zhi yi yi actually means. The same applies to Japanese, Korean, all the languages on the Indian subcontinent, etc.--Roy17 (talk) 14:24, 25 August 2019 (UTC)

Has petEdit

I want "Has pet" has pet (P1429) to display at my user:ssr, how do I make it? --ssr (talk) 15:40, 16 August 2019 (UTC)

@Ssr: It's now in the sandbox, although I'm not sure the items meet Wikidata's notability requirements... Thanks. Mike Peel (talk) 16:33, 21 August 2019 (UTC)

highest point (P610)Edit

Hello. We should probably display this as it would be useful for mountain ranges, trails and whatever else. Thierry Caro (talk) 05:24, 18 August 2019 (UTC)

@Thierry Caro: It's now in the sandbox, please give it a go. Thanks. Mike Peel (talk) 16:34, 21 August 2019 (UTC)
@Mike Peel: It works fine. It's ready to be implemented. Thierry Caro (talk) 20:19, 21 August 2019 (UTC)
Trails would also benefit from having terminus (P559) displayed, by the way. Thierry Caro (talk) 11:23, 22 August 2019 (UTC)
Moin Moin Thierry Caro, it is in the sandbox, too. Please check this out. Regards --Crazy1880 (talk) 17:28, 22 August 2019 (UTC)

Display P54 - member of sports teamEdit

Moin Moin Mike Peel, for the sports area it would be totally helpful if we could display P54. I'll put the external identifiers in the sandbox. Then I'd need a second opinion. Regards --Crazy1880 (talk) 17:33, 22 August 2019 (UTC)

@Crazy1880: P54 is now in the sandbox for testing [5]. Thanks. Mike Peel (talk) 17:49, 24 August 2019 (UTC)
Moin Moin @Mike Peel:, can it be that only the current club is displayed? Each club is usually marked with "Start date" and "End date". And what I personally also don't like so much is the arrangement of "games played" and "goals scored", which are in brackets directly after the "start date". What could we do? Regards --Crazy1880 (talk) 19:14, 24 August 2019 (UTC)

Stadium locationEdit

Hello! I would like to draw the attention of Wikimedia administrators one inaccuracy in the template for stadiums on the Wikimedia Commons. In the LOCATION field, instead of the current 2019 administrative-territorial structure of the country outdated information from the year of construction of the sports facility is indicated.

It turns out such nonsense: Category:Dynama Stadium, Minsk built in 1934, but instead of a location in the country BELARUS, in the Wikidata Infobox description indicates the states that existed in the 1930s on the territory of modern BELARUS — Lithuanian–Belorussian Soviet Socialist Republic, Byelorussian Soviet Socialist Republic. And it should be: LOCATION - MINSK, BELARUS.

Same thing with Category:Central Stadium, Gomel. The stadium was built in the 1920s, but Gomel Povet and Mogilyov Viceroyalty no longer exists. And it should be: LOCATION - GOMEL, GOMEL DISTRICT, GOMEL REGION, BELARUS.

By administrative-territorial structure of the Republic of BELARUS for 2019 all cities is part of the district, then the region, then the country. The capital city of Minsk is a separate administrative unit within BELARUS.

In this regard, I ask administrators to make the necessary changes to the Wikidata Infobox on the Wikimedia Commons for stadiums so that outdated information does not mislead readers. Is it possible to make changes to this template so that the location of the stadium is displayed as of today, and not at the time of construction?

Thanks for attention! --Football Beetle (talk) 20:23, 22 August 2019 (UTC)

@Football Beetle: The data displayed in the infobox is from Wikidata, you need to change things there. For your first example, I think @Tacsipacsi: already fixed it with [6]. For the second example, it was necessary to say which is the preferred value of located in the administrative territorial entity (P131) so that the historical one was not accidentally selected, see [7]. These are a bit complex to debug, sorry, as you have to follow the location tree from the Wikidata item. Thanks. Mike Peel (talk) 07:03, 23 August 2019 (UTC)

Thanks for the answer! Regarding the location of stadiums in Minsk, I’ll try to invite administrators of the Belarusian Wikipedia to make changes to Wikidata. --Football Beetle (talk) 10:28, 23 August 2019 (UTC)

@Football Beetle: My (above-linked) edit was on the Wikidata item of Minsk itself, so all places in the city should look OK. By the way, such edits require no administrator access, any autoconfirmed user can edit this item (you’re autoconfirmed as well; this right—as its name suggests—is automatically assigned by the software). You can ask for help from more experienced users if you have difficulties, but they don’t need to be administrators to be able to help.
@Mike Peel: This issue may need module change indeed. It’s fairly common to not have located in the administrative territorial entity (P131) for entities of administrative level just below country, which was the case at Minsk until now. It was complicated with the fact that this was not true in Soviet times, but all P131 statements were (are) properly qualified with start time (P580)/end time (P582). It may be worth checking them, and using only statements that are currently applicable (i.e. have no P582 qualifier, or, in rare cases, that’s in the future). —Tacsipacsi (talk) 21:54, 23 August 2019 (UTC)

@Tacsipacsi: Thanks for the answer! In the future, I will take into account the comments that you have indicated. But it would be great if information on the location of all the stadiums of the world was displayed on the Wikimedia Commons at the current moment, and not in the past tense. --Football Beetle (talk) 09:20, 24 August 2019 (UTC)
@Tacsipacsi, Football Beetle: It's best to just fix this on Wikidata if you can. An alternative might be to sort property values by date qualifiers and to only select the most recent, but as @RexxS: explained above at #sort spouses chronologically, that's rather tricky. Thanks. Mike Peel (talk) 17:46, 24 August 2019 (UTC)
@Mike Peel: I don’t know exactly how the module works, but I can imagine simply discarding statements with given qualifiers is much easier than returning the qualifier along with the statement. As I mentioned, this issue is fairly common on Wikidata (I didn’t make any measures, but come across such cases from time to time), so it’s worth dealing with. —Tacsipacsi (talk) 22:53, 24 August 2019 (UTC)


They are timeout errors on the following pages, which strangely flicker on and off. Page sometimes shows timeout and sometimes does not.

--Jarekt (talk) 13:15, 23 August 2019 (UTC)

@Jarekt, RexxS: The thing they have in common is that they use a lot of country items - e.g. "France (Q142) Other (Statements), Some labels, Title" - and those are typically big Wikidata items. Is there any Lua optimisation that could be done to reduce the amount of information fetched for each country? Otherwise I can try setting maxval to a lower number, and removing some of the qualifiers. Thanks. Mike Peel (talk) 13:47, 23 August 2019 (UTC)
@Jarekt, Mike Peel: The problem is simply the time it takes to retrieve information from each country just to display a link when there are lots of countries. I checked Category:Teenage Mutant Ninja Turtles (2014 film) and found that an edit-preview took as much as 9 seconds out of the 10 seconds allowed before time-out. The cached view naturally didn't have the same problem. So I added |linked=no to the WikidataIB call in the line that does the publication date (line 476) in the sandbox. Using the sandbox version in Category:Teenage Mutant Ninja Turtles (2014 film) reduced the preview time to under 2 seconds at the cost of unlinking all of the countries in that huge list.
  • {{#invoke:WikidataIB | getValue | rank=best | P577 | name=publication | linkprefix=":" | qlinkprefix=":" | list={{{liststyle|ubl}}} | qid=Q9653404 | spf={{{spf|}}} | fwd={{{fwd|ALL}}} | osd={{{osd|no}}} | noicon={{{noicon|yes}}} | qual=ALL |linked=no}}
    • 8 August 2014 (United States of America)
    • 16 October 2014 (Germany)
    • 8 August 2014 (Sweden)
    • 3 August 2014 (Los Angeles)
    • 6 August 2014 (New York City)
    • 7 August 2014 (Azerbaijan, Chile, Hong Kong, Mexico, Malaysia, Peru, Russia, Singapore)
    • 8 August 2014 (Canada, Estonia, Iceland, Kazakhstan, Latvia, Norway, Poland, Taiwan, Vietnam)
    • 9 August 2014 (Kosovo)
    • 13 August 2014 (Indonesia, Philippines, Serbia)
    • 14 August 2014 (Albania, Argentina, Brazil, Colombia, Cambodia, Pakistan, Slovenia, Ukraine, Uruguay)
    • 15 August 2014 (Sri Lanka)
    • 21 August 2014 (Czech Republic, Netherlands, Slovakia, Thailand)
    • 22 August 2014 (Bulgaria, Finland, Romania)
    • 26 August 2016 (Seoul)
    • 28 August 2014 (Costa Rica, Hungary, South Korea, Lebanon, North Macedonia)
    • 29 August 2014 (Republic of Cyprus, Honduras, India, Lithuania, Nepal, Panama)
    • 3 September 2014 (Egypt, Kuwait)
    • 4 September 2014 (United Arab Emirates, Denmark, Croatia, Iraq, Jordan)
    • 5 September 2016 (Bangladesh, Turkey)
    • 11 September 2016 (Australia, Papua New Guinea)
    • 12 September 2016 (Venezuela)
    • 18 September 2014 (Switzerland, Italy, New Zealand)
    • 11 October 2014 (Scotland)
    • 15 October 2014 (Belgium, France, Luxembourg)
    • 16 October 2014 (Austria, Germany)
    • 17 October 2014 (Spain, United Kingdom, Ireland, Kenya, South Africa)
    • 22 October 2014 (Malta)
    • 23 October 2014 (Greece)
    • 30 October 2014 (Portugal)
    • 31 October 2014 (People's Republic of China)
    • 2 February 2015 (special wards of Tokyo)
    • 7 February 2015 (Japan)
You can see the difference in the above call by changing to |linked=yes. I couldn't do a permanent fix in the sandbox because it's presently unsynchronised. I suggest, though, that any field where you are likely to get more than about 50 linked items ought to compromise by unlinking those items. TMNT has about 80 countries in its publication date field.
I could make the code run faster by skipping the parts where it looks for a short name and where it uses the sitelink when available, etc. so that it just gets a label, but I'd need yet another parameter to turn on the skipping because folks asked for the present functionality. --RexxS (talk) 14:51, 23 August 2019 (UTC)
@Jarekt, RexxS: OK, I've updated the current version of the sandbox to unlink those items, and also collapse the list when it gets very long. I'll probably deploy the new version tomorrow after a bit more work, so please test it to make sure it looks OK! Thanks. Mike Peel (talk) 17:34, 24 August 2019 (UTC)

Celestial coordinates problemEdit

Because Wikidata saves celestial coordinates in 360 degree decimal format (see P6257 and P6258), rather than H M S ° ' " format, the Infobox link to Wikisky shows the wrong location because Wikisky interprets the input as celestial hour/degree decimals rather than 360 degree decimals. For example, on Category:PDS 70, the link goes to [8] whereas it should go to [9]. See also Category:Andromeda Galaxy, Category:Orion Nebula, etc etc. I honestly do not know how to fix this problem, other than entirely remove it.

If that issue can be fixed, here's a couple of other minor things: I'd suggest changing "img_source=IMG_all" to "img_source=DSS2", since this by default presents a clearer sky picture than the hodgepodge of photographs that make up the current default; and change the zoom factor from 7 to 9, while this would make already major objects a bit too big, the vast majority of stars and other celestial objects are almost impossible to pick out at lower zoom factors. Huntster (t @ c) 16:20, 23 August 2019 (UTC)

Return to "Wikidata Infobox" page.