Template talk:Wikidata Infobox

From Wikimedia Commons, the free media repository
Jump to navigation Jump to search
SpBot archives all sections tagged with {{Section resolved|1=~~~~}} . 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 http://zone47.com/crotos/). 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)
  • Danmarks Kirker (edited by Nationalmuseet, Denmarks National Museum, in print versions as a long time project, started in 1919). Note, mostly there is an entrance page such as http://danmarkskirker.natmus.dk/vejle/oester-nykirke/ that can be linked, from where one or more PDFs can be downloaded. Only in a few cases (or only with tricks), direct links to the PDF can be detected, such as http://danmarkskirker.natmus.dk/uploads/tx_tcchurchsearch/Holbaek_3345-3416.pdf --Ulamm (talk) 08:36, 8 October 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) Edit this on Wikidata
{{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 Edit this on Wikidata
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 missing[edit]

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 P6375[edit]

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 street address (P6375) is 597 and usage of 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 street address (DEPRECATED) (P969)) supposed to be deprecated?--Leit (talk) 21:48, 21 January 2019 (UTC)

@Leit: That's because the 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 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 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 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 pages[edit]

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=[http://biodiversitylibrary.org/page/ |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=[http://biodiversitylibrary.org/page/ |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 locations[edit]

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. Face-smile.svg --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=[http://biodiversitylibrary.org/page/ |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 of[edit]

Hello. With MisterSynergy's MsynBot's recent work, there now are about 13,000 Wikidata items using P3722 (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 P3722 (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 P3722 (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 P3722 (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 P3722 (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 category[edit]

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 favour[edit]

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 annoying[edit]

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 categories[edit]

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

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)

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

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

Commemorative plaque[edit]

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)

copyright license (P275)[edit]

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

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

...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 entities[edit]

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)

LIBRIS is moving LIBRIS-URI[edit]

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 countries[edit]

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)

@Jura1: Heads up that there's going to be a major change to display category combines topics (P971) information shortly, see {{Wikidata Infobox/sandbox}}. Can you check that this doesn't cause any problems for your use cases, please, and let me know if the code that was added before should be removed or if it's still useful? Thanks. Mike Peel (talk) 17:17, 19 April 2020 (UTC)

  • @Mike Peel: Thanks. The testcase for health looks good and I (re-)added one for education/economics: works too. Jura1 (talk) 08:35, 20 April 2020 (UTC)

P996 as alternative image location[edit]

The evolution of worlds - Lowell.djvu

Module:Artwork uses document 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 wikidata[edit]

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}} → Category:Culture in Pescara
  • {{#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 chronologically[edit]

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 - cleanup[edit]

{{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 pet[edit]

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)
As this infobox is displayed Commons, it is up to the Commons community to decide which Wikidata info to include. I say no to "has pet", as it would push human biographical infoboxes (many already very crowded) ever further into trivial, arbitrary and indiscriminate territory. A person's pet is almost never a significant aspect. If we're including pets on, say, Barack Obama, why not height, weight, hair color, Twitter account, net worth, number of appearances on C-Span, earlobe shape, and favorite flavor of ice cream? But I am less opposed to displaying the inverse ("owned by") on pet infoboxes, as for example Bo the dog is often defined and described as "the Obama family dog". --Animalparty (talk) 23:42, 6 September 2019 (UTC)

Display P54 - member of sports team[edit]

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 location[edit]

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)

Celestial coordinates problem[edit]

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)

Displayed Wikidata QIDs not linked[edit]

It seems that for a place of birth (and probably all item values), which doesn't have a label in the user language or English, the Wikidata identifier gets displayed like this: "Q2006937". I don't think that's particularly useful considering en:WP:Readers first, anyway … but it isn't even linked! It should at least be something like "Q2006937". Thanks for any changes to this! Cheers, (pings appreciated) --Marsupium (talk) 18:27, 5 September 2019 (UTC)

@Marsupium: Can you point to some examples, please? Thanks. Mike Peel (talk) 18:15, 13 September 2019 (UTC)
Mike Peel, you can use queries like this one to find probably concerned category pages (here those where the value of place of burial (P119) has the problem), e.g. on Category:Peter Steiner. Thanks for any changes to this situation! --Marsupium (talk) 23:02, 13 September 2019 (UTC)

parameter defaultsort[edit]

Is it ok to change the line

| defaultsort = y


| defaultsort = y

? Some users might be too lazy to type and copypaste the allcaps version.--Roy17 (talk) 14:10, 13 September 2019 (UTC)

@Roy17: I'd rather not, if that's OK. The parameter is only really meant to be used temporarily (and added via bot edit), until someone can check why the conflict exists and resolves it by removing the local definition or tweaking the information on Wikidata. Also, I'm not sure if the MediaWiki software has a problem with the capital letter version, as it isn't showing up above. Thanks. Mike Peel (talk) 18:13, 13 September 2019 (UTC)
thx a lot! You're right. I shouldnt be too lazy. However, users may often want to specify defaultsort for Chinese people who dont have their common names in pinyin. For example, a person with the name 吳華 would have a surname item Wu and a given name Hua (in pinyin, the standard romanisation scheme), so sorted by Wu, Hua, but if he's a Hong Kong Cantonese and were to be sorted by his common name, it could be Ng, Wah. I'm not sure whether this can be fixed on wikidata side.--Roy17 (talk) 18:26, 13 September 2019 (UTC)

climbing route (P7309)[edit]

Hello. Can this be added to the Infobox? It would be useful for mountains and hills. Thierry Caro (talk) 18:20, 20 September 2019 (UTC)

species kept (P1990) would also be useful, this time for zoos and stuff. I would limit the number of values displayed to five, just in case. Thierry Caro (talk) 11:41, 22 September 2019 (UTC)
@Thierry Caro: Both are now in {{Wikidata Infobox/sandbox}}, please test them. I've set the second one to auto-collapse at 5, and maxvals=30, for now. Thanks. Mike Peel (talk) 13:37, 28 September 2019 (UTC)
@Mike Peel: Thank you. Both are working perfectly. You may add them to the actual template now. Thierry Caro (talk) 20:09, 28 September 2019 (UTC)
Listing five (or any limited number of) species kept for a zoo seems pointless. Which five? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 14:18, 3 October 2019 (UTC)
@Mike Peel: Maybe we can get climbing route (P7309) only for the moment. Thierry Caro (talk) 12:03, 13 October 2019 (UTC)
@Mike Peel: Thanks. Thierry Caro (talk) 07:06, 9 February 2020 (UTC)

Display P366 (Use)[edit]

Can we add a line to display P366 (Use)? It is valuable to display the use/purpose/mission of an aircraft type. Thanks! Josh (talk) 16:41, 22 September 2019 (UTC)

@Joshbaumgartner: It's now in {{Wikidata Infobox/sandbox}}, please could you test it? Thanks. Mike Peel (talk) 13:31, 28 September 2019 (UTC)
@Mike Peel: I tested it on a few categories, it looks perfect. Thanks! Josh (talk) 16:15, 28 September 2019 (UTC)
Thanks for checking it. I'll deploy it in the next week or so, when other changes are also ready. Thanks. Mike Peel (talk) 16:23, 28 September 2019 (UTC)

Location in Scotland issues[edit]

P1813 short name, icons[edit]

For example, Category:Blantyre, South Lanarkshire gives location: South Lanarkshire, 🏴󠁧󠁢󠁳󠁣󠁴󠁿, but it should give South Lanarkshire, Scotland, United Kingdom.

South Lanarkshire (Q209142) has P131=Scotland, and Scotland (Q22) has P131=United Kingdom. Obviously, short name (P1813)=🏴󠁧󠁢󠁳󠁣󠁴󠁿 is used instead, see also [10].

For comparison, England (Q21) has the same constellation afaics, but infoboxes for locations in England don't have the same problem. Could someone help please? --Te750iv (talk) 21:12, 22 September 2019 (UTC)

@Te750iv: I see it as "South Lanarkshire, Blantyre, United Kingdom", where "Blantyre" is because Blantyre (Q881708) and Blantyre (Q68815005) seem to be different things. I think 'Scotland' is automatically skipped when assembling the location string, but I'm not sure - @RexxS: can you have a look? I have reverted the icon as short name addition, though, which might help. Thanks. Mike Peel (talk) 13:26, 28 September 2019 (UTC)
There are multiple problems, Mike. First, Blantyre (Q881708) is located in the administrative territorial entity (P131) of both Blantyre (Q68815005) and South Lanarkshire (Q209142), which is ridiculous over specification – it might as well be in the administrative territorial entity of Scotland and of the UK (both having role of country) in that case. It is not helpful to state location A is in both location B and location C, when location B is in location C already. In this case, the code will skip the second 'Blantyre' as a duplicate name, so it won't cause issues.
The next problem is that the parish is stated as being in both South Lanarkshire (Q209142) (true) and in Lanarkshire (Q530296) (untrue for the last 44 years). I've made the former the preferred value to alleviate that.
The last problem is that Template:Wikidata Infobox/core is switching to using {{Wikidata location}} in this case, rather than #invoke:WikidataIB|location for reasons that aren't obvious to me. We know that {{Wikidata location}} can be flakey, and it doesn't work well when Wikidata is over-complicated. Compare:
{{#invoke:WikidataIB |location |Q881708}}Blantyre, South Lanarkshire, Scotland
{{Wikidata location | qid=Q881708}}South Lanarkshire, Blantyre, United Kingdom
To pick up on your other point, the code in WikidataIB|location terminates the chain when it encounters a country (Q6256) (or constituent part of the United Kingdom (Q3336843) if |skip =true). However, according to Wikidata, Scotland (Q22) is both a constituent part of the United Kingdom (Q3336843) and a country (Q6256), while England (Q21) is a constituent part of the United Kingdom (Q3336843), but not a country (Q6256). Garbage in, garbage out:
  • {{#invoke:WikidataIB |location |first=true |Q881708}}Blantyre, South Lanarkshire, Scotland
  • {{#invoke:WikidataIB |location |Q881708 |first=true |skip=true}}Blantyre, Scotland
  • {{#invoke:WikidataIB |location |Q1684337 |first=true}}Tipton, Sandwell, West Midlands, England
  • {{#invoke:WikidataIB |location |Q1684337 |first=true |skip=true}}Tipton, England
I've removed some more icons pretending to be short name (P1813), but no doubt they will be back, polluting the data. --RexxS (talk) 14:55, 28 September 2019 (UTC)
@RexxS: Thanks! I'd forgotten that we were falling back to {{Wikidata location}} where there are multiple located in the administrative territorial entity (P131) values. It would be good to get rid of that at some point, but I think that needs some more of the special cases integrating into the Lua code first. Thanks. Mike Peel (talk) 15:01, 28 September 2019 (UTC)
@Mike Peel: you'll have to remind me what are the special cases you want integrating into the Lua code, as my poor dinosaur brain can't remember. --RexxS (talk) 15:58, 28 September 2019 (UTC)
@RexxS: Neither can mine! Looking at line 259 of Template:Wikidata Infobox/core, I think the main thing is being able to cope with multiple values of located in the administrative territorial entity (P131) and location (P276) in the connected item. So in the case of Blantyre (Q881708), perhaps the ideal thing to do is to follow both chains and print them out, either on separate lines or by following them until they reach a common point and then joining them together somehow. There were some cases where that does make sense (windmills on one site that spans multiple regions comes to memory). All that {{Wikidata location}} does is dump out all values of located on terrain feature (P706), location (P276) and located in the administrative territorial entity (P131), plus country (P17) with a fallback to continent (P30) in Antarctica. Thanks. Mike Peel (talk) 16:10, 28 September 2019 (UTC)

Thanks for solving the issue. --Te750iv (talk) 00:39, 29 September 2019 (UTC)
Only noticed after Jheald's post below: I reported the example Blantyre (Q881708) on 22 September 2019. The item was changed afterwards, so Mike Peel saw a different location chain on 28 September (without the 🏴󠁧󠁢󠁳󠁣󠁴󠁿 short name, which was given instead of Scotland before). I don't know therefore, if the original issue (usage of P1813) really is solved. --Te750iv (talk) 08:58, 6 October 2019 (UTC)

P131, civil parishes[edit]

Because the parish boundaries were frozen in 1930 when they ceased to have an administrative role, parishes sometimes now split over more than one modern council area (partial list at Category:Civil_parishes_in_multiple_council_areas_of_Scotland, full list at https://w.wiki/9H6), so we have been giving both the civil parish and the modern council area in the located in the administrative territorial entity (P131) statement, qualified with object has role (P3831) = civil parish (Q5124673) and local authority (Q837766) respectively. See eg Kiltarlity (Q2790381) for an example, as well as most listed buildings in Scotland.
In turn, the parish items (eg Q6881584 (Q6881584)) also typically have two P131 statements, qualified object has role (P3831) = local authority (Q837766) for the modern council areas, and shire of Scotland (Q1350181) for the traditional counties respectively.
Ideally the order returned should probably be (locality), parish, historic county, modern council area -- unless the modern council area (eg South Ayrshire) includes the name of the historic county, in which case it may make sense to put it first; or if the two have the same name, in which case it probably makes sense to keep the modern council area and suppress the historic county.
Would this seem sensible/doable ? Jheald (talk) 10:08, 3 October 2019 (UTC)
@Jheald: I don't know if this would be doable. In general, I think, outdated "historic" location values should not be displayed in infobox location chains. Otherwise, we would have too much confusion worldwide (see e.g. more complex cases of old Soviet Union administrative units, or various past administrative changes in Germany including old GDR districts). --Te750iv (talk) 08:58, 6 October 2019 (UTC)
@Te750iv: Thanks, Te750iv. Civil parishes in Scotland are an odd case. On the one hand, they lost their decision-making powers in 1930, and were formally abolished in 1975. But on the other hand, they were never systematically replaced with anything at that scale. So a lot of land records, historical buildings records, etc, still record the civil parish (even for new records), according to the final 1930s boundaries. Because they are well-defined territories over time, census summaries and aggregates are also systematically calculated and made available for them. Finally, because (especially in rural areas), their boundaries still typically are very similar to Church of Scotland boundaries, there is still significant local identification with them, and eg local societies may be structured on a parish bases. So I don't think the parallel with old Soviet administrative units is exact.
The key argument here, I think, is the lack of any unit as readily available at the same scale. The formal units now, the Scottish council areas, are very big. It's really helpful to be able to indicate units that are at a more local scale than that, eg for grouping together listed buildings (important for Wiki Loves Monuments). We systematically have pages on en-wiki for listed-builidings-by-civil-parish for Scotland. We also have categories here for about 80% of them. So IMO it is useful to be able to give a link from an infobox here to a civil parish, that people can then browse down from to find other buildings and settlements in the vicinity.
The case for the traditional counties is more balanced; but again, they existed for hundreds of years, and there is still very strong identification with them from local people. Significantly in rural areas they again tend to be singnificantly smaller than council areas, so identifying places as being in eg "Caithness" or "Dumfriesshire" or "Selkirkshire" is a useful level of identification, beyond "Highland" or "Dumfries and Galloway" or "Scottish Borders". Why, I suppose, may be part of why they have continued to persist in people's minds locally.
So I do think this is quite useful information to be able to give in the infobox. But if there is a better way to model it, that could be adjusted.
The situation at present is that this is in the P131s, so is being presented; but often rather out-of-order in the sequence. Jheald (talk) 09:22, 6 October 2019 (UTC)

Display code/encoding for numbers[edit]

I added code (P3295) and encoding (P3294) in the sandbox. It's currently visible at Category:987_(number).

Is there a predefined way to switch display to the following:

  • have the first cell display the encoding (a qualifier on Wikidata)
  • the second cell the code (the value that has that qualifier).
  • Then do a new line for the next statement (different encoding).

The current label "Code" wouldn't be needed. Jura1 (talk) 16:15, 28 September 2019 (UTC)

That's not currently possible, but perhaps @RexxS: could magic something up. Thanks. Mike Peel (talk) 16:22, 28 September 2019 (UTC)
The simplest would be:
  • {{wdib |ps=2 |qid=Q258492 |P3295 |qual=P3294 |list=ubl}}
    • ⁹⁸⁷ (Unicode superscript number)
    • 3DB (hexadecimal in 0-9A-F notation)
    • ๙๘๗ (Thai numeral)
    • ৯৮৭ (Bengali numeral)
    • CMLXXXVII (Roman numeral in basic notation)
    • 1111011011 (binary in 0/1 notation)
    • ९८७ (Devanagari numeral)
    • ૯૮૭ (Gujarati numeral)
    • ௯௱௮௰௭ (Tamil number notation using ௰, ௱, ௲)
    • ௯௮௭ (Tamil number notation using ASCII 0)
    • − − − − · − − − · · − − · · · (Morse code in · −  notation)
    • ៩៨៧ (Khmer numbers)
    • ೯೮೭ (Kannada numerals)
    • ໙໘໗ (Lao numerals)
Otherwise, I can kludge table cells using the separators and prefix/suffixes using {{wdib |ps=2 |qid=Q258492 |P3295 |qual=P3294 |sep="&nbsp;</td></tr>" |prefix="<tr><td>" |postfix="</td><td>"}}:
⁹⁸⁷ (Unicode superscript number) 
3DB (hexadecimal in 0-9A-F notation) 
๙๘๗ (Thai numeral) 
৯৮৭ (Bengali numeral) 
CMLXXXVII (Roman numeral in basic notation) 
1111011011 (binary in 0/1 notation) 
९८७ (Devanagari numeral) 
૯૮૭ (Gujarati numeral) 
௯௱௮௰௭ (Tamil number notation using ௰, ௱, ௲) 
௯௮௭ (Tamil number notation using ASCII 0) 
− − − − · − − − · · − − · · · (Morse code in · −  notation) 
៩៨៧ (Khmer numbers) 
೯೮೭ (Kannada numerals) 
໙໘໗ (Lao numerals)
But that would need more kludging in the template to enclose them inside the current table cells. --RexxS (talk) 18:04, 28 September 2019 (UTC)
  • Cool. Thanks. Looks good. I don't really mind having the values first. I added the last one to the sandbox (visible at Category:987_(number)). Is there a way to have the encoding value link (WD or locally)? Jura1 (talk) 18:29, 28 September 2019 (UTC)
  • @Mike Peel: would you mind copying it from the sandbox to the "real" template? Jura1 (talk) 20:18, 30 September 2019 (UTC)
    • @Jura1, RexxS: I think this needs some more work before it's ready for deployment. In particular, the columns need to be swapped, and brackets should be removed. Thanks. Mike Peel (talk) 05:12, 1 October 2019 (UTC)
      • I see. If the current approach isn't convincing, maybe a solution could be to re-add the "code"-column and place the reminder in the second cell. Jura1 (talk) 06:29, 1 October 2019 (UTC)
  • @Mike Peel: ✓ Done Jura1 (talk) 15:36, 1 October 2019 (UTC)
    • @Jura1: Interesting! I've merged the code into Module:Wikidata Infobox/sandbox and made some formatting changes. Most notably, the infobox doesn't link to Wikidata as a rule, it only links within Commons. How does that look now? If it's OK, I'll make it live shortly. Thanks. Mike Peel (talk) 18:17, 1 October 2019 (UTC)
      • Thanks. Ok for me. Personally, I'd have opted for a smaller font-size in the first cell. I also increased the font-size for the second cell. BTW Category:8_(number) has the test version as well. Jura1 (talk) 19:21, 1 October 2019 (UTC)
  • @Mike Peel: I did some more tweaks to it, do you think it's ready to go live? I was hoping to include d:Wikidata:Property proposal/code (image), but that part might take a bit more time. Jura1 (talk) 08:39, 8 October 2019 (UTC)
    • @Jura1: Sorry to have taken a while to come back to this. The remaining issue is the text sizes - it would be better to have them uniform so that they match the rest of the infobox, rather than having some smaller and some larger. If you're OK with that, then I'll look again at making this live. Thanks. Mike Peel (talk) 18:55, 11 October 2019 (UTC)
      • @Mike Peel: np, I'd rather not, but feel free to do so, as it's licensed CC BY-SA 3.0. Jura1 (talk) 20:44, 11 October 2019 (UTC)
        • @Jura1: Could you explain why you'd rather not? Thanks. Mike Peel (talk) 20:46, 11 October 2019 (UTC)
      • @Mike Peel: most labels of encodings are relatively long and the code itself is usually just a few characters, possibly not that readable if the numeral isn't an Arabic numeral.Jura1 (talk) 21:03, 11 October 2019 (UTC)
        • On my computer, it doesn't look good - the label text is too small, while the content is too large. Perhaps it displays differently on different computers. There are also accessibility issues with having small text in a box that already has reduced font size. So I'll change it back to the standard text size for the next release, and we can revisit this again in the future. Thanks. Mike Peel (talk) 13:54, 18 October 2019 (UTC)
          • Np. Maybe my browser is borked. Jura1 (talk) 15:09, 18 October 2019 (UTC)
      • @Mike Peel: code (image) (P7415) is active now too. Would you update the live versions? Jura1 (talk) 12:14, 14 October 2019 (UTC)
        • @Jura1: It's now live, thanks for your work and patience. Thanks. Mike Peel (talk) 11:06, 19 October 2019 (UTC)

Hiero name[edit]

name in hiero markup (P7383) can be used to add hieroglyphs in hiero syntax. I added support for that in the sandbox.

Samples at Category:Anubis and Category:Thutmosis III.

The first one looks fine. I'm not quite sure how to improve the second one. Jura1 (talk) 12:11, 8 October 2019 (UTC)

Maybe it should be collapsed if the source string exceeds a defined length. Jura1 (talk) 12:13, 8 October 2019 (UTC)
  • Seems to work now. Jura1 (talk) 11:21, 11 October 2019 (UTC)
    • @Jura1: It looks OK, but it would look better if it were centre-aligned. I attempted to do this, but there seems to be a lot of nested HTML code (particularly tables) that I don't fully understand... Thanks. Mike Peel (talk) 14:16, 18 October 2019 (UTC)
      • I tried to fix it, but didn't really succeed. Jura1 (talk) 15:08, 18 October 2019 (UTC)

Birth not displayed[edit]

Hello, why for this category the birth is not displayed? --Arnd (talk) 17:53, 8 October 2019 (UTC)

Moin Moin Arnd, in dem zugehörigen Wikidata-Objekt ist das Geburtsdatum als "misbilligter Rank" eingestuft, deswegen wir er nicht dargestellt. Wenn du vorn auf die drei Punkte im Wikidata-Objekt klickst, siehst du das. Für Rückfragen stehe ich dir gerne zur Verfügung. mfg --Crazy1880 (talk) 18:12, 8 October 2019 (UTC)

Danish urban area code (P1894)[edit]

This is an official identifier for urban areas in Denmark. Can we have it displayed, please? --Hjart (talk) 12:55, 13 October 2019 (UTC)

No data, although there should be[edit]

I've been having trouble updating Wikidata Infoboxes that for categories that claim to have no data, even though they should have it. My most recent troublesome infobox is with Category:Wassaic, New York, and though I've seen others, I forgot what they were right now. Is there any way to fix this and the others? ----DanTD (talk) 21:15, 17 October 2019 (UTC)

Have you tried purging? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 21:42, 17 October 2019 (UTC)
I've done that in the past, and it hasn't worked so well. ----DanTD (talk) 21:58, 17 October 2019 (UTC)
For sure, doing it in the past won't fix a problem in the present. If you haven't first tried to resolve the issue yourself by taking this simple step on the category page in question, and not doing so deliberately, you are wasting the time of fellow volunteers by asking for help here. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 10:10, 18 October 2019 (UTC)
@DanTD: My checklist to solve this kind of issue tends to be:
  1. "?action=purge" at the end of the Commons category URL to purge the Commons cache
  2. Open the edit window of the commons category, and save it without making any changes (a "null edit"). Possibly re-run (1)
  3. Go to Wikidata. Double-check the commons category sitelink is there, and is correct (not pointing to a redirect, or to a gallery)
  4. If the item on Wikidata is a category item, make sure that topic's main category (P910)/category's main topic (P301) values are correctly set, and aren't duplicated
  5. If everything looks correct on Wikidata, then make an edit to the Wikidata item (e.g., adding a property, or removing Commons category (P373), or adding then removing 'test' from the aliases). Then try (1) and (2) again. This step has been important recently when items have been merged on Wikidata, as for some reason that has been breaking the sitelinks until the Wikidata item has been edited again.
I tend to find that steps (1) or (2) solve it 80% of the time, (3)/(4) 18%, and (5) 2% of the time. Hope that helps. Thanks. Mike Peel (talk) 01:37, 18 October 2019 (UTC)

Errors in Category:Pages with script errors[edit]

@Mike Peel: Hi please look at Category:Ice cream cones. --Jarekt (talk) 12:16, 18 October 2019 (UTC)

Also Category:Russians, Category:SNCF, Category:English language --Jarekt (talk) 12:27, 18 October 2019 (UTC)
The location values on d:Q44248 are problematic. Jura1 (talk) 13:56, 18 October 2019 (UTC)
I meant ice cream cone (Q1156634). Jura1 (talk) 14:45, 18 October 2019 (UTC)
@Jarekt, Jura1: I've raised this at d:Wikidata:Project_chat#Unusually_long_lists_in_some_items, I think these need sorting out on Wikidata, but I'm not sure how. Also @RexxS: in case you can spot ways of avoiding timeouts here - some of them seem to be coming in through country (P17), which is different from usual. Thanks. Mike Peel (talk) 14:12, 18 October 2019 (UTC)
I am fixing ice cream cone (Q1156634). --Jarekt (talk) 14:22, 18 October 2019 (UTC) ✓ Done --Jarekt (talk) 14:58, 18 October 2019 (UTC)
@Jarekt: Thanks for fixing ice cream cone (Q1156634). What kind of mentality thinks it's a good idea to add a list of every country that has ice cream cones?
@Mike Peel: I can see some point in having a list of the main countries where Russians live, but 300 Russians living in Monaco - who cares, is it accurate, and where do these figures come from? Also population (P1082) isn't a valid qualifier for country (P17).
Anyway, there's no way I know of to anticipate server timeouts; it just depends on what's running. My only suggestion is to get into the habit of setting |maxvalues=6 or something like that for any field where you suspect fuckwittery can happen on Wikidata. Sorry, --RexxS (talk) 15:15, 18 October 2019 (UTC)

image with frame (P7420)[edit]

Not sure if and how to include this in the infobox (mainly on items for paintings). Normally, there should be a value in P18, but I suppose it could serve as backup if there isn't.

A way to include this for other infoboxes could be a zoom(-out)-icon. Where could we place this? Jura1 (talk) 14:07, 18 October 2019 (UTC)

@Jura1: A while back I was looking into adding switchable images into the infobox, see User:Mike Peel/Sandbox2 when you have this javascript running. I think that would work here, but it needs someone that knows Javascript to implement it more cleanly, and an interface admin to add it to Commons' built-in javascript - plus then there are portability issues so there would need to be a fallback when the Javascript isn't present. Thanks. Mike Peel (talk) 14:24, 18 October 2019 (UTC)
I'm not really good with js .. Maybe an icon-sized version can do? I added one at the bottom (test here). Jura1 (talk) 15:06, 18 October 2019 (UTC)
@Mike Peel: I like the javascript idea. It would probably be interesting for Wikipedias as well. Once it's available, we could replace it in the template here.
In the meantime, would you kindly update the template from the sandbox? I also added creator's signature (P7457) (test here) and image of backside (P7417) (will be visible here). Jura1 (talk) 07:25, 22 October 2019 (UTC)

{{Edit request}}

diff (only the parts about P7420, P7457, P7417) Jura1 (talk) 14:45, 23 October 2019 (UTC)

I don't think this works well, it's better to keep the images together at the top, rather than mixing text and images. Let's keep thinking about this. Thanks. Mike Peel (talk) 15:04, 23 October 2019 (UTC)
If there are working suggestions, I'm obviously open to them.
Signatures (on persons) are already at the bottom, e.g. at Category:Douglas_Adams. Adding the signature of the creator next to the name of the creator seems a good topical arrangement.
I think it's good to be able to check if the backside is available, but I don't think it should be above most of the other statements .. Jura1 (talk) 15:11, 23 October 2019 (UTC)
In the absence of a better suggestion. I restore the edit request. Jura1 (talk) 18:37, 30 October 2019 (UTC)
Sorry, I've been working on other things. If it's OK I'll circle back to this at the weekend. Thanks. Mike Peel (talk) 20:49, 30 October 2019 (UTC)
@Jura1: I've now coded up the image switcher in {{Wikidata Infobox/sandbox}} - if you install the Javascript from User:Mike Peel/common.js then you can try it out at Category:Presumed portrait of Guillaume Filastre. I've submitted a request to install the javascript site-wide, currently at Commons:Administrators'_noticeboard#Interface_admin_request (as I don't exactly know where I should submit this!), after that's done then I can make the new change live. Does everything look OK to you? Thanks. Mike Peel (talk) 18:04, 2 November 2019 (UTC)
  • Thanks, looks good. I activated the js. Let me think it over. Notably the view without javascript might need some work. Jura1 (talk) 21:31, 2 November 2019 (UTC)
  • A few tweaks would be nice:
  • If js is disabled, I'd favor a more compact view in the way this was initially presented (having an icon rather than the regular sized image). This can also work for the mobile view.
  • I'd place creator's signature just below the creator row, not as a person's signature.
BTW, without the script you wrote, in the earlier test version, some other gallery function kicked in, allow to view the three images in sequence. Jura1 (talk) 06:28, 3 November 2019 (UTC)

Note that there's now a proposal to turn on the Javascript by default, please see Commons:Village_pump/Proposals#Displaying_multiple_images_in_the_Wikidata_Infobox_using_Javascript. Thanks. Mike Peel (talk) 15:52, 10 November 2019 (UTC)

  • In the meantime, can use the version I first did? Jura1 (talk) 08:00, 11 December 2019 (UTC)
    @Jura1: The Javascript is now live, so I'll update the infobox with the new code shortly, unless any issues appear. Thanks. Mike Peel (talk) 11:31, 15 December 2019 (UTC)

suggestion to ignore disambiguation-related statements[edit]

For infoboxes, please ignore different from (P1889) if criterion used (P1013) is used with descriptive page and disambiguation page have to be in different items (Q24005632). Such statements are usually of no use here, and they take much space (example). --Te750iv (talk) 01:47, 25 October 2019 (UTC)

Symbol support vote.svg Support For my sake the display of different from (P1889) could be dropped completely. --Marsupium (talk) 12:43, 25 October 2019 (UTC)
Symbol support vote.svg Support. We don't need to see so much of the guts of Wikidiata, i.e. criteria used in distinguishing items. It may be relevant on Wikidata, but it's just noise on Commons. Especially pointless are the "different from" statements on surname categories, e.g. McNeil (surname) or Hodges (surname), and even when the disambiguation has a actually a functional Commons link (e.g. Johnson (surname), I see little use in the link, because unlike Wikidata items, Commons categories and galleries cannot have the same name, and so we disambiguate by parenthetical terms or other means. --Animalparty (talk) 16:47, 25 October 2019 (UTC)

It's probably useful at, e.g., Category:London, Ontario, so I don't want to get rid of it completely, but I wonder if it's best to not show it for unlinked statements. @RexxS: Is that something that would be easy to do? (i.e., if there isn't a link for a value, ignore it). Thanks. Mike Peel (talk) 17:21, 25 October 2019 (UTC)

@Mike Peel: Another example: see Category:London (surname) where a disambiguation actually is linked via such a statement. I would prefer it being ignored; your suggestion would keep it (because it's linked).
I think P1889 statements – linked, or not (or not yet; categories might be created in the future) – can be useful sometimes. But those disambiguation-related ones (some more criteria here) are dispensable in any case. --Te750iv (talk) 18:52, 25 October 2019 (UTC)
@Mike Peel: It would need a fairly big re-write to provide the ability to return nothing when a sitelink doesn't exist. Currently when a sitelink doesn't exist, the code in WikidataIB looks for a local page with the same name and creates a linked item if it is a redirect. Otherwise it looks for a label in the local/target language and returns that unlinked. That behaviour is required for most items most of the time, and we would probably break a lot of uses if we didn't return the label.
If we must process different from (P1889) at all, then surely the way to suppress it on some articles is to use a |spf=different from parameter in the article, as I've just done at Category:Houses of culture? --RexxS (talk) 19:36, 26 October 2019 (UTC)
  • One could check for a few values in P31 (e.g. family name, given name) and not display it when present. Jura1 (talk) 07:17, 5 November 2019 (UTC)

Parameter to optionally switch off categorization?[edit]

Assume a wikidata, category etc. and infobox of Frank Lloyd Wright (or anyone else). We're likely to also have a "Works by" category and this could be improved by an infobox on Lloyd Wright giving the basic biog, and of course the link to WP etc.

For Lloyd Wright, there's already such an infobox and it's driven by its own Wikidata item. However in many lesser cases we don't need that, but there's still use in being able to replicate the infobox onto such categories. This works pretty easily, but it also places the category page inappropriately into the biographical categories as well.

A simple parameter could switch off this categorization. Could such a thing be provided? Andy Dingley (talk) 21:36, 26 October 2019 (UTC)

@Andy Dingley: In this case there is already an infobox at Category:Buildings by Frank Lloyd Wright, which links to the appropriate category on enwp, and it's easy enough to create similar Wikidata items for other artists. Perhaps a different solution here would be for the infobox to show more information from the category combines topics (P971) items? Thanks. Mike Peel (talk) 06:49, 27 October 2019 (UTC)
  • It's hardly "easy to create Wikidata items" (this is a perennial problem!).
Also in such a case it would be wrong to create one: the notable subject is the author, their corpus of work is probably voluminous but not (unlike Lloyd Wright's) enough to pass independent notability all on its own. The goal here is to replicate an easy self-populating infobox onto a different location (wasn't this some of the original pitch for Wikidata?). It's still relevant to the new page, but it's not the same page as a definition, so to impose the categorization would be wrong. Andy Dingley (talk) 10:03, 27 October 2019 (UTC)
@Andy Dingley: My view is that Wikidata items are easy to create (having created quite a few!), and notability is met by the existence of the Commons category. I think it's better to describe the category on Wikidata using its own item rather than reusing an infobox from another category. But if you prefer otherwise, then the parameter you're looking for is "autocat=no". Thanks. Mike Peel (talk) 17:46, 28 October 2019 (UTC)

Supress display on file pages[edit]

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

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

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

@Mike Peel: Any news? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 14:17, 11 February 2020 (UTC)

Please suppress "located at street address (DEPRECATED)" (and maybe all deprecated properties)[edit]

Is there a valid reason we need to see street address (DEPRECATED) (P969) (or any deprecated properties)? See Bay View Cemetery for senseless redundancy in action. Perhaps all deprecated properties should be suppressed. --Animalparty (talk) 02:01, 31 October 2019 (UTC)

I think there are still too many items with street address (DEPRECATED) (P969), but no street address (P6375). Maybe you can get an ETA from the proponents of P6375? @Jc86035, VIGNERON, Gzen92: Jura1 (talk) 09:00, 31 October 2019 (UTC)
I will look where is the transfer from P969 to P6375 on Wikidata.
Meanwhile, it doesn't matter for Commons as there is no reason for the infobox to show the two values. There should be a test "if P6375 exists, then don't get P969". Ping @Mike Peel: would you look into it?
Cheers, VIGNERON (talk) 09:23, 31 October 2019 (UTC)
@Animalparty, Jura1, VIGNERON: Hmm, I thought that a) the infobox did that already, and b) that when street address (P6375) is added then street address (DEPRECATED) (P969) is removed. Apparently not though! I've tweaked the display as suggested, please test that to see if it works. I'll update the main version this weekend. Thanks. Mike Peel (talk) 19:06, 31 October 2019 (UTC)
@Animalparty, Jura1, VIGNERON: The change is now live. Thanks. Mike Peel (talk) 15:47, 9 November 2019 (UTC)
  • Thanks. @Jc86035, VIGNERON, Gzen92: what's the progress on your side? Having both properties isn't really helpful. Jura1 (talk) 11:39, 10 November 2019 (UTC)
Hello, I work on this request. But it's complicated when there is already street address (P6375) or/and located on street (P669) or weird address. I will start with simple cases, it will probably end manually. Gzen92 [discuter] 17:04, 11 November 2019 (UTC)
I will start with the addresses in France (country (P17) and France (Q142)), Gzen92 [discuter] 07:28, 12 November 2019 (UTC)

Display P1343?[edit]

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

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

Auto-categorization for names[edit]

Currently given name (P735) and family name (P734) adds categorization based on an item's label followed by "(given name)" or "(surname)". Generally, this works fine, but sometimes the category linked from the P735/P734-value isn't the same as that category or the category doesn't exists.

  • It happens notably when Wikidata has several items with the same Latin script label (e.g. for different genders),
  • or the item is for a name that isn't originally written in Latin script (e.g. Chinese names).
  • It also happens when Wikidata has two items for a name depending on uppercase/lowercase initial (e.g. van-Van).

The result is that the infobox displayed on the Commons category doesn't match the name item actually used for a person. Sometimes this leads to people doing odd edits on Wikidata trying to "fix" it. The question is if we should try to correct auto-categorization or just accept that the categories aren't exactly as the items defined on Wikidata. @E4024: who brought this up on Wikidata. @JuTa: who edits frequently on Commons. Jura1 (talk) 17:55, 10 November 2019 (UTC)

I want to switch this at some point to use the Commons sitelinks rather than the label to find the category. That wasn't done originally as there weren't many sitelinks then, but there are rather more now. It ideally needs someone to do some quantification of the % of names that have commons sitelinks now - or we run both systems in parallel for a bit along with tracking categories. Thanks. Mike Peel (talk) 18:36, 10 November 2019 (UTC)
  • Sounds good. Maybe this can help: [11]. 963 of the top 1000 given name have a sitelink to Commons. The top 1000 cover ca. 70% of all given name (P735) values. Jura1 (talk) 20:00, 10 November 2019 (UTC)
Hi, Sounds not too bad in first glance, but this could lead to other problems. There are different items on wd for the same names here on commons like latin script and cyrillic script variants. I.e. d:Q830350 (Ivan latin) and d:Q21104340 (Ivan cyrillic). Only one wd item can have a sitelink to Category:Ivan (given name). Would that leave all cyrillic Ivans uncategorized? Another (strange) example is d:Q31362405 (Konstantin/Constantin/Constantine/Kostyantyn cyrillic) compared with d:Q7111053 (Konstantin latin), d:Q5163687 (Constanin latin), d:Q19327451 (Constanine latin) and d:Q23308390 (Kontantyn but also cyrillic). I have currently a discussion witha user who insists on the multi-labels on wikidata at d:User talk:Infovarius#Konstantin/Constantin/Constantine/Kostyantyn. PS: d:Q31362405 is currently filling up Category:Konstantin/Constantin/Constantine/Kostyantyn (given name) with several hundred entries. --JuTa 14:26, 12 February 2020 (UTC) (pinging:Mike Peel)


WikiProject Names/lists/given names/Vasily can given an idea of item you would generally find at Wikidata for similar names.
I think you probably have three options for categorization:
  • (1) create categories for all of them,
  • (2) add English transliteration to all of them and modify the infobox to display values from several items,
  • (3) not categorize names that aren't in English.
As I'm not that active here at Commons, I don't want to recommend one option over another.
To overwrite values at Wikidata to "make it work" for English categories isn't really a good idea (at least from a Wikidata perspective). @Mike Peel, Infovarius, JuTa: Jura1 (talk) 09:46, 13 February 2020 (UTC)
Let's make Commons finally international interlanguage! (if to have such name categories at all) I propose to create categories with correct names like Category:Иван (given name) (Category:Иван (личное имя)?), Category:Константин (given name) (for d:Q31362405) and so on. --Infovarius (talk) 19:37, 13 February 2020 (UTC)

Improvements for given name/family name categories/infobox[edit]

It might be worth re-doing the infobox for name items:

display native label (P1705)
If it isn't done yet, it should appear on top of the infobox. It's different from English for non-Latin script names.
change the display of said to be the same as (P460)
Reasonator uses the "see also"-statements and language statements on items to display a table of name variants, see https://tools.wmflabs.org/reasonator/?&q=1495413 for Category:Emilia (given name).
Something that is currently missing at Reasonator is that it should include the "native label" statement from these items
sample: Emilia → Эми́лия (Russian), based on d:Q67630193#P1705
display pronunciation
Other statements that might be worth displaying are the one for pronunciation: IPA transcription (P898) (and others), pronunciation audio (P443) (grouped by language qualifier), maybe directly combined with the language of work or name (P407) statements on the item. Not sure about including Soundex (P3878) or similar though.
sample: Emilia → Polish: ɛ̃ˈmʲilʲja
index transliteration
some items include some of the many properties for transliterations. Maybe their values could be made available for search.
display nickname (P1449)
could be interesting
sample: Emilia → Mimi
display given name version for other gender (P1560)
with language from qualifier or language statement on value,
sample: Emilia → Emilio (Spanish, Portuguese)
display name day (P1750)
with qualifiers
sample: Emilia → November 14 (Sweden)
remove display "different from"
see discussion #suggestion_to_ignore_disambiguation-related_statements above
additional sitelinks from "different from" values
similar to what is being done for taxons/species, one could use the "different from" statements to include additional sitelinks to disambiguation pages in other wikis. This is something that users at Wikipedias sometimes miss.
sample: Category:Emilia (given name) would link to es:Emilia (desambiguación).
display rankings
d:Q1495413#P5323 could be interesting to be displayed if made in a compact form,
sample: Emilia → #935 on "frequency of first names in the Netherlands, 2010"

As I'm currently not able to contribute to Wikidata, I leave this to you @Mike Peel: Jura1 (talk) 09:27, 11 December 2019 (UTC)

  • For the record, "Emilio" is not proper Portuguese: Correct post-1911 orthography is "Emílio". -- Tuválkin 04:15, 11 February 2020 (UTC)
Would you also be interested in displaying Digital Dictionary of Surnames in Germany ID (P6597) as external identifier in the infobox for family names? Julian Jarosch (digicademy) (talk) 14:45, 8 April 2020 (UTC)

Problem with employer data[edit]

See Commons:Village pump#Sea of blue links in the infobox. Kaldari (talk) 17:26, 14 November 2019 (UTC)

Thanks for the pointer. I've replied there. There's now a tweak in {{Wikidata Infobox/sandbox}} to add a little bit of whitespace between lines so that they are more clearly separated. Thanks. Mike Peel (talk) 05:48, 15 November 2019 (UTC)

Bridges and tunnels[edit]

For bridges and tunnels, displaying both next crossing upstream (P2673) and next crossing downstream (P2674) would be useful. @Mike Peel: Can you do that? That would be nice. Thierry Caro (talk) 20:02, 18 November 2019 (UTC)

@Thierry Caro: It's now in the sandbox, please test {{Wikidata Infobox/sandbox}} in a relevant category. Thanks. Mike Peel (talk) 19:48, 14 December 2019 (UTC)
@Mike Peel: It works perfectly fine. I would display this right under carries (P2505) though. Thierry Caro (talk) 12:25, 24 December 2019 (UTC)

rounding of coordinates[edit]

I have noticed that the infobox takes the coordinates from Wikidata, then rounds them to D.dddd°, which is fine by me. However, it then reports those coordinates as D°M′S.ss″. An example is Category:Camp Fire (2018) which shows 39° 48′ 37.08″ N, 121° 26′ 13.92″ W (which works out to 39.8103, -121.4372) even though Wikidata item Q58416875 has 39°48′37″N 121°26′14″W. Either the infobox should just report the 39.8103, -121.4372, that it is really using, or it could round the D°M′S.ss″ back to D°M′S″. Abductive (talk) 19:10, 23 November 2019 (UTC)

Notice the "precision" value. If you don't want the coordinates rounded, remove the "precision" by unmarking the checkbox. --Hjart (talk) 19:20, 23 November 2019 (UTC)
It is unchecked, on Wikidata, if that is what you are referring to. In any case, this should be fixed so that it does not require intervention on every item, or by every user who wants to improve the Commons. Abductive (talk) 05:01, 24 November 2019 (UTC)

Error message: "Does not match [..] pattern"[edit]

https://commons.wikimedia.org/w/index.php?search=%22does+not+match%22&title=Special%3ASearch&go=Seite&ns0=1&ns6=1&ns9=1&ns12=1&ns14=1&ns100=1&ns106=1 --Arnd (talk) 22:18, 7 December 2019 (UTC)


If there is interest, there is a way to include urns based on statements on Wikidata items/properties, e.g.

One concept can have different URNs. These are meant to be persistent. Unless one has some special extension installed, they are not URLs.

URNs could be displayed on the category or merely made available for text search or Special:LinkSearch/urn:*. Jura1 (talk) 11:31, 11 December 2019 (UTC)

Link to sdcquery[edit]

In addition to Reasonator/PetScan/Scholia/Statistics, eventually (once it updates regularly), it would be interesting to include a link to Query Server for Commons.

I'm not entirely sure about the query to use. The item of the category should probably be either a value or a qualifier value. Jura1 (talk) 07:06, 13 December 2019 (UTC)

How sort key for DEFAULTSORT is created?[edit]

In particular for persons. An info on Commons:Wikidata infobox help would be nice. Also what categories are automatically added? Based on what properties? --jdx Re: 14:58, 24 December 2019 (UTC)

Odd Wikidata additions[edit]

WD Infobox occasionally adds WD properties as floating text: see Category:Romeo (character) which improperly displays manner and cause cause of death (suicide and poison, respectively), and Category:Mrs. Brooks (née Watson), which improperly displays "unknown", presumably due to the unknown value listed in Given name (P735). --Animalparty (talk) 06:05, 26 December 2019 (UTC)

@Animalparty: The infobox definitely shouldn't be doing that. For the first case, I've reworked the 'death' section so thatt it includes manner and cause of death within separate rows, {{Wikidata Infobox/sandbox}} seems to work OK now. For the latter, that's coming in through the sort key code, so that's more difficult to fix - @RexxS: perhaps another option is needed to be able to suppress 'unknown' from being returned? Or we could just remove the 'unknown' value from the Wikidata item... Thanks. Mike Peel (talk) 08:29, 26 December 2019 (UTC)
@Mike Peel: The code currently returns this for Mrs. Brooks (Q79727976), given name (P735):
  • {{wdib|ps=1|qid=Q79727976|P735}} → Unknown
but note:
  • {{#property:P735 | from=Q79727976 }} → Some value without a Wikidata item
You will need to check the logic in the template to work out why the value 'unknown' appears outside of the infobox.
If we don't know a given name (and we know that we don't know the given name), then it seems reasonable to me that an infobox should state "Given name: Unknown", which is why I coded it that way. However, you're using P735 to create a category, so that is less relevant. You can deal with that in the template logic: look at this bit of the template:
  • forename -->{{#if:{{#property:P735 | from={{#invoke:WikidataIB |getQid |qid={{{qid|}}} }}}} | {{#invoke:WikidataIB |getValue |rank=best |P735 |qid={{#invoke:WikidataIB |getQid |qid={{{qid|}}} }} | name=forename | |fwd={{{fwd|ALL}}} |osd={{{osd|no}}} |noicon=yes | linked=n | spf={{{spf|}}} | prefix="[""[Category:" |postfix=" (given name)]]" | lang=en | sep=" "}} | [[Category:Uses of Wikidata Infobox with no given name]]}}<!--
You could add a test for a value equal to "Some value without a Wikidata item" and then also set the category 'Uses of Wikidata Infobox with no given name'.
Optionally, and more simply, I could suppress returning "Unknown" for unknown values inside WikidataIB by default. For more flexibility, I could implement a parameter to set the value returned for unknown, |unknown=, and use |unknown=nil to suppress it. Please let me know what you prefer. Cheers --RexxS (talk) 19:41, 26 December 2019 (UTC)

translations of unknown value[edit]

The Category Schloss Bergedorf connected to Q2240259 (Q2240259) displays inception (P571). There I found out that the wikibase unknown value gets translated with Unknown – at least for German, Latin, Spanish and English. Is there a way to translate those values? CamelCaseNick (talk) 21:41, 11 January 2020 (UTC)

@CamelCaseNick: I don't know, but there must be a way of translating it. @RexxS: does WikidataIB hard-code this, or use an existing translation? Either way, I would recommend asking this at wikidata:Wikidata:Project chat. Thanks. Mike Peel (talk) 22:39, 12 January 2020 (UTC)
@Mike Peel, CamelCaseNick: The value you see is supplied in the current line 898 as val = i18n["Unknown"]. That variable is defined in the internationalisation section (currently lines 30–81) as ["Unknown"] = "Unknown" at line 64. Other languages can directly edit that line (and remember to re-do that when they update to the latest version of the code), or they can create their own Module:WikidataIB/i18n containing all of their localisations. That module will then automatically override the English versions, and will not require further action when updating the main module. --RexxS (talk) 01:20, 13 January 2020 (UTC)
@RexxS: Could that be changed to use the translated versions that Wikidata displays, please? Those seem to be available here via MediaWiki:Wikibase-snakview-variations-somevalue-label. Thanks. Mike Peel (talk) 16:27, 13 January 2020 (UTC)
@Mike Peel: It could be changed, but I see no reason to change "Unknown" to "unknown value". Why would we want Fred Bloggs' infobox to display "Spouse: unknown value" instead of "Spouse: Unknown"? The entries at Wikidata serve a different audience and purpose from those in infoboxes, and we should beware of attempting to impose a "foolish consistency". Cheers --RexxS (talk) 16:58, 13 January 2020 (UTC)
@RexxS: The reason is multilingual support. I agree that just saying 'Unknown' is nicer than 'Unknown value', but in Spanish, 'Valor desconocido' is better than 'Unknown'. Thanks. Mike Peel (talk) 17:10, 13 January 2020 (UTC)
Then all that's needed is a line in es:Module:WikidataIB/i18n: i18n["Unknown"] = "Valor desconocido" and that's what they get on es-wiki. It's not so simple on multilingual wikis, but until we can optimise values on MediaWiki for all our applications, I don't see why we should use their sub-par English descriptions, when we can make use of the i18n mechanisms on 99% of wikis to get the best one for each language. --RexxS (talk) 18:06, 13 January 2020 (UTC)
@RexxS: We're talking about Commons here, which is a multilingual wiki, so the i18n option won't work as it currently stands. Perhaps if there is no i18n value set here, then the default could be to use the (translated) mediawiki text? Thanks. Mike Peel (talk) 11:04, 19 January 2020 (UTC)
Sure Mike, I'd spotted that this is a multilingual wiki, but the content language is set to English, which is what 99% of readers will see (as opposed to editors, who can set language prefs). Anyone could create Module:WikidataIB/i18n here with the line i18n["Unknown"] = {{MediaWiki:Wikibase-snakview-variations-somevalue-label}}, but I still maintain that seeing "unknown value" worsens the experience for 99% of readers, for whom "Unknown" would look better. Nevertheless, feel free to create the sub-module and try it out. Let me know if you run into any problems. --RexxS (talk) 21:21, 19 January 2020 (UTC)
I don’t know what percentage of Commons readers use an interface language other than English, but I suppose more than 1%, as all desktop users are able to do so if they configure their browser properly—for example, my browser’s preferred language is Hungarian, so MediaWiki:AnonymousI18N.js suggests me to use Hungarian interface when browsing logged out (and stores this choice in a cookie and applies it from then on). Commons is a truly multilingual wiki that tries to give anyone the chance to use languages other than English, but it’s possible only if templates and modules are made multilingual. —Tacsipacsi (talk) 23:12, 19 January 2020 (UTC)

Alternate image[edit]

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

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

Multiple date of births in wikidata with the same year.[edit]

Hi there! It's not uncommon for a person on wikidata to have two dates of birth listed: one the full date and one just the year of birth. This is the result of the latter being published in more sources than the former. This shouldn't matter for the "xxxx births" category added by the infobox but at the moment at Category:Peter Kwint the category gets omitted. Vera (talk) 08:31, 9 February 2020 (UTC)

I think in this case the more accurate date should be given a preferred rank in Wikidata. --ghouston (talk) 06:44, 10 February 2020 (UTC)

Please defaultsort without tussenvoegsel[edit]

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

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

Sourcing circumstances not displayed[edit]

In case of Category:Heisterbacher Straße 210 (Königswinter) and the corresponding Wikidata item wikidata:Q86458053 the sourcing circumstances of the construction time are not displayed. If a building was constructed "circa 1900", it could have also been constructed in 1898 or in 1902. In such cases, "circa" or other sourcing circumstances should certainly be displayed.--Leit (talk) 18:48, 26 February 2020 (UTC)

@Leit: @RexxS: I think this also needs a tweak in WikidataIB somehow. {{wdib|ps=2|P793|qid=Q86458053 | qual=ALL}} -> construction (1900, circa) - should return "construction (c. 1900)" or "construction (1900, circa)". Thanks. Mike Peel (talk) 10:08, 19 April 2020 (UTC)
@Mike Peel: The problem is that sourcing circumstances (P1480) is actually stored as a qualifier for construction (Q385378), not as a qualifier for the value of point in time (P585) (1900) as it should be. Wikidata doesn't allow qualifiers to have qualifiers.
Normally, when the code finds a property value that has a qualifier of sourcing circumstances (P1480) equal to circa, it applies the 'circa' to the property value even when qualifiers are not requested, so {{wdib|ps=2|P569|qid=Q1817}} → 204 (date of birth of Philip the Arab). Consequently it catches sourcing circumstances (P1480) equal to circa when processing qualifiers and drops it from the qualifiers (because it's applied to the value already), so you never get 'circa' shown as a qualifier value.
In the present case, the code would apply 'circa' to the value 'construction'; except that isn't a date, so isn't processed by Complex date, which is necessarily where the 'circa' is added.
So, either we disable the automatic rendition of 'circa' to simple statements with a date value (not desirable), or we lobby Wikidata to create a property 'date of construction' that can have the value 1900 and a proper qualifier 'sourcing circumstances: circa' which would immediately render as "circa 1900". This is the "birds coming home to roost" for all those examples of misusing significant event (P793) to make pseudo properties that can't have real qualifiers. --RexxS (talk) 16:27, 19 April 2020 (UTC)
@RexxS: Any chance of a check that sees whether the property value is a date, and only drops it from the qualifiers if that was the case? Replacing significant event (P793) is a rabbit hole I'd prefer not to go down... Thanks. Mike Peel (talk) 16:38, 19 April 2020 (UTC)
@Mike Peel: Not without a substantial re-write of the code (and that really is a grade-A mega-rabbit hole you don't want to go down). The circa is dropped from the assembled list of qualifiers at line 1300 and at that point the code has no idea that the value is not a date. Why should it? It is sheer stupidity to apply 'circa' to something that isn't a date.
Let me have a think about it. I might be able to re-purpose a boolean flag that's passed so that it can carry the datatype as well. --RexxS (talk) 17:00, 19 April 2020 (UTC)
@Mike Peel: Meh - it turned out to be trivial. I already had the datatype stored so that I could deal with the language if it was monolingual text. Oh well, just chalk that down to senility:
  • {{wdib |ps=1|P569|qid=Q1817}}c. 204
  • {{wdib/sandbox |ps=1|P569|qid=Q1817}}c. 204
  • {{wdib |ps=2|P793|qid=Q86458053 | qual=ALL}} -> construction (1900, circa)
  • {{wdib/sandbox |ps=2|P793|qid=Q86458053 | qual=ALL}} -> construction (1900, circa)
Philip the Arab stays the same for his birthday, but Heisterbacher Straße 210 (Königswinter) gains the 'circa' qualifier for its significant event. I can't guarantee the order. That will only happen, of course, if the significant event's value isn't a date (which it can't be with the current definition). --RexxS (talk) 18:17, 19 April 2020 (UTC)
@RexxS: That looks good, thanks! @Leit: what do you think? I have a pending update to the infobox that I'll post shortly, I can update WikidataIB at the same time. Thanks. Mike Peel (talk) 18:20, 19 April 2020 (UTC)
@Mike Peel: @RexxS: Thanks for your efforts. Of course I agree with every change that makes circa being displayed. I have to say that I would never have used significant event (P793) for the construction time if inception (P571) did have the ability to define start time (P580) and end time (P582) (point in time (P585) should probably only be used when only one date is known). By the way, I guess it is still impossible to display circa 1900 [start time]–1903 [end time] as construction or any other item related time. On the other hand, for architectural structures significant event (P793) is anyway still necessary for renovation (Q2144402), Gutting (Q56603425), Roof extensions (Q760072) etc. --Leit (talk) 19:49, 19 April 2020 (UTC)

Name of this template?[edit]

@Mike Peel: why it the name of this template {{Wikidata Infobox}} and not {{Wikidata infobox}}? I'm quite sure that "infobox" is not a given name so it shouldn't have a capital. I only noticed because of this edit. Multichill (talk) 19:28, 22 April 2020 (UTC)

@Multichill: It's been a few years so I can't remember exactly, but I suspect that I started at Template:Infobox, found it was already in use, so added 'Wikidata' in front of it. I don't think I paid much attention to the capitalisation. It's easier to bot-maintain uses if we don't use redirects, hence the bot tidying, but I'm not sure it's worth the edits to move it to the lower case version now. Thanks. Mike Peel (talk) 19:46, 22 April 2020 (UTC)
We have these wonderful things called redirects for that. No need to resolve these so no edits needed. Can you adjust your bot to no longer do the redirect resolving before we move this template to the correct name? Multichill (talk) 19:53, 22 April 2020 (UTC)
@Multichill: You're trolling me, right? I'd rather not make ~3 million more bot edits because of capitalisation. Mike Peel (talk) 20:29, 22 April 2020 (UTC)
I'm not trolling you. Renaming a template doesn't mean you have to resolve redirects. Those are useless edits (and I recall bots getting blocked for that, but that was probably on Wikipedia). So can you please adjust your bot to not resolve the redirect and not explode when the template gets moved to the correct name? Multichill (talk) 18:12, 23 April 2020 (UTC)
@Multichill: If this is really necessary, then I can try to work through the bot and infobox code changes that would be needed this weekend, but I'd still prefer not to waste my time doing so. I'm not sure that this is the only template that capitalises the second word (e.g., Template:Art Photo), and I'd like to hear from a few other editors before spending time on this. Thanks. Mike Peel (talk) 20:20, 23 April 2020 (UTC)
No, not really, but usually these kind of things just hurt more if you wait longer.
Might get renamed some day in the future or not. We'll see. Not worth wasting time over (this weekend). Multichill (talk) 19:19, 24 April 2020 (UTC)
I'm also not seeing any real value in renaming it at this point. I could point out that most infoboxes follow the format "Infobox xxx", but since we have redirects from both {{Infobox Wikidata}} and {{Infobox wikidata}}, there's simply no point in going through the effort of a rename. Huntster (t @ c) 19:49, 24 April 2020 (UTC)

For religious buildings[edit]

It would be nice to also display religion (P140) in categories such as Category:Mt. Moriah Lutheran Church. Would someone take time to add this to the current features? Thierry Caro (talk) 08:13, 23 April 2020 (UTC)


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

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

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

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

@RexxS: Is this something that could be incorporated in WikidataIB? Thanks. Mike Peel (talk) 18:55, 24 April 2020 (UTC)
@Mike Peel, 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)

trouble with Category:Recipients of the Copley Medal[edit]

Category:Recipients of the Copley Medal runs out of time and causes an error. I am sure it is caused by data on Wikidata. Can we put a limit on number of "winners" a page is allowed to display? --Jarekt (talk) 03:56, 26 April 2020 (UTC)

Q28003 should be cleaned-up (awards should be on items for persons). I added a temporary fix. Jura1 (talk) 10:42, 26 April 2020 (UTC)
@Jarekt, Jura1: I've added a limit now - it auto-hides if it's over 5, and cuts off at a maximum of 20. Thanks. Mike Peel (talk) 15:10, 10 May 2020 (UTC)

Performance in ship categories[edit]

Editing ship category pages has recently gotten a lot more annoying, and it seems it's due to the Wikidata Infobox template. For example, clicking edit on Category:Atlas Strength (ship, 2006) just took a very long time to come back, and the performance summary says it used 7.096 seconds of CPU time and 7.813 seconds of real time to render. The Lua profile says 3080 ms is in recursiveClone, 1360 ms is in an unknown function, and various other calls like Scribunto_LuaSandboxCallback::getAllExpandedArguments take a smaller but still noticeable amount of time. The Lua time overall is measured at 6.205 seconds (limit of 10), which seems uncomfortably close. If I remove the infobox, then "preview" edits occur very quickly. The IMO category pages seem a bit faster, say about half that amount of time, but are still slow. This can happen on simply viewing a ship category page which hasn't been recently rendered, too. Is there any way to improve that performance? Carl Lindberg (talk) 14:55, 28 April 2020 (UTC)

@Clindberg: The websites have generally been running slowly for the last few days, but they seem to be faster today. Let's see how it goes. Most of the time, it shouldn't be necessary to edit the category pages now, as you can add the info on Wikidata. Thanks. Mike Peel (talk) 18:33, 29 April 2020 (UTC)
@Mike Peel: Nope, don't think it's a general slowness. Remove the infobox template, and the pages render instantly. The one above someone had changed to point to a specific QID which made it much better, maybe half or a third the time (though still not fast), but all the others are very consistent. The same penalty is there simply *viewing* a ship category which hasn't been rendered in a while -- you wait 7-8 seconds for the page to come up. I am also getting occasional database errors when trying to save (even just adding categories) due to timeouts; unsure if that is related or not but might be. Never seen those before. Carl Lindberg (talk) 12:06, 30 April 2020 (UTC)
Yes, there is a definite penalty to having the infoboxes; I've been noticing it wit the spaceflight categories I've been working on. In the case of Atlas Strength, I added the specific QID because it was originally calling a combined three Wikidata items (Q83968658, Q56351075, and Q83649667). When I made it specific to one of them, the time required for the page to load indeed dropped by about half. Huntster (t @ c) 13:59, 30 April 2020 (UTC)
@RexxS: Any thoughts about this - in particular, can you think of any ways we could speed up the infobox code while still displaying the same information? I'm not sure how to debug the performance here to identify what is taking up the most processing time. Thanks. Mike Peel (talk) 20:40, 30 April 2020 (UTC)
Sorry, Mike it's not something I'm familiar with. Between ArbCom, AE and trying to keep misinformation out of COVID-19 articles, I'm editing up to 16 hours a day, so I just don't have time to take on another investigation right now. Maybe when things get less crazy. --RexxS (talk) 21:08, 30 April 2020 (UTC)
  • If it persists (explicit QID rendering much faster than QID from page property), I think it's something WMDE devs should look into. Jura1 (talk) 07:30, 1 May 2020 (UTC)
  • Jura1, the method of the call isn't relevant, I gather. The slowdown seems intrinsic to simply calling WikiData objects; it was just especially noticeable in the above example because three separate WD objects were being called all at once. Still something that needs looking into, of course. That the infobox is designed to import irrelevant meta-data for display is another issue entirely. Huntster (t @ c) 13:33, 1 May 2020 (UTC)
  • The ship category infoboxes do seem to render multiple different Wikidata items. By making that render a single Wikidata item, it seems as though the time was reduced correspondingly -- but it still seems to be roughly 2.5 seconds per item, which is still quite slow compared to pages without them. I don't recall this type of penalty with the Wikidata stuff in the past, though it's possible that it was there. Maybe it was a change to the infobox to render all related Wikidata items (which could multiply the items rendered) made it especially noticeable. Or maybe there is some other recent change which is the cause. Carl Lindberg (talk) 15:00, 1 May 2020 (UTC)
I've tweaked {{Wikidata Infobox/sandbox}} to not show information from ship name (Q56351075), which cuts the processing time in Category:Atlas_Strength_(ship,_2006) from 8.1s to 5.3s, compared to 3.4s for the manual QID. Running faster would definitely be good, but the infobox does quite a lot of work, and I'm not sure how to optimise it (any volunteers to look into this?). Using manual QIDs will add to maintenance debt in the long run, so I'd prefer to avoid those as much as possible. I'll continue thinking about it. Thanks. Mike Peel (talk) 20:02, 2 May 2020 (UTC)


Hi, could you add translator to this template? Code:

translator -->{{#invoke:Wikidata Infobox|formatLine | P655 | {{#invoke:WikidataIB | getValue | rank=best | P655 | name=translator | linkprefix=":"
| qlinkprefix=":" | list={{{liststyle|ubl}}} | qid={{#invoke:WikidataIB |getQid |qid={{{qid|}}} }} | spf={{{spf|}}} | fwd={{{fwd|ALL}}} | osd={{{os
d|no}}} | noicon={{{noicon|yes}}} | qual=ALL}} }}<!--

This code need to be after author section.

Tested on https://commons.wikimedia.org/w/index.php?title=Template:Wikidata_Infobox/core/sandbox&oldid=416502029

It will help to add crucial information for book editions which are translated. Skim (talk) 15:25, 2 May 2020 (UTC)

CC: @Mike Peel:
@Skim: The change is now live. Thanks. Mike Peel (talk) 15:09, 10 May 2020 (UTC)

Location, continent, hemisphere, error[edit]

Hi. At some point, when continents were added, something went wrong, since the location chain of Madrid is Madrid, Community of Madrid, Spain, Africa, Southern Hemisphere. Definitely not in Africa, neither in the Southern Hemisphere. The item Spain has two values in the P30 property, but Africa is not even the first of them (wrt hemisphere, Africa is both in the Southern and Northern Hemisphere. The infobox apparently chooses the second value again, in this case P706's). Strakhov (talk) 05:34, 6 May 2020 (UTC)

@Strakhov: Traced down to this edit that removed instance of (P31)=country (Q6256). There's a chance that might get reverted on the basis that instance of (P31) is also set to Mediterranean country (Q51576574) for some reason there - @RexxS: this might need a coding tweak to handle. Also, I'm not sure why the retrieved value of continent (P30) fetched both the 'preferred' and 'normal' rank values from Spain (Q29), which may also be worth fixing. Thanks. Mike Peel (talk) 07:47, 6 May 2020 (UTC)::
@Mike Peel, Strakhov: The algorithm doesn't follow continent, just P276 (location), or P131 (located in the administrative territorial entity), or P706 (located on terrain feature). When Spain was not an instance of country, the code would find P706 and use it for the next level up the chain (no P276 or P131 for Spain). Best values are: {{wdib |ps=1 |P706 |qid=Q29 |lp=:}}Iberian Peninsula. So the code checks the previous link in the chain to see whether "Community of Madrid" is located in "Africa" or the "Iberian Peninsula". It turns out that the answer is no, it's just in "Spain", not in "peninsular Spain". So the algorithm has no way of telling which of the higher levels to use. In that case, it just picks the second one. If you wanted to set Iberian Peninsula as preferred value of P706 for Spain, that would solve it for every location with mainland Spain. Similar considerations apply when trying to determine the hemisphere (via P706) that African Spain belongs to. The information isn't there, so it picks the second one. Nevertheless, the function was designed to terminate at the country level, so it's best to set the country as a country.
The problem with excluding classes such as countries when subclasses exist is that a coder has to anticipate all possible values of the subclass. At line 1550, I already test for the location being a country within the United Kingdom (Q3336843) as a condition to terminate the chain, now it's being suggested that I have to test for 'Mediterranean country" as well. Do I also have to test for 'Baltic country'? What about banana producing countries (Q66903706) or any of the other 32 items that are subclasses of country? https://w.wiki/Q6d refers.
Currently, {{#invoke:WikidataIB |location |Q2807 |first=y}}Madrid, Community of Madrid, Spain -- Thanks Mike.
@Mike: it never looks at P30. It got "Africa" or the "Iberian Peninsula" from P706, where they have equal rank. So are there really any tweaks you want me to make? --RexxS (talk) 17:49, 6 May 2020 (UTC)
@RexxS: Thanks for the background info, I've modified located on terrain feature (P706) accordingly, [13]. My preference would actually be to remove located on terrain feature (P706) support completely, as I'm not sure it's useful. With the subclasses, @Roberpl: replied to my revert saying that sovereign state (Q3624078) is a subclass of the country, but given that this only affects a few countries and would involve a lot of checks, my preference is to keep things simpler here and keep P31=country - but I don't know what will happen in the long term here. Thanks. Mike Peel (talk) 18:01, 6 May 2020 (UTC)
@Mike Peel: I think there were originally some terrain features that had P706, but no P131. I would have thought that normally having the fallback to P706 would only be beneficial, because they may show up missing data in entries. Or how about {{#invoke:WikidataIB |location |Q320936 |first=y}}Mare Tranquillitatis, LQ12 (needs support for P376). --RexxS (talk) 18:28, 6 May 2020 (UTC)
Thanks, now it displays correctly except for a few anormalities which have apparently been tracked. I do not have a strong opinion on the rest, since I don't know much about these modules' functioning. Strakhov (talk) 02:56, 7 May 2020 (UTC)

ex-libris (P8195)[edit]

There is a new property for a person's ex libris. I added it to the sandbox. It can be tested at Category:Andrée Béarn. Please check and add to the live version Jura1 (talk) 17:36, 6 May 2020 (UTC)

I think an ex-libris is a rather niche, trivial aspect of most people who have them, and I'm not a fan of image cramming for the sake of mere show-and-tell. When will it stop? Image, grave, coat of arms, commemorative plaque, 'related image', signature, ex libris, etc, why not images of house, spouse, hometown, and left toe? Less is best, in my opinion. Does the infobox have a limit to the number of images/radio buttons it displays? --Animalparty (talk) 20:06, 6 May 2020 (UTC)
Only one image is displayed by default: image (P18) if present. It might be rare that we have all of the above for an individual.
The property is there to simplify retrieving the image. Jura1 (talk) 21:09, 6 May 2020 (UTC)
@Jura1: The change is now live. Thanks. Mike Peel (talk) 15:08, 10 May 2020 (UTC)

Duplicate defaultsort warning displayed although defaultsort=no is set[edit]

Hi! Although I have set defaultsort=no in Category:Buildings by Elissa Aalto, the duplicate defaultsort warning is still displayed. ––Apalsola tc 12:33, 10 May 2020 (UTC)

And Category:Buildings by Elissa Aalto is also categorised under family name, given name, births by year etc. categories derived from Q2628666.
These problems may be related to the feature that displays data from the items set in P971 parameter in Q93864507. ––Apalsola tc 12:56, 10 May 2020 (UTC)
@Apalsola: Good catch, I forgot to turn off auto-categorisation for the embedded infoboxes. I've now modified {{Wikidata Infobox/sandbox}} to do that, please check it. I'll make that live shortly as it's a significant issue. Thanks. Mike Peel (talk) 13:38, 10 May 2020 (UTC)
@Mike Peel: Thanks for your prompt response. The fix in the sandbox template seems to work OK. ––Apalsola tc 13:53, 10 May 2020 (UTC)
@Apalsola: Thanks for checking it, the change is now live. Thanks. Mike Peel (talk) 15:08, 10 May 2020 (UTC)

Severe problems with Infoboxes and Wikidata queries[edit]

  • Since the introduction of recursive infoboxes, there are massive amounts of Lua script errors (time exhauted), and TONS of false autocategorization everywhere.
I repeat what I said to the author of this change : DO NOT RECURSE DOWN into related topics to generate ANY recursive infobox, IF the related topics (lsited at top of the main infobox) ALREADY have a link where they point to the relevant page with the SAME infos.
This change made this wiki incredibly slow foor every update, and is now causing severe degradation of performance and generate a huge load on servers.
Such recursive infoboxes are just duplicating info that is available ON REQUEST of visitors by just following the links displayed in the related topics. We don't need such repetition.
As well almost all these recursive infoboxes are now autocategorizing pages (but with wrong sort keys) and frequently the scripts terminate by an error causing a test for membership not being performed correctly. Tests for existences (which are very costly on the server) for example will be wrong and will cause a page to be categorized even with the scripting error (which is not detected at all).
This change now makes many categories to have random contents collected everywhere. Many become overpopulated with these false categorization.
PLEASE REMOVE these unnecessary recursive infoboxes. And in all cases (if a recursive infobox is still used, because the related topics have no links to a relevant page showing thir own infobox), the autotocategorization of subinfoboxes should ALWAYS be disabled).
This is now dramatic on this site: If the author does not want to do that to remove the subinfoboxes, I will once again disable this change for all subinfoboxes (unconditionnally).
  • Note that there's also a dramatic slowdown in Lua scripting, and another major issue where {{Label}} now uses more than 7MB of memory (a severe new bug in Module:Wikidata) plus about 3-5 MB for each other label added, so many pages now have other errors (because the Lua memory usage is limited to 50MB for redering each page). The maintainers of Module:Wikiata should really monitor their memory usage.

Thanks. verdy_p (talk) 14:53, 11 May 2020 (UTC)

@Verdy p: If you want to be constructive here, please stage your edits in the sandbox so that they can be tested before they go live. I try to keep the number of edits to the template to a minimum, as invalidating the cache of ~3 million categories probably shouldn't be done too often for performance reasons (ironically here!). Issues are being fixed as they are raised, if you can point out more examples then I can look into them. Better if you can help investigate and make things more efficient (in the sandbox again!), as that would be really useful. However, saying things like "I will once again disable this change for all subinfoboxes (unconditionnally)" is not useful nor welcome. Thanks. Mike Peel (talk) 18:02, 11 May 2020 (UTC)
You are not using the sandbox yourself to make tests for your changes. It's a fact that you've severaly degraded this site with tons of errors and severe degradation of performance
This is visible for everyone. You are not constructive because you insist in doing these recursive infoboxes when they are in fact almost never needed (this is jsut duplicating info by copying again and again to tons of unrelated pages, including importing all their categories (that should have never occured), breaking many categories and causing lot of server damages on millions of unrelated categories. Your edits with recursive infoboxes have created this huge maintenance cost everywhere (with millions pages affected and invalidated in the cache).
So apply all what you ordered me here to yourself. I've not made edits that caused these millions pages being invalidated (and then never refreshed later even after errors that this "feature" introduced). You have invalidated millions of pages, many of them broken now.
So I repeat what I said: DO NOT RECURSE DOWN ANY sub-infobox for related topics are already **linked** at top of the box (that link is enough)! This is absolutely never useful, always undesirable pollution, it generated considerable maintenance cost, and this basic rule is simple to apply and will dramatically reduce the damages. verdy_p (talk) 00:29, 12 May 2020 (UTC)
@Verdy p: Every change I make goes in the sandbox first, just look at the histories and the number of times it says 'sync from sandbox'. I'm handling errors as they are pointed out - if you are aware of currently live ones, please point them out and I'll investigate them. You clearly have a strong opinion here, but I think that the recursion is useful in quite a few categories, as a random example, see Category:Milwaukee Clipper (ship, 1905) and Category:IMO 5235375, or Category:Buildings by Elissa Aalto. It definitely needs improvements, though, which we can make incrementally. Thanks. Mike Peel (talk) 07:01, 12 May 2020 (UTC)
No I disagree, for example: the link to Elissa Aalto is self-sufficient, it shows all the details in its own infobox (which is alsu available on hovering if you have enabled this option) without needing to be repeated (and importing false categories about herself and not about some creations she made, which should neve rinherit things, like the place of birth/schools/death or her related family members or other creations she got: there are lot of information about people, there's no need to reimport them each time a person is named).
The same is true for the ship. There are lot of cases where categories are imported incorrectly, and in fact this is unncessary and very costly (as you've seen with all the details about countries, or major sports events, and even about famous people, or large topics with lot of details like vehicles). We don't need that in articles: for details we just lik to the related articles (when they exist) and want to keep things short and simple to read (and there's no risk of ambiguity as the link is there to disambiguate everything).
So again I ask you remove these subinfoboxes for related topics (notably here because there can be several ones, each with their own details) if and only if these topics have a relevant link to their own category (which has its own infoboxes for details) already listed at near the top of the infobox. verdy_p (talk) 07:43, 12 May 2020 (UTC)

Performance questions[edit]

The extra information can be nice, but there can also be too high a cost, which I think it is at the moment. A few comments:
  • The Category:Milwaukee Clipper (ship, 1905) page, when I go to edit it, is taking roughly 4.9 to 5.0 *seconds* of *CPU time*, and over five seconds real time, to render. That number is down from 7ish seconds due to a change made per an earlier discussion here, which is great, but not nearly enough. If I disable the infobox template by deleting the first brace character, leaving everything else there, it now takes 0.06-0.07 seconds of CPU time, and 0.1 - 0.14 seconds real time to load. That is fast, and most categories are a bit faster than that (under 0.05 seconds CPU, under 0.1 real).
  • A website's loading time is pretty critical. Once you get above a second to render a page, you can start losing users, more after two seconds, and it's very bad after three. Just doing a google search there is this document, which has several quotes giving various opinions of exactly where it becomes a problem. And it is apparently a factor in Google's site ranking.
  • For the Wikidata Infobox template to take 5 seconds all to itself is singlehandedly taking Commons from a very fast website to an egregiously slow one, at least on pages where the template appears. I would guess image pages are the most common and are unaffected, but browsing category pages has become much worse anywhere this template exists. If cached it's OK, but any time the template is changed, or any time files or categories are added or removed from a given category, it will need to be re-rendered. And those pages are now painful if not recently cached.
  • For people donating their time to categorizing stuff and managing categories, the penalty is now on every "preview" click as well. It's either taking away their time, or reducing the amount of work they can get done in a given time.
  • I do like a lot of the extra information provided, but if the cost is this high, it's not worth it. I would imagine you will get some arguments against particular data being shown, when the real frustration is the performance. If that can be made acceptable, then the information shown becomes a function of screen space really, and more information if not losing significant performance) is usually better.
  • Frankly, a full second of CPU time is an *enormous* amount of processing. Even for a complex template, it seems to me it shouldn't be anywhere near there -- I can't remember other templates anywhere near that performance cost. Something seems really wrong, either some pathological template or Lua code doing way more work than is being realized, or a database index is broken, or something. I really don't know the architecture at all or where the performance problem could be. It's possible there is a quick solution, but I have no real idea.
  • If you get the CPU time down to 0.1 seconds, which would be a tripling of the CPU time for pages without the template, that should be fine. Somewhere between there and 0.5 seconds is probably the point where it's not worth it, and it's time to cut functionality out until the performance can be improved. The current five seconds is far, far beyond that -- I'm finding I have to disable the template if I want to use the "preview" button like I'm used to. And sometimes I may forget to re-enable it. I don't know if the excessive CPU usage is causing server problems or not, but it's definitely causing editing and viewing problems.
  • The template has been around for quite a while, and is very cool -- it's only recently (maybe the last month or two) that something changed and it started taking far, far longer to render than it used to. I have no idea what changes were made to potentially cause that. I definitely like the template and would prefer for the performance to be fixed rather than losing information, but the extra info is certainly not 100x more valuable than the actual category contents which I'm trying to see, and is not worth 100x the rendering time it's currently taking.
In short, would definitely like to know what options there are -- if this recursion is the problem, and disabling it gets the template to at least under a second and preferably closer to a tenth of a second, maybe that would work for now until a way can be devised to make the recursive feature performant. Or maybe the problem is elsewhere, but could experiments be made to see how to drastically reduce the render time? Carl Lindberg (talk) 12:17, 12 May 2020 (UTC)
@Mike Peel: I was just debugging the reason why Category:Pages with script errors takes so long to respond and come to the same conclusion Carl Lindberg just made: It takes 6.9 s to load with {{Wikidata Infobox}} and 0.07 seconds without. 6.9 seconds is way too long, and people will begin to remove those templates. We had issues like this in the past where some people were manually adding creator templates to files while others were removing them with bots because they had some categorization issue. It was very unpleasant. I think we can give up some functionality to speed this template up. --Jarekt (talk) 18:26, 12 May 2020 (UTC)
Also according to page info of Category:Matches_of_the_2014_FIFA_World_Cup the category shows looks up statements from 58 entities. That may by why it takes 12 seconds to load. --Jarekt (talk) 19:25, 12 May 2020 (UTC)
OK, I'm really busy this week (literally going up and down a mountain each day for work), but I can look into this in more detail over the weekend. If you're interested in helping, then please try things out in the sandbox. @RexxS: One thing in particular might help, in Module:WikidataIB around line 650, Commons category (P373) is always fetched, could that logic be changed so that if the commons sitelink is available then that is used, and only if it's not available is Commons category (P373) checked? Or better, just remove Commons category (P373) support now that we're over the critical mass of sitelinks. Thanks. Mike Peel (talk) 06:31, 13 May 2020 (UTC)
@Mike Peel, Jarekt, Clindberg: I altered Template:Wikidata Infobox/core/sandbox to use Module:WikidataIB/sandbox, where I removed support for P373. Testing a preview of Category:Matches of the 2014 FIFA World Cup a few times using the main {{Wikidata Infobox}} and the sandbox {{Wikidata Infobox/sandbox}}: the random variability in the results is far greater than any saving from disabling that (quite cheap) call. Most of the time, it's timing out on Lua time usage. It also then mis-categorised the page into every available category of year and month type, so there's something that is iterating through qids and calling the infobox code. I've re-enabled P373 support to eliminate that problem.
I tried disabling the SEO, the checks and the categories, which made only a small improvement. I tried disabling the location field, which again did very little.
I restored all of those and tried moving the getQid call to the main template from the core. Removing 586 redundant calls sped things up a bit, but it is still not enough. You can see the changed coding for that in the two template sandboxes. I'll have another look tomorrow if I can. --RexxS (talk) 14:22, 13 May 2020 (UTC)
@RexxS: As a thought, is there a cheap way to retrieve a list of all properties that are set in a Wikidata item? If so, a function that retrieves those, and returns a list of them ("P18,P31,P276,...") that could be passed into the infobox core as a variable, along the same lines as suppressfields (but as a whitelist rather than a blacklist) might reduce the number of checks that need to be made while the infobox is being assembled. Thanks. Mike Peel (talk) 17:14, 15 May 2020 (UTC)
@Mike Peel: No. That would simply call getEntity() as we used to do before getBestStatements() was implemented. Loading the entire entity and then scanning through it for properties that exist completely defeats the savings of using getBestStatements(). If you really want to go down the path of removing the overhead of multiple module calls, then you need to write the entire infobox in Lua. That's perfectly possible, but begs the question of what order you would use for the fields in the infobox? Also how many maintainers would we have for an all-Lua version? --RexxS (talk) 18:45, 15 May 2020 (UTC)
@RexxS: Perhaps we could ask the developers for a Lua call that returns the list of properties without having to resort to getEntity? But perhaps the best approach is to switch to Lua completely - since your Lua course at Wikimania Stockholm I've been picking up various bits of Lua while writing Module:Wikidata Infobox, but switching completely would still be complex. The main issue I think I'd have is the passing of frames to WikidataIB - see the 'formatLine' function in Module:Wikidata_Infobox/sandbox - is there a simpler way to do that? Thanks. Mike Peel (talk) 18:57, 15 May 2020 (UTC)
Yes, Mike. The new infobox would be based on the code in Module:Infobox and Module:WikidataIB, but at the top level, it would simply load the entire entity once, and then loop through all of its statements to generate each html row of the infobox, presumably using the property label as the field name (although you could have a table of substitutions if required); each row's value would then be the call to Wikidata. You'd have to fix some exception cases like the image and caption, and statements that we don't use like instance of (P31), but essentially it would only require a single call to generate the infobox. The only thing in that frame would be the qid (and perhaps fwd and spf if they were to be implemented). The question of sourcing and osd is something to think about. --RexxS (talk) 19:13, 15 May 2020 (UTC)
There are known causes for this lack of speed:
  • the major reason in the Wikibase interface in PHP which lacks functionality to efficiently filter just the properties we want (all properties are retrieved), just the qualifiers we want (all qualifiers are loaded), as well as filter for labels/descriptions we want (too many languages, and we don't care at all about retrieving aliases, only useful in Wikidata), as well as sitelinks (too many site codes for unneeded languages, note that sitecodes for lovalized projects group languages differently, they use interwiki codes and group several distinct languages not using the same BCP47 code as for labels/descriptions/aliases and monolingualtexts). And the JSON returned is MUCH too verbose with lot of redundancy. Wikibase should have a much more efficient way to be quiries instead of using "mw.wikibase.getEntity()" which is very costly, has very badly tuned caches (15 entities are fully cached even if we don't need them completely, but this is still not enough for infoboxes showing more than 15 entities: there are repeated queries to Wikidata for the same entities, which takes a long time; additionally there's a cache for only 50 properties which are also kept entirely with all their own entity data, so we end up with up to 65 entities in memory, using lot of memory, up to 7MB, sometimes even more).
  • Wikibase does not properly intern many Lua strings (this is a limitation of Lua) and many Lua tables have overlong collision lists (also a bug of Lua, with inefficient hashing)
  • Wikibase returns a lot of unnecessary metadata; the entities in caches are not kept with weak references (so we get "out of memory" errors): memory is incorrectly managed in Wikibase.
  • Really we need better and faster way to retrieve more selectively the data we want (probably using by queries by RDF triples, using SPARQL, but without any internal cache in this interface, and with a JSON output that is much better filtered).
  • Several algorithms in Wikibase and in the Module:Wikidata are very inefficient, using slow lookups. There are ways to improve it, but the current Module:Wikibase is wrong, and Module:WikibaseIB is not really much better because it also keeps too much data in memory (then there's also a huge activity of the garbage collector because it uses really too many intermediate objects for various string operations or conversions, plus a very inefficient sort algorithm, which can also reload entities being compared but that are no longer in the Wikibase cache: the big JSON from aech query is reparsed again and again for the same entities).
  • The topologic sort algorithm (for tree-like data, even if they contain loops that can be detected) is also very inefficient (there's absolutely no need to "mark" items with additional tables, in fact this sort can be made in a single visit pass in sequential order without even having to madify the traversed nodes in trees). I've rewritten this algo in a much faster way, using much less memory (only an map of entity ids to entity is sufficient; there's no need to add data for rank in the tree, no recursion, all visits can be made in a single loop: it can be implemented as a simple forward iterator, so no second pass is even needed to format the topologically ordered items; it's even possible to use the iterators in Lua and return to the wiki parser that can recall Lua later with the iterator keeping its progress state: most formatting should be done outside Lua, because the wiki parser is more efficient and has better memory management for processsing templates and non-costly parser functions: a Lua call can be costly and notably Lua calls that use mw.wikibase queries).
  • May be the alternative would be to not use Lua for Infoboxes, but use a custom parser function written directly in "native" PHP (PHP is compiled, unlike Lua which uses a VM for interpreting bytecode and which has numerous memory management issues, very inefficient hash tables, inefficient string hashing functions, very poor garbage collection, inefficient management of the pool of unmutable strings) and that would build a single selective SPARQL query not requiring any cache of full entities. verdy_p (talk) 02:19, 22 May 2020 (UTC)
  • Note: as long as getEntity() can only load full entities, we'll have a problem. We should be able to first build the query we need for all the useful properties/qualifiers/labels/languages, and retrieve only those, then a pass to eliminate conditional properties, before even starting to format everything. verdy_p (talk) 02:25, 22 May 2020 (UTC)

Removing categories[edit]

@Mike Peel:: the categories that I removed from the core are fake almost always, never needed. They are only for specific categories (year numbers) that are categorized directly by their own template, separately from the infobox, without even performing any Wikidata query: they are resolved algorithmically and locally). These additional entries in Infobox just create lot of unneeded overhead, and frequent errorsn with fake entries added in these autocategories by year type or by month.
I did not need any sandbox to remove them directly, there was absolutely no degradation of functionality. And their cost is too expensive for all other unrelated pages (infobox/core needs serious optimization, it takes really too much time now, and lot of ressources on server, increased now by multiple subinfoboxes which were also added, multiplying the cost by several factors). Did you even notice any problem with this removal ? Did you ever look at pages with script errors (almost always by categories incorrectly listed as if they were years). We never need such autocategorization for years, all Gregorian years (and months) are categorized dirctly by their own template, with much lower cost. No need to add this for all other categories or pages that have an infobox. Additionally the names of the target categories are clearly wrong and are about to change.
Given the cost of the infobox/core, this unneeded overhead can be removed directly. verdy_p (talk) 16:23, 15 May 2020 (UTC)
@Verdy p: @Pigsonthewing: requested their addition, and they shouldn't take up much processing power. What you did was remove a symptom, not a cause. My plan was to move those higher up in the template code if necessary. In general, the way the development of this template works is that things are discussed here, sandboxed, then deployed in a batch to avoid invalidating cache too often. I've upped the page protection to admin-only edits to enforce that for now, although it hasn't been a problem until now... Thanks. Mike Peel (talk) 16:39, 15 May 2020 (UTC)
So what we need now to fix:
  • Lua needs to have its hash tables fixed (notably for all string keys): they don't work as intended (as a "fast hashed" access), and we've reached a point where the worst case is reached with most lookups for keys used in Wikidata JSON queries are only found by long scans over many nodes (the access time is then proportional to the total number of items in the table! This is no longer a fast hashed table access! Be careful with Lua tables using string keys, and notably any global "hashtable" used for string interning, supposed to save memory but which is very slow with all these scans caused by overlong collision chains, and a very inefficient internal representation of collision chains using additional storage for chaining "next" pointer in every table node!).
  • We need a better more compact representation of JSON query data: there's lot of unnecessary duplication of language codes associated to translated labels/aliases/descriptions, requiring the creation of an additional subtable for only these two items, even if these subtables are values for a specific language (the same) or values in an integer-indexed ordered table used as value for the same language. This is a defect of the current JSON query format (and JSON deserialization in Lua uses way too much memory, especially when loading the full data for a full item). For that we need a new query format (not the current JSON model which is very inefficient and really too much verbose, with overlong desrialization using lot of memory in Lua).
  • We need probably new more selective queries supported by Wikibase/Wikidata to load specific properties, and not the full set of properties with all their qualifiers (using an internal case in Modulewikidata will not solve the problem, everything is still loaded, in inefficient tables indexed by strings with lot of collisions and very slow lookup using scans of long chains).
Seriously, did I make something damageable ???? Consider removing these unnecessary lines in Infoxbox/core given they are never needed, produce lot of fake categorizations (caused by internal memory limits in Lua script), and removing it saves CPU time everywhere (in the wiki parser for templates). Infobox/core template is dramatically too complex and performs really tooo many Wikidata queries (and Module:Wikidata itself has severe performance problems as it is not selecvtive enough about the data it loads from the server). verdy_p (talk) 16:45, 15 May 2020 (UTC)
Module:Wikidata (and also Module:Wd) should be deprecated in favour of Module:WikidataIB, that was one of my plans to look through this weekend. Thanks. Mike Peel (talk) 16:52, 15 May 2020 (UTC)
@Verdy p: What performance increase did you get by removing the categories? I couldn't detect any when I tested it in the sandbox. --RexxS (talk) 18:45, 15 May 2020 (UTC)
It's not a question of "performance" (though it is still true) but memory usage. And definitely this template is too huge. Adding these categories also counts on the number of Wikidata queries performed on ALL pages using infoboxes, and there are still many that experience memorey exhaustion. We can save many unneeded queries and template expansion time on tons of pages that never need these categorizations: these subcategories are jsut for specific categories pages which are ALREADY categorized by their dedicated navbox, without performing any query and not depending at all with Wikidata.
In addition this blocks the renming of these categories (which are named only for their starting day ignoring the fact they are also categorizing the ending days and in fact every date in these years (or months). They are clearly not needed, we don't need the infobox to properly categorize these years and months.
Any way to reduce the cost of infobox by being more selective is a win (and clearly the infobox core is now really slow, and its cost on everypage must absolutely be reduced): 6-7 seconds per page is much too high, the server is now extrmely busy and cannot even refresh the pages correctly: it's busy 100% of the CPU, everyday, at all hours, only because of it (and notably since the introduction of subinfoboxes that were not even needed but added without any form of discussion, causing lot of errors and false categorizations everywhere).
You've not properly used the sandbox, and not thought at all if they were really needed (they are absolutely not needed in ANY of the relevant categories to which they would apply: this is duplicate work, and these also don't properly set the correct sort key, which is correct in the dedicated year and month navboxes).
So you reject my edit which is perfectly safe and goes in the right direction. But really harmful additions that were added without prior talk or any evaluation on a limited set of pages (using a sandbox version only for a subset of categories instead of being applied unconditionally everywhere) have been kept, causing major damages: the sandbox is not used as it should be: it's not intended to test a single page or preview, its effect mist be analyzed on a significant **subset** of real pages and NOT all pages using it (just to see some days laters tons of errors spread everywhere). verdy_p (talk) 06:01, 16 May 2020 (UTC)
verdy_p, It is not OK to be "improving" templates and modules actively maintained by other users, without discussing the proposed changes first and arranging best time to release the changes. You have made twice, without prior discussion, seemingly unnecessary changes to Module:Wikidata label altering 14M pages for unknown reasons. Now you are "fixing" this template against the wishes of its maintainers. I see you just got template editor rights (given to you by User:Magog the Ogre) allowing you to edit highly used templates and modules. That right is usually given to individuals trusted by the community to know and follow rules and traditions of this project. Please follow those rules and traditions or you will loose the template editor right. --Jarekt (talk) 04:17, 18 May 2020 (UTC)
Why the quotes around "improving". I explained above what I did. These were real needs (and related to other talks elsewhere). These were tested first and also after.
This huge template has lot of performance problems and what I did could certainly not hurt except going to the correct direction by a small step. verdy_p (talk) 07:23, 18 May 2020 (UTC)
The "wishes of maintainers " is not a policy. Everyone modifies what other are doing in any wiki, and improves what he thinks appropriate. Only when there are diagreement, there can be discussions. Thanks all Wikimedia wikis are not the property of the initial creator of any page. And Many things I've done have been later modified by others (including templates I create here). Ther is no express "wishes" from authors except the general consensus that these should not break the work of all others (like this Infobox/core now does to everyone, with its huge performance and resource usage problem that affects EVERYONE (and that I modestly wanted to fix as I explained you).
But visibly you continue ignoring all explications and want to keep the bad performances experiences by everyone, and continue to steal massive server ressources by repetedly adding more and more complication and more costs instead of fixing what is now a major problem. You have made repeated edits that have affected millions of pages on this wiki many times (and the server still cannot follow the speed of these additions, most pages are now outdated, and this site has never been as slow as it is today, and this continues to be worse and worse other time).
Can't you make a pause and start profiling this template and cleanup what is not even needed (like these lines that modestly remove things that are not even not needed but that also block other corrections discussed elsewhere). The problem of false cvategorization continues constantly, jut like the number of pages tracked with script errors.
The addition of subinfobox was not discussed and tested, still it has been applied massively (even if it is broken and made the situation very bad for everyone). I do not trust the initial maintainers that constantly want to add more and more compelxity and cost at huge price for servers and for all visitors).
So even if optimizations and removal of unneeded parts are modest, they are a step for a solution that must be progressively made: this goes with small things that you consider minor, but give nthe current costs, winning a bit somewhere is still benificial as there remains little or no ressources for any progress. Initial maintainers don't always have the best solution, they propose something, that can be improved, because they've not seen everything. And I've NOT broken anything in terms of functionality by removing only something that was completely unneeded but just adding more problems. verdy_p (talk) 09:57, 20 May 2020 (UTC)


There are new errors at Category:Matches of the 2014 FIFA World Cup and Category:Venues of the 2006 FIFA World Cup. Ithought they might be due to {{FIFA World Cups}} but it is due to {{Wikidata Infobox}}. --Jarekt (talk) 14:13, 23 May 2020 (UTC)

I've seen also that (these are NOT new errors, they occurs since days, at least since the addition of subinfoboxes). The Infobox is once again crashing with inefficient and costly loading of data (here because of recursive infoboxes added recently that the author insists to keep even if they are completely unneeded when the subject of the infobox is ALREADY linked at top of the main infobox in the "related subjects": the link is compeltely enough and does not need to be detailed locally, given that it goes to another category that already shows everything). We almost never need these subinfoboxes (except transitionally when one of the "related subjects" has no relevant link to a category or gallery on Commons, so that these subjects are shown as plain text without link: this is only transitional before a relevant category is created in Commons, but for these cases where infobox explodes, this never happens has the complex subinfoboxes are for subjects that should ALL have a target category to link to).
These subinfoboxes areresponsible of the constant and very heavy load of the server now, with time to render all pages now exceeding several seconds, and the memory usage being very near or exceeding the maximum: when the memory is exhausted, or when there has been too many queries to more than 15 entities, we always have an error, and the subinfoboxes or all other template parts further down in the page come to errors: the scripts are even aborted, false categorizations occurs everywhere because the error thrown in Lua is not caught by the Wiki templates).
why can't we just remove these damn'd subinfoboxes that break so many things and were never needed, but were just a personal initiative taken by a single user with an incorrect analysis and no evaluation of the global cost ??? I've ABSOLUTELY NEVER seen any page needing these subinfoboxes!
As well the Wikidata module has severe deficiencies as it collects too much data from the server (e.g. "getEntityObject()" retrieves ALL languages even when they are not needed, we should have "getEntityObjectWithLang(lang)" to remove many labels, aliases, and descriptions; and in fact we never need any alias but only a single label in a relevant language, so getEntityObjectWithLang(lang) should implement language fallbacks on the Wikidata server side, not in the client side on this wiki, and not even in the PHP client, these unneeded data should not reach the local Lua VM, except if a label is explicitly requested for a specific language). And the Wikidata module should use a much more efficient API that use a much more compact JSON format (there are lot of redundancy, this stresses a lot the PHP engine as well as the Lua engine in their respective garbage collectors, and this can explain the huge memory cost and the very huge CPU usage, in addition to the severe performance bugs in Lua's implementation of tables, that do not behave as hashed tables but as unordered arrays with fullscans for lookups; Lua tables are also costly in term of meory allocation: it uses three pointers per node when 2 pointers are clearly enough; and the table size uses exponential growth by an excessive factor of 2, as it is limited to table sizes that are exact powers of 2: to allocate a hash table with just 33 nodes, Lua allocates 64 nodes, each with three 64-bit pointers, i.e. 192 pointers or nearly 1.6KB (some Wikidata entities require more than 800 tables for one entity, i.e. nearly 2MB, and in fact much more if we also include all strings for description texts and aliases as well as all sitelinks on all wikiprojects in all their linguistic editions)! And note that the current JSON interface uses really too many tables and subtables: property values are objects that contain a snak object that contains a datavalue object containing the actual value and internal representation type; and almost all strings returned from JSON are NOT interned at all; a single query requires about 1MB only for the result; and the caches of entities also takes about 5-7MB; each new query requires 2MB, we rapidly explode the 50MB memory limit for running all Lua scripts for rendering a single page!).
Developers of Wikidata, Lua, Mediawiki, Scribunto, and template-admins of this wiki (like you Jarekt because you've blocked many templates without fixing them and using very inefficient algorithms) MUST ABSOLUTELY rework these five parts (which can be done independantly):
  • (1.) a new JSON data model (removing excessive duplication of keys inside their associated values such as language codes in objects already mapped by language code; compaction of snaks; removal of unnecessary "type" subfields which cluters all Lua scripts trying to use Wikidata and requires additional table lookups; adding the necessary server API and a new API for the client side, compatible with this newer compact format).
  • (2.) fixing Lua's tables (the broken "fast-hashing" function for strings, the broken collision lists (where multiple colision lists collide and merge into a single one, transforming a hash lookup into a very slow full table scan via a single long linked list), removing next points in all collision chains, and changing the allocation strategy (not using the exponential growth!).
  • (3.) adding the "getEntityObjectWithLang(lang)" interface to the "mw.wikidata" module (which also includes filters like BestRank, but avoids using separate additional requests to Wikidata); add a way to request only a subset of properties and a subset of qualifiers, not all of them by default, implement a filter on sitelinks (which are not exactly scoped by language but by interwiki code grouping several languages under sometimes different codes). Possibly even allow requesting Wikidata by SPARQL queries, with more customized filters. Note that "Module:WikidataIB" does NOT optimize anything as it depends on "Module:Wikidata" with all its existing deficiencies.
  • (4) if Scribunto uses the 64-bit version of Lua, replace it by the 32-bit version: we will never need the 64-bit version before long, at least not before the server allows many instances of Scribunto for visitors where each instance is allowed to use several gigabytes of memory (the current limit is 50MB for rendering a single wiki page, we are EXTREMELY far from this threshold: this can significantly reduce the memory footprint of the many objects used for Lua tables needed to represent Wikidata JSON results by saving about 40% to 50%!)
  • (5.) And also independantly the Infobox/core template MUST remove the subinfoboxes (this is now urgent and it is the easiest thing to revert this recent addition that causes severe troubles to this wiki). [And once again I request the removal of unnecessary autocategorization of years by dominical letter from this infobox, it is breaks often and is NEVER needed].
verdy_p (talk) 21:08, 23 May 2020 (UTC)
@Jarekt: I've changed both categories to use {{Wikidata Infobox/sandbox}} for now, and the error is no longer present. I'm still trying to improve the performance of the infobox.
@Verdy p: I think the embedded content about the competitions is useful in these cases (the description of what a match or a venue is was less useful, but it's now removed by excluding items with subclass of (P279) values). I also still think they are useful elsewhere (e.g., in ship name categories). Most of what you are complaining about here is out of scope (no-one here can fix how Lua works, or what Scribunto does). Other points are useful, but the main issue we're encountering here is with CPU time, not memory. The infobox shouldn't use getEntityObject at all - getBestStatements is generally better and more efficient - but there are some calls to it in Module:Wikidata Infobox, I've asked @Jura1: to look into those as he wrote those parts of the code. I have added a call to getEntity and getProperties to fetch a list of all properties in a wikidata item, so that the rest of the code can check against that list, which seems to improve performance a bit (@RexxS: this was what I was thinking about above, I found a way to do it that didn't require WikidataIB changes). I'll keep looking for other improvements that can be made, before deploying a new version next weekend (probably). Your help is appreciated - if you can spot specific performance issues that can be fixed without removing features or making the code harder to maintain, please point them out, and of course you can edit the sandboxes directly if you want. Thanks. Mike Peel (talk) 18:24, 24 May 2020 (UTC)
@Mike Peel: Once you call getEntity, you load the entire Wikidata entity, whether you need all of it or not. It's okay if you're only ever calling it for the associated page as you're looking at the cached version and it's not expensive. You're trading increased memory use for increased speed, so remember that as Wikidata expands, every language will add content in their own language to each entity and the memory required for getEntity will increase with time.
@Verdy p: I don't know where you got the idea that Module:WikidataIB depends on Module:Wikidata. That's pure nonsense, and WikidataIB contains a number of optimisations over the earlier module, although the principal difference is in increased functionality not previously available. --RexxS (talk) 19:07, 24 May 2020 (UTC)
That's not "non-sense": there's an evidence dependency (Module:Wikidata is loaded first, then the PHP interface is hidden and no longer accessible. And I looked at the code of WikidataIB, it really contains a dependance in Module:Wikidata, notably for getEntity which it still needs and is memory intensive)
Lua can be fixed (but separately). Lua 5.4 will come soon that will fix some problems with its incorrect string hashing and will improve the collision lists to avoid worst cases (but this is still a work in progress).
And the JSON model can be improved by Mediawiki developers to be much less verbose (using much less memory). I have already made a test showing that the memory required for a full entity can be largely decreased using 3 times less tables and removing all superfluous redundancy of language codes and value types: this should benefit to the size of full entities kept in the cache, so that we could cache more entities with no more memory cost, and so with less external queries to Wikidata for complex infoboxes. For now the cache is not even sufficient for infoboxes, it uses too much memory for large entities with lot of properties, translated labels, translated descriptions, and translated aliases, and sitelinks (and we never need any alias in infoboxes, and most sitelinks have no use at all, except for a few ones at top of the main infobox for a single entity i.e. the entity linked from the current page only!)
Loading a full entity in all languages should never be needed in infoboxes: the Wikidata API should really add getEntityByLang to purge the unneeded languages (it should then implement the language fallbacks, directly in the PHP code so that the extra data si not even loaded in the Lua VM and not even exposed in the JSON data returned and converted to Lua tables). The conversion of JSON to Lua tables should really compress the current redundancy of types and langauge codes and avoid breaking up each property statement into a separate snak table and datavalue table: these two tables can become just one and we never need the 3 fields "snaktype", "type" and "datatype", only one "type" field is enough for all, the "value" and "datavalue" are superfluous, we can just keep a single"value" field; all the rest is "internal cooking" from the legacy JSON model!).
verdy_p (talk) 08:38, 25 May 2020 (UTC)
@RexxS: Understood. I've started phab:T253485 to see if the process of fetching a list of defined properties can be made simpler. Thanks. Mike Peel (talk) 19:29, 24 May 2020 (UTC)
I will have a look. Essentially, what my part of the code does it checks if the associated item has a p31 of education, etc. by region. If that is so, it looks for the country/region item and loads a series of properties from that. So, at least, it would need to load the category item, the main topic item and the region item. Jura1 (talk) 23:12, 24 May 2020 (UTC)
The sandbox version no longer does all that. Shall I re-add it or what's the plan? Jura1 (talk) 00:28, 26 May 2020 (UTC)
@Jura1: It should all still be there? I removed it briefly to check performance, but added it back. I also wrapped the code in some additional checks, to make sure the corresponding properties were present, and that the infobox isn't in 'embed' mode. If it's not working, then I might have done something wrong - remind me of an example category please? Thanks. Mike Peel (talk) 08:25, 26 May 2020 (UTC)
@Mike Peel: There is one for each: health, education, economy. Jura1 (talk) 18:35, 26 May 2020 (UTC)
@Jura1: I found the problem - it was with the check of which properties exist in the article item, not the category item. Now fixed in the sandbox. Thanks. Mike Peel (talk) 18:56, 26 May 2020 (UTC)
Thanks. It seems to work. Maybe I should try to develop more of these. Jura1 (talk) 20:19, 26 May 2020 (UTC)

Links to English Wikipedia in media legend[edit]

Some wikidata items’ images has interwiki links to wikipedia articles in the "media legend" description to the image. Those link correctly in Commons to non-English Wikipedias (if you change Common’s interface to respective language). But links to English Wikipedia attempt to link to Commons instead. Example: LASIK. Links to English Wikipedia work in other places in Commons, but not in Wikidata Infobox. Where should I ask for fixing it?— Роман Рябенко (talk) 21:50, 23 May 2020 (UTC)

Someone fixed it. Now it works for English too.--Роман Рябенко (talk) 06:16, 24 May 2020 (UTC)
@Роман Рябенко: I think you fixed it through your edits at LASIK (Q278846). Due to caching, changes can take a while to show up here - you can do a null edit (edit and save the page without making changes) or purge the cache (add ?action=purge at the end of the URL) to check if it is a caching issue. Also, technically the media legends aren't supposed to include wikitext, so this is an unsupported feature, but it does seem to work... Thanks. Mike Peel (talk) 11:36, 24 May 2020 (UTC)