Template talk:Wikidata Infobox/Archive 5

**Gertrude Mary Woodward**
	British scientific illustrator
	Upload media
	Wikipedia
Date of birth	1861; St Pancras
Date of death	2 September 1939; Hertfordshire
Country of citizenship	United Kingdom; United Kingdom of Great Britain and Ireland;
Occupation	scientific illustrator;
Employer	Natural History Museum, London;
Father	Henry Woodward;
Sibling	Alice Bolingbroke Woodward; Henry Page Woodward; Ellen Caroline Woodward; Martin F. Woodward;
Authority file
	Q23603371; Stuttgart Database of Scientific Illustrators ID: 4383
	Reasonator; Scholia; Wikidocumentaries; KML file; Search depicted;

This is an archive of past discussions. Do not edit the contents of this page. If you wish to start a new discussion or revive an old one, please do so on the current talk page.

Creating Wikidata items for all categories

Hi all. We're about half way through the process of linking Commons categories with Wikidata items - we now have 3.6 million categories displaying the multilingual infobox. I would like to see this increased so that all Commons categories are linked with Wikidata items and use the infobox. This means creating new Wikidata items for the categories where there aren't potential matches with existing Wikidata items.

I've started an RfC about this at: https://www.wikidata.org/wiki/Wikidata:Requests_for_comment/Creating_new_Wikidata_items_for_all_Commons_categories

Please comment there if you're interested in this! Thanks. Mike Peel (talk) 23:05, 18 December 2021 (UTC)

This section is resolved and can be archived. If you disagree, replace this template with your comment. Mike Peel (talk) 19:04, 26 December 2021 (UTC)

Automatic category adding

Please admin or who has access to locked template page, make automatic category/categories adding in a such way it is first first name and not surname. Example of wrong categories (archive, archive 2). --5.43.74.120 21:01, 1 February 2022 (UTC)

It is not clear what you think is wrong, in your example. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 10:59, 2 February 2022 (UTC)

I think they want the category renaming. This isn't the place to discuss that. Thanks. Mike Peel (talk) 11:36, 2 February 2022 (UTC)

This section is resolved and can be archived. If you disagree, replace this template with your comment. Mike Peel (talk) 11:36, 2 February 2022 (UTC)

Day of week categories

{{Edit request}} Please delete the following lines in Template:Wikidata Infobox/core:

-->{{#if:{{#invoke:WikidataIB|checkvalue | val=Q235670 | P31 | qid={{{qid|}}}}}|[[Category:Common years starting on Sunday]]}}<!--
-->{{#if:{{#invoke:WikidataIB|checkvalue | val=Q235673 | P31 | qid={{{qid|}}}}}|[[Category:Common years starting on Saturday]]}}<!--
-->{{#if:{{#invoke:WikidataIB|checkvalue | val=Q235676 | P31 | qid={{{qid|}}}}}|[[Category:Common years starting on Wednesday]]}}<!--
-->{{#if:{{#invoke:WikidataIB|checkvalue | val=Q235680 | P31 | qid={{{qid|}}}}}|[[Category:Common years starting on Friday]]}}<!--
-->{{#if:{{#invoke:WikidataIB|checkvalue | val=Q235684 | P31 | qid={{{qid|}}}}}|[[Category:Common years starting on Tuesday]]}}<!--
-->{{#if:{{#invoke:WikidataIB|checkvalue | val=Q235687 | P31 | qid={{{qid|}}}}}|[[Category:Common years starting on Monday]]}}<!--
-->{{#if:{{#invoke:WikidataIB|checkvalue | val=Q235690 | P31 | qid={{{qid|}}}}}|[[Category:Common years starting on Thursday]]}}<!--

-->{{#if:{{#invoke:WikidataIB|checkvalue | val=Q217041 | P31 | qid={{{qid|}}}}}|[[Category:Leap years starting on Sunday]]}}<!--
-->{{#if:{{#invoke:WikidataIB|checkvalue | val=Q217026 | P31 | qid={{{qid|}}}}}|[[Category:Leap years starting on Saturday]]}}<!--
-->{{#if:{{#invoke:WikidataIB|checkvalue | val=Q217015 | P31 | qid={{{qid|}}}}}|[[Category:Leap years starting on Wednesday]]}}<!--
-->{{#if:{{#invoke:WikidataIB|checkvalue | val=Q217036 | P31 | qid={{{qid|}}}}}|[[Category:Leap years starting on Friday]]}}<!--
-->{{#if:{{#invoke:WikidataIB|checkvalue | val=Q217034 | P31 | qid={{{qid|}}}}}|[[Category:Leap years starting on Tuesday]]}}<!--
-->{{#if:{{#invoke:WikidataIB|checkvalue | val=Q217024 | P31 | qid={{{qid|}}}}}|[[Category:Leap years starting on Monday]]}}<!--
-->{{#if:{{#invoke:WikidataIB|checkvalue | val=Q217019 | P31 | qid={{{qid|}}}}}|[[Category:Leap years starting on Thursday]]}}<!--

All of these categories have been redirected, and the target categories (e.g., compare Category:Common years starting on Sunday with Category:Common years starting and ending on Sunday) are already present on the pages containing these values, so the special categorization rule appears no longer necessary. --R'n'B (talk) 12:40, 21 June 2021 (UTC)

It was @Pigsonthewing: that wanted these adding in the first place, any comments? I'll implement this soon if not. Thanks. Mike Peel (talk) 19:17, 16 July 2021 (UTC)

Thank you, Mike, for the ping. It's my view that the code should be updated, and the manual categorisation be removed from the affected categories, in favour of the infobox. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 20:54, 16 July 2021 (UTC)

@Verdy p: This was the discussion I referred to in [1]. To emphasise, it needs a discussion here before a decision can be made. Thanks. Mike Peel (talk) 17:45, 20 August 2021 (UTC)

@Mike Peel: And that's why I removed these 14 lines from the SANDBOX version, and I FULLY tested them (with the sandbox): they are NEVER needed.

I have NOT changed the base tempalte, but the sandbox is exactly what is needed to propose (and properly test) a change to the base template. That's what I did. I was explicitly requested to find a solution and tested it live. Reverting this test (which is conclusive and successful) is very unproductful and will not help anyone.

Please remove these 14 lines, they are NEVER needed anywhere (not even in any of the ~2000 year categories where they are occuring and which are ALWAYS incorrect). And you'll save code/time/mempory in the Infobox for all the many other pages (the Infobox makes too much guesses and breaks often due to its giant size: this saves significant number of calls to Wikidata, memory, CPU time...). All the autocategorization is handled directly and correctly in a single template call used in all these pages, without needing any support from the infobox.

The infobox makes TOO much things, and too much guesses. It uses too much resources when it's not needed at all (autocategorization in the Infobox is just a temporary helper that should be limited as it is very costly on too many unrelated pages).

And you forgot the more recent discussion I had publicly here: Template talk:Yearcategory. (that nav template is fully functional and has NO problem at all, only the infobox is currently wrong). The deletion was also requested since more than one year. Only one user requested it, the code above was added (and locked) without any prior test or discussion, it has never worked. verdy_p (talk) 17:55, 20 August 2021 (UTC)

It was requested by @Pigsonthewing: . So far @R'n'B and Verdy p: have opposed it, not sure what @迴廊彼端: thinks. I'd like to see more input before deciding what to do here. For now, I'll implement a fix rather than removing it. In term of performance, it's negligible compared to the rest of the template. In terms of discussion elsewhere, it helps to have the discussion here so people see it - or at least ping others to include them in the discussion. Thanks. Mike Peel (talk) 18:15, 20 August 2021 (UTC)

fix implemented in the sandbox. Thanks. Mike Peel (talk) 18:33, 20 August 2021 (UTC)

This is demonstrated now in ALL year categories, that no longer place these false categories. All the correct onees are in the "YearCategory" template already. Nothing in these 14 lines should be kept (this is the only fix to do, no need to change names in the 14 lines, they are NEVER needed anywhere, all the pages needing them are using the Yearcategory template, and optionally invoking the infobox).

Just before you have reverted the infobox sandbox, all these 14 redirected categoriers were empty, as appropriate, now they start being fed again (unnecessarily) by the infobox whereas the correct categorty is already in the "Yearcategory" template.

Can't you understand that? You abuse you power if you don't allow anyone to use a sandbox that is meant to demonstrate that everything is OK to make the removal proposed multiple times by multiple users.

I've made all the required tests, according to existing policies. You just break things again and block the solution even if it's simple ! verdy_p (talk) 18:21, 20 August 2021 (UTC)

And Mike, ~this is YOU that have made the editwar here, acting blindly and rejecteing multiple requests, and rejecting any test of a demonstrated solution for something correctly tested and requested since molkng in multiple discussions; I made the correct test to demosntrate that these deletions were appropriate!! verdy_p (talk)

@Verdy p: The sandbox is used to test features before deploying them, I queue things up in there before making an edit to keep edits to the main template to a minimum. It can't show that something isn't being used, you can't do that unless you do something daft like switch all year categories to the sandbox, which you should never do. It's simple to remove these lines - but the question asked here is *whether* they should be removed. Right now you're mostly adding noise to that discussion. Thanks. Mike Peel (talk) 18:33, 20 August 2021 (UTC)

No you pollute the discussion by not seeinh the demonstration thatI made showing that all these redirected categories (about 600 were including the infobox) were now empty, and still not missing the correct category.

I've used the sandbox properly to test and demosntrate that these 14 lines (to add a single broken category) were not needed at all and could be safely removed. They are NEVER useful for anything. But now with your revert in the sandbox we see the problem occuring again and the tests are now failing, when they were successful with the sandbox Infobox not containing these 14 lines!

We never need these lines in the Infobox, nowhere! And it is necessary to remove them to allow working with other calendars than the Gregorian calendar (including the Julian calendar for example).And wikiata contains many fake entries tat cinrrectly give the incorrect weekdays, it has lot of work to do to properly handle other calendars and make correct data calculation, but in Commons the tempaltes dod the correct thing without using the infobox autocategorization importing things blindly (even when they are incorrect)... verdy_p (talk) 18:49, 20 August 2021 (UTC)

Category redirect usage fix request

The {{/core}} subtemplate has coding pointing to the following categories, which should be moved to their current names (assuming these are used at all):

Thank you. -BRAINULATOR9 (TALK) 03:03, 24 January 2021 (UTC) @Brainulator9: I've merged this with a related discussion, please see just above this. Thanks. Mike Peel (talk) 18:45, 20 August 2021 (UTC)

This section is resolved and can be archived. If you disagree, replace this template with your comment. Mike Peel (talk) 20:08, 4 February 2022 (UTC)

Automatic category adding 2

Please admin or who has access to locked template page, make automatic category/categories adding in a such way it is first first name and not surname. Example of wrong categories (archive, archive 2). --5.43.74.120 15:02, 4 February 2022 (UTC)

You need to discuss this at Category talk:Saša Kovačević, there's nothing that can be done about this here. Thanks. Mike Peel (talk) 20:06, 4 February 2022 (UTC)

This section is resolved and can be archived. If you disagree, replace this template with your comment. Mike Peel (talk) 20:06, 4 February 2022 (UTC)

typically sells (P7163)

Hello. It would be great for categories such as Category:Bird stores if this property was displayed in the Infobox. Can someone implement that? Thierry Caro (talk) 04:47, 9 November 2021 (UTC)

@Thierry Caro: This is now in {{Wikidata Infobox/sandbox}}, please test. Thanks. Mike Peel (talk) 12:56, 2 February 2022 (UTC)

@Mike Peel: It feels like it works fine! Thierry Caro (talk) 19:29, 2 February 2022 (UTC)

This is now live. Thanks. Mike Peel (talk) 19:22, 19 February 2022 (UTC)

This section is resolved and can be archived. If you disagree, replace this template with your comment. Mike Peel (talk) 19:22, 19 February 2022 (UTC)

Celestial coordinates problem

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 [2] whereas it should go to [3]. 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)

@Huntster: For the main issue, see my reply below. For the other two, I've also changed these in {{Wikidata Infobox/sandbox}}, please have a look and see if it works as you expect. Thanks. Mike Peel (talk) 12:45, 2 February 2022 (UTC)

This is now fixed. Thanks. Mike Peel (talk) 19:21, 19 February 2022 (UTC)

This section is resolved and can be archived. If you disagree, replace this template with your comment. Mike Peel (talk) 19:21, 19 February 2022 (UTC)

interchange station (P833)

Hello. Having this property displayed would be quite useful for categories such as Category:Gare de Besançon-Viotte. Can we make this happen? Thierry Caro (talk) 03:23, 18 January 2022 (UTC)

@Thierry Caro: It's now in {{Wikidata Infobox/sandbox}}, please have a look and see if that works as expected. Thanks. Mike Peel (talk) 12:41, 2 February 2022 (UTC)

@Mike Peel: I can see no bug! It's ready. Thierry Caro (talk) 19:30, 2 February 2022 (UTC)

@Thierry Caro: This is now live. Thanks. Mike Peel (talk) 19:20, 19 February 2022 (UTC)

This section is resolved and can be archived. If you disagree, replace this template with your comment. Mike Peel (talk) 19:20, 19 February 2022 (UTC)

Super-wide infobox for Andromeda Galaxy?

Hi Mike! The infobox of Category:Andromeda Galaxy is super wide because of a reason that is a bit unclear to me... any idea? Thanks, Spinster (talk) 15:14, 26 January 2022 (UTC)

After some back-and-forth investigation: the infobox looks OK for me in Firefox 94.0.1 (Mac OS 10.13.6) but stretches very wide in Chrome 97.0.4692.71. It's the wikisky.org link that doesn't break properly there. Spinster (talk) 15:25, 26 January 2022 (UTC)

Spinster: I think I've fixed it. The WD entry had two entries for RA and DEC. I've deprecated the older of the two for each. — Huntster (t @ c) 16:01, 26 January 2022 (UTC)

@Huntster: it indeed looks good in Chrome as well now! Thank you so much! Spinster (talk) 16:16, 26 January 2022 (UTC)

Spinster: Not a problem. Of course, all infobox links to Sky-Map are of zero value right now, as Sky-Map uses "RA (hours) DEC (deg)" rather than the more standard "RA (deg) DEC (deg)" that's used by entities like SIMBAD and NED. — Huntster (t @ c) 16:27, 26 January 2022 (UTC)

@Huntster: Thanks for spotting that! It should be fixed in {{Wikidata Infobox/sandbox}} now (RA in degrees / 15 = hours), could you test it to make sure it's working as expected? Thanks. Mike Peel (talk) 11:45, 2 February 2022 (UTC)

Mike Peel, oh my, I didn't think it would be such a simple thing to fix. Thanks for that, but....

I admit that I messed up my previous comment: hour/deg is the more common compared to deg/deg, and is what's used by Sky-Map, SIMBAD, NED, etc. The problem is that when *decimal* formatting is used, that's when some sources switch to deg/deg. Further complicating it is that right ascension (P6257) dictates using deg/deg without being very apparent about it, and Sky-Map needs a weird decimal version of hour/deg passed to it to function, as you've deduced. sigh. Some WD items use decimal hour/deg, some use decimal deg/deg. I'm trying to think of a way to make it more apparent to users which format should be used for that Property, but nothing feels right. So, now I'm questioning whether a "fix" here should be done at all, or if this is a "screw it" moment and force any fixes on WD. I don't know a good way forward and my head honestly hurts because it's such a mess and my time is becoming increasingly limited by work. I'd appreciate your thoughts. — Huntster (t @ c) 00:21, 3 February 2022 (UTC)

Heck, at this point I may just be confusing myself, I don't know anymore. — Huntster (t @ c) 00:26, 3 February 2022 (UTC)

@Huntster: Measuring RA in Hours is kinda old-fashioned, and is more an optical thing. I tend to work more in Galactic coordinates, where degrees are always used. But decimal hours are even weirder, which is why I didn't expect to see them! right ascension (P6257) does have the constraint that the value should be in degrees, and it looks like that is how it is being used, I can't spot any that are using hours? I think for now the solution is to assume degrees, and convert here to hours for the Wikisky link, and to try to get Wikidata to be consistent - and if that doesn't work then we can revisit this to do something more complex. Thanks. Mike Peel (talk) 20:04, 4 February 2022 (UTC)

Yes, yours makes plenty of sense. I appreciate you discussing this and working on the fix. — Huntster (t @ c) 00:52, 5 February 2022 (UTC)

@Spinster and Huntster: This is now live. Thanks. Mike Peel (talk) 19:15, 19 February 2022 (UTC)

This section is resolved and can be archived. If you disagree, replace this template with your comment. Mike Peel (talk) 19:15, 19 February 2022 (UTC)

Lyricist/lyrics by (P676)

{{Edit request}} Please add lyrics by (P676), e.g. for infoboxes related to musicals or popular songs. In some cases this is the same person as librettist (P87), but not always, as A Grand Night for Singing fails to mention Hammerstein, of the famous songwriting duo Rodgers and Hammerstein and Dearest Enemy omits the lyricist of Rodgers and Hart. Display-wise (visually), I think P676 should appear below composer (P86) and above librettist (P87). Thanks. --Animalparty (talk) 07:30, 31 January 2022 (UTC)

Please don't use {{Edit request}} unless you are providing code or text that can be substituted. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 11:01, 2 February 2022 (UTC)

@Animalparty: It's now in the sandbox, please try {{Wikidata Infobox/sandbox}} to make sure it's working as you expect it to. Thanks. Mike Peel (talk) 11:41, 2 February 2022 (UTC)

@Mike Peel: Thanks, this edit seems to work well and look good where I've tested it. "Take Me Out to the Ball Game" (sung by every American at every professional baseball game in every 7th-inning ever) gives credit to lyricist Jack Norworth. Meanwhile, "God Bless America" indicates Irving Berlin was both the composer and lyricist, and A Grand Night for Singing allocates credit to the composer, lyricist, and some guy who libretted. I still think qualifiers should be suppressed for most if not all fields (excepting perhaps marriage dates; Wikidata is unfiltered trivial pedantry run amok, Commons should be filtered, tastefully arrayed presentation), but that's a dog for a different derby. Cheers. --Animalparty (talk) 01:13, 5 February 2022 (UTC)

@Animalparty: This is now live. Thanks. Mike Peel (talk) 19:14, 19 February 2022 (UTC)

This section is resolved and can be archived. If you disagree, replace this template with your comment. Mike Peel (talk) 19:14, 19 February 2022 (UTC)

Errors at Pacific_Ocean

I am not sure how to fix lua errors at Pacific_Ocean. --Jarekt (talk) 03:51, 17 February 2022 (UTC)

@Jarekt: It's caused by too many values of inflows (P200). I've added a maximum of 20 in {{Wikidata Infobox/sandbox}}, will deploy that soon. Thanks. Mike Peel (talk) 18:08, 19 February 2022 (UTC)

Fix is now live. Thanks. Mike Peel (talk) 18:22, 19 February 2022 (UTC)

This section is resolved and can be archived. If you disagree, replace this template with your comment. Mike Peel (talk) 18:22, 19 February 2022 (UTC)

Identifiers for monuments in Germany

Hello @Mike Peel: the Infobox currently shows the value of property d:Property:P4244 for monuments in Bavaria (for example Category:Falterstraße_24_(Dettelbach) -> BLfD-ID: D-6-75-117-42).

Would it be possible to add/display also the newer property d:Property:P9339 for Bavarian monuments? The advantage of this property is, that is has a formatter URL, so it can be linked to an external website, for example: https://geoportal.bayern.de/denkmalatlas/searchResult.html?objtyp=bau&koid=62066

Other monument IDs for Germany are

some of them have a formatter URL and there could be made clickable in the Infobox. Thanks a lot! --M2k~dewiki (talk) 22:57, 20 February 2022 (UTC)

Zur Info @Derzno, Rufus46, Edelmauswaldgeist, Ordercrazy, and Z thomas: Zur Info --M2k~dewiki (talk) 23:06, 20 February 2022 (UTC)

@Mike Peel: please add d:Property:P9342 as well and stay tuned for "Ensembles". These are currently requested on top. (adding @Looniverse: ) --Derzno (talk) 04:40, 21 February 2022 (UTC)

@M2k~dewiki and Derzno: Now in {{Wikidata Infobox/sandbox}}, please test and make sure it's working as expected. Thanks. Mike Peel (talk) 08:22, 21 February 2022 (UTC)

Hello @Mike Peel: i have checked {{Wikidata Infobox/sandbox}} with

Category:Falterstraße 24 (Dettelbach) (P4244 / P9339)
Category:Andreaskirche (Berlin-Wannsee) (P2424)
Category:Rathaus Bad Liebenwerda (P2081)
Category:Altes Rathaus (Hofheim am Taunus) (P1769)
Category:Kirche (Riebrau) (P7900)
Category:Am Weißeweg 15 (Seifhennersdorf) (P1708)
Category:Schloss Benkendorf (P9148)
Category:Marienkirche (Rendsburg) (P6102)

from

Category:Cultural_heritage_monuments_in_Germany_and_Wikidata

For me it looks fine, from my point of view the change could be added to the productive template as well. Thanks a lot! @Giorgio Michele and Muck50: zur Info, also see de:Vorlage_Diskussion:Tabellenzeile_Baudenkmal_Bayern#Bayerische-Denkmal-Atlas-ID_als_zusätzliche_optionale,_klickbare_Spalte? --M2k~dewiki (talk) 10:02, 21 February 2022 (UTC)

@Mike Peel: for it looks fine for me either. Thanks for your support and I'll keep you posted if the last one will be proofen in Wikidata to apply. --Derzno (talk) 12:43, 21 February 2022 (UTC)

Hello @Mike Peel: when will the recent changes for identifiers for monuments in Germany in the infobox-sandbox be applied to the productive template for the productive infobox as well? Is there anything left for me to do (like additonal tests, etc.)? Thanks a lot! --M2k~dewiki (talk)

@M2k~dewiki: It's now live. Thanks. Mike Peel (talk) 18:35, 27 February 2022 (UTC)

This section is resolved and can be archived. If you disagree, replace this template with your comment. Mike Peel (talk) 18:35, 27 February 2022 (UTC)

No need to display reason for deprecation or reason for promotion

See for example: Category:Ludwig_Gottlieb_Friedrich_von_Erlanger where we are displaying the reason the full-date was promoted over the year-only date. I started a discussion at Wikidata about demoting year-only dates, and the consensus was to promote the full-date instead. I wanted to have a bot do the work, but no one is interested, so maybe we can solve the situation here. Recently a bot has been combing through sources to add in birth dates and death dates from Identifiers, the problem is that most Identifiers use year-only dates, and the bots add them even when we already have a full-date. The result is duplication and both display. I assume this is because we occasionally have two conflicting full-birth-dates or full-death-dates for people. In those cases we want to display both until one is deprecated or promoted. There is really no need to display year-only dates when we have a full-date, it is confusing and looks bad esthetically. Can we:

Not display the reason for deprecation or promotion.
Not display the year-only when we already have a full-date. Sometimes the year only is off by a year, because it was back calculated from their age at death listed in an obituary. Or maybe someone here will be able to make a bot that will promote the full-date at Wikidata. We have over 100,000 examples of this.

Thanks for reading! --RAN (talk) 19:13, 2 January 2021 (UTC)

I second this request. I think in many cases qualifiers don't need to be displayed at all. They are primarily bookkeeping tasks for robots and data purists. They often look confusing and cluttered in infoboxes. Infoboxes need not display the messy trivial guts or metadata of items. --Animalparty (talk) 19:37, 10 January 2021 (UTC)

@Mike Peel: Could you please address this, so that reasons for deprecation or preferred rank are not displayed? See also Category:Albert Ellsworth Thomas for more ugly, useless data clutter. Wikidata gnomes will increasingly qualify statements with more refinements until the end of time. Infoboxes should be simple, elegant, and resistant to changes in display. Thanks in advance. --Animalparty (talk) 20:25, 14 April 2021 (UTC)

Now resolved. Thanks. Mike Peel (talk) 20:41, 24 March 2022 (UTC)

This section is resolved and can be archived. If you disagree, replace this template with your comment. Mike Peel (talk) 20:41, 24 March 2022 (UTC)

Please disable "reason for preferred rank" and similar qualifiers

Happy 2022. I'm reviving an unresolved issue from exactly 1 year ago. Would it be too much to ask to disable the appending of "reason for preferred rank" qualifiers? See birth date at Category:Gertrude Mary Woodward and the previous discussion for examples. This seems to be a data curation issue relevant only Wikidata that has nearly zero educational or utilitarian value on Commons, where the template lies. If this ubiquitous infobox is to be the be-all, do-all, omnipresent factor of Commons categories, it should be honed to provide only high quality useful information, not trivial metadata cruft. Why should Commons users care why a given value is in the box? Why should they care how many other values are not shown? As I've said before, infoboxes should be simple, elegant, and rather buffered against unwarranted changes in display. Cheers, --Animalparty (talk) 06:09, 2 January 2022 (UTC)

Support MSGJ (talk) 12:27, 12 January 2022 (UTC)

Support wholeheartedly. This qualifier is being used by a particular editor extensively for spaceflight related material, which is already data-dense. We don't need such metadata showing through. — Huntster (t @ c) 15:13, 12 January 2022 (UTC)

With the currently available Lua code (in WikidataIB), you can either show none, all, or selected qualifiers. You can't say 'all but this one'. Given that @RexxS: isn't around any more to help maintain that, I think this has to be a Not done. Thanks. Mike Peel (talk) 16:57, 15 January 2022 (UTC)

@Mike Peel: Can qualifiers be disabled entirely for certain fields, regardless of property? Such that , for instance, date of birth/death not display any qualifiers? Honestly I think that would be an improvement over the current situation. We might lose the "age at death" qualifier found in some entries, but I'd rather omit that then boldly display meaningless crap. --Animalparty (talk) 19:13, 15 January 2022 (UTC)

Support --Marsupium (talk) 08:02, 20 January 2022 (UTC)

Note: I'm not as familiar with how ugly and awful this looks in other items (geographical locales, astronomical entities), but the birth and death dates for a whole lot more human items are soon going to get a lot messier ("most precise value" galore) as BorkedBot is doing what bots do best, leaving humans to deal with the resulting mess. --Animalparty (talk) 06:04, 21 January 2022 (UTC)

Support I came here just to bring up the issue, good to see others disapprove, it only makes sense if other values are displayed, and we only need to display the most precise value. Someone mentioned "age at death", is that currently in the template? I would want that. --RAN (talk) 19:42, 8 March 2022 (UTC)

Code prepared in sandbox to omit reason for preferred rank (P7452) and reason for deprecated rank (P2241). It will also require an edit to Module:WikidataIB. If this looks good I will put in edit requests MSGJ (talk) 20:40, 14 March 2022 (UTC)

MSGJ, testing the sandbox version, it seems to remove most/all sub-properties from displaying, rather than just the targeted ones. For example, apply the sandbox to New York City, Ceres (dwarf planet), or Al-Tabari. — Huntster (t @ c) 21:24, 14 March 2022 (UTC)

It's because the Module:WikidataIB/sandbox has been updated but Module:WikidataIB has not been yet. I had prepared the code in Template:Wikidata Infobox/core/sandbox ready for when it has been. MSGJ (talk) 22:15, 14 March 2022 (UTC)

In that case, I'll trust your judgement that all is ready to go since I'm too dumb to figure module testing out. Thanks for your work! — Huntster (t @ c) 22:30, 14 March 2022 (UTC)

There are more tests at Module talk:WikidataIB/sandbox with examples from the items you referenced above MSGJ (talk) 13:16, 15 March 2022 (UTC)

@MSGJ: Thanks for working on this. Let me check this (probably at the weekend) and if it all looks OK then I'll make the edits live? Thanks. Mike Peel (talk) 21:23, 15 March 2022 (UTC)

@Mike Peel: I have implemented changes to Module:WikidataIB so it is now possible to test the template sandbox. Let me know if you have any queries — Martin (MSGJ · talk) 13:01, 18 March 2022 (UTC)

@MSGJ: Thanks, checked, and all looks good. I was wondering whether it might have been computationally less expensive to leave qual=ALL unless needed, but looking at how you've coded it I don't think it makes any difference in terms of CPU cycles. I'll include it in the next update of the infobox. Thanks. Mike Peel (talk) 20:08, 18 March 2022 (UTC)

This is now live. Thanks. Mike Peel (talk) 20:41, 24 March 2022 (UTC)

This section is resolved and can be archived. If you disagree, replace this template with your comment. Mike Peel (talk) 20:41, 24 March 2022 (UTC)

Add Berlin Street ID P10451

Please add https://www.wikidata.org/wiki/Property:P10451 - so it is clear to the user it is an official street and also which one it is, since names of streets are not unique in Berlin. BerlinBerlinBerlinBerlin (talk) 13:00, 7 March 2022 (UTC)

@BerlinBerlinBerlinBerlin: Now in {{Wikidata Infobox/sandbox}}, please test. Thanks. Mike Peel (talk) 20:10, 18 March 2022 (UTC)

@Mike Peel: tested on several pages and looks good. Thank you! Please ping again when in main code. Thank you! BerlinBerlinBerlinBerlin (talk) 18:15, 21 March 2022 (UTC)

@Mike Peel and Jarekt: can one of you copy this addition to Template:Wikidata Infobox/core ? There are now 10000+ IDs in Wikidata and linking streets in WD with streets in Commons and controlling data could be a bit easier if the IDs are shown in Commons. BerlinBerlinBerlinBerlin (talk) 20:20, 24 March 2022 (UTC)

@BerlinBerlinBerlinBerlin: OK, this is now live. Thanks. Mike Peel (talk) 20:39, 24 March 2022 (UTC)

This section is resolved and can be archived. If you disagree, replace this template with your comment. Mike Peel (talk) 20:39, 24 March 2022 (UTC)

Uses of Wikidata Infobox for taxons

Not sure what is happening, but it looks like this category is being emptied: Category:Uses of Wikidata Infobox for taxons. Already from 275k to 78.078 Rudolphous (talk) 07:28, 13 March 2022 (UTC)

Already found it some cats are not used anymore and cache is catching up. Rudolphous (talk) 09:10, 13 March 2022 (UTC)

@Rudolphous: Yes, per Commons:Categories for discussion/2022/01/Category:Uses of Wikidata Infobox for taxons. Thanks. Mike Peel (talk) 10:51, 13 March 2022 (UTC)

The category has now been deleted. Thanks. Mike Peel (talk) 20:34, 24 March 2022 (UTC)

This section is resolved and can be archived. If you disagree, replace this template with your comment. Mike Peel (talk) 20:34, 24 March 2022 (UTC)

Identifiers_for_monuments_in_Germany/2

Hello @Mike Peel: please add according to this request now d:Property:P10486 for monument ensembles in Bavaria (for example Category:Ensemble_Altstadt_Betzenstein_mit_Burg -> BLfD-ID: E-4-72-118-1). thx --Derzno (talk) 07:54, 14 March 2022 (UTC)

@Derzno: Now in {{Wikidata Infobox/sandbox}}, please check. Thanks. Mike Peel (talk) 20:13, 18 March 2022 (UTC)

@Mike Peel: it looks good! Let's go and thx for your support. --Derzno (talk) 04:48, 19 March 2022 (UTC)

@Derzno: OK, this is now live. Thanks. Mike Peel (talk) 20:39, 24 March 2022 (UTC)

This section is resolved and can be archived. If you disagree, replace this template with your comment. Mike Peel (talk) 20:39, 24 March 2022 (UTC)

Link to FranceArchives agent ID (P9371) and ImagesDéfense ID (P10539)

{{Edit request}} Hello, would it be possible to add a link to these two external authorities?--Le Petit Chat (talk) 10:45, 3 April 2022 (UTC)

@Le Petit Chat: These are now in {{Wikidata Infobox/sandbox}}, please could you test that and make sure it works as expected? Thanks. Mike Peel (talk) 17:52, 29 April 2022 (UTC)

@Mike Peel Thanks. It seems to work perfectly: User:Le Petit Chat/test. -- Le Petit Chat (talk) 18:31, 29 April 2022 (UTC)

@Le Petit Chat: Now live. Thanks. Mike Peel (talk) 18:37, 27 May 2022 (UTC)

This section is resolved and can be archived. If you disagree, replace this template with your comment. Mike Peel (talk) 18:37, 27 May 2022 (UTC)

Obsolete logo still showing up

See Category:AUVASA and wikidata:Q5712430 --Robot8A (talk) 21:04, 11 May 2022 (UTC)

@Robot8A: I see the new logo? Try purging the cache to see if that helps, or make a null edit? Thanks. Mike Peel (talk) 05:22, 12 May 2022 (UTC)

Thanks, seems to be that. My mistake then. Best --Robot8A (talk) 10:05, 12 May 2022 (UTC)

This section is resolved and can be archived. If you disagree, replace this template with your comment. Mike Peel (talk) 18:36, 27 May 2022 (UTC)

Incorrect display in the infobox

Wenn die Infobox auf Category:Dutch-language surnames eingeblendet wird, zeigt sie statt den Inhalt von Category:Dutch-language surnames (Q7886503), den Inhalt von Dutch family name (Q22813575) an. Wird der Parameter category's main topic (P301) aus Category:Dutch-language surnames (Q7886503) entfernt, zeigt sie den korrekten Inhalt von Category:Dutch-language surnames (Q7886503) in der Infobox an. Am Beispiel von Category:English-language surnames kann man sehen, wie es ohne den Parameter category's main topic (P301) auf Category:English-language surnames (Q7598401) korrekt in der Infobox angezeigt wird.

(When the infobox on Category:Dutch-language surnames is displayed, it shows the content of Dutch family name (Q22813575) instead of the content of Category:Dutch-language surnames (Q7886503). If the parameter category's main topic (P301) is removed from Category:Dutch-language surnames (Q7886503), it shows the correct content of Category:Dutch-language surnames (Q7886503) in the infobox. Using the example of Category:English-language surnames, you can see how it is correctly displayed in the infobox without the parameter category's main topic (P301) to Category:English-language surnames (Q7598401).)

--HarryNº2 (talk) 14:22, 8 September 2020 (UTC)

@HarryNº2: Yes, this is the normal operation of the template, it looks OK to me? If the category's main topic (P301) value is incorrect, would category combines topics (P971) be better? Thanks. Mike Peel (talk) 19:09, 29 September 2020 (UTC)

@Mike Peel: Hi Mike, please have a look at the content of the German Infobox and the content of the Dutch Infobox. Both show different content. The Dutch infobox shows the wrong result (family name in the Netherlands). Only when I delete the parameter category's main topic (P301) on Wikidata (as in the example of the German Infobox) will the correct content be displayed (Category:German-language surnames). You are also welcome to have a look at the other info boxes (e.g. Danish, English, French etc.) for comparison, which always show Category:Xxxxx-language surnames, but only if parameter P301 is not set. I hope you understand what i mean. --HarryNº2 (talk) 18:29, 5 December 2020 (UTC)

This section is resolved and can be archived. If you disagree, replace this template with your comment. This is intened behavior (LennardHofmann (talk) 18:54, 21 July 2022 (UTC))

Doctoral student

Can "Doctoral student" be made collapsable and collapse automatically if there are more than 3 students?

Someone on Wikidata is working on importing a lot of mathematics doctoral advisor/student information and it's making some infoboxes very unwieldy because most doctoral students don't have categories. See Category:H. Blaine Lawson as an example. --William Graham (talk) 04:57, 2 January 2021 (UTC)

I second this request. Infoboxes of any kind are not intended to display all possible information but to succinctly display select relevant info. --Animalparty (talk) 19:24, 10 January 2021 (UTC)

This section is resolved and can be archived. If you disagree, replace this template with your comment. Collapsed if more than 4 students. (LennardHofmann (talk) 18:54, 21 July 2022 (UTC))

Collapsible-collapse vs Hide

Hi,

There is an issue with how this template works: When it's loaded, it initially shows the message "Collapsible-collapse" (Collapse) at the top next to the title, and as the page is loaded, it is replaced with the message "Hide" Hide.

It may look correct in English, but actually it is wrong. "Hide" is intended for use in compound messages on Recent Changes, such as "Hide transclusions". In other languages, such as Hebrew, it is shown incorrectly.

Can this be fixed?

If you really want the word "Hide" and not "Collapse" to be shown, the easiest current solution that will work well across (hopefully) all languages is probably to use "Hidetoc" (hide). Some time in 2021, when Translatable modules (hopefully) become available, it will be easy to create a message just for this. (It may seem unintuitive, but reusing messages in different contexts is usually not great, and it's better to create new ones even if they are identical to existing messages.) --Amir E. Aharoni (talk) 13:10, 6 January 2021 (UTC)

This section is resolved and can be archived. If you disagree, replace this template with your comment. We use the default messages now. (LennardHofmann (talk) 18:54, 21 July 2022 (UTC))

Disambigs in 'different from'

Infobox should ignore statements 'different from (P1889)' = '... (Q...)' if qualifier is set to 'criterion used (P1013)' = 'descriptive page and disambiguation page have to be in different items (Q24005632)'. Such statements in Wikidata Infobox are really useless and use too much space. Wostr (talk) 20:25, 22 January 2021 (UTC)

Agreed. With few exceptions (such as qualifying dates with "circa", or start & end dates of significant events), qualifiers should not be displayed. It's utterly trivial, unhelpful detritus that clutters what should be a succinct box with useful links and/or data. --Animalparty (talk) 20:39, 22 January 2021 (UTC)

As far as I understand, the question is not whether we want to display the qualifiers, but rather whether we want to display such statements at all. I agree we shouldn’t. —Tacsipacsi (talk) 21:18, 22 January 2021 (UTC)

This section is resolved and can be archived. If you disagree, replace this template with your comment. Only linked values are now shown for different from (P1889). (LennardHofmann (talk) 18:54, 21 July 2022 (UTC))

Error displaying images with filenames beginning with an asterisk

If a filename begins with * (an asterisk), the template thinks it is wikitext for an unordered list. See Category:April Greiman for example. Senator2029 23:23, 4 February 2021 (UTC)

MediaWiki’s too smart here:

[[File:{{#invoke:WikidataIB|getValue|rank=best|P18|name=P18|qid=Q4782033|spf=|fwd={{#invoke:Wikidata Infobox|preloadWikidataProperties|Q4782033}}|osd=no|noicon=yes|maxvals=1}}|200px]]

results in a code so broken that I couldn’t even insert it here. :( (But you can put it on any page and preview it to see the result.) If a template/module output starts with a code that has special meaning at the beginning of a line (e.g. asterisk), it automatically inserts a newline before it, and as far as I know, there’s no way to circumvent this—apart from not putting special codes at the very beginning of the output, for example by putting the [[File: in the Lua module as well (or by generating the whole infobox with Lua, see #Lua memory error). —Tacsipacsi (talk) 23:57, 5 February 2021 (UTC)

Perhaps make a module just for this expression? --ghouston (talk) 02:31, 6 February 2021 (UTC)

This section is resolved and can be archived. If you disagree, replace this template with your comment. Fixed. (LennardHofmann (talk) 18:54, 21 July 2022 (UTC))

Bad handling of only deprecated official website

I've found a bug where [ official website] appears in the output if the only value for official website (P856) is deprecated. An example can be currently seen on Template:Wikidata Infobox/sandbox (archive), which I've linked to Wikidata Sandbox (Q4115189) (archive) for now. Perhaps this also affects other properties, but this one in particular generates odd wikitext. --Pokechu22 (talk) 19:17, 26 March 2021 (UTC)

Anything with an end date qualifier should probably not be displayed. --- Jura1 (talk) 08:55, 7 April 2021 (UTC)

It looks like the current behavior ignores end date (if it's deprecated, the broken output occurs regardless of whether end date is present or not, and if it's at normal rank, it's displayed with correct formatting even if end date is present). --Pokechu22 (talk) 19:10, 7 April 2021 (UTC)

In Wikidata, it's frequently an error if deprecation is used (instead of the addition of an end date). --- Jura1 (talk) 11:53, 14 April 2021 (UTC)

Malformed official website link

Category:Juweihui has a special error. its official website is fetched from residents' committee (Q12808731). it's a deprecated value, and i think this causes the malformed link. (the Q12808731 value is wrong. i will remove it soon, but now i leave it there for you to see the error it causes.) RZuo (talk) 13:23, 21 April 2022 (UTC)

This section is resolved and can be archived. If you disagree, replace this template with your comment. Fixed. (LennardHofmann (talk) 18:54, 21 July 2022 (UTC))

qualifier with datatype "wikibase-form"

Minerva97 noticed that qualifiers with that datatype aren't supported.

e.g. Category:Sérgio Sette Câmara showing "(unknown data type: wikibase-form)"

trying to display generational suffix (P8017) from Q18195633#P1477.

--- Jura1 (talk) 09:00, 7 April 2021 (UTC)

It's a lexeme, that's something new for a property value. --ghouston (talk) 05:02, 8 April 2021 (UTC)

This section is resolved and can be archived. If you disagree, replace this template with your comment. Fixed in WikidataIB by ignoring values of datatype wikibase-form. (LennardHofmann (talk) 18:54, 21 July 2022 (UTC))

Zoom level, area

I think I read somewhere the zoom level used in the map was related to the area of the item (when this data has been included in the Wikidata item, of course). Nevertheless, the infobox does not behave differently whether units are km² (pretty good with these ones) or ha (not that good, it would be nice zooming in these maps). I mean, I understand taking into account every area unit could be too complex, but would it be possible selecting different zoom level at least when units are "hectares"? (a pretty common unit). Strakhov (talk) 17:59, 13 October 2021 (UTC)

Actually I don’t think supporting any area unit would be too complex, as long as these units have conversion to SI unit (P2370) statements, the conversion to square kilometers can be deduced from it. —Tacsipacsi (talk) 21:29, 13 October 2021 (UTC)

Yep, you are right. As long as these conversion factors (I didn't notice they existed) are included in Wikidata, I guess supporting every unit area should not be too complex. Strakhov (talk) 12:04, 23 October 2021 (UTC)

This section is resolved and can be archived. If you disagree, replace this template with your comment. Fixed by automatically adjusting map zoom level so that the geoshape (gray region) fits inside the map if the Wikidata item has OpenStreetMap relation ID (P402). Otherwise zoom level is calculated from area, respecting km², m², hectares, square miles, and acres. (LennardHofmann (talk) 18:54, 21 July 2022 (UTC))

'none' values in Wikidata break this template

Some properties in Wikidata cause this template to break if their value is set to 'none'. I've seen this happen with logo image (P154) and official website (P856), but it may also affect other properties. You can see the 'logo image' breaking at Category:RIT News and Events (the text "[[File: | 110px]]" appears where the logo would normally be). I don't have an example link on hand for 'official website', but as I recall, the text "[ official website]" appears. –IagoQnsi (talk) 20:48, 15 February 2022 (UTC)

@IagoQnsi: So don't use 'none' values, they don't make sense. Thanks. Mike Peel (talk) 23:32, 15 February 2022 (UTC)

It makes sense to me that an entity might not have a logo or a website. Both of these properties have a constraint that requires that a single best value be set. If an entity had multiple logos/websites in the past but none of them are current, it's necessary to add a 'none' value with a preferred rank so that old values are not incorrectly displayed as a current/best value.

I just checked: for logo image (P154), there are 12 'none' values and 56 unknown values. For official website (P856), there are 340 'none' values and 140 unknown values.

It seems to me that the template should hide the logo/website if they are set to none, rather than expecting that these properties will never be set to none. IagoQnsi (talk) 23:40, 15 February 2022 (UTC)

This section is resolved and can be archived. If you disagree, replace this template with your comment. Fixed itself, see Kingdom of God. (LennardHofmann (talk) 18:54, 21 July 2022 (UTC))

Quickload option

Someone (perhaps @Jarekt: ?) suggested at today's Data Reuse Days presentation that we have a parameter that reduces what the infobox loads, so it can handle more tricky cases. I've implemented this as a "quickload=yes" parameter in the sandbox, which seems to work. For example, see Category:COVID-19 pandemic in Colombia, which finally works again. Please test - I'll deploy this in the next release if it works OK. Thanks. Mike Peel (talk) 20:31, 18 March 2022 (UTC)

Doesn't work for me. No links, no files were displayed - all links are red with text "Lua error: not enough memory" GeorgHH • talk 21:55, 18 March 2022 (UTC)

Thanks Mike. Yes it was my suggestion. Once it is stable we could add it to pages in Category:Pages with script errors (I can do that). I will test it on some pages. --Jarekt (talk) 00:54, 19 March 2022 (UTC)

Itested it on a single page Category:1871 in Austria-Hungary and it seems to work. --Jarekt (talk) 15:43, 19 March 2022 (UTC)

Seems to work for English only (at least at Category:COVID-19 pandemic in Colombia), after switching to another language lua errors are back.Jklamo (talk) 23:56, 19 March 2022 (UTC)

Mike, Let me know when Quickload option is live, as I would like to add it to categories in Category:Pages with script errors. --Jarekt (talk) 02:52, 14 April 2022 (UTC)

This section is resolved and can be archived. If you disagree, replace this template with your comment. The new infobox written in Lua doesn't have a |quickload= parameter as most pages take less than four seconds to load (see Category:Uses of Wikidata Infobox with bad performance for those that don't). Rewriting autocat in Lua might fix the memory issues but we have to see. (LennardHofmann (talk) 18:54, 21 July 2022 (UTC))

Might still be dependent on P373

Category:Pipa was recently moved to Category:Pipa (frog), but wdib still pointed the genus to the old page, so i deleted the p373 values from Pipa (Q2351631) and Category:Pipa (frog) (Q8763208). now wdib shows no link for the genus. RZuo (talk) 09:43, 1 April 2022 (UTC)

I suspect that might be a caching thing? — Martin (MSGJ · talk) 20:36, 2 April 2022 (UTC)

This section is resolved and can be archived. If you disagree, replace this template with your comment. Category:Pipa (frog) looks fine to me, probably a caching thing (LennardHofmann (talk) 18:54, 21 July 2022 (UTC))

Expression error

On all pages of celestial objects (stars, galaxies), such as c:Category:NGC 7061 appears in the infobox a message 'Expression error: Unrecognized punctuation character' when setting the language to one different from English (e.g. Dutch, French) which use decimal comma's instead of dots. Apparently this happens for the Right Ascension. Hobbema (talk) 11:18, 8 April 2022 (UTC)

The issue seems to be in {{#expr:{{#invoke:WikidataIB | getValue | rank=best | fetchwikidata=ALL | onlysourced=no | noicon=yes | P6257 | qid=Q1149326 | showunits=no}}/15}}: 21.457454446667

In English it results in the value 21.457454446667, but in Dutch it results in 'Expression error: Unrecognized punctuation character'. It could be releted ot the latest change in Module:WikidataIB HenkvD (talk) 17:59, 9 April 2022 (UTC)

This can be fixed by adding |lang=en to the WikidataIB invocation, see this sandbox edit. Note that the numbers and units for the link title are still localized, only the numbers used to generate the URL need to be in English format. LennardHofmann (talk) 11:34, 10 April 2022 (UTC)

Thanks. So I suppose one should make an edit request {{Edit request}} in order that someone is making this change? Hobbema (talk) 20:09, 12 April 2022 (UTC)

This looks good, I'll include it in the next release. Thanks. Mike Peel (talk) 17:50, 29 April 2022 (UTC)

This section is resolved and can be archived. If you disagree, replace this template with your comment. LennardHofmann (talk) 18:54, 21 July 2022 (UTC)

Update needed for showing currently valid P131 values

On Category:Kapileswarapuram,_Konaseema, the Infobox is showing P131 values for districts which are outdated, as the administrative boundaries of districts were changed extensively for Andhra Pradesh in April 2022. Wikidata is updated for the affected entities, with end date qualifier for old P131 values and start date qualifier for new P131 values. (Example: wikidata:Q59939794). The template code needs to be changed to pick only the currently valid value, by checking for P131 entries without end date set. Arjunaraoc (talk) 04:44, 21 May 2022 (UTC)

@Arjunaraoc: You should do this on Wikidata by setting the latest value to 'preferred', e.g., [4]. Thanks. Mike Peel (talk) 08:33, 21 May 2022 (UTC)

@Mike Peel, Nice to connect with you again. Setting a value as preferred for hundreds of entities is not easy in Wikidata, as there is no tool. To my knowledge, only some bots set that flag. I learnt that using current flag with wikidata template on wikipedia can easily produce the currently valid value. (code:{{wikidata|properties|normal+|current|eid=Q59939794|P131}}) I did not find that feature on Commons template. It may be better to add such a feature for the template. Arjunaraoc (talk) 01:37, 22 May 2022 (UTC)

@Arjunaraoc: I am currently rewriting the infobox in Lua as part of Google Summer of Code. Excluding values based on the presence of the end time (P582) qualifier is trivial with Lua and other properties (such as official website (P856) or logo image (P154)) could benefit from it as well. So expect this to be fixed by July 3. Setting the latest values to 'preferred' is still a good idea but unfortunately QuickStatements does not support setting ranks. LennardHofmann (talk) 06:32, 22 May 2022 (UTC)

This section is resolved and can be archived. If you disagree, replace this template with your comment. Fixed. (LennardHofmann (talk) 18:54, 21 July 2022 (UTC))

P1382

Please consider to display partially coincident with (P1382) in the infobox.

partially coincident with (P1382) is an alternative to said to be the same as (P460) and different from (P1889).
partially coincident with (P1382) is an alternative to located in the administrative territorial entity (P131), located in protected area (P3018), part of (P361), has part(s) (P527) etc.

--ŠJů (talk) 00:08, 28 May 2022 (UTC)

This section is resolved and can be archived. If you disagree, replace this template with your comment. Added. (LennardHofmann (talk) 18:54, 21 July 2022 (UTC))

P834

Hello. Can we make sure train depot (P834) is displayed? It would be super useful for categories such as Category:Paris Métro Line 5, that would now link to Category:Bobigny metro and tramway workshop. Thierry Caro (talk) 17:22, 22 June 2022 (UTC)

This section is resolved and can be archived. If you disagree, replace this template with your comment. Added. (LennardHofmann (talk) 18:54, 21 July 2022 (UTC))

Qualifier link broken

Infobox of Category:Shielhill Bridge, under 'carries'. Corresponding item Q113262146#P2505 has a replaces (P1365) qualifier pointing to Shielhill Bridge, Old Bridge (Q17777613) which maps to c:Category:Sheilhill Old Bridge. But the infobox is redlinking to "Shielhill Bridge, Old Bridge". Thx, Jheald (talk) 22:11, 24 July 2022 (UTC)

Seems to have sorted itself out. Jheald (talk) 22:13, 24 July 2022 (UTC)

@Jheald: I think this was caching, after you moved the Commons category. BTW, it's good to leave a category redirect in place so that anywhere that's linking to the category can still find it after the move. Thanks. Mike Peel (talk) 06:32, 25 July 2022 (UTC)

This section is resolved and can be archived. If you disagree, replace this template with your comment. Mike Peel (talk) 06:32, 25 July 2022 (UTC)

misplaced captions

(workaround: make sure all images have captions in at least one language)

Wrong caption in Wikidata infobox

When there are more pictures of the same item in Wikidata, and not all of them have a media legend, the infobox sometimes chooses a different caption for a different image. The issue has recently been discussed at the Village Pump, when the infobox displayed a picture of Melanogaster tuberiformis but accompanied it with a caption of Melanogaster variegatus. That particular problem has been solved by adding the media legend to the picture of M. tuberifosmis in Wikidata, but there can be many more problems like this in Commons. I think the infobox should be fixed so that it was not allowed to choose a caption that is not relevant to the chosen image. --Jan Kameníček (talk) 08:36, 7 December 2020 (UTC)

Template pulling the wrong image description from Wikidata

In Category:Schmallenberg, the infobox shows File:Schmallenberg from above.jpg, which is the first image specified at Schmallenberg (Q5628). But below it, it shows the caption Casa de la vila (town hall), which does not fit the image. Took me a while to figure out that the template is pulling the caption from the Catalan media legend field associated with the second image linked at wikidata (File:Schmallenberg, stadhuis foto2 2010-08-12 11.51.JPG, which indeeed shows the town hall). Providing a media legend for the aerial photograph would probably fix that, but I'm going to leave it alone for the moment do demonstrate the problem. El Grafo (talk) 09:58, 25 February 2022 (UTC)

@El Grafo: It's a known issue, there's no easy fix on the template side right now, the best thing is to add the media legend for the first photo - or better, only have one image (P18) value and move the other one to aerial view (P8592). Thanks. Mike Peel (talk) 10:23, 25 February 2022 (UTC)

Yes, I was looking into cleaning that up, just didn't want to destroy the evidence. But if that's a known issue I guess I'll just go ahead. Anyway, thanks for having a look! -- El Grafo (talk) 10:34, 25 February 2022 (UTC)

Would it be possible to skip over any images that lack a caption in cases where there is at least one that has one? (ran into this with baby cry (Q109649419)) Arlo James Barnes 20:43, 19 June 2022 (UTC)

This has been fixed. LennardHofmann (talk) 12:57, 28 July 2022 (UTC)

copyright license (P275)

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)

@Mike Peel: copyright license (P275) is ideal information in the template for Pixabay ({{Pixabay}}), now with non-free license (see the Wikidata Infobox use in Category:Pixabay without the license data).BoldLuis (talk) 00:48, 1 June 2020 (UTC)

This section is resolved and can be archived. If you disagree, replace this template with your comment. P275 has been added. (LennardHofmann (talk) 16:49, 28 July 2022 (UTC))

Identifiers for monuments in France

Hi,

I have three requests (by decreasing order of importance) about identifiers for monuments in France:

would it be possible to add the d:P:P481 identifier, it would be useful for instance on Category:Retable du maître-autel de l'église Saint-Jacques-le-Majeur de Brousse-le-Château
would it be possible to add all the values for d:P:P481 and d:P:P380? it's quite common for these properties to have several values (all equally right and useful, see Category:Viaduc des Rochers Noirs for instance)
would it possible to have the icon before these identifiers?

Thanks in advance.

Cheers, VIGNERON (talk) 10:33, 17 September 2020 (UTC)

@VIGNERON: The first one is straightforward, it's in {{Wikidata Infobox/sandbox}} for testing. The second is more tricky, as the current {{Wikidata ID}} code only supports one value per ID and it would need a complete rewrite to support multiple values. The third is also tricky, as the code fetches all information about the property from Wikidata, is there a property that could be added to the property pages to link to icons? Thanks. Mike Peel (talk) 18:57, 29 September 2020 (UTC)

Thanks @Mike Peel: ,

I've tested (in preview) the first, it works perfectly.

For the second, that's a bummer. Would this rewrite be possible in a not-too-far future? (let's say less than a year, for WLM 2021?)

I've been bold and tested to add d:P:P2910 on d:P:P481 and d:P:P380 (it was already done on d:P:P496 and d:P:P1793). I'll leave a message on the Project Chat to see if there is any objections or comments.

Cheers, VIGNERON (talk) 19:28, 29 September 2020 (UTC)

@Mike Peel: FYI, one week later, 2 people said my idea of adding icons was good (see d:Wikidata:Project_chat#Icons_for_properties). And for the first point, I did some more check, I've seen no problem; could this be applied to the real-not-sandbox template? Cheers, VIGNERON (talk) 11:29, 6 October 2020 (UTC)

{{Wikidata Infobox/sandbox}} now supports icons as well as multiple values for an external identifier. LennardHofmann (talk) 15:29, 28 July 2022 (UTC)

This section is resolved and can be archived. If you disagree, replace this template with your comment. LennardHofmann (talk) 15:15, 3 August 2022 (UTC)

Taxa categories and "Search depicted"

Hi, there is a link "Search depicted" in the infobox. When you are in a taxon category and that you click on this link, then only are shown the pictures which show strictly the depicted items, e.g.:
Category:Trochilidae → haswbstatement:P180=Q43624
However a more accurate result woult comprises all the child taxa, e.g.:

#shows files that depict Hummingbirds 
#defaultView:ImageGrid
SELECT ?file ?image
WITH
{
  SELECT ?item 
  WHERE
  {
    SERVICE <https://query.wikidata.org/sparql>
    {
        ?item wdt:P171/wdt:P171* wd:Q43624.
     } 
  }
} AS %get_items
WHERE
{
  INCLUDE %get_items
  ?file wdt:P180 ?item .
  ?file schema:contentUrl ?url .
  BIND(IRI(CONCAT("http://commons.wikimedia.org/wiki/Special:FilePath/", wikibase:decodeUri(SUBSTR(STR(?url),53)))) AS ?image)
}

Try it!

I think it is the likely the same thing for many other subjects than taxa, however the relationship parents/child taxa is always the same and known (parent taxon (P171)). Is there a chance that when we visit a taxon category we can have a link that lead such results? Christian Ferrer ^(talk) 12:44, 9 January 2021 (UTC)

This section is resolved and can be archived. If you disagree, replace this template with your comment. Has been added (LennardHofmann (talk) 15:15, 3 August 2022 (UTC))

Template translation

Hi,

@Père Igor: is asking (on Wikidata) where to translate the "show all" option of this template (underneath the images). @Mike Peel: could you help?

Cheers, VIGNERON (talk) 14:55, 26 April 2022 (UTC)

@VIGNERON: I'm not sure it's possible. It's currently hard-coded in English in MediaWiki:Gadget-Infobox.js... Thanks. Mike Peel (talk) 15:27, 26 April 2022 (UTC)

Then probably it should be. Since the infobox already has non-Wikidata-based localization at Template:Wikidata Infobox/i18n, it’s just the matter of adding a new localization string and passing it somehow to the gadget (e.g. using a hidden <div> or a data-* attribute). —Tacsipacsi (talk) 08:36, 2 May 2022 (UTC)

@Tacsipacsi: I'd be happy to see it internationalised, I just can't figure out the "passing it somehow to the gadget" bit! Happy to help implement this if you can figure it out, though. Thanks. Mike Peel (talk) 18:08, 2 May 2022 (UTC)

This section is resolved and can be archived. If you disagree, replace this template with your comment. It now displays as "Show all" in your language. (LennardHofmann (talk) 15:15, 3 August 2022 (UTC))

Czech RÚIAN and ÚSOP identifiers

Hi. Could be added RÚIAN identifiers for Czech administrative, territorial, statistical and cadastral division?

And identifiers of Czech protected trees and areas from the Central Register of Nature Protection:

This section is resolved and can be archived. If you disagree, replace this template with your comment. Have all been added. (LennardHofmann (talk) 15:15, 3 August 2022 (UTC))

Category links

@Mike Peel: it appears after your latest update that it is now incorrectly transcluding categories.

now adds Category:Letters of marque to Category:Pirates.

You can see here how this was explicitly meant as an exclusion but due to a missing : character, it is transcluded. Magog the Ogre (talk) (contribs) 16:01, 23 July 2022 (UTC)

@Magog the Ogre: I've moved this here to keep discussions in one place, hope that's OK. I think this is an easy thing for @LennardHofmann: to fix. Thanks. Mike Peel (talk) 16:05, 23 July 2022 (UTC)

This is related to the discussion #Bug? Why is different from (P1889) no longer displayed? above and fixed in {{Wikidata Infobox/sandbox}}. --LennardHofmann (talk) 09:41, 24 July 2022 (UTC)

This section is resolved and can be archived. If you disagree, replace this template with your comment. LennardHofmann (talk) 15:15, 3 August 2022 (UTC)

Migrate more of the wikitext of this template to lua?

This template is quite slow and is taking 90% of parse time of any category in commons (and taking north of five seconds). The biggest reason is that it's using parser functions and mediawiki's templating which was the whole reason lua was introduced to handle. See File:Linux.conf.au_2014_-_Scribunto_presentation.webm Amir (talk) 19:58, 28 July 2022 (UTC)

@Ladsgroup: Amir! See #Lua rewrite! ;-) Thanks. Mike Peel (talk) 06:40, 29 July 2022 (UTC)

Awesome Amir (talk) 10:40, 29 July 2022 (UTC)

This section is resolved and can be archived. If you disagree, replace this template with your comment. LennardHofmann (talk) 15:15, 3 August 2022 (UTC)

Removal of birth and death categories

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 --Ju Ta 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. --Ju Ta 21:50, 17 July 2019 (UTC)

@Mike Peel: Any updates, any plans? --Ju Ta 06:14, 15 August 2019 (UTC)

@JuTa and 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 --Ju Ta 14:42, 15 August 2019 (UTC)

Ping Mike... --Ju Ta 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. --Ju Ta 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. --Ju Ta 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. --Ju Ta 16:53, 21 August 2019 (UTC)

@JuTa: OK, try again now. These are the characters that are now being replaced before setting the sort key: ÁÀÂÄǍĂĀÃÅĄƏĆĊĈČÇĎĐḌÐÉÈĖÊËĚĔĒẼĘẸĠĜĞĢĤĦḤİÍÌÎÏǏĬĪĨĮỊĴĶĹĿĽĻŁḶḸṂŃŇÑŅṆŊÓÒÔÖǑŎŌÕǪỌŐØŔŘŖṚṜŚŜŠŞȘṢŤŢȚṬÚÙÛÜǓŬŪŨŮŲỤŰǗǛǙǕŴÝŶŸỸȲŹŻŽ
áàâäǎăāãåąəćċĉčçďđḍðéèėêëěĕēẽęẹġĝğģĥħḥıíìîïǐĭīĩįịĵķĺŀľļłḷḹṃńňñņṇŋóòôöǒŏōõǫọőøŕřŗṛṝśŝšşșṣťţțṭúùûüǔŭūũůųụűǘǜǚǖŵýŷÿỹȳźżž. 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. --Ju Ta 21:42, 21 August 2019 (UTC)

@Mike, next weekend coming soon. Any plans? --Ju Ta 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. --Ju Ta 18:18, 30 August 2019 (UTC)

According to i.e. Category:Mạc Thái Tông the character ạ seems not to be sorted correctly. @Mike Peel: Can you have a look please. --Ju Ta 00:15, 15 October 2020 (UTC)

This section is resolved and can be archived. If you disagree, replace this template with your comment. The ArndBot has removed the redundant categories, and diacritics are stripped from DEFAULTSORT. (LennardHofmann (talk) 20:20, 24 August 2022 (UTC))

Recursion

@Verdy p: Re [5] - 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).

Conclusions:

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)

This section is resolved and can be archived. If you disagree, replace this template with your comment. The performance problems of subinfoboxes have been solved with the Lua rewrite. (LennardHofmann (talk) 20:20, 24 August 2022 (UTC))

Width of the infobox

I've just noticed that @Verdy p: changed the infobox style yesterday to make the infobox wider (250px rather than 210px) and to remove "table-layout: fixed;". Has this caused any problems? I was trying to keep the width of the infobox as narrow as possible, but if this new width is OK then I'll make the images and map a bit larger in the next version. Thanks. Mike Peel (talk) 21:31, 24 June 2020 (UTC)

@Mike Peel: Yes it caused problems: the fixed layout notably is wrong: it cannot be infered correctly from the first row (which is taking 100% of the width: it is frequently an image spanning the two columns; so the fixed table layout is then 50%/50% independantly of everything that is below), so all the headings below take 50% of the total width, leaving a very narrow column for the values (and with 210px, values could be only 105px wide: too many linewraps or truncated values, or sometimes even a larger infobox).

And 210px is too narrow for German. In wikimedia, floatting images are 250px wide, we can use that default so they line-up correctly with infoboxes.

250px does not cause problems given it is the default for floatting images, and they align perfectly vertically. Given that "fixed" layout does not work and has bad effects, it's best to remove it, and allow columns to be flexible: in many cases the heading columns will be adaptative: not be 50% but lower, giving ampler space for the valuesin the second columns.

This is also needed for other languages than German, like Thai (that don't use any space between words, and have weak unexplicit linewraps opportunities in most browsers, as they depend on complex dictionnary lookups); this is not a problem for Chinese or Japanese where linewraps are allowed everywhere between each sinogram; in Korean, there are whitespace separations between words written in Hangul syllables and they use standard Latin punctuation. Basically this is needed for languages that use word-agglutination (German, Finnish) when Wikidata frequently does not include any soft-hyphen in the labels to allow break opportunities. And in a 105px column, this does not fit so well. Now it can be 125px or a bit larger, taking some space from the underused heading columns which is now flexible). The result is much more readable, and we no longer have very tall columns of values after each heading, and a very tall infobox: we need less linewraps to correctly render the values, adn the infobox still remains constrained in the 250px flexible width (most of the time): this was almost never the case with 210px only and with fixed layout.

You should know that the "fixed" table lyout requires that the table has ALL its columns sized in its 1st row (this is never the case for infoboxes, as the 1st row contains the object's label/description spanning all columns.

And on Mediawiki we still cannot use the standard "column" HTML element to size them with styles; as well there's still no support for standard columns-groups with "colgroup" or row groups with "thead", "tbody" and "tfoot"... I think this is a stupid limitation of Mediawiki which consider them as "unsafe" HTML elements, which is obviously wrong; May be we'll have in some future addition HTML elements from HTML5; but the HTML4-inherited "column", "colgroup", "thead", "tbody" and "tfoot" elements, preserved in HTML5 and still recommended, they should have been supported since very long, not causing any security problem if they were treated like "div" or "li" block elements for row groups, or like "span" for "column" and column groups).

Note that I have NOT changed the image sizes in the infobox, but thery are properly centered, and increasing their size could make the infoboxes unnecessarily taller. verdy_p (talk) 21:37, 24 June 2020 (UTC)

It looks very awkward with image and map size not matching infobox size. I don't particularly care what size, but it should match. Pi.1415926535 (talk) 00:09, 25 June 2020 (UTC)

I agree. It doesn't look nice now. Strakhov (talk) 14:20, 25 June 2020 (UTC)

I'm glad to see the width has been increased. It would be good to increase the image width, and cap the heights. Perhaps 250x300, or even 250x250? — Huntster (t @ c) 23:03, 26 June 2020 (UTC)

@Verdy p, Pi.1415926535, Strakhov, and Huntster: Can you try {{Wikidata Infobox/sandbox}} please? This incorporates the CSS changes and also widens the image and map widths. Thanks. Mike Peel (talk) 18:32, 1 July 2020 (UTC)

We can enlarge maps, but I don't think we need to enlarge images at top, which are properly centered and displayed in an area which has enough margins. Extending the image width at top could make the infobox taller... For OSM maps, there's no problem: we can set it a bit larger without increasing their height.

The sandbox version however still does not change these image/map widths. Let's first start with the map... verdy_p (talk) 18:37, 1 July 2020 (UTC)

Mike Peel, at first glance and checking miscellaneous location categories, I see nothing abnormal for the two properties in question. What did you specify for maximum height? However, property P2716 (collage image) should probably be added to the list of new sizes, since a lot of cities use that field rather than "image", and I can imagine a limited number of other such properties at https://www.wikidata.org/wiki/Special:WhatLinksHere/Q26940804 might also qualify for treatment. — Huntster (t @ c) 05:39, 2 July 2020 (UTC)

This section is resolved and can be archived. If you disagree, replace this template with your comment. LennardHofmann (talk) 20:20, 24 August 2022 (UTC)

P373

Was the use of P373 deprecated for this template? Apparently it no longer fetches the Commons category from this property, only from site link. I don't understand why we have to add a category to both P373 and site link, it seems redundant. —capmo (talk) 15:00, 25 December 2020 (UTC)

One reason is that the multiple wikidata items may point to same commonscat category using P373. (ie. technically sitelinks are One-to-one relations and P373 values are Many-to-many) --Zache (talk) 16:48, 25 December 2020 (UTC)

Also commons sitelink may also not point to category but to gallery page in example. --Zache (talk) 17:05, 25 December 2020 (UTC)

This needs a change in WikidataIB, @RexxS: could you look into it please? I think it just needs line 660 of Module:WikidataIB ("mw.wikibase.getBestStatements(id, "P373")[1]") changing to use getCommonsLink, and ideally any mention of P373 should just be removed now. Thanks. Mike Peel (talk) 19:40, 25 December 2020 (UTC)

Why it needs to change? I think that based on usecases the wikidata<->commonscat will be always 1:M relations and it will be impossible to normalize them to 1:1 ones without problems. --Zache (talk) 20:21, 25 December 2020 (UTC)

@Zache: I've been working on synchronizing Commons and Wikidata for several years now, and cases where there aren't 1:1 links are really rare (many of the 1:many links aren't useful, or can be solved by improving Commons categorisation and/or the Wikidata items). I'm hoping that P373 will be deprecated soon, and deleted sometime in 2021, see d:Wikidata:Properties_for_deletion#Property:P373. Thanks. Mike Peel (talk) 20:46, 25 December 2020 (UTC)

I've changed the line in Module:WikidataIB/sandbox to use _getCommonsLink, but I don't think that will give the results you want, because it will always create a category now. I honestly don't know what algorithm you want to use for the link, so I can't be certain what to implement. WADR, I usually find it better for someone to tell me the results they want and let me sort out what is the best way to implement it. Merry Xmas --RexxS (talk) 20:30, 25 December 2020 (UTC)

@RexxS: Thanks! I'll set up the infobox sandbox to check things. Ideally everything at e.g., Category:South Pole Telescope would work the same, but without using P373. It shouldn't add categories, it should just link to them, but using the sitelinks (following category's main topic (P301) etc.) rather than P373. Thanks. Mike Peel (talk) 20:46, 25 December 2020 (UTC)

@RexxS: "Lua error in Module:WikidataIB/sandbox at line 669: attempt to call global '_getCommonsLink' (a nil value).". Thanks. Mike Peel (talk) 20:53, 25 December 2020 (UTC)

@Mike Peel: it seems I called the function _getCommonslink, so that's fixed now. I still don't see how it's ever going to return a gallery. --RexxS (talk) 20:58, 25 December 2020 (UTC)

@RexxS: I tried to prefix the links with ":", but it doesn't look like it worked, as it now returns 'Category:Category:Blah'. {{Wikidata Infobox/sandbox}} now uses Module:WikidataIB/sandbox, see examples at Special:WhatLinksHere/Template:Wikidata_Infobox/core/sandbox. Thanks. Mike Peel (talk) 21:05, 25 December 2020 (UTC)

@Mike Peel: That's more or less what I expected. How about you tell me what output you want from the different cases and I'll try to sort out the logic? --RexxS (talk) 21:09, 25 December 2020 (UTC)

I've made a guess at what you want and made some amendments. Does that fit the bill? --RexxS (talk) 21:14, 25 December 2020 (UTC)

@RexxS: That's a step forward. In these cases, the link should never add the category to a parent category, it should just display the link. E.g., at Category:Anubis, the new version tries to add it to categories, while the main version just shows the links. Thanks. Mike Peel (talk) 21:21, 25 December 2020 (UTC)

Sorry, Mike. That's just too opaque for me. I think we need a bunch of test cases like we did for CiteQ, so that I can try to make sense of what is required. I suggest that we pause changing the code until I can get a better idea of the algorithm needed. --RexxS (talk) 21:27, 25 December 2020 (UTC)

@RexxS: OK, lets come back to this another day. I thought it was a straight swap, we just stop using P373 to provide inline links to other categories, and use the sitelinks insead. But clearly we're not connecting somewhere here. Thanks. Mike Peel (talk) 21:33, 25 December 2020 (UTC)

Thanks for the explanations, Zache. That's fair enough. —capmo (talk) 17:20, 26 December 2020 (UTC)

@RexxS: following up on this with some test cases. National Institute for Astrophysics - this works OK, but if you try the sandbox then it includes the page in the category rather than displaying the link. Same for radio telescope . However, Italy seems to work OK in both cases, which is good. Thanks. Mike Peel (talk) 18:03, 29 December 2020 (UTC)

This section is resolved and can be archived. If you disagree, replace this template with your comment. Fixed with Special:Diff/682198150 after the problem was rediscovered in #Decoding Q-values. (LennardHofmann (talk) 20:20, 24 August 2022 (UTC))

Lua memory error

in the Infobox with Category:COVID-19 pandemic in Austria. And (as a consequence?) a lot of unplausible categories. @Mike Peel: best --Herzi Pinki (talk) 05:51, 22 January 2021 (UTC)

@Mike Peel: any idea? --Herzi Pinki (talk) 20:50, 31 January 2021 (UTC)

@Herzi Pinki: The problem is that COVID-19 pandemic in Austria (Q86847911) is 3,771,486 bytes, and the infobox can't handle an item that is that big. It's #4 on d:Special:LongPages! Perhaps @RexxS: might have ideas for optimising the code, but a better solution would be to move all of the COVID data into tabular data rather than storing it in the Wikidata item. Pinging @TiagoLubiana: as the bot operator that's added most of the data to that item. Thanks. Mike Peel (talk) 12:06, 4 February 2021 (UTC)

Thanks for analysis and for calling possible problem-solvers. In general, Covid sucks. As far as I suppose, it is due to category's main topic (P301) in Category:COVID-19 pandemic in Austria (Q88805825). Isn't it the wrong topic anyway? The pandemic has much more aspects than just a list of daily figures. --Herzi Pinki (talk) 12:20, 4 February 2021 (UTC)

It looks like it is the right topic. I thought of a work-around for now, I've pointed the infobox to COVID-19 pandemic (Q81068910) to use info from that instead. It's not ideal, and will need to be undone at some point in the future when the infobox is more efficiently coded, but it avoids the brokenness for now... Thanks. Mike Peel (talk) 12:24, 4 February 2021 (UTC)

Hi Mike I'm sporadically working on a 'lite' version of WikidataIB without all of the extra functionality that is demanded on enwiki, so that it can be used as a 'drop-in' replacement in performance critical applications to reduce both the number of entities called and the memory footprint. However, trying to optimise performance is often a balancing act between memory and speed, and it's time-consuming to test what effect any particular change might have. In the long run, we're going to have to re-write the Wikidata Infobox completely in Lua to eliminate the overheads of so many #invokes, but let's see what the Summer Outreachy brings, as that may be a big help. --RexxS (talk) 16:24, 4 February 2021 (UTC)

NB: using the infobox without the manual qid still gives a memory error. Thanks. Mike Peel (talk) 05:33, 2 August 2022 (UTC)

This section is resolved and can be archived. If you disagree, replace this template with your comment. Fixed by rewriting autocat in Lua. (LennardHofmann (talk) 20:20, 24 August 2022 (UTC))

Strange errors and categories at Category:COVID-19 pandemic in Colombia

Category:COVID-19 pandemic in Colombia has a bunch of “not enough memory” Lua errors, and also a large list of seemingly arbitrary categories, from “Common years starting on Sunday” to “LGBT people by name”. Does anyone know what’s going on? Lucas Werkmeister (talk) 16:28, 12 June 2021 (UTC)

@Lucas Werkmeister: The categories are an artefact of the error messages messing up the template expansion (error messages are non-empty and therefore evaluate as truthy in the {{#if:}} parser function). As for the out of memory error itself, a likely large contributor to that would seem to be that the item that Category:COVID-19 pandemic in Colombia ultimately backs on to is massive, meaning that loading it in its entirety using mw.wikibase.getEntity() (or mw.wikibase.getEntityObject()) in Lua modules several times would cause the Lua VM to run out of memory. This function is used during infobox generation, such as in preloadWikidataProperties in Module:Wikidata Infobox (called from Template:Wikidata Infobox) and getAllLabels in Module:WikidataIB (called from Template:Wikidata Infobox/core). GreenComputer (talk) 05:04, 13 June 2021 (UTC)

@GreenComputer: Can you solve this problem? @Mike Peel: ? It's a pretty awful problem. --Animalparty (talk) 16:02, 15 June 2021 (UTC) Update: I just removed the template. Modern times call for simple solutions. --Animalparty (talk) 16:05, 15 June 2021 (UTC)

This section is resolved and can be archived. If you disagree, replace this template with your comment. Fixed by rewriting autocat in Lua. (LennardHofmann (talk) 20:20, 24 August 2022 (UTC))

Polish National Library ID

I would like to suggest a replacement of P1695 (NLP) with P7293 (PLWABN) in the authority control section of the template. I fully understand that there can be just one "Polish" ID in the template (and anyway, if there would be space for more, I would see P1207 as much better candidate to take the second spot). My proposal is in line with the policy of the National Library of Poland itself, which has now fully implemented PLWABN as their main authority ID. Powerek38 (talk) 18:05, 30 December 2021 (UTC)

Good idea! Let's change it! Gower (talk) 20:05, 30 December 2021 (UTC)

@Powerek38 and Gower: Is there a plan to deprecate NLP ID (old) (P1695) on Wikidata? There's no problem with including multiple IDs from Poland, so I've added both PLWABN ID (P7293) and NUKAT ID (P1207) to the sandbox at {{Wikidata Infobox/sandbox}} - please check that this is working as expected. Thanks. Mike Peel (talk) 22:29, 30 December 2021 (UTC)

@Mike Peel: It seems to be working perfectly fine with the sandbox, thank you! At the moment the National Library is still keeping its NLP database online, so the links on Wikidata (and here) are still working. That's why I don't think it should depracated just yet. It has been marked in WD descriptions in many languages that it's the old ID. As far as I know, they don't develop it any more, don't expand the database, don't train people in using it etc. On top of that, PLWABN has been uploaded to Mix'n'match, so if you don't want to create Polish biographical WD elements from scratch and you prefer to have Mix'n'Match preset some properties and labels for you, PLWABN is now probably the most comprehensive source. Powerek38 (talk) 22:45, 30 December 2021 (UTC)

This section is resolved and can be archived. If you disagree, replace this template with your comment. LennardHofmann (talk) 20:20, 24 August 2022 (UTC)

Memory/timeout issues cause pages to get added to Category:LGBT people by name??

I've discovered a bit of an odd issue. I was looking in Category:LGBT people by name and noticed a number of pages that clearly didn't belong there, such as Category:1906 in Connecticut, Category:Earthquakes of 2008, Category:COVID-19 pandemic in Argentina. It appears the rogue category was caused by {{Wikidata Infobox}} bugging out, but each time in slightly different ways:

On Category:1906 in Connecticut (and several other "YEAR in Connecticut" categories), the infobox template was accidentally transcluded twice, and the second instance of it had caused "The time allocated for running scripts has expired." to appear in big red letters about 50 times. Interestingly, "LGBT people by name" did not appear in the list of categories at the bottom of the page (even though the page appears in that category).
- I removed the duplicate infobox from one of these (Category:1823 in Connecticut), which fixed the timeout error messages and caused it to disappear from Category:LGBT people by name.
On Category:Earthquakes of 2008, the infobox was also used twice, although there are no visible error messages. "LGBT people by name" doesn't appear in the category list here either.
On Category:COVID-19 pandemic in Argentina (and a few other "COVID-19 pandemic in COUNTRY" categories), it appears that the infobox was only used once. However, the page is covered in red bold "Lua error: not enough memory." messages. Curiously, on this page, "LGBT people by name" DOES appear in the list of categories at the bottom.

My big question is, why would this random category get added just because a template crashed?? I see some logic in Template:Wikidata Infobox/core that adds Category:LGBT people by name, but it clearly requires certain values of sex or gender (P21); none of these items had P21 set at all. (Possibly unrelated, but I also happened to notice that Category:COVID-19 pandemic by country has the "The time allocated for running scripts has expired." red error message spam, but it does not appear in Category:LGBT people by name.) Can anyone figure this one out? Thanks, IagoQnsi (talk) 04:56, 22 January 2022 (UTC)

@IagoQnsi: The problem is that when Lua stops, it stops doing the checks, and returns the categories despite the logic. I've just implemented a work-around for this - the categories are now added through a simple Lua function, so if Lua stops then the categories won't be added. It's in {{Wikidata Infobox/sandbox}} at the moment, hopefully that should solve this from the next infobox version (will deploy it soon). Thanks. Mike Peel (talk) 12:39, 2 February 2022 (UTC)

@Mike Peel: This solution is an awful hack IMHO. I think a much cleaner solution would be checkProplist to return 1 instead of true if the property is present, and maybe 0 instead of the empty string if it isn’t, and test if we get a number greater than zero by concatenating the numbers. If Lua has timed out, the result won’t be a number, and depending on the exact implementation an expression error may show up, but no category is added. And this solution doesn’t require an extra Lua call, which would make even more pages to time out/run out of memory. —Tacsipacsi (talk) 19:45, 3 February 2022 (UTC)

@Tacsipacsi: I'm all for a better solution. I'll think through what you're suggesting and see what I can do - or if you want to demo it in the sandbox, please go for it? (see [6] for the Lua code). Thanks. Mike Peel (talk) 20:14, 3 February 2022 (UTC)

The code I wrote doesn't seem to work when made live, and I don't understand why that's happening. So for now this is still an open issue. Thanks. Mike Peel (talk) 19:16, 19 February 2022 (UTC)

This section is resolved and can be archived. If you disagree, replace this template with your comment. Fixed by rewriting autocat in Lua. (LennardHofmann (talk) 20:20, 24 August 2022 (UTC))

Mapy.cz ID etc.

Hi User:Mike Peel, could we go back to this attribution which was archived without any reaction?

I would appreciate Mapy.cz ID (P8988) in the Infobox template. This connection is very relevant especially for Czech geographical items. Possible other relevant on-line maps with linkable described objects (points of interest) can be treated in a similar way.
The correct output format of (postal) adresses according to standards of the respective country is a challenge for the future, especially for the system of dual numbering in cities of Czechia and Slovakia.

Thank You. --ŠJů (talk) 13:24, 27 April 2022 (UTC)

@ŠJů: I've added Mapy.cz ID (P8988) to {{Wikidata Infobox/sandbox}}, please test that and see if it works as expected? Formatting of addresses is a bigger problem for the future, sorry. Thanks. Mike Peel (talk) 17:50, 29 April 2022 (UTC)

@Mike Peel: Thank You. In the infobox, the ID diplays correctly, but in the link, it is incomplete. E.g. the parameter "base&id=2222420" is shortened to "2222420" and thus doesn't work (the resultant link is https://mapy.cz/zakladni?source=2222420 instead of the correct https://mapy.cz/zakladni?source=base&id=2222420). --ŠJů (talk) 21:32, 29 April 2022 (UTC)

Hi Mike Peel, within one month, the error was not corrected. --ŠJů (talk) 23:35, 27 May 2022 (UTC)

The infobox link for Mapy.cz ID (P8988) is invalid, while the link from the Wikidata pages works correctly. Tranformation of the URL adress for the infobox fails. See d:Property talk:P8988#Style of external ID for futher specification of the problem with the values containing two parameters in one string. --ŠJů (talk) 17:30, 14 July 2022 (UTC)

@ŠJů: The Mapy.cz links should be working now in {{Wikidata Infobox/sandbox}}. I tried it on Category:Drábské světničky. --LennardHofmann (talk) 16:19, 28 July 2022 (UTC)

@LennardHofmann: Hi. When I try preview page with the template {{Wikidata Infobox/sandbox}}, the link is as incorrect as in the current version of {{Wikidata Infobox}}, ie. it links "?source=1834772" instead of "?source=base&id=1834772". --ŠJů (talk) 22:11, 28 July 2022 (UTC)

@ŠJů: Can you try again and tell me on which page the link is incorrect? Thanks. LennardHofmann (talk) 07:12, 29 July 2022 (UTC)

@LennardHofmann: Hi. Tested again on the preview page of Category:Drábské světničky with the template {{Wikidata Infobox/sandbox}}. The page generates liks https://wikidata-externalid-url.toolforge.org/?p=8988&url_prefix=https://mapy.cz/zakladni?source=&id=base&id=1834772 which results to https://mapy.cz/zakladni?source=1834772, instead of the correct https://mapy.cz/zakladni?source=base&id=1834772. --ŠJů (talk) 11:36, 29 July 2022 (UTC)

@ŠJů: That's weird. When I preview that page with the sandbox template, it generates https://wikidata-externalid-url.toolforge.org/?p=8988&url_prefix=https://mapy.cz/zakladni?source=&id=base%26id%3D1834772 (note how everything after source=&id= is percent-encoded), which results to https://en.mapy.cz/zakladni?source=base&id=1834772 (I even tried it on multiple operating systems and web browsers).

Does the link on d:Q625415#P8988 work for you? It does for me. The best solution would be to split the property into "base ID", "muni ID", "ward ID" etc. LennardHofmann (talk) 14:51, 29 July 2022 (UTC)

@LennardHofmann: The links from the Wikidata item page work correctly. Now I found out that when I insert the sandbox-template directly to the Commons category page, the link works correctly, while through the "Preview page with this template" function of the template-edit page, the link works not correctly. I.e. the sandbox version of the template may be correct, but the "Preview page with this template" function of template pages has some bug. The bug seems to be independent on the browser (tested in Firefox, Edge and Chrome). --ŠJů (talk) 15:23, 29 July 2022 (UTC)

@ŠJů: “Preview page with this template” shows the preview with whichever templates it uses. It doesn’t automagically use the sandbox instead of the main template, the only thing it does replacing the currently edited template’s saved content with the content that’s currently in the edit box—if the currently edited template is used at all. In the July 28 version of the category, {{Wikidata Infobox/sandbox}} wasn’t used, so if you used that version for the preview, previewing it from the sandbox didn’t make any difference. Generally, using “Preview page with this template” makes only sense if you’ve changed the content of the edit box before, otherwise it shows exactly the same as how opening the target page would look like. —Tacsipacsi (talk) 18:19, 31 July 2022 (UTC)

@Tacsipacsi: You are right, that was my thinking short circuit that I tried to test it through “Preview page with this template” instead of through the preview of the category page with a replaced template. --ŠJů (talk) 19:04, 31 July 2022 (UTC)

@LennardHofmann: Sorry for my mistake, the sandbox template is OK. --ŠJů (talk) 19:04, 31 July 2022 (UTC)

The proposal to have many special properties for Mapy.cz links instead of one universal two-parameter property was discussed, but was rejected. It would complicate the work of all subsequent infoboxes, scripts or other tools across projects. I think it is easier to solve one problem with wrong encoding of URL links than to maintain an ever-increasing number of analog properties, and for each new layer of data that appears in the future, again tediously asking for approval of every new property. For now, it were 14 properties (addr|area|base|coun|dist|muni|quar|regi|stre|ward|osm|pubt|firm|traf), and more may be added or discovered in the future. --ŠJů (talk) 15:23, 29 July 2022 (UTC)

This section is resolved and can be archived. If you disagree, replace this template with your comment. Links to Mapy.cz are working now. (LennardHofmann (talk) 20:20, 24 August 2022 (UTC))

Bug with getOriginalCombination

If the original combination of a taxon has a citation, it is currently displayed directly after the combination's name string without a space inbetween. To take an example from my usual focus on Commons (since I can't find any non-obscure examples offhand), Category:Bromius obscurus's original combination displays as "Chrysomela obscuraLinnaeus, 1758". Monster Iestyn (talk) 13:32, 5 August 2022 (UTC)

@Monster Iestyn: Good catch! Should there also be a comma after the combination's name or should the citation be wrapped in parentheses if the value on Wikidata isn't already wrapped in parentheses? Stated differently, which of the following formats do you prefer?

Chrysomela obscura Linnaeus, 1758
Chrysomela obscura, Linnaeus, 1758
Chrysomela obscura (Linnaeus, 1758)

Or should it be something else? LennardHofmann (talk) 09:10, 6 August 2022 (UTC)

@LennardHofmann No, there shouldn't be a comma after the combination's name, and the citation should not be wrapped in parentheses if the value on Wikidata didn't have them. (The parentheses have a specific meaning in both botany and zoology, so they should not be used all the time.) So I'd say format 1 is best. Monster Iestyn (talk) 13:27, 6 August 2022 (UTC)

@Monster Iestyn: Fixed in {{Wikidata Infobox/sandbox}}. Will be made live in a few weeks. --LennardHofmann (talk) 10:25, 9 August 2022 (UTC)

This section is resolved and can be archived. If you disagree, replace this template with your comment. Now live (LennardHofmann (talk) 20:20, 24 August 2022 (UTC))

Decoding Q-values

The template does a great thing, translating the Q-id values of wikidata statements into blue links pointing to Commons categories.

However, I notice that it seems to be missing cases where it would need to follow topic's main category (P910) and then the sitelink from that item to get the Commons category. For example, on Category:General Post Office (1874 building), the template is not blue-linking "General Post Office" because it is not following the chain

General Post Office (Q1325334) -> topic's main category (P910) -> Category:General Post Office (Q13263440) -> Category:General Post Office (United Kingdom)

On the other hand, it is blue-linking St. Martin's Le Grand parish (Q7590022) to Category:French Protestant Church in the City of London apparently following a spurious Commons category (P373) statement on that item. (snapshot). P373s quite often have problems, haven't been updated in a long time, and if User:Mike Peel had his way would all be abolished, so should only be used as a last resort (if at all). The topic's main category (P910) mechanism is what the template should be following if possible, when it is a category-item rather than a main item on WD that holds the sitelink. Jheald (talk) 16:56, 12 August 2022 (UTC)

@Jheald: The problem here seems to be bad Commons category (P373) values, and the need to improve topic's main category (P910) values and similar on Wikidata? I'm not sure this needs a change to the infobox, except it would be good to get rid of uses of Commons category (P373)? Thanks. Mike Peel (talk) 17:19, 12 August 2022 (UTC)

@Mike Peel: The key problem I wanted to flag is that the template isn't following topic's main category (P910) values as a fallback, even when they are there. That's not a wikidata problem, it's revealing an issue with the template code. Jheald (talk) 18:30, 12 August 2022 (UTC)

Not sure why the Post Office isn't linked. {{#invoke:WikidataIB|getCommonsLink|qid=Q1325334}} works fine. LennardHofmann (talk) 16:22, 13 August 2022 (UTC)

@Jheald: Fixed in {{Wikidata Infobox/sandbox}} with this edit. To my big surprise, WikidataIB was using Commons category (P373) instead of getCommonsLink for the links. How did we not notice this before??? LennardHofmann (talk) 17:04, 13 August 2022 (UTC)

This section is resolved and can be archived. If you disagree, replace this template with your comment. LennardHofmann (talk) 20:20, 24 August 2022 (UTC)

Links at the bottom shouldn't split over multiple lines

A minor thing: some of the links at the bottom now seem to split over multiple lines, in particular sta-tistics, and KML <line break> file. It would look a bit better if we just started a new line, rather than splitting the links, probably it just needs a CSS tweak. Thanks. Mike Peel (talk) 17:10, 13 August 2022 (UTC)

This section is resolved and can be archived. If you disagree, replace this template with your comment. I added CSS nowrap to each item (LennardHofmann (talk) 20:20, 24 August 2022 (UTC))

first family name in Portuguese name

Hi, guys! ㋡
There is a new property for surnames, but it does not add surname categories yet because it is not included in this template. I will be grateful if any of you can add it.
first family name in Portuguese name (P9139) Minerva97 (talk) 13:08, 20 February 2021 (UTC)

This section is resolved and can be archived. If you disagree, replace this template with your comment. first family name in Portuguese name (P9139) is now used for autocat. (LennardHofmann (talk) 10:27, 28 August 2022 (UTC))

P1639

Hello. I believe we should display pendant of (P1639). This would be very useful for categories such as Category:Portrait of Battista Sforza. Can someone add the required code where needed? Thierry Caro (talk) 15:43, 18 August 2022 (UTC)

@Thierry Caro: Added. You can find pendant of (P1639) right after part of (P361). LennardHofmann (talk) 20:20, 24 August 2022 (UTC)

@LennardHofmann: Art lovers thank you. Thierry Caro (talk) 22:56, 24 August 2022 (UTC)

This section is resolved and can be archived. If you disagree, replace this template with your comment. LennardHofmann (talk) 10:27, 28 August 2022 (UTC)

Display of occupation (P106) depending on gender (P21)

Hi I see that in Category:Eilling_Bekken that occupation is displayed in french as « skieur ou skieuse ». However, it should be displayed using WD:P2521 or WD:P3321 to be correct, depending if person is female or male-gendered (and if no gender is specified, label can be displayed).

Sadly, I do not know lua and I can't make any suggestion to fix this.

Do you know how to fix this?

Regards Lupin~fr (talk) 20:15, 19 August 2022 (UTC)

@Mike Peel: could you take a look at this? (and it's not only for French, but in French we will change soon-ish all the Wikidata labels so it will be particulary visible). Cheers, VIGNERON (talk) 08:09, 20 August 2022 (UTC)

@Lupin~fr and VIGNERON: The values for occupation (P106) and most other properties are formatted using Module:WikidataIB. I added a new parameter |gendered= to WikidataIB/sandbox and instructed {{Wikidata Infobox/sandbox}} to use it for occupation (P106). The sandbox versions will be made live on Wed, Aug 24 if the changes didn't introduce new problems. --LennardHofmann (talk) 12:08, 20 August 2022 (UTC)

Thanks a lot LennardHofmann, here some tests that seems to work well:

d:Q113495060 skier

d:Q10085 alpine skier

d:Q7186 (for a totally different example) physicist, chemist, university teacher

I think it's good to go live. @Lupin~fr: feel free to do other test.

Cheers, VIGNERON (talk) 18:03, 20 August 2022 (UTC)

Thank you very much @LennardHofmann and @VIGNERON :) Lupin~fr (talk) 23:06, 20 August 2022 (UTC)

Other test on Category:Jonathan Van Ness (a non-binary person) : actor, television personality, hairdresser, television presenter, podcaster, writer (per Shev123 idea). @PAC2 and Lupin~fr: is it what we expect? if not, what should we expect? Cdlt, VIGNERON (talk) 13:49, 21 August 2022 (UTC)

Good one @VIGNERON.

Since this person does not identify themself as a man or a women, and if no épicène form is available, this result seems the best we can do to me. Lupin~fr (talk) 21:35, 21 August 2022 (UTC)

This section is resolved and can be archived. If you disagree, replace this template with your comment. LennardHofmann (talk) 10:27, 28 August 2022 (UTC)

Expanding autocat for gender by country categories

Just a thought, we could extend autocat to include subcats of Category:People by name by country (particularly men/women by country) using country of citizenship (P27). Thanks. Mike Peel (talk) 18:15, 20 August 2022 (UTC)

This section is resolved and can be archived. If you disagree, replace this template with your comment. Added (see function countrycat in Module:Wikidata Infobox). (LennardHofmann (talk) 10:27, 28 August 2022 (UTC))

Label fallbacks no longer work

See report at w:Wikidata:Report a technical problem#Issue with "category combines topics". Looking at https://commons.wikimedia.org/wiki/Category:Windows_of_Nasir-ol-Molk_Mosque?uselang=sh, the issue is actually not constrained to category combines topics (P971), but rather affects all values that don’t have Serbo-Croatian labels (Nasir-ol-Molk Mosque (Q1962312), Hassan Ali Nasir al-Molk (Q5957165) and Nasir Mosque (Q5883370) in this case). Wherever it should fall back to English (or another South Slavic language—Serbo-Croatian’s fallback chain is bs, sr-el, hr), it displays the Qid instead. (It has nothing to do with the fact that Serbo-Croatian has several fallback languages, though, Hungarian—which falls back directly to English—also shows some Qid’s.) —Tacsipacsi (talk) 00:55, 25 August 2022 (UTC)

@Tacsipacsi: Thanks for letting me know. This should now be fixed in {{Wikidata Infobox/sandbox}} thanks to Special:Diff/684951649. --LennardHofmann (talk) 09:36, 25 August 2022 (UTC)

@LennardHofmann: Thanks for fixing it! Previewing the named category with the sandbox looks good now.

@Mike Peel: I think this is a major regression, could we get an out-of-schedule sync from the sandbox?

@Orijentolog: FYI. The normal infobox is not yet fixed, but if you change {{Wikidata Infobox}} to {{Wikidata Infobox/sandbox}} (and either save it or just click preview), it should be good. —Tacsipacsi (talk) 07:48, 26 August 2022 (UTC)

This section is resolved and can be archived. If you disagree, replace this template with your comment. The fix is now live (LennardHofmann (talk) 10:27, 28 August 2022 (UTC))

"Double" surnames

A little bug report for the Lua version of the box (by the way - the new version is even better than the old one has been, thank you so much for all the work!). In my native language, Polish, when someone (usually woman, but men are also legally allowed to do it) is getting married and decides to use both their maiden name and their spouse's name, those two names are connected by "-" sign and written next to each other. This is commonly known as a "double surname". On Wikidata we express this by adding two statements of P734 with P1545 qualifier to indicate the order of names. In the old infobox, both surnames were automatically displayed in categories. After the Lua relaunch only the first one is displayed. Examples: 1, 2. Thank you for looking into this. Powerek38 (talk) 11:06, 25 August 2022 (UTC)

@Powerek38: Thanks for letting me know. This should now be fixed in {{Wikidata Infobox/sandbox}}. --LennardHofmann (talk) 11:50, 25 August 2022 (UTC)

This section is resolved and can be archived. If you disagree, replace this template with your comment. The fix is now live (LennardHofmann (talk) 10:27, 28 August 2022 (UTC))

Empty categories

If a person has multiple surnames, such as Wikidata:Q28736 (Nasse-Meyfarth/Meyfarth), only the first name from the list will be displayed in the categories. The same is the case with e.g. Wikidata:Q102592 (Kallee/von Kallee), the Category:Von Kallee (surname) is now Empty, as it is for many others. HarryNº2 (talk) 01:59, 27 August 2022 (UTC)

Already fixed in {{Wikidata Infobox/sandbox}}. --LennardHofmann (talk) 06:39, 27 August 2022 (UTC)

When will the changes be visible? The Category:Von Kallee (surname) is still empty. Hopefully, empty categories will not be suggested for quick deletion now. HarryNº2 (talk) 11:23, 27 August 2022 (UTC)

@HarryNº2: The changes will be visible at some point today. LennardHofmann (talk) 12:23, 27 August 2022 (UTC)

Thank you! HarryNº2 (talk) 13:08, 27 August 2022 (UTC)

@Mike Peel: Do you still want to make the changes live today? LennardHofmann (talk) 18:58, 27 August 2022 (UTC)

This section is resolved and can be archived. If you disagree, replace this template with your comment. The fix is now live (LennardHofmann (talk) 10:27, 28 August 2022 (UTC))

Reverse order of categories

Why do a person's awards (Wikidata:Property:P166) appear first in category order recently, see e.g. Category:Eduard von Kallee? HarryNº2 (talk) 02:14, 27 August 2022 (UTC)

It's pretty annoying that the awards categories are at the start. I changed the order in {{Wikidata Infobox/sandbox}}. LennardHofmann (talk) 06:39, 27 August 2022 (UTC)

When will the changes be visible? The awards still at the beginning in the order of the categories. HarryNº2 (talk) 11:18, 27 August 2022 (UTC)

This section is resolved and can be archived. If you disagree, replace this template with your comment. The fix is now live (LennardHofmann (talk) 10:27, 28 August 2022 (UTC))

Lua errors in Covid related categories

Category:COVID-19 pandemic by country and Category:COVID-19 pandemic in Europe‎ still have Lua errors ("The time allocated for running scripts has expired"). The issue with enormous COVID related items was discussed many times before. In case of Category:COVID-19 pandemic by country, is the issue the size of COVID-19 pandemic by country and territory (Q83741704) (100 kG), a page linked through category's main topic (P301) or the size of COVID-19 pandemic (Q81068910) (1.1 GB) which is linked through category combines topics (P971)?

I tried to use {{Wikidata Infobox|suppressfields=P971}} to presumably tell {{Wikidata Infobox}} to suppress it use of P971, but it did not helped. Any ideas on how to tell the template to ignore P971? Jarekt (talk) 16:41, 8 August 2022 (UTC)

@Jarekt: The problematic item is COVID-19 pandemic by country and territory (Q83741704). The infobox only uses category combines topics (P971) for subinfoboxes if the connected Wikidata item has no category's main topic (P301). There is currently no parameter to disable subinfoboxes.

I fixed the timeout by adding |suppressfields=P527. Calling getCommonsLink on the has part(s) (P527) values was slow because of phab:T237884. I disabled links for collapsed values because of this, but recently I added exceptions for has part(s) (P527) and connects with (P2789) to fix user's complaints. --LennardHofmann (talk) 11:27, 9 August 2022 (UTC)

LennardHofmann, Thanks a lot. How to work with {{Wikidata Infobox}} to prevent it's timeout issues is always a bit mysterious to me. I noticed Category:COVID-19 pandemic in Argentina also has errors now. It is connected to 4GB item by P301. I tried to suppress bunch of fields: {{Wikidata Infobox|suppressfields=P527,P1120,P1603,P8010,P8011}}, but did not fixed the errors. --Jarekt (talk) 03:58, 10 August 2022 (UTC)

@Jarekt: The memory issues are fixed in {{Wikidata Infobox/sandbox}} thanks to Special:Diff/681407191, which gets rid of getAllLabels, getAllDescriptions, and getAllAliases, cutting down three redundant getEntity('Q87235137') calls. LennardHofmann (talk) 07:56, 10 August 2022 (UTC)

Nice. --Jarekt (talk) 11:19, 10 August 2022 (UTC)

This section is resolved and can be archived. If you disagree, replace this template with your comment. Mike Peel (talk) 20:40, 30 August 2022 (UTC)

Map-Shapes Protected Areas

The Infobox does sometimes show a Coordinate and sometimes show a coordinate and a shape in the map. Examples: Infobox mit Shape vs Infobox ohne Shape.
The shape is NOT uploaded to wikidata nor did i find it in commons. Can anyone tell me, where the shape-data is coming from, how to find this information (is there some LUA in the background?) and why it is sometimes there and sometimes not? Thank you for making a simple editor very happy! --Ordercrazy (talk) 09:19, 11 August 2022 (UTC)

@Ordercrazy: It comes from OpenStreetMap. If you edit OSM, you can add a Wikidata QID to structures there. Then, once WMF updates its copy of the OSM map, the shape will appear in the infoboxes. Thanks. Mike Peel (talk) 12:06, 11 August 2022 (UTC)

This section is resolved and can be archived. If you disagree, replace this template with your comment. Mike Peel (talk) 20:36, 30 August 2022 (UTC)

WikiShootMe

Having seen the WikiShootMe link here, I recently (thread) asked Magnus whether it would be possible to highlight images that are already in a category, to (i) make their locations obvious, and (ii) help to identify nearby images that are not yet in the category, but perhaps should be.

A test version of this is now live: achieved by adding &main_commons_category=... to the end of the WSM url, to give eg https://wikishootme.toolforge.org/#lat=52.166484557136386&lng=0.13515651226043704&zoom=18&layers=commons,wikidata_image,wikidata_no_image&main_commons_category=Nine_Wells
Images that are in the category (or within two sub-cats below it) now get a little lemon-yellow halo.

Would it be possible to update the link from the template here accordingly, to be able to give it a go? Thanks, Jheald (talk) 16:35, 12 August 2022 (UTC)

@Jheald: Has been added to {{Wikidata Infobox/sandbox}}. Try it on Cambridge. --LennardHofmann (talk) 15:57, 13 August 2022 (UTC)

Thanks! Jusr tried it on c:Category:Sheilhill Old Bridge and I think this could be very useful. Jheald (talk) 19:13, 13 August 2022 (UTC)

This section is resolved and can be archived. If you disagree, replace this template with your comment. Mike Peel (talk) 20:37, 30 August 2022 (UTC)

additional media properties

The following were created only a while ago. Maybe some could be included as well:

size comparison diagram (P8512) (for many things). Sample: d:Q300949#P8512 for Category:Hyperoodon ampullatus
aerial view (P8592) (for any location). Sample: d:Q513#P8592 for Category:Mount_Everest
image of entrance (P9721) (mainly for buildings, but also for other types). Sample: d:Q897712#P9721 for Category:Great Lavra Belltower
image with color chart (P10093) (proposed for paintings, but applicable to other objects as well. Will be more useful there). Sample: d:Q5826311#P10093 for Category:The Port of Marseilles by Paul Signac (Hermitage, 1907)

Full list is at d:Special:ListProperties/commonsMedia. --- Jura1 (talk) 11:59, 31 December 2021 (UTC)

All of those are added now except for image with color chart (P10093) because it would be shown on only ten category pages. It would also be nice to keep track of new image properties being created since image properties are the cheapeast to add to the infobox. LennardHofmann (talk) 18:54, 21 July 2022 (UTC)

This section is resolved and can be archived. If you disagree, replace this template with your comment. Mike Peel (talk) 14:05, 9 October 2022 (UTC)

Bug? Why is different from (P1889) no longer displayed?

Why is different from (P1889) no longer displayed in the Infobox? See e.g. Category:Bornschein (surname) and other Categorys with names. HarryNº2 (talk) 10:52, 21 July 2022 (UTC)

@HarryNº2: As stated in the changelog, I changed it so that only linked values are shown for different from (P1889). This hides many useless family name has to use a different item than disambiguation page (Q27924673) values. Do you find unlinked values useful sometimes? LennardHofmann (talk) 14:45, 21 July 2022 (UTC)

Basically yes, so that the reader is informed that there are other people and terms in Wikimedia projects that go with the name, even if no page has been created on Commons yet. --HarryNº2 (talk) 15:02, 21 July 2022 (UTC)

@LennardHofmann: Generally, linked items with no Commons category are usually equally important as a value which has its own Commons category. The problem is that if there is a pure label with no description and no link, it is often impossible to recognize which item they are referring to. For values with no Commons category link, a link to the Wikidata item page should be added instead (and maybe also its description in the bubble tooltip). Besides, I think the request for an alternative link for such cases has already been raised. To suppress all these values in the infobox was not a good idea. --ŠJů (talk) 21:30, 22 July 2022 (UTC)

{{Wikidata Infobox/sandbox}} now shows all values for different from (P1889) and has links to Wikidata with tooltip. Try it at Category:Bornschein (surname). --LennardHofmann (talk) 09:36, 24 July 2022 (UTC)

This section is resolved and can be archived. If you disagree, replace this template with your comment. Mike Peel (talk) 14:05, 9 October 2022 (UTC)

unit testing

User:Mike Peel I added testing and test results pages to your module. Please expand. --Jarekt (talk) 17:17, 17 August 2019 (UTC)

This section is resolved and can be archived. If you disagree, replace this template with your comment. Mike Peel (talk) 14:04, 9 October 2022 (UTC)

Wrong map for "Category:Lake islands of the United States"

Category:Lake islands of the United States shows map of Europe and North Africa. Jarekt (talk) 04:01, 31 July 2022 (UTC)

@Jarekt: Thanks for letting me know, the map was zoomed in too much. This is now fixed in {{Wikidata Infobox/sandbox}}. The next time you see a badly zoomed map with a highlighted shape, try previewing the page with {{Wikidata Infobox/sandbox}}, and if that doesn't fix it, add an OpenStreetMap relation ID (P402) statement to the item. LennardHofmann (talk) 07:15, 31 July 2022 (UTC)

This section is resolved and can be archived. If you disagree, replace this template with your comment. Mike Peel (talk) 14:04, 9 October 2022 (UTC)

Icons look great

Hey, I noticed that the infobox recently started showing icons next to many external identifiers. I assume this came as part of @LennardHofmann's rewrite -- thanks for adding that! I started adding icons to lots of properties a while back in hopes that someone would find them useful, and I'm thrilled to see them finally being used. Cheers, IagoQnsi (talk) 06:59, 5 August 2022 (UTC)

But these icons shouldn't be clickable (with link=no) in order to not display in the MediaViewer. — Draceane ^talk_contrib. 12:17, 30 August 2022 (UTC)

@Draceane: Agreed, but according to w:Help:Pictures#Links, the link is required to credit the icon's copyright holder. Looking at How can I disable Media Viewer for unrelated images?, the best option seems to be |class=noviewer. LennardHofmann (talk) 19:11, 30 August 2022 (UTC)

@LennardHofmann: The Wikimedia convention is to use the 'link=no' parameter for icons like these, since they are being used in a way that shouldn't be clickable. It's less about MediaViewer compatibilty, more about user interface friendliness. Thanks. Mike Peel (talk) 20:34, 30 August 2022 (UTC)

This section is resolved and can be archived. If you disagree, replace this template with your comment. Mike Peel (talk) 14:04, 9 October 2022 (UTC)

Video should not be in the image switcher

Example at Category:Knowledge for Everyone - it would be better if the image showed below the image switcher, rather than part of it, the same way we show audio separately. Thanks. Mike Peel (talk) 18:15, 6 August 2022 (UTC)

I'm afraid the video thumbnail would take too much space if it was shown separately on Category:European Union. --LennardHofmann (talk) 20:20, 24 August 2022 (UTC)

Good point. I'm not sure that is a useful video there... Thanks. Mike Peel (talk) 20:36, 30 August 2022 (UTC)

This section is resolved and can be archived. If you disagree, replace this template with your comment. Mike Peel (talk) 14:03, 9 October 2022 (UTC)

Display P1343?

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)

@Steenth and Hjart: ? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 11:23, 8 August 2021 (UTC)

@Hjart, Animalparty, Pigsonthewing, and Steenth: I'm going to decline this, sorry. The best solution is to create a new property for the database, which we can easily add to the infobox. However, adding described by source (P1343) would likely add too much in other items.

This section is resolved and can be archived. If you disagree, replace this template with your comment. Mike Peel (talk) 17:34, 31 October 2022 (UTC)

Alternate image

Is the alternate image, d: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)

@Richard Arthur Norton (1958- ): The behaviour here has changed a while back, the book image now displays correctly. Thanks. Mike Peel (talk) 17:36, 31 October 2022 (UTC)

This section is resolved and can be archived. If you disagree, replace this template with your comment. Mike Peel (talk) 17:36, 31 October 2022 (UTC)

Please defaultsort without tussenvoegsel

I'm disabling the defaultsort quite often because Dutch family names aren't sorted by their "tussenvoegsel", infix (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)

@1Veertje: See d:Wikidata:WikiProject Names. (I just commented there on another human onomastics matter that’s affecting Commons cats; I’m not holding my breath waiting for a solution, though.) -- Tuválkin ✉ ✇ 04:21, 11 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)
According to w:WP:MCSTJR, Belgian people born after 1830 are sorted with their tussenvoegsel (e.g. Paul van Ostaijen is sorted "Van Ostaijen, Paul"), so there is not much we can do. LennardHofmann (talk) 16:37, 16 August 2022 (UTC)

@1Veertje, Ghouston, Tuvalkin, and Jura1: This isn't done per the comment by @LennardHofmann: . I think this needs more work on the Wikidata side of things to properly implement in a way that can cope with exceptions - perhaps by having infix (P7377)=van der (Q69869239) and family name (P734)=Velden (Q106331968) in the items it applies to. Or if not, we need a clear recipe for what will work. For now there's the DEFAULTSORT override that hopefully works OK? Thanks. Mike Peel (talk) 17:44, 31 October 2022 (UTC)

This section is resolved and can be archived. If you disagree, replace this template with your comment. Mike Peel (talk) 17:44, 31 October 2022 (UTC)

Roman names

Hi, could the wikidata properties Roman cognomen and Roman praenomen be used for the sorting into correspongding given and surname categories (and perhaps as DEFAULTSORT as well)? Thx and regards --Ju Ta 07:54, 18 June 2020 (UTC)

@Mike Peel: Any comments or opinions? --Ju Ta 13:07, 12 July 2020 (UTC)

It does not seem to be common to categorize people of Ancient Rome into given name and surname categories; I only see categories such as Gens Iulia. What do others think? --LennardHofmann (talk) 20:20, 24 August 2022 (UTC)

@JuTa: This isn't done per @LennardHofmann: 's comment. If it isn't common and it should be, then it probably needs a discussion elsewhere first. Thanks. Mike Peel (talk) 17:53, 31 October 2022 (UTC)

This section is resolved and can be archived. If you disagree, replace this template with your comment. Mike Peel (talk) 17:53, 31 October 2022 (UTC)

Suppress display on file pages

I've just removed an instance of this template from File:Mecodema dux (2).jpg. Can we wrap the template code in the necessary 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)

@Mike Peel: Nudge... Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 10:57, 28 June 2020 (UTC)

disable use in File namespace

Can we disable use of this template in File namespace? for some reason I see more of those lately. Sometimes it is added directly an sometimes by intentionally or accidentally transcluding category page. --Jarekt (talk) 03:21, 22 June 2020 (UTC)

See #Suppress display on file pages, above. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 15:33, 22 June 2020 (UTC)

@Pigsonthewing, Jarekt, Sadads, and Andy Dingley: It's clear that it's not appropriate to use this infobox on file pages. Last year, I was hoping that it might be possible to modify it so it would work well there by including different code in that namespace, but now I think it's better if that is a completely separate template (like {{Structured Data}}), particularly given the performance issues that have been raised.

My preference would still be to keep the status quo, though. It's easy to spot uses of the infobox in file namespace by looking at Category:Wikidata infobox maintenance, and there aren't too many of them, so they can be manually resolved. The alternative is that we add a namespace check to the template that disables the display of the infobox, and adds it to a maintenance category. However, that check would have to be done on every use of the template, which adds to the performance issue. Thoughts? Thanks. Mike Peel (talk) 18:02, 1 July 2020 (UTC)

My preference would be to just disable it in other namespaces by wrapping the whole template in a IF statement checking the namespace. We often have such statements when adding "problem" categories to some pages but not the others. I do not know why but I see lately much more categories added manually with {{}} brackets instead of [[]] brackets which transclude the category page with {{Wikidata Infobox}}, which then has weird interaction with SDC and creates errors. --Jarekt (talk) 18:12, 1 July 2020 (UTC)

@Jarekt: Is there another way of identifying the incorrect brackets issue apart from infobox mis-transcludes? Thanks. Mike Peel (talk) 18:34, 1 July 2020 (UTC)

One can create SQL query to find transcluded category pages. The problem is that at some point we had some crazy scheme of adding Artwork template to a category and than transclude the category. It was always a bad idea and we still have plenty of it around. We would have to exclude those from the query. --Jarekt (talk) 21:07, 1 July 2020 (UTC)

Do you have any examples of File: pages with these infoboxes? There don't seem to be any at present.

I find it slightly hard to imagine when this would be useful (the canonical image of a clear topic for which there's a WD entry?), but still can't see a reason to break the infobox from ever being used like this. If a particular use is inappropriate, then a better (and simpler) solution would be to simply remove it from that page. Andy Dingley (talk) 20:24, 1 July 2020 (UTC)

Andy I am spending a lot of my time simply removing it from pages, which I would rather spend doing other things. To me it seems like a sanity check: the template was not designed to be used that way so lets prevent it from being used that way. --Jarekt (talk) 20:59, 1 July 2020 (UTC)

OK then, OPPOSE

If you can't give a reason for, or even an example of, how awful such use of this template is, then don't expect me to support a blanket ban on anything. Andy Dingley (talk) 23:21, 1 July 2020 (UTC)

"can't see a reason to break the infobox from ever being used like this" Nothing would be "broken", and especially not for "ever"; this being a wiki, any edit can be reverted or changed. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 22:20, 1 July 2020 (UTC)

is there some similar template for the use in the file-name-space. If yes this can replace WIKIDAT INFO template. Altough I do not understand that it should not used in the file-namespace.--Hfst (talk) 15:35, 15 October 2020 (UTC)

@Pigsonthewing, Sadads, Andy Dingley, Jarekt, and Hfst: I'm marking this as not done since it really doesn't seem to be a big problem? Or at least, if you look through the subcategories of Category:Wikidata infobox maintenance, it's rare to see files being included - and if they are it's easy to fix. It would be possible to add the check if really needed, but is it worth the overhead? Thanks. Mike Peel (talk) 17:58, 31 October 2022 (UTC)

This section is resolved and can be archived. If you disagree, replace this template with your comment. Mike Peel (talk) 17:58, 31 October 2022 (UTC)

Vestmannabjørgini

I added a located in/on physical feature (P706) to Vestmannabjørgini (Q1425782) and now the infobox in Category:Vestmannabjørgini looks rather weird. The island Streymoy is subdivided in 4 administrative areas. What do? --Hjart (talk) 16:02, 23 June 2020 (UTC)

@Hjart: This seems to have sorted itself out? Otherwise, the fix is on Wikidata: use located in the administrative territorial entity (P131) instead. Thanks. Mike Peel (talk) 18:00, 31 October 2022 (UTC)

This section is resolved and can be archived. If you disagree, replace this template with your comment. Mike Peel (talk) 18:00, 31 October 2022 (UTC)

Infoboxes on disambiguation pages

I complained at Mike Peel’s talk page about adding the infobox on disambiguation categories, and he directed me here to have more opinions on the topic. For those who don’t want to read through the discussion over there, I summarize the opinions:

In Mike’s view the infobox is useful on disambiguation categories, as it may provide disambiguation links that aren’t listed elsewhere, and its categorization feature helps finding disambiguation categories connected with non-disambiguation items or vice versa.
In my view the infobox is completely unnecessary on disambiguation categories, at least on clear ones (i.e. ones that are marked as disambiguation both on Commons and Wikidata). I think the infobox is not a natural place to search disambiguation links at; they should be rather added to the main list. In clear cases, the maintenance categories don’t help either, as there’s nothing to fix. In my opinion adding these infoboxes is a plain waste of server resources (albeit not a huge one thanks to the low number of disambiguation categories).

Thoughts? —Tacsipacsi (talk) 23:29, 1 July 2020 (UTC)

I share you view that the infobox for that type of categories is completely unnecessary and without any added value.Jklamo (talk) 07:31, 2 July 2020 (UTC)

Give some examples please. --Richard Arthur Norton (1958- ) (talk) 20:31, 9 August 2020 (UTC)
- Just click on the discussion link above, and you’ll find the example. —Tacsipacsi (talk) 09:50, 10 August 2020 (UTC)
- These are nominally tracked in Category:Uses of Wikidata Infobox for disambig pages. Thanks. Mike Peel (talk) 09:55, 10 August 2020 (UTC)

I'm more with Mike Peel here. I find it useful for users to see that there is a corresponding Wikidata item, linking it to articles in various languages. I very often look at corresponding articles in various languages to better understand differences and commonalities of the various meanings of a term in those languages. And - even if you see little value for yourself, does it do any harm to have those boxes? -- H005 14:04, 10 August 2020 (UTC)

The interlanguage links appear in the sidebar even without the infobox. (The infobox provides interlanguage links only when the category page is connected to a category item (i.e. the item has instance of (P31): Wikimedia category (Q4167836)), which I can hardly imagine to happen in case of disambiguation categories.) I don’t find it harmful, though, apart from seeing it as a plain waste of resources (both bot/server and human resources—the unnecessary page history/watchlist entries need to be scanned and understood.) —Tacsipacsi (talk) 20:17, 10 August 2020 (UTC)

@Tacsipacsi, Jklamo, Richard Arthur Norton (1958- ), and H005: I'm closing this as I don't see a consensus either way, and it's been several years now. Perhaps it needs a discussion at a wider venue at some point. Thanks. Mike Peel (talk) 18:03, 31 October 2022 (UTC)

This section is resolved and can be archived. If you disagree, replace this template with your comment. Mike Peel (talk) 18:03, 31 October 2022 (UTC)

IMO for ships

Can we bring {{IMO}} and {{IMOcat}} into this template, using IMO ship number (P458)? The latter is verbose, but needlessly so IMO. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 23:57, 5 August 2020 (UTC)

Why would IMOcat help? It's just a pointer to an IMO category, which can be done with a simple link. Carl Lindberg (talk) 03:44, 6 August 2020 (UTC)

@Pigsonthewing and Clindberg: I'm not sure how best to integrate this. If you look at Category:Hanseatic (ship, 1930), the link to the IMO category is under 'Category combines topics', although perhaps it's not too obvious. But does it really need to be made very obvious using IMOcat? Also, the P458 link (and other authority control) isn't currently shown in these 'category combines' categories for performance reasons. Thanks. Mike Peel (talk) 18:42, 7 August 2020 (UTC)

I don't see how integrating these would help either -- I do see the links to the IMO cat, and that seems enough to me. Well it might be nice to have the IMO number displayed -- it currently uses the Wikidata title for its IMO entry, which is usually an arbitrary one of the ship names over its history, and may be a little confusing given there is likely another Commons category with that other name but that's not where the link goes. IMOcat is fine standalone, I think. And I would definitely want to fix the performance before expanding the template's scope :-) Carl Lindberg (talk) 05:01, 8 August 2020 (UTC)

@Pigsonthewing and Clindberg: Sorry, but I don't think this will happen any time soon, and things seem to be working OK as they are. Thanks. Mike Peel (talk) 18:05, 31 October 2022 (UTC)

This section is resolved and can be archived. If you disagree, replace this template with your comment. Mike Peel (talk) 18:05, 31 October 2022 (UTC)

Non-terrestrial coordinates

Coordinates on Category:Gale Crater, which is about a feature on Mars, are not displaying correctly; compare with those on Gale (Q622221). Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 18:36, 27 August 2020 (UTC)

@RexxS: I've been trying to find the cause of this, see my recent edits in Template:Wikidata Infobox/core/sandbox, but it's weird. The problem is in the code

{{#invoke:Coordinates | GeoHack_link | lat={{#invoke:WikidataIB | getPreferredValue | P625 | qid={{{qid}}} | fwd={{{fwd|ALL}}} | maxvals=1 | osd=no | noicon=yes | format=decimal | show=lat}} | lon={{#invoke:WikidataIB | getPreferredValue | P625 | qid={{{qid}}} | fwd={{{fwd|ALL}}} | maxvals=1 | osd=no | noicon=yes | format=decimal | show=long}}|globe={{#invoke:WikidataIB|getLabel|{{#invoke:WikidataIB |getGlobe|{{{qid}}}}}}}}}

. However, if you substitute the qid for Q622221, then it works fine: 5° 22′ 12″ S, 137° 48′ 36″ E. The problem seems to be with the WikidataIB calls, which aren't returning values that are passed to Coordinates. Can you see what's going on? The only thing I can think of it some sort of whitespace bug? Thanks. Mike Peel (talk) 17:01, 3 September 2020 (UTC)

Before I do any more detective work, can you confirm that replacing each {{{qid}}} with {{{qid|}}} does not fix the problem?

These are the results of the calls:

>{{#invoke:WikidataIB | getPreferredValue | P625 | qid={{{qid|Q622221}}} | fwd={{{fwd|ALL}}} | maxvals=1 | osd=no | noicon=yes | format=decimal | show=lat}}< → >-5.37<
>{{#invoke:WikidataIB | getPreferredValue | P625 | qid={{{qid|Q622221}}} | fwd={{{fwd|ALL}}} | maxvals=1 | osd=no | noicon=yes | format=decimal | show=long}}< → >137.81<
>{{#invoke:WikidataIB|getLabel|{{#invoke:WikidataIB |getGlobe|{{{qid|Q622221}}}}}}}< → >Mars<

All of those look right to me. But the code {{{qid}}} will be set to {{{qid}}} literally if the parameter is not supplied, whereas it needs to be set to blank for WikidataIB to use the qid associated with the page. --RexxS (talk) 17:22, 3 September 2020 (UTC)

Forgot to ping Mike Peel. --RexxS (talk) 17:23, 3 September 2020 (UTC)

@RexxS: Yes, I removed the | in {{{qid|}}} as part of my debugging attempt, it didn't make a difference. The starting code was

{{#invoke:Coordinates | GeoHack_link | lat={{#invoke:WikidataIB | getPreferredValue | P625 | qid={{{qid|}}} | fwd={{{fwd|ALL}}} | maxvals=1 | osd=no | noicon=yes | format=decimal | show=lat}} | lon={{#invoke:WikidataIB | getPreferredValue | P625 | qid={{{qid|}}} | fwd={{{fwd|ALL}}} | maxvals=1 | osd=no | noicon=yes | format=decimal | show=long}}|globe={{#invoke:WikidataIB|getLabel|{{#invoke:WikidataIB |getGlobe|{{{qid|}}}}}}}}}

. Thanks. Mike Peel (talk) 17:28, 3 September 2020 (UTC)

GeoHack links to Mars coordinates are working now, see Gale Crater. --LennardHofmann (talk) 18:54, 21 July 2022 (UTC)

@LennardHofmann: Thank you. However the infobox still has "wikimap", "WikiShootMe" and "OpenStreetMap" links, which should be suppressed for non-terrestrial globes. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 15:02, 5 August 2022 (UTC)

@Pigsonthewing: Now fixed in {{Wikidata Infobox/sandbox}}. I also suppressed the Locator tool, even though Mars categories might contain a few images taken on Earth. --LennardHofmann (talk) 06:28, 6 August 2022 (UTC)

@LennardHofmann: Works well. Thank you. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 10:38, 6 August 2022 (UTC)

Coordinates for other planets

@ArthurPSmith: pointed out at d:Wikidata:Property proposal/planetary coordinates that the coordinates for Category:Olympus Mons don't display properly - this need investigation. Thanks. Mike Peel (talk) 20:16, 16 October 2020 (UTC)

@ArthurPSmith and Mike Peel: Note the above. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 21:57, 30 October 2020 (UTC)

Category:Olympus Mons uses P10628 (P10628) instead of coordinate location (P625) now so no coordinates are displayed. LennardHofmann (talk) 18:54, 21 July 2022 (UTC)

@Pigsonthewing, ArthurPSmith, and LennardHofmann: This seems to be working fine now, see Category:Olympus Mons. This is despite P10628 (P10628) being deprecated. So I think this is sorted and can be closed now. Thanks. Mike Peel (talk) 18:13, 31 October 2022 (UTC)

This section is resolved and can be archived. If you disagree, replace this template with your comment. Mike Peel (talk) 18:13, 31 October 2022 (UTC)

Death date before

The death date on Category:Dnyaneshwar Atmaram Turkhud is showing as "death: Unknown (before 1944)", whereas it is actually recorded on Wikidata as "unknown value; latest date: January 1944". Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 12:46, 14 September 2020 (UTC)

More recently, on Category:Kyle Heller, his DoB of "1980s; earliest date: 1980; latest date: 1981" in Wikidata is shown on Common as "1980s (before 1981, after 1980)". @Mike Peel: . Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 17:50, 6 October 2020 (UTC)

Switch around "before" and "after" for inception dates

Some Wikidata items, like Mictlantecuhtli (Q109928629) have an inception date with 'earliest date' and 'latest date' qualifiers. Now these are rendered in the reversed order ("before 1502, after 1430"). I think it would make more sense to reverse that order, so: "after 1430, before 1502". See Category:Mictlantecuhtli, Templo Mayor for an example. Husky ^{(talk to me)} 22:55, 7 December 2021 (UTC)

See also Death date before, above. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 13:47, 8 December 2021 (UTC)

@LennardHofmann: Are the above issues on your radar? Are you able to devote any of your energies to fixing them, please? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 15:04, 5 August 2022 (UTC)

@Pigsonthewing: The date formatting must be internationalized and is done using Module:WikidataIB and {{Complex date}}, both of which are quite complex. The qualifier "latest date: 1502" could easily be rendered as "by 1502", but there is no "1430 or later" notation in {{Complex date}} to render "earliest date: 1430" appropriately (pinging Jarekt in case he knows more).

If both qualifiers are present, WikidataIB seems to show them in an unpredictable order because it loops over the qualifiers with pairs(). It is possible to render "earliest date: 1980; latest date: 1981" as "between 1980 and 1981", but that would require some effort and the addition of more complexity to WikidataIB. I will add that to the bottom of my todo list. LennardHofmann (talk) 08:56, 6 August 2022 (UTC)

@LennardHofmann and Pigsonthewing: If {{Wikidata Infobox}} is calling Module:WikidataIB to call Module:Complex date that is probably not the best way. Module:Wikidata date was written to handle Wikidata dates and it is being maintained and used by Module:Artwork and others. For example {{#invoke:Wikidata date|date|item=Q109928629|property=P571|lang=en}} gives "between 1430 and 1502". That is better way to handle Wikidata dates. --Jarekt (talk) 03:16, 7 August 2022 (UTC)

@Pigsonthewing, Husky, LennardHofmann, and Jarekt: I'm marking this as not done, sorry. It doesn't seem easy to fix, particularly since @RexxS: isn't around. Jarekt, if you want to have a look through the code and propose a version that uses Module:Wikidata date, please feel free to do so. Thanks. Mike Peel (talk) 18:18, 31 October 2022 (UTC)

This section is resolved and can be archived. If you disagree, replace this template with your comment. Mike Peel (talk) 18:18, 31 October 2022 (UTC)

Display of the language under the audio files

It would be helpful if the language would be displayed under the audio file, especially if there are several audio files in different languages. For an example see Category:Moritz (given name). --HarryNº2 (talk) 12:27, 8 October 2020 (UTC)

Is it a problem to mention the language under the audio file in the infobox? --HarryNº2 (talk) 19:10, 29 October 2020 (UTC)

@HarryNº2: You should only see one audio file, selected based on your language settings - e.g., I don't see any audio file there as I'm browsing in English, and there are only audio files in German (Q188) and Austrian German (Q306626). Which language do you have set? @RexxS: possibly this is a bug in getValueByLang. Thanks. Mike Peel (talk) 16:26, 5 December 2020 (UTC)

@Mike Peel: The language setting is mainly set to German. Nevertheless, it would be helpful if the language of the audio file were displayed, especially in cases where three audio files such as German, Austrian German and Swiss German are available on Wikidata. --HarryNº2 (talk) 17:09, 5 December 2020 (UTC)

@HarryNº2: Just to check, you only see one audio file here, correct? It should be the German version if it's working right, if you're browsing in German. If we added the language of the audio file, it should only display the language that you're browsing in, which I don't think it too useful. Thanks. Mike Peel (talk) 17:22, 5 December 2020 (UTC)

@Mike Peel: If I have set German, only the German audio file is also displayed. However, you cannot set Austrian German or Swiss German at all. The same is the case with English, British English, and Canadian English. --HarryNº2 (talk) 17:35, 5 December 2020 (UTC)

@HarryNº2: Are you sure? I can see those options in the language selector (top of the screen, to the left of your username). Thanks. Mike Peel (talk) 18:00, 5 December 2020 (UTC)

(Edit conflict) @Mike Peel and HarryNº2: I can see the point of the question. If I browse Category:Moritz (given name) with my language set to Deutsch, I get a male voice pronouncing Moritz (File:De-Moritz.ogg). If I browse set to Österreichisches Deutsch, I get a female voice (File:De-at Moritz.ogg) with a noticeably different accent (Berlin vs Vienna). That's working as intended. If I browse set to Schweizer Hochdeutsch or Alemannisch, I don't get an audio file. That's because I deliberately didn't implement language fallback in getValueByLang as it was specifically designed to only return the property value (e.g. filename) that has a direct match with the given language. At present, the language of the file you see is always the language you have set, so there should be no need for repeating that under the audio file.

Nevertheless, if you want to implement language fallback, then we're going to need another function to achieve that (another editor re-wrote getValueByLang and getValueByQual to use common code, and that prevents a simple implementation of language fallback). If we go down that route, then the German variants without an audio file would see the German version, and it would make sense to add the language code for the file underneath, which would require more coding to perhaps add a hidden comment containing the language code used to the returned filename, which could then be stripped off in the template code and used separately. That seems like a fair bit of work to achieve language fallback and I have to ask how much of a priority it is? --RexxS (talk) 18:04, 5 December 2020 (UTC)

@HarryNº2: Fallback languages are now respected. The language code could be displayed in parentheses after the property label if necessary. Other suggestions where to place the language code are welcome! LennardHofmann (talk) 18:54, 21 July 2022 (UTC)

@HarryNº2 and LennardHofmann: This seems to have been resolved now. Thanks. Mike Peel (talk) 18:19, 31 October 2022 (UTC)

This section is resolved and can be archived. If you disagree, replace this template with your comment. Mike Peel (talk) 18:19, 31 October 2022 (UTC)

YYYY (YYYY-YYYY)

Category:Scribner's Magazine/Volume 47 is one of several volumes of journal which were published 2/yr for many years.

The infobox is displaying only the year, which looks kind of funny. In the example, it is 1910 (1910-1910) where a display of 1910 (July-Dec.) is more accurate and interesting.

Thanks for your attention!--RaboKarbakian (talk) 13:00, 6 April 2021 (UTC)

@RaboKarbakian: Sorry, this won't be done. This is also an issue with complex date, and there's no easy way to resolve this. Thanks. Mike Peel (talk) 18:23, 31 October 2022 (UTC)

This section is resolved and can be archived. If you disagree, replace this template with your comment. Mike Peel (talk) 18:23, 31 October 2022 (UTC)

follows and followed by as qualifiers

I have been working with serialized fiction, (novels preesented over several issues and even volumes of a magazine) each new "has part" (P567) would get its own follows (P155) and followed by (P156). Many of our greatest and most well known novels began life this way, and many other lesser known novels....

Infobox displays these P155, 156! This was a happy surprise for me! Maybe they can be migrated to the usual location in the box?

Display example at Category:Sleepy Hollow (1839, Irving), Category:Vincent Eden (1839, Deacon) and now that I look at it, maybe the qualifiers just need to be labeled or not shown at all.

If (when is more accurate) the journal is available at any wikisource, it would be also nice if followed by and follows could show that link if the category/gallery is not here.

Even without these improvements/differences, Infobox is sure beautiful.--RaboKarbakian (talk) 13:27, 27 April 2021 (UTC)

@RaboKarbakian: The solution here is to move them into properties rather than qualifiers, then they will display better. Otherwise, this is the best we can do already. Thanks. Mike Peel (talk) 18:26, 31 October 2022 (UTC)

This section is resolved and can be archived. If you disagree, replace this template with your comment. Mike Peel (talk) 18:26, 31 October 2022 (UTC)

Add "Births in" category?

Hi,
I did not find a similar existing question. Is it possible to add "Births in" category automatically based on place of birth (P19) property. Entering the property, the dedicated Commons category can be retrieved using category for people born here (P1464) then Commons category (P373) or declared here as Commons site. I don't know if the path is too complicated to be integrated in this template.
Jgui (talk) 14:50, 1 July 2021 (UTC)

@Jgui: If I recall correctly, @Harmonia Amanda: was auto-adding categories like this at one point, not sure if that's still happening. We talked about how to implement it automatically via the infobox, but it wasn't clear - since the granularity on Wikidata may be higher than the existing category structure here. It sounds like a good thing to implement, I'm just not sure how it would work in practice. Thanks. Mike Peel (talk) 18:43, 20 August 2021 (UTC)

I've not done this for a while, but it may be time to do it again if a backlog built up. There are too many granularity problems between Commons and Wikidata right now for it to do it automatically I think, not even speaking of the disambiguation problems (Wikidata has a lot of items sharing labels, but Commons can't do that for categories, and setting up a consistent disambiguation system that could be automated… would be a lot of work. I basically worked from Commons existing categories, run the corresponding SPARQL query for people born there, and then added the category if it was missing using QuickCategories. It should not be hard to replicate. --Harmonia Amanda (talk) 03:42, 30 August 2021 (UTC)

@Jgui: This is not done per @Harmonia Amanda: . Thanks. Mike Peel (talk) 18:27, 31 October 2022 (UTC)

This section is resolved and can be archived. If you disagree, replace this template with your comment. Mike Peel (talk) 18:27, 31 October 2022 (UTC)

Time problem

Please see the infobox at Paleozoic, where the ages are given in millennia instead of millions of years, therefore a thousand-fold too young. The WD page whence the figures purport to come has millions of years, so I can only guess some sort of wrong conversion or translation is occurring when the infobox is generated. Please fix.—Odysseus1479 (talk) 22:45, 6 October 2021 (UTC)

The infobox at Cenozoic is also wrong; at Mesozoic the correct starting epoch is shown (albeit weirdly, in millennia) but the ending is wrong like the others mentioned.—Odysseus1479 (talk) 08:18, 11 October 2021 (UTC)

@Odysseus1479: I think you need to raise this at Module talk:Complex date. Thanks. Mike Peel (talk) 18:27, 31 October 2022 (UTC)

This section is resolved and can be archived. If you disagree, replace this template with your comment. Mike Peel (talk) 18:27, 31 October 2022 (UTC)

Cultivar template

Can we merge {{Cultivar}} (see for example Category:Chrysanthemum 'Dance') into this template? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 12:01, 12 November 2021 (UTC)

Sorry @Pigsonthewing: nice suggestion, but this isn't likely to happen any time soon, particularly since the data used in that template seems to be held locally and would need to be migrated to Wikidata, which would be a big job. Thanks. Mike Peel (talk) 18:31, 31 October 2022 (UTC)

This section is resolved and can be archived. If you disagree, replace this template with your comment. Mike Peel (talk) 18:31, 31 October 2022 (UTC)

Template:Date navbox

{{Date navbox}} would be another merge candidate. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 18:17, 21 November 2021 (UTC)

Sorry @Pigsonthewing: nice suggestion, but this isn't likely to happen any time soon since the data's not on Wikidata. But perhaps the work we've been doing over the last year has moved a bit towards this being possible? Thanks. Mike Peel (talk) 18:32, 31 October 2022 (UTC)

This section is resolved and can be archived. If you disagree, replace this template with your comment. Mike Peel (talk) 18:32, 31 October 2022 (UTC)

Exact dates not displayed

See Category:Loggia am Stadthaus. For the topping out the exact date (which is stated on Wikidata) should be displayed, not only the year. How can this be changed?--2003:E5:173E:7248:A0FC:C31D:B54E:6DFC 18:47, 11 March 2022 (UTC)

In many cases it is not desirable to show exact dates in qualifiers. LennardHofmann (talk) 18:54, 21 July 2022 (UTC)

This section is resolved and can be archived. If you disagree, replace this template with your comment. Mike Peel (talk) 18:45, 31 October 2022 (UTC)

Near someplace

Hi, I see that the template put a place located with d:P:P276 always as in the says place (like for Category:Pete Kitchen Ranch, even if the building is located in proxiomity of the town, like it's indicated in d:Q20714854#P276. Can you indicate in brackets the sourcing circumstances (d:P:P1480) when a location is entered with P276? Fralambert (talk) 17:33, 27 March 2022 (UTC)

@Fralambert: Sorry, the location code is quite complex, and this change is non-trivial. It also seems to be an edge case - it's normally better to simply use located in the administrative territorial entity (P131) instead. So, closing as not done. Thanks. Mike Peel (talk) 18:51, 31 October 2022 (UTC)

This section is resolved and can be archived. If you disagree, replace this template with your comment. Mike Peel (talk) 18:51, 31 October 2022 (UTC)

Omit "hide/show" for authority control in common case

I think the usability and design of the infobox would be improved if the "Authority control" section rendered without being collapsible, for the common case where there is only a few entries, especially when there is only the one default entry for Wikidata itself.

Note, I'm not suggesting to remove the section from any situation, rather to remove the collapsible buttons in some cases.

I tried doing this myself, but couldn't find the right place to make this change. It seems non-trivial due to the nested use of Wikidata queries. As I understand it, we'll need a way within this structure to get a boolean result, and/or move some of the layout into a Lua module in order to more easily re-use and aggregate the same information multiple times. Krinkle (talk) 14:37, 4 May 2022 (UTC)

@Krinkle: Sorry, but I suspect this would be controversial, so it's best not to do this. The link is quite compact anyway, so it doesn't affect the layout too much. Thanks. Mike Peel (talk) 18:53, 31 October 2022 (UTC)

This section is resolved and can be archived. If you disagree, replace this template with your comment. Mike Peel (talk) 18:53, 31 October 2022 (UTC)

earliest end date (P8554) not displayed

See the infobox for Bismarckstraße 22 (Q112971428) in Category:Bismarckstraße 22 (Bonn). The exact start time of owned by (P127) is known, but not the exact end time, so I used earliest end date (P8554) instead. I guess the earliest end date should be displayed there as after 1926. Interestingly, for occupant (P466) the opposite property latest start date (P8555) is displayed by the infobox but it should rather be displayed as before 1932 and without the comma.--84.176.239.117 15:27, 8 July 2022 (UTC)

Sorry, but this needs work at Module:Complex date, not done here. Thanks. Mike Peel (talk) 18:55, 31 October 2022 (UTC)

This section is resolved and can be archived. If you disagree, replace this template with your comment. Mike Peel (talk) 18:55, 31 October 2022 (UTC)

somevalue

A standard idiom on Wikidata is to give a statement the value somevalue with qualifier object named as (P1932) = a text string for the value, if the value of a statement is known but has no wikidata item.

For example, d:Q1494059#P193 for the builder of the Garden Bridge at Inverary.

When there is a object named as (P1932) qualifier (cf Category:Garden Bridge, Inveraray), it would be therefore good to suppress printing of 'Unknown' in this case, and just give the value of the string.

Hoping this may be possible, thanks, Jheald (talk) 19:44, 12 July 2022 (UTC)

I am not aware of this convention and think it might be worth further discussion. I can see the potential benefits, but it is not labelled as somevalue but "unknown" value. Saying a value is unknown and then going on to specify the value seems counterintuitive. — Martin (MSGJ · talk) 11:34, 15 July 2022 (UTC)

@MSGJ: d:Help:Statements#Unknown_or_no_values : "Unknown value may also mean the value is actually a known object, but there's currently no Wikidata item about the object."

In the more technical documentation, eg the spec for wikibase, or the docs for WDQS and the RDF dumps (as here or here), the status is referred to as somevalue.

Here are some examples of where the idiom has been cited in property proposal discussions 1, 2, 3. More could be added.

And here's a query https://w.wiki/5TF6 to find the most common properties using the mechanism, with examples, based on a 4% sample of object named as (P1932) qualifiers (so actual number of uses for each property will be 25x higher).

Hope this helps. Jheald (talk) 22:15, 15 July 2022 (UTC)

See also eg how the 'creator' field is being handled in the structured data tab of geograph files like geograph files like this one. Jheald (talk) 16:14, 16 July 2022 (UTC)

@Jheald and MSGJ: That looks like bad practice on Wikidata to me, the natural thing to do is to create a new item for the person, which then gets rendered properly here. It's not an unknown value if the value is actually known. So this won't be changed here, sorry. Thanks. Mike Peel (talk) 18:57, 31 October 2022 (UTC)

This section is resolved and can be archived. If you disagree, replace this template with your comment. Mike Peel (talk) 18:57, 31 October 2022 (UTC)

More properties

route map (P15) would be a useful addition to the fallback chain for displaying a map of the item in the infobox
significant person (P3342) is a useful connecting property

-- Jheald (talk) 09:17, 16 July 2022 (UTC)

contains the administrative territorial entity (P150) is missing in the infobox, while analogous located in the administrative territorial entity (P131) and has part(s) (P527) are included. --ŠJů (talk) 18:25, 16 July 2022 (UTC)
- significant person (P3342) does seem pretty useful for navigation, even though I might have voted against its creation in favor of more specific properties.
- I'm not sure about contains the administrative territorial entity (P150). Out of all items with this property, 44 % have more than 10 values for it, that's pretty excessive. But if people find it useful, I won't object. LennardHofmann (talk) 12:01, 18 July 2022 (UTC)

@Jheald and ŠJů: route map (P15) is already included, significant person (P3342) and contains the administrative territorial entity (P150) seem to be too general to be useful, so they won't be added. Thanks. Mike Peel (talk) 19:00, 31 October 2022 (UTC)

This section is resolved and can be archived. If you disagree, replace this template with your comment. Mike Peel (talk) 19:00, 31 October 2022 (UTC)

has part(s) (P527) with higher number of values doesn't display links?

I noticed a non-standard behavior of has part(s) (P527). While at the page Category:Road III/1489 (Czech Republic), all 3 values are displayed correctly as links, at the page Category:Road II/473 (Czech Republic) all 10 values are displayed as a pure label text, although 3 of them should by displayed as links. This makes it impossible to recognize which of the streets already have their own categories. I believe the previous version of the infobox worked normally. ŠJů (talk) 21:16, 22 July 2022 (UTC)

@ŠJů: Collapsed values are intentionally not linked because getCommonsLink can be very slow for certain Wikidata items, but there is no way to know beforehand how slow it will be. If the missing links are really annoying you, we could raise the collapse limit for has part(s) (P527), which is currently set to 5. We could also wrap all values inside <span data-qid="Q43567652"> so that people can write user scripts that add links after the page has been loaded. LennardHofmann (talk) 09:39, 23 July 2022 (UTC)

@LennardHofmann: Anyway, now there has been a substantial deterioration of the function of the infobox compared to the previous version. Rather, I would expect some modification so that even an entry without an existing link to the Commons category makes sense – i.e. to include a tooltip with a description and/or a link to the Wikidata item. --ŠJů (talk) 12:51, 23 July 2022 (UTC)

P2789 - connects with

Today I see that connects with (P2789) in some cases not link to the target commons categories. For example c:Category:Winterbergstraße, Dresden. Another street with not so many connections to other streets c:Category:Am Winkelsprung, Dresden work very well. Is the number of connections a problem? Is there a new limit. I think some months before it work at any of the 3000 streets in Dresden. Can we fix this? It is extremely helpful for the navigation in the commons categories. --sk (talk) 13:37, 3 August 2022 (UTC)

@Stefan Kühn: See above. Since you are the second person requesting this, I added exceptions for connects with (P2789) and has part(s) (P527) so that values for these properties are always linked (if they have a Commons category). This change was just made live together with the rewrite of authority control and helper links. LennardHofmann (talk) 14:30, 3 August 2022 (UTC)

@LennardHofmann: Many thanks! --sk (talk) 17:04, 4 August 2022 (UTC)

This section is resolved and can be archived. If you disagree, replace this template with your comment. Mike Peel (talk) 19:07, 31 October 2022 (UTC)

Maps for roads and other extended features

When Kartographer is working again, this map should show a motorway in England in addition to the one in Germany.

The infobox on en-wiki for en:Bundesautobahn 1 appears to contain the route of the road, drawn from OSM data via en:Template:Maplink. Could Category:Bundesautobahn_1 show this too?

(Though it actually seems to be incomplete, compared to d:Q9006#P15). But it would be good to be able to draw on more extended OSM shapes, eg for rivers too.

In the meantime, as suggested above, route map (P15) could be a useful addition. Jheald (talk) 08:02, 25 July 2022 (UTC)

@Jheald: {{Wikidata Infobox/sandbox}} now shows roads (and other geolines) on the map. On Wikipedia you have to opt-in into geolines with {{maplink|type=line}} but the Wikidata Infobox should work without user input, so I made it use geolines instead of geoshapes (polygons) if the Wikidata item has one of the following properties: length (P2043), transport network (P16), tributary (P974), mountain range (P4552), crosses (P177), track gauge (P1064), route map (P15), traffic sign (P14), type of electrification (P930), Wikimedia route diagram template (P3858).

As for route map (P15) … this has already been added, see Category:Bundesautobahn_1 ;) --LennardHofmann (talk) 12:25, 26 July 2022 (UTC)

Archived, but restored. Jheald (talk) 16:23, 12 August 2022 (UTC)

@LennardHofmann: Pulling this back from the archive. Thanks for adding route map (P15) support -- I will now be sure to check the radio buttons more closely in future! Thanks!!

On linear features in the main maps though, I'm not seeing it. Consider eg Category:M1 motorway (England). The infobox includes a link to OSM, which shows the motorway as an extended feature [7]. But the Commons infobox just shows a point location. Is there something I have missed? Thanks, Jheald (talk) 16:23, 12 August 2022 (UTC)

@Jheald: This is a bug in Kartographer. I was about to write a bug report, but then Category:Bundesautobahn 1 started working again. Let's hope that Category:M1 motorway (England) will also start showing the geoline soon. LennardHofmann (talk) 15:35, 13 August 2022 (UTC)

@LennardHofmann: Very pleasing. That's really good now. Thank you so much.

Though I don't suppose there would be any chance of making rivers and other types of watercourse (Q355304) come up in blue, would there? eg c:Category:River Tay. That would be amazing. Thank you again so much for all that you are doing, Jheald (talk) 16:00, 13 August 2022 (UTC)

This section is resolved and can be archived. If you disagree, replace this template with your comment. Mike Peel (talk) 19:09, 31 October 2022 (UTC)

end time / end cause / replaced by / replaces

Normally the solution of taking a qualifier value and just adding it in brackets, irrespective of the context, works really well.

But I wonder if more special treatment may be useful where we have eg end time (P582), end cause (P1534), and replaced by (P1366) all together, as at eg c:Category:Sheilhill Old Bridge, where

carries: unclassified road (Shielhill Bridge, bypassing, –1973)

is a bit opaque to unpack.

It would (necessarily) still be very terse, but I wonder whether usefully we might be able to make it a bit more intuitive by looking out these particular qualifiers (which can turn up in other circumstances too, as well as just infrastructure), and when they are present to perhaps re-order the output to something like

carries: unclassified road (–1973; bypassing; → Shielhill Bridge)

with the extra → to give a hint that the final item has the context of a replacement.

It might also be nice to be able to give some similar context hint for a value that an item replaces (P1365); but I can't immediately see a shorthand for that; unless perhaps ↖ might do, presumably then paired with ↗ (directions might need to be reversed for RTL scripts).

Do people think that might be useful for these particular qualifiers? Jheald (talk) 20:03, 12 August 2022 (UTC)

Another qualifier that might benefit from being moved to after end time (P582) could be latest date (P1326), if both are present - eg c:Category:Oban Times Building in the line for Occupant = Oban Times. Thx! Jheald (talk) 16:07, 13 August 2022 (UTC)

For what it's worth, here https://w.wiki/5ZyT are the qualifiers that most commonly co-occur with end time (P582). Nothing else particularly jumps out to me as needing special care.

Curious though that c:Category:Sheilhill Old Bridge does show values of end cause (P1534) and replaced by (P1366) qualifiers, whereas seeming they are suppressed for people, such as in the 'postion held' line on c:Category:Andrea_Dandolo. But I guess all the different qualifiers on some of those position held (P39) statements can get pretty baroque, so I can see why suppressing them may make sense. Jheald (talk) 20:50, 13 August 2022 (UTC)

Another case that could benefit from review could be end time (P582) = somevalue with qualifiers earliest end date (P8554) and/or latest date (P1326). This can all turn into a bit of a jumble at the moment. (Related but slightly different to the use of somevalue discussed at #somevalue above, though the cases should maybe be taken together).

Similarly start time (P580) = somevalue with qualifiers earliest date (P1319) and/or latest start date (P8555), as in the dates given at Category:St Mary's House, Bramber for when it started being a "house museum". Jheald (talk) 21:07, 20 August 2022 (UTC)

@Jheald: Thanks for the suggestions, but sorry, they are too complex to easily implement. Also see the above discussions about complex date. So I'm closing this as not done, sorry. Thanks. Mike Peel (talk) 19:10, 31 October 2022 (UTC)

This section is resolved and can be archived. If you disagree, replace this template with your comment. Mike Peel (talk) 19:10, 31 October 2022 (UTC)

P1382 vs. P527

@LennardHofmann: partially coincident with (P1382) and has part(s) (P527) are similar and analogous properties, but have different behaviour in the infobox.

partially coincident with (P1382) displays up to 10 items unwrapped and with links (if exist), more than 10 (up to 20?) items wrapped and without links.
has part(s) (P527) displays up to 5 items unwrapped, 6–20 items wrapped, but allways with links (if exist)

IMHO the behaviour should be unified, partially coincident with (P1382) should have identical behavior as the has part(s) (P527).

Btw., items without Commons category links should display Wikidata item links or at least description tooltip because the pure label is often very unspecific. This applies to all properties which have items as their values. I imagine it as an inconspicuous tooltip and link, perhaps in this form:

Ústecká
Teplická
Pivovarská

See Category:Road I/13 (Czech Republic) as an example of an item with more partially coincident with (P1382) and has part(s) (P527) item values. --ŠJů (talk) 23:38, 17 August 2022 (UTC)

I unified the behavior of partially coincident with (P1382) and has part(s) (P527). What do others think about the second wish? LennardHofmann (talk) 08:28, 27 August 2022 (UTC)

This section is resolved and can be archived. If you disagree, replace this template with your comment. Mike Peel (talk) 19:11, 31 October 2022 (UTC)

Language dependent circa handling

It was reported on the local Czech village pump, that the handling of circa with dates is different depending on (UI) language set. While with English circa is displayed as "c." with tooltip before date value, with Czech (čeština) it is displayed as cca before date value (correct), but also at the same time after the date value in brackets (unnecessary duplication). The same way it looks with Polish or Slovak language set. Jklamo (talk) 08:43, 26 August 2022 (UTC)

@Jklamo: Do you have an example page where this happens? LennardHofmann (talk) 09:10, 26 August 2022 (UTC)

For example Category:Janet Young. Jklamo (talk) 09:41, 26 August 2022 (UTC)

@Jklamo: The bracketed "circa" link is removed in a hacky way, see Special:Diff/685133506. WikidataIB's date formatting really needs to be rewritten (see all the date issues reported on this talk page), but the thought of doing that doesn't excite me and WikidataIB's original author isn't active here anymore. LennardHofmann (talk) 14:08, 26 August 2022 (UTC)

Not done, this would have needed @RexxS: . Thanks. Mike Peel (talk) 19:11, 31 October 2022 (UTC)

This section is resolved and can be archived. If you disagree, replace this template with your comment. Mike Peel (talk) 19:11, 31 October 2022 (UTC)

family name has to use a different item than disambiguation page

It's nice that the Infobox now links to a Wikimedia disambiguation page, but Wikidata:Q27924673 linking is superfluous, see e.g. Category:Smith (surname). HarryNº2 (talk) 02:28, 27 August 2022 (UTC)

Unfortunately, WikidataIB only provides means to toggle linking as a whole, so unlinking "(family name has to use a different item than disambiguation page)" is not possible, but I could hide it if you want. LennardHofmann (talk) 06:39, 27 August 2022 (UTC)

Maybe the values for different from (P1889) shouldn't be formatted using WikidataIB. Then I could replace "family name has to use a different item than disambiguation page" with the shorter label "Wikimedia disambiguation page" from Q4167410 or the icon

. --LennardHofmann (talk) 06:58, 27 August 2022 (UTC)

The text version of Wikimedia disambiguation page (Q4167410) would be better than a SVG version, because not everyone can do something with a picture. HarryNº2 (talk) 10:54, 27 August 2022 (UTC)

“not everyone can do something with a picture“: That's what alt text is for. You can see how it looks by replacing {{Wikidata Infobox}} with {{Wikidata Infobox/sandbox}}. LennardHofmann (talk) 12:23, 27 August 2022 (UTC)

@LennardHofmann: Alt text is really tricky, see d:Wikidata:Property proposal/alt text and links therein. Thanks. Mike Peel (talk) 20:39, 30 August 2022 (UTC)

This section is resolved and can be archived. If you disagree, replace this template with your comment. Mike Peel (talk) 19:12, 31 October 2022 (UTC)

Autocat no longer working properly

It seems that when the infobox adds items to Category:National Register of Historic Places with known IDs (and possibly the similar autocats), it's no longer adding the ID as a sortkey. This is causing scripts that check for the ID to miss those categories; w:User:TheCatalyst31/AddCommonsCatLinks.js hasn't been catching new categories with IDs on Wikidata for a bit now. TheCatalyst31 (talk) 20:02, 10 September 2022 (UTC)

@TheCatalyst31: The infobox is still adding the sortkey, e.g. on Category:Husung Hardware‎ it produces following wikitext: [[Category:National Register of Historic Places with known IDs|00000003]]. However, it no longer adds a space in front of the sortkey like {{NRHP}} does. This is because the infobox now treats all "with known IDs" categories equal, see Module:Wikidata Infobox and search for "autocats_by_id". Could this be the problem? LennardHofmann (talk) 07:57, 11 September 2022 (UTC)

@TheCatalyst31 and LennardHofmann: removal of the space breaks it. Every once in a while someone, who isn't aware of how the sorting logic works, breaks this. this should fix it.

The missing {{Image template notice|Wikidata Infobox}} template should be added to the other categories like Category:National Register of Historic Places with known IDs to make clear what template is adding it.

The list at Module:Wikidata_Infobox#L-798 seems to be incomplete if I compare it to User:ErfgoedBot/Depicts monuments.js (and that one is sure not complete) so more can be added. Multichill (talk) 09:31, 11 September 2022 (UTC)

@Multichill and LennardHofmann: Can you sync the changes over to the sandbox, please, otherwise we'll lose them in the next update? (Also, better to do changes like these is the sandbox so they can be batch-deployed...) Thanks. Mike Peel (talk) 13:45, 11 September 2022 (UTC)

If we add the categories from User:ErfgoedBot/Depicts monuments.js as Multichill suggested, should pages with Bavarian monument authority ID (P4244) still be categorized under Uses of Wikidata Infobox providing Bavaria ids, or should we embrace Cultural heritage monuments in Bavaria with known IDs? --LennardHofmann (talk) 14:51, 11 September 2022 (UTC)

@Multichill: It looks like the script is working again. Good catch! TheCatalyst31 (talk) 17:06, 11 September 2022 (UTC)

This section is resolved and can be archived. If you disagree, replace this template with your comment. Mike Peel (talk) 19:12, 31 October 2022 (UTC)

require('strict')

{{Edit protected}} As per the new lua feature mentioned at m:Tech/News/2022/42, could require('Module:No globals') be replaced with require('strict') in Module:Wikidata Infobox -- WOSlinker (talk) 17:21, 25 October 2022 (UTC)

@WOSlinker: Since this template is used in many categories, changes are normally batched to reduce server load. I'll look into deploying this soon along with other changes. Thanks. Mike Peel (talk) 18:50, 25 October 2022 (UTC)

@WOSlinker: This is now live. Thanks. Mike Peel (talk) 19:18, 31 October 2022 (UTC)

This section is resolved and can be archived. If you disagree, replace this template with your comment. Mike Peel (talk) 19:18, 31 October 2022 (UTC)

Edit request for Template:Wikidata Infobox/core – misplaced table tag

{{Edit request}} {{Wikidata Infobox/core}} has a closing table tag in the wrong location. It is inside the second if statement, but it was opened in the first if statement. I have moved it in {{Wikidata Infobox/core/sandbox}}. Please copy the sandbox to the live template, or replicate the move of the table closing tag two characters to the right. Thanks. Jonesey95 (talk) 23:01, 26 October 2022 (UTC)

@Jonesey95: Looking at the diff, I can't see the change? It just seems to be a new line inside a comment that has been removed. Please could you double-check this? Thanks. Mike Peel (talk) 17:28, 31 October 2022 (UTC)

This is the diff to look at. Ignore the /sandbox at the top. Note the swap of braces and the closing table tag. That is the fix. Jonesey95 (talk) 17:36, 31 October 2022 (UTC)

@Jonesey95: Thanks, this is now live. Thanks. Mike Peel (talk) 19:18, 31 October 2022 (UTC)

This section is resolved and can be archived. If you disagree, replace this template with your comment. Mike Peel (talk) 19:18, 31 October 2022 (UTC)

Collapsing of the Author field appears broken at Category:Media from Lavesque et al. 2021 - 10.5852/ejt.2021.782.1593

The collapsing of the Author field appears broken at Category:Media from Lavesque et al. 2021 - 10.5852/ejt.2021.782.1593. In the Author field, I see [Show], followed by all but the first author. When I click [Show], the first author appears.

What should happen, I believe, is that all of the authors should be hidden, and when I click [Show], they should all appear.

There are also between three and five Linter errors that appear to be caused by this section, so the rendering error seems likely to be related to a syntax error of some kind. Jonesey95 (talk) 04:59, 28 October 2022 (UTC)

Thanks for reporting. This will be fixed with Special:Diff/699899100. --LennardHofmann (talk) 11:39, 28 October 2022 (UTC)

Thanks. I tested the sandbox version of the template on that page, and there are no rendering or Linter errors. The collapsing is gone, which appears to be intentional. Jonesey95 (talk) 22:17, 28 October 2022 (UTC)

@Jonesey95 and LennardHofmann: This is now live. Thanks. Mike Peel (talk) 19:19, 31 October 2022 (UTC)

This section is resolved and can be archived. If you disagree, replace this template with your comment. Mike Peel (talk) 19:19, 31 October 2022 (UTC)

Geogroup

Where the category is about places, or things in places, can we find a sensible way to embed {{Geogroup}} at the foot of the infobox? Or can we have a manual switch, such as {{Wikidata Infobox|geo=y}}, which bots could then set for relevant sets of catgories? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 22:28, 14 October 2020 (UTC)

@Pigsonthewing: Rather than including the template, the links are included under the map and coordinates within the infobox. The bing link in geogroup doesn't work (I've just been testing adding it to the infobox, but no luck). OSM is there in the current version, but might be upgraded per the discussion just above, testing code is in the sandbox. Would the KML link be useful or add clutter? Thanks. Mike Peel (talk) 15:54, 5 December 2020 (UTC)

@Mike Peel: I think we're at cross purposes; please take a look at Category:Public art in Birmingham. The map links in {{Geogroup}} do not appear in the infobox, which has no map and no coordinates. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 17:36, 5 December 2020 (UTC)

@Pigsonthewing: OK, I get it. The OSM link was only being displayed if there was a coordinate. I've changed it so that the link is now displayed at the bottom, regardless of whether there is a coordinate, so that should work in your case. Could you try {{Wikidata Infobox/sandbox}} please? Thanks. Mike Peel (talk) 17:56, 5 December 2020 (UTC)

Yes, that works, but it needs more explanation, since the link is not to "OpenStreetMap" (Geogroup uses "Map of all coordinates on OSM", but could be shortened to, say, "coordinates (OSM)"). And we do need a KML download option. If the Bing link is not working, then of course drop it, but please bear in mind it might be fixed, and other services my become available. Also, it adds the OSM link to pages like Category:SuperTinyIcons where there is no Geographic metadata, and never will be. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 20:15, 5 December 2020 (UTC)

@Pigsonthewing: The label has to be multilingual. Using the label of OpenStreetMap (Q936) does that automatically, anything beyond that becomes a lot more complicated. I can add the KML link easily, but I need to be able to point to a reason why it's needed if someone objects to its inclusion. Bing can similarly be linked to easily if it starts working. Thanks. Mike Peel (talk) 20:52, 5 December 2020 (UTC)

BTW, @Hjart: we talked about this a bit via a mini edit war / discussion on my talk page back at the start of November, can you check the sandbox version and see what you think? Also, if you have any comments about the Bing and KML links, please share them. Thanks. Mike Peel (talk) 18:19, 5 December 2020 (UTC)

Map of coordinate locations

I wonder if this might be a useful query to add as a link from categories (or, at least, from geographical categories): Commons:SPARQL_query_service/queries/examples#Camera_location_of_files_in_a_category ? Jheald (talk) 12:06, 17 May 2022 (UTC)

Or would relevant categories already use template {{Geogroup}} ? (Category:River Ravensbourne does, which may make for an interesting comparison; but most categories probably don't). Jheald (talk) 12:57, 17 May 2022 (UTC)

Geogroup (2)

Hi. Don't forget to include something like {{Geogroup}} into the infobox. Thank You. ŠJů (talk) 05:20, 15 July 2022 (UTC)

@ŠJů Was tried. The Geogroup template is just plain better. Hjart (talk) 09:23, 16 July 2022 (UTC)

There are some of the same links at the bottom of the infobox at the moment, the others could be added at some point. Thanks. Mike Peel (talk) 09:26, 16 July 2022 (UTC)

@Mike Peel: There are some links in the infobox to display specifically files from the current category? I thought that all the map links in the current infobox display all geocoded images from the nearby area, not selectively those contained in the current category. {{Geogroup}} is important for maintenance - for sorting files into subcategories of a given category as well as for detecting miscategorized images or images with incorrect coordinates. --ŠJů (talk) 14:10, 16 July 2022 (UTC)

@ŠJů: Have a look at the 'OpenStreetMap' and 'Locator tool' links in the infobox - they use category contents. There were others but the tools stopped working, so they were commented out. All Geogroup does is to link to external tools, it doesn't do anything on the Commons side, so it should be easy enough to finish incorporating the other links (perhaps it's actually just the KML link that's missing?). Thanks. Mike Peel (talk) 15:19, 16 July 2022 (UTC)

@Mike Peel: As my comments indicate, the problem is that the links are not described and explained sufficiently to distinguish what they display in the map: whether images from the current category, or all geocoded images in the coordinate area of that category. Both functions are needed. One for checking the content of the category, the other e.g. for searching for images that should belong to the category, but are not yet in it, and also for overview of related nearby items, articles, categories, duplicate detection etc. --ŠJů (talk) 15:31, 16 July 2022 (UTC)

@ŠJů: That's for the tools to describe. I think I copy-pasted those links from the Geogroup template anyway, so they should have the same functionality as there. Thanks. Mike Peel (talk)

@Mike Peel: Both similar templates or boxes ({{Location}}, {{Geogroup}}) contain some simple description what the links do and what the linked map displays. Wikidata Infobox contains a set of 7 links and is not easy to discover what which of them does. The label "OpenStreetMap" itself says nothing about what images are in the OSM displayed. If it displays images from the category (like the {{Geogroup}} OSM link), than there is missing a tool displaying all images from the location in the OSM (like the OSM link from the {{Location}} template). Both variants are needed. The 'Locator tool' link is not very intuitive: when i click to this link in the category of Prague district Category:Hostivař, it displays to me a map of the center of the City of London – that's unusable now. --ŠJů (talk) 16:13, 16 July 2022 (UTC)

@ŠJů: Thanks for all the background. I suggest we park this for now, while the Lua rewrite goes live, and then we revisit this once we're working on Lua-ising the links part of the infobox. Thanks. Mike Peel (talk) 16:16, 16 July 2022 (UTC)

@ŠJů: Is the WikiMiniAtlas map you get by clicking the icon in front of the coordinates sufficient for you or do you need the OSM link from {{Location}}? Compare e.g. the WikiMiniAtlas map on Category:Westfälische Hochschule with this OSM link. More descriptive labels for helperlinks would be nice but would also require translation. --LennardHofmann (talk) 19:23, 1 August 2022 (UTC)

@LennardHofmann: The

icon has a tooltip "Show location on an interactive map" - that doesn't indicate that this link is intended to display photos from the current category (as GeoGroup does), and the linked map clearly does not have this purpose and content. To show the location, there are several maps, but I ask to show specifically geocoded images from the current category in the map. These are completely different map contents: either I want to display all images, articles or Wikidata items related to the coordinates assigned to the category, or on the contrary I want to display on the map the locations of the images that are included in the current category. This can help to detect miscategorized photos; to sort photos from the category into its subcategories; or simply to search for photos by location, if the category does not have its localizing subcategory for the demanded location. --ŠJů (talk) 20:17, 1 August 2022 (UTC)

@ŠJů: The "OpenStreetMap" helperlink (will be renamed to "WikiMap") shows images from the category on a map, e.g. this map shows 310 files from Berlin and a few (probably miscategorized) files from other cities. The WikiMiniAtlas shows files related to a coordinate, see https://wma.wmflabs.org, but WikiMap can also be used for this purpose if you remove the ?cat= parameter from the URL. Doesn't this cover both of your use cases? LennardHofmann (talk) 06:33, 2 August 2022 (UTC)

@LennardHofmann: Yes, they probably cover both use cases (btw., the "miscategorized" files of category Berlin apparently have some relation to Berlin). Now it is necessary to choose an appropriate arrangement and concise descriptions of the links so that each user can clearly see which link is for what. And maybe also tools to set subcategory depth? --ŠJů (talk) 14:16, 2 August 2022 (UTC)

KML export

The KML export functionality of {{Geogroup}} has been added as a helper link to the bottom of {{Wikidata Infobox/sandbox}}. --LennardHofmann (talk) 19:23, 1 August 2022 (UTC)

@Pigsonthewing, Hjart, Jheald, ŠJů, and LennardHofmann: I think this has been resolved now. Uses of {{Geogroup}} on pages using the infobox should probably be removed to avoid duplication. Thanks. Mike Peel (talk) 18:22, 31 October 2022 (UTC)

@Mike Peel: Shouldn't be given as a permanent task for bots to avoid+remove a duplication of {{Wikidata Infobox}} with {{Geogroup}}? --ŠJů (talk) 18:29, 31 October 2022 (UTC)

@ŠJů: I could code pi bot to do that if it would be useful. Thanks. Mike Peel (talk) 18:42, 31 October 2022 (UTC)

I've modified Pi bot so that when it adds an infobox, it will remove geogroup. I'll leave it at that for now and see how it goes. Thanks. Mike Peel (talk) 14:16, 1 November 2022 (UTC)

@Mike Peel Is there anywhere I can test this? Hjart (talk) 18:38, 31 October 2022 (UTC)

@Hjart: Pick your favourite category and compare links between the two? It's live everywhere in the infobox. Thanks. Mike Peel (talk) 18:42, 31 October 2022 (UTC)

@Mike Peel Ok. I just haven't been looking at all those links for quite some time. Also I always preferred having the geogroup links at the top. I was a very active OpenStreetmapper for many years. In some cases I would like to be able to go directly to osm.org to edit the object (create a new house or add a wikidata=*). Currently this unfortunately only works if the osm object has the appropriate wikidata tag. Hjart (talk) 19:09, 31 October 2022 (UTC)

@Hjart: So the solution is to add tags on OSM? ;-) Not sure that more can be done here. Thanks. Mike Peel (talk) 19:13, 31 October 2022 (UTC)

@Mike Peel I would really like to be able to have a link in the infoboks that would open the area directly without going through the Overpass API. Wikidata has the coords, so it really shouldn't be that hard. I often copy coords directly from the osm address line to insert into P625 btw. Hjart (talk) 19:20, 31 October 2022 (UTC)

@Hjart: Can you give an example of what you're thinking of? Thanks. Mike Peel (talk) 19:25, 31 October 2022 (UTC)

@Mike Peel Category:Ringridermuseet. In OSM it's this building. Modifying the end of the osm adressline should be fairly simple. I added the coords of Ringridermuseet (Q27955511) by simply copying from the OSM adressline (just needed to replace the "/" with a ","). Hjart (talk) 19:40, 31 October 2022 (UTC)

@Hjart: OK, but that can be done on Wikidata? There's no obvious URL or change to make to the infobox? Thanks. Mike Peel (talk) 19:45, 31 October 2022 (UTC)

What I want in the infobox in this particular case is a link that just says https://www.openstreetmap.org/#map=19/54.91096/9.78783. Hjart (talk) 19:53, 31 October 2022 (UTC)

@Mike Peel Please note that finding the building (or whatever the wikidata item is supposed to represent) can be quite tricky if it's not already in OSM and there's no fairly unique place names in the vicinity. The Overpass API trick is nice if P625 is inaccurate or there's a need to highlight the object or zoom to a large area. Otherwise it's useless. Hjart (talk) 09:47, 1 November 2022 (UTC)

@Hjart: If you click on the coordinates, you get to Geohack, which links to OSM - albeit with a wider zoom. You also get the choice of other maps at that page too. Is that not sufficient? Adding another link would feel like duplication. Thanks. Mike Peel (talk) 09:52, 1 November 2022 (UTC)

@Mike Peel Clicking the "OpenStreetMap" link gives me the error message "No results found." Would it be possible for the infoboks to detect this and switch to the simpler direct link? Hjart (talk) 10:08, 1 November 2022 (UTC)

@Hjart: No, it would have to access the API for that, and the infobox can't do that. Can you try what I said just above about clicking on the coordinate instead? Thanks. Mike Peel (talk) 10:14, 1 November 2022 (UTC)

@Mike Peel I tried it. I'ts more cumbersome than what I would have liked, but if I can't have anything better it'll do. Hjart (talk) 10:29, 1 November 2022 (UTC)

OK, let's stay with that. It's the same amount of cumbersome to get to any of the maps. Thanks. Mike Peel (talk) 11:21, 1 November 2022 (UTC)

@Mike Peel: I'm not seeing the OSM link on Category:Public art in Birmingham. But yes (once fixed), redundant {{Geogroup}} should be removed by bot. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 20:05, 31 October 2022 (UTC)

@Pigsonthewing: There's no coordinate there, so there's no OSM to be shown? Thanks. Mike Peel (talk) 20:08, 31 October 2022 (UTC)

No, it;s the link that's been renamed "WikiMap. All good Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 20:11, 31 October 2022 (UTC)

This section is resolved and can be archived. If you disagree, replace this template with your comment. Mike Peel (talk) 14:16, 1 November 2022 (UTC)

Strange text instead of "Date of Death" in English version

For English "21 October 2022" instead of "Date of Death" is shown. Everything is fine eg. in de or fr versions. -- 94.42.46.224 01:15, 5 November 2022 (UTC)

It was vandalism at [8] - now reverted. If you still see it, purge the cache (add ?action=purge onto the end of the URL) and it should go away. Thanks. Mike Peel (talk) 14:21, 5 November 2022 (UTC)

This section is resolved and can be archived. If you disagree, replace this template with your comment. Mike Peel (talk) 21:53, 7 November 2022 (UTC)

located on street (P669) missing

Somehow the property seems to be missing from the infobox when street address (P6375) is present.

I don't think this is desirable as

many streets have categories and links to these could be displayed.
Also, the content between the two can differ. The text property should include the city and ZIP codes.

Samples:

Category:Mozarts_Geburtshaus currently links Category:Getreidegasse (Salzburg) based on d:Q3327039#P669
Category:Getreidegasse 7, Salzburg, the building next to it, doesn't despite d:Q37970872#P669. This as there is also d:Q37970872#P6375. Same for all other buildings in that street.

--- Jura1 (talk) 13:20, 30 December 2021 (UTC)

@Jura1: If I remember right, this was a deliberate coding choice - when we have street address (P6375), then that supersedes located on street (P669) and P969 (P969) (although that latter needs to be removed from the code now). What behaviour would you lik eto see - if we have values for both properties, what should we display? Thanks. Mike Peel (talk) 22:21, 30 December 2021 (UTC)

Personally, I'd display both. Maybe first P669, then the string of P6375. --- Jura1 (talk) 22:32, 30 December 2021 (UTC)

Interestingly, addresses are searchable on Commons, but not anymore on Wikidata (see d:Property_talk:P6375#value_is_not_indexed_for_string_search). --- Jura1 (talk) 20:44, 13 March 2022 (UTC)

@LennardHofmann: What do you think about this? Thanks. Mike Peel (talk) 18:44, 31 October 2022 (UTC)

@Mike Peel: I don't have a strong opinion about this. See Category:Getreidegasse 7, Salzburg how it looks if street address (P6375) and located on street (P669) are both shown. LennardHofmann (talk) 07:58, 1 November 2022 (UTC)

Thanks Lennard. @Jura1: does this solve your request? Thanks. Mike Peel (talk) 09:49, 1 November 2022 (UTC)

@Jura1: This is now live. Thanks. Mike Peel (talk) 19:36, 8 November 2022 (UTC)

This section is resolved and can be archived. If you disagree, replace this template with your comment. Mike Peel (talk) 19:36, 8 November 2022 (UTC)

Lua rewrite

I am currently rewriting this infobox as part of Google Summer of Code 2022. You can read about my progress here. I promise it's an interesting read if you are into technical things. LennardHofmann (talk) 14:02, 6 June 2022 (UTC)

The second report is out! LennardHofmann (talk) 10:37, 2 July 2022 (UTC)
The third report discusses the performance of getEntity, getBestStatements, and getCommonsLink. LennardHofmann (talk) 12:22, 19 July 2022 (UTC)
The fourth report includes a little challenge for you. LennardHofmann (talk) 19:33, 15 August 2022 (UTC)

Try out the new Lua infobox

The main part of this infobox has now been fully rewritten in Lua. The other parts (Authority control and autocat) will be rewritten over the course of the next weeks. You can preview the new infobox on any Commons page by adding {{Wikidata Infobox/sandbox}} to it. Please tell us whether everything looks fine to you. The new infobox will go live on July 20.

While the main goal behind the rewrite was to improve the performance of the infobox, I also fixed some long-standing bugs and made other tweaks:

Changelog

* Image captions always refer to the correct image now – reported by Jan.Kamenicek and El Grafo in #misplaced captions

Removed second image row: Logo and flag images are no longer treated separately and can be selected with the radio buttons – This was requested by Mike Peel and heavily simplifies the code
Added copyright license (P275), train depot (P834), and partially coincident with (P1382) – requested by Christian Ferrer, Thierry Caro, and ŠJů, respectively
Fixed bug that prevented taxon author (P405) and year of publication of scientific name for taxon (P574) from showing up.
Added many image properties. See full list at Template:Wikidata_Infobox/doc/properties.
Moved creator's signature (P7457) from the bottom of the infobox to the top where all other images are. Infoboxes about humans still have signature (P109) at the end.
Removed has pet (P1429).
By default, table rows get collapsed if they have more than ten values.
Subinfoboxes are not shown for instances of calendar year (Q3186692) and decade (Q39911). See Category:1700 in Pennsylvania.
Audio files respect language fallbacks
Collapse doctoral student (P185) if there are more than four values – requested by William Graham in #Doctoral student
Collapsed values are not linked. This drastically speedups the infobox on Category:Matches of the 2014 FIFA World Cup.
Use default collapse messages – requested by Amire80 in #Collapsible-collapse vs Hide
Only linked values are shown for different from (P1889) – This solves #Disambigs in 'different from' in a different way than proposed by Wostr
Adjust map zoom level so that the geoshape (gray region) fits inside it if the Wikidata item has OpenStreetMap relation ID (P402). Otherwise zoom level is calculated from area, respecting the four most common units as requested in #Zoom level, area by Strakhov.
Statements with end time (P582) qualifier are ignored for official website (P856) and when going up the location hierarchy – This fixes #Update needed for showing currently valid P131 values reported by Arjunaraoc
Support for more datatypes in Module:WikidataIB/sandbox – This fixes #qualifier with datatype "wikibase-form" reported by Minerva97.
- For all changes to WikidataIB, see its history
Pages with an infobox that takes longer than 4 seconds to load are categorized under Uses of Wikidata Infobox with bad performance.
Some bugs fixed themselves:
- #Error displaying images with filenames beginning with an asterisk
- #Bad handling of only deprecated official website

If you have other suggestions to make the infobox better, please let us know! LennardHofmann (talk) 17:07, 14 July 2022 (UTC)

@LennardHofmann: OK. No problem for me. Thierry Caro (talk) 21:30, 14 July 2022 (UTC)

@LennardHofmann, I tested the sandbox version on Category:Bapatla and found that the P131 hierarchy is displaying valid values. Thanks. Arjunaraoc (talk) 04:49, 15 July 2022 (UTC)

The new infobox is live!

The changes to WikidataIB and this infobox I mentioned above are now live. You no longer need to append /sandbox to try out the new infobox. Please tell us if you notice any problems. LennardHofmann (talk) 17:23, 20 July 2022 (UTC)

Hello @LennardHofmann and Mike Peel: the category Category:House-shaped shrines currently returns: Lua error in Module:Wikidata_Infobox at line 928: attempt to index upvalue 'CLAIMS' (a nil value).. --M2k~dewiki (talk) 19:57, 20 July 2022 (UTC)

@M2k~dewiki: Add some claims to House-shaped shrine (Q107632347) to fix it. LennardHofmann (talk) 19:59, 20 July 2022 (UTC)

@LennardHofmann: Since this template is mass-added to categories that have a Wikidata connection, regardless of whether it actually contains any data, the Lua code should respect this and not error out if there’s nothing to show. Either show an empty box or absolutely nothing, but not an error message. —Tacsipacsi (talk) 01:10, 23 July 2022 (UTC)

@Tacsipacsi: I added a friendlier error message that can be translated, see Uses of Wikidata Infobox with no claims. Encouraging users to add some basic claims to the Wikidata item (which usually only takes a minute) is better than hiding the error. LennardHofmann (talk) 07:41, 23 July 2022 (UTC)

@LennardHofmann: I agree that showing a user-friendly error message is even better, the main point was that there should definitely not be a script error, not that it should be empty. However, there’s still one regression compared to the wikitext-based version: the infobox title gets hidden for some reason. There may be labels in different languages even if there aren’t any statements, so please add it back. —Tacsipacsi (talk) 11:34, 24 July 2022 (UTC)

And also please use $1 instead of %s as a placeholder: in the translation system, $1, $2 etc. are the standard placeholders, this is what translators are used to and what’s provided by the translation interface as a so-called “insertable” (little gray button at the bottom left of the input box). —Tacsipacsi (talk) 11:38, 24 July 2022 (UTC)

@Mike Peel: The issue about the placeholder is not yet resolved. It’s pretty easy – instead of string.format, use mw.message.newRawMessage (or string.gsub if performance is a concern) –, but it’s not easily testable, as changing Template:Wikidata Infobox/i18n affects both the sandbox and the live version. —Tacsipacsi (talk) 22:31, 1 November 2022 (UTC)

@LennardHofmann: Maybe this is easy to change? It is good to use the standard approach, for consistency. Thanks. Mike Peel (talk) 21:55, 7 November 2022 (UTC)

@Mike Peel: It's an easy change, but it requires changing the module and the translation pages in conjunction. When do you plan to make the sandbox changes live? LennardHofmann (talk) 16:03, 8 November 2022 (UTC)

@LennardHofmann: Whenever you'd be ready with the change, there are several other changes queued up, so we're about due for an update. Thanks. Mike Peel (talk) 17:39, 8 November 2022 (UTC)

@Tacsipacsi: This is now live. Thanks. Mike Peel (talk) 19:35, 8 November 2022 (UTC)

This section is resolved and can be archived. If you disagree, replace this template with your comment. Mike Peel (talk) 19:35, 8 November 2022 (UTC)

Placement: At the top of the page

The placement for the template: At the top of the page is really a bad instruction. This way, all important categories move to a place not more really visiv´ble on the first view, and totally unintersting, user unfriendly categories will be listed first. Examples: Category:Maarten van Heemskerck - really uninteresting (and partially red) categories are listed first - Category:Van Heemskerk (surname); Maarten (given name); Maerten (given name); or Category:Hendrick Goltzius; Hendrik (given name), Hendrick (given name) are the best categories to be listed first? This is really the information a user should read first? The box on top is good, but never the placement of the template. Florentyna (talk) 06:12, 29 October 2022 (UTC)

@Florentyna. Just to confirm you mean the parent categories which are in the footer of the page are in the wrong order? -- Zache (talk) 07:46, 29 October 2022 (UTC)

Yes, correct Florentyna (talk) 09:22, 29 October 2022 (UTC)

Page (wikitext) or page (rendered) ?

The Infobox should appear at the top of the rendered page, before any other text. This is so that the CSS float box can work to its best.

In the wikitext, important categories should come first. We can place category markup before the Infobox, but the problem there is that this inevitably attracts whitespace and renders as spurious blank lines at the top of the page.

So the best solution I can come up with for this (I've had the same problem on commercial wikis for years) is to generate the important categories inside the Infobox. Which in this case will involve pulling from wikidata. Otherwise it's best to just live with the poor category ordering.

If you control the MediaWiki code, it's also possible to generate categories in reverse order from the wikitext. This is a much easier fix for pages, but not deployable here. Andy Dingley (talk) 12:31, 29 October 2022 (UTC)

@Florentyna: I understand the problem, and sympathize with it, but I can't see a good alternative solution right now. Often the categories include other wikitext/templates, and the infobox should be included above them to display correctly. The infobox also systematically adds categories that wouldn't otherwise have been added, which is important. However, other categories are definitely more relevant, and it would be good if they were displayed first - but there's no way to tell MediaWiki about category ordering apart from the wikitext. If you can suggest a way of improving this, I'll listen to it, but I'm not sure there's much more that can be done right now. Thanks. Mike Peel (talk) 20:36, 29 October 2022 (UTC)

The solution is not so difficult, that's way the topic is called Placement: At the top of the page. One can simply move the template to the bottom of the page, and everything looks fine. Categories are well sorted, infobox remains at the beginning of the page. This means also, that the advice Placement: At the top of the page must be changed. --Florentyna (talk) 22:10, 31 October 2022 (UTC)

@Florentyna: That doesn't work, because a multitude of other potential templates and descriptions are also placed at the top of category pages. If the infobox is placed at the bottom, this creates significant display and functional issues. I'm sorry, but this is a non-starter. As mentioned, the only real existing solution is to put the categories above everything else, which contravenes all common and recommended practices across all wiki projects, and becomes a proposal well outside of this template. — Huntster (t @ c) 22:25, 31 October 2022 (UTC)

Can you provide an example of the display and functional issues, I never recognized such a behavior. Thanks in advance, best regards --Florentyna (talk) 05:48, 1 November 2022 (UTC)

If you have other templates or text at the top of the category, then the infobox display would be moved down, creating whitespace in the top-right and generally not working optimally. The convention everywhere on-wiki is to have categories at the bottom, I suggest taking the issue to Commons:Village pump to see what a wider audience thinks. Thanks. Mike Peel (talk) 17:43, 8 November 2022 (UTC)

This section is resolved and can be archived. If you disagree, replace this template with your comment. Mike Peel (talk) 17:43, 8 November 2022 (UTC)

Wikidata infobox may be causing Linter errors by unnecessarily including language translations that are not displayed

This is just a hypothesis, so please take it with a grain of salt. On the page Category:Culture by language, {{Wikidata infobox}} is used, and the page shows a "Missing end tag" error, indicating that there is a '' that is opened but not closed. When I look at the Wikidata entry for the page, the only instance of '' that I see is in the nap category name: Categurìa:Cultura a ssicond''a lengua.

That category name is not displayed on the page, as far as I can tell, but it appears to be parsed or rendered in some hidden way that causes '' to be in the rendered wikicode of the category page.

This also appears to happen when there is an unclosed '' in one of the "In more languages" section of the wikidata page that corresponds to a page using this infobox.

Is there a way to suppress the importing of this extraneous information so that it does not cause these errors?

It may also be the case that ssicond''a is not valid Napolitano language, but the category exists at nap.WP, and the construction appears to be common there. Jonesey95 (talk) 16:41, 3 November 2022 (UTC)

On a possibly related note, Category:Post Office Ltd shows the same Missing end tag error coming from the Wikidata infobox, but I do not see any '' on the Wikidata page. Jonesey95 (talk) 16:49, 3 November 2022 (UTC)

Category:Mark Ma shows a Missing end tag, this time '''. I removed two instances of stray markup from the Wikidata page, but there is still one error left on the category page. Jonesey95 (talk) 17:25, 3 November 2022 (UTC)

@Jonesey95: The infobox includes the other labels from the Wikidata item so that they are picked up by Commons' search - so you can search in multiple languages. They aren't displayed deliberately. They shouldn't cause any display issues. Thanks. Mike Peel (talk) 17:33, 3 November 2022 (UTC)

Can they be wrapped in nowiki tags or otherwise processed such that they do not cause these (possibly spurious) Linter errors? I don't want to interfere with the searching, but having them cluttering up the error lists makes it more difficult to track down actual errors. Thanks. Jonesey95 (talk) 17:36, 3 November 2022 (UTC)

@Jonesey95: Using nowiki sounds like a good idea. I've implemented that in the sandbox, please can you try {{Wikidata Infobox/sandbox}} and see if that solves the problem? Thanks. Mike Peel (talk) 21:52, 7 November 2022 (UTC)

I have edited Category:Culture by language and the other two pages linked above to use the sandbox version temporarily. The Linter errors are gone (nice work!). Does the searching and other background functionality still work there? Jonesey95 (talk) 02:06, 8 November 2022 (UTC)

@Jonesey95: It seems to, e.g., [9]. Thanks. Mike Peel (talk) 17:40, 8 November 2022 (UTC)

That looks like a good workaround then. Thanks. Jonesey95 (talk) 18:20, 8 November 2022 (UTC)

@Jonesey95: This is now live. Thanks. Mike Peel (talk) 19:35, 8 November 2022 (UTC)

This section is resolved and can be archived. If you disagree, replace this template with your comment. Mike Peel (talk) 19:35, 8 November 2022 (UTC)

Wrong image displayed in English and French versions

On Category:Electronic_color_code page, viewed in English and in French the Wikidata Infobox displays picture for German language File:Farbcode von Widerständen.svg in both cases, whereas specific pictures exist for both languages:

the picture should be File:Resistor Color Code.svg for English,
it should be File:Code couleur résistance.svg for French.

-- ◄ David L • discuter ► 14:12, 6 November 2022 (UTC)

@DavidL: Thanks for reporting, this will be fixed by Special:Diff/703357496. --LennardHofmann (talk) 16:49, 7 November 2022 (UTC)

@DavidL: This is now live. Thanks. Mike Peel (talk) 19:34, 8 November 2022 (UTC)

This section is resolved and can be archived. If you disagree, replace this template with your comment. Mike Peel (talk) 19:34, 8 November 2022 (UTC)

Link to 'location' category

I'm not sure what I've done wrong, or if it's a bug in this template, but the location (P276) for Category:Worlds of Wikimedia 2022 does not link to Category:Sibyl Centre. Anyone got an idea? — Sam Wilson ( Talk • Contribs ) … 01:22, 17 November 2022 (UTC)

@Samwilson, I suspect that it's because Sibyl Centre (Q115180739) didn't have either located in the administrative territorial entity (P131) or location (P276). Once I added these, the link appears properly now. — Huntster (t @ c) 02:39, 17 November 2022 (UTC)

Yep, confirmed. If an item's location doesn't have its own P131 and/or P276, a link to that location's category won't appear. Curious little bug. — Huntster (t @ c) 02:43, 17 November 2022 (UTC)

@Huntster: Ah great! Thanks for figuring it out. :-) — Sam Wilson ( Talk • Contribs ) … 02:52, 17 November 2022 (UTC)

This is working as expected. The last entry in the location chain is not linked by WikidataIB.location because it's usually a country. I assume this is what you were observing. LennardHofmann (talk) 09:02, 17 November 2022 (UTC)

@LennardHofmann, so this is just an edge case where, rather being the last link in the chain, it was the only link in the chain, and thus wasn't wikilinked? — Huntster (t @ c) 15:57, 17 November 2022 (UTC)

Exactly. LennardHofmann (talk) 07:28, 18 November 2022 (UTC)

This section is resolved and can be archived. If you disagree, replace this template with your comment. Mike Peel (talk) 11:08, 30 December 2022 (UTC)

Interwikis

Can we switch off interwikis from WD-item for categories which are not intended for them? Example: Category:Estatuas por Axel Cotón Gutiérrez. Infovarius (talk) 09:05, 1 December 2022 (UTC)

To clarify, are you looking for something like a parameter which would turn interwikis off? How often does this come up? I don't think I've come across this type of intentional "misuse" before. — Huntster (t @ c) 09:43, 1 December 2022 (UTC)

@Infovarius: Use {{Wikidata Infobox|interwiki=no}}. See the documentation for available parameters. LennardHofmann (talk) 10:09, 1 December 2022 (UTC)

@Infovarius and Huntster: The infobox is not designed to work with user categories like that, I've removed it from the category. Ideally the category would have its own Wikidata item linked to it, but that's not feasible for user categories. Thanks. Mike Peel (talk) 21:41, 1 December 2022 (UTC)

I had a feeling this would be the case and outcome, but wanted this discussion to play out first and understand Infovarius' intent. Thanks for taking care of it. — Huntster (t @ c) 02:29, 2 December 2022 (UTC)

This section is resolved and can be archived. If you disagree, replace this template with your comment. Mike Peel (talk) 11:07, 30 December 2022 (UTC)

Link incl Logo

Is it possible to add the logo on the top of line of RegiowikiAT-Link with like the lines above ov this GND or VIAF? --thx -- K@rl (talk) Diskussion 17:24, 29 December 2022 (UTC)

@Karl Gruber: You need to add it on Wikidata, as a icon (P2910) value for the authority control property. See VIAF ID (P214) as an example. Thanks. Mike Peel (talk) 21:07, 29 December 2022 (UTC)

@Mike Peel: Now it's in. thx, now I think it's a question of cache, till it appears in the boxes. many thx ---- K@rl (talk) Diskussion 11:02, 30 December 2022 (UTC)

@Mike Peel: Hi, was it real enough, to add the icon (P2910), because, the logos is never seen in a box since this action---- K@rl (talk) Diskussion 17:41, 30 December 2022 (UTC)

@Karl Gruber: Do you have an example category, and I can have a look? Thanks. Mike Peel (talk) 18:42, 30 December 2022 (UTC)

@Mike Peel: One of such categories would be Category:Mödlinger Friedhof -- -- K@rl (talk) Diskussion 19:07, 30 December 2022 (UTC)

Moin User:Karl Gruber, ich gebe mal mitlesend eine Antwort. Wenn ich mir RegiowikiAT ID (P6228) anschaue und mit GND ID (P227) vergleiche, dann sehe ich beim RegionalWiki leider ein Statment für "Symbol". Da muss das Symbol rein und dann wird es auch angezeigt. (Und ja, der Cache bei über 4 Millionen Infoboxen braucht dann etwas.) mfg --Crazy1880 (talk) 20:06, 30 December 2022 (UTC)

@Crazy1880: Servus, danke, das war mein Fehler, ich gab das Symbol bei d:Q32752205 statt bei RegiowikiAT ID (P6228) hinein. Jetzt funkts. @Mike Peel: many thanks it was my mistake - the symbol was in the false object. regards -- K@rl (talk) Diskussion 21:22, 30 December 2022 (UTC)

This section is resolved and can be archived. If you disagree, replace this template with your comment. Mike Peel (talk) 09:37, 31 December 2022 (UTC)

Radio buttons and their description texts

@LennardHofmann: Is it possible to make a no-break space between the radio button and its description text right below the top picture in the box. Sometimes is the radio button in the first line, its description in the second. A sample is here: https://upload.wikimedia.org/wikipedia/commons/archive/6/6a/20221231141953%21PNG_Test.png

Kind regards and Happy New Year, – Doc Taxon • Talk • 14:20, 31. Dec 2022 (UTC)

@Doc Taxon: There already is a no-break space between the radio button and the label, it just doesn't work. This needs to be fixed in MediaWiki:Gadget-Infobox.js using CSS. LennardHofmann (talk) 15:29, 31 December 2022 (UTC)

@Raymond: can you fix it in MediaWiki:Gadget-Infobox.js please? – Doc Taxon • Talk • 18:43, 31. Dec 2022 (UTC)

@Doc Taxon: I am not very firm in JavaScript. I would prefer if either someone with better JS knowledge do it or give me the code to replace the existent. Raymond 13:22, 1 January 2023 (UTC)

@Lucas Werkmeister: can you do something please? – Doc Taxon • Talk • 14:02, 1. Jan 2023 (UTC)

@Doc Taxon: Please file an {{Edit request}} (probably against MediaWiki:Gadget-Infobox.js, if I’m not mistaken) instead of pinging random interface admins. It will also help if you (or User:LennardHofmann) can provide more details than “do something”. (But for what it’s worth, while more detailed edit requests are easier to act on, I don’t agree with Andy Mabbett above that this is a requirement for using {{Edit request}}.) I’ll also mention that the above screenshot corresponds to Category:Rohrdorf (am Inn)?uselang=de. --Lucas Werkmeister (talk) 10:56, 2 January 2023 (UTC)

@Lucas Werkmeister: you use "Edit request", if you really know what to change. I'm not very familiar with JavaScript, so it'd better to ping interface admin who has the knowledge about what to change. The page of the linked snippet is Category:Rohrdorf (am Inn)?uselang=de, yes! If you don't want to edit the template code it'd very help if you can say me, what to change. Thanks for any help. Kind regards, – Doc Taxon • Talk • 01:45, 3. Jan 2023 (UTC)

AntiCompositeNumber could find the solution for the problem: https://commons.wikimedia.org/w/index.php?title=MediaWiki:Gadget-Infobox.js&diff=722617083&oldid=680078268 Thanks to all who tried to help ... Kind regards – Doc Taxon • Talk • 03:06, 4. Jan 2023 (UTC)

This section is resolved and can be archived. If you disagree, replace this template with your comment. Crazy1880 (talk) 09:40, 5 January 2023 (UTC)

Wikimedia map from topics property

Hi,

I was just trying to find why the map is not displayed in the infobox of Category:Female sportspeople from Paraguay. The map is working well on Category:Female golfers from France for example. The Wikidata item wikidata:Q15285400 is correctly filled with wikidata:Q733 in wikidata:Property:P31 (topics). But looking at the module source, the function named body() does not return the map if numbers of topics is greater than 2. This is the case here and explains why the map is not displayed. When testig without such a test, map appears in the infobox.

Do you know why such a limitation on number of topics has been introduced? @Mike Peel: ?

Jgui (talk) 15:25, 13 January 2023 (UTC)

@Jgui: It's to make sure the infobox remains compact without trying to display too much, and the page loads quickly (the more items that are loaded, the slower it gets). female athlete (Q106037372) exists, but I'm not sure if that's a good solution - or follow the structure at Category:Female golfers from France. Thanks. Mike Peel (talk) 16:09, 13 January 2023 (UTC)

This section is resolved and can be archived. If you disagree, replace this template with your comment. Mike Peel (talk) 21:11, 17 January 2023 (UTC)

Purge of this categories

Moved from Category talk:Wikidata infobox maintenance. Mike Peel (talk) 21:10, 17 January 2023 (UTC)

Moin Moin Mike Peel, Can you tell me how often these categories are purged? The background of the question is that I have transferred first names in Wikidata, but they are still not out of the category. In the German Wikipedia we had a similar problem. There is now a bot and purge this articles. Regards --Crazy1880 (talk) 16:01, 11 September 2018 (UTC)

See de:Benutzer:AsuraBot/Purges

It seems to take a couple of days to a week. We could do null edits by bot if necessary, although it would put some extra strain on the servers. Thanks. Mike Peel (talk) 19:32, 11 September 2018 (UTC)

Moin Moin Mike Peel, sounds good with the bot. I did some tests. It's more than a week. Could not the bot be restricted to this category and surnames? I see that I get the category emptied. Regards --Crazy1880 (talk) 13:36, 15 September 2018 (UTC)

@Crazy1880: Which category specifically? Thanks. Mike Peel (talk) 13:39, 15 September 2018 (UTC)

@Mike Peel: :

I think that these three are the main thing. Regards --Crazy1880 (talk) 16:26, 15 September 2018 (UTC)

@Crazy1880: It turns out that the code to do this is quite simple [10] - however it's not very quick to run. Does this still need running, or have the caches refreshed themselves now? Thanks. Mike Peel (talk) 22:00, 23 September 2018 (UTC)

Morning @Mike Peel: , partly partly. Some entries have disappeared and others, still from 9th September, are still inside. I think it could not hurt, running this. Regards --Crazy1880 (talk) 07:55, 24 September 2018 (UTC)

@Crazy1880: OK, the bot's running through all three categories now. Expect it to take a few days to complete, though. Thanks. Mike Peel (talk) 12:39, 24 September 2018 (UTC)

@Crazy1880: Looks like the bot's finished, does that look better now? I won't run this regularly, so ask me if it needs doing again sometime. Thanks. Mike Peel (talk) 19:06, 29 September 2018 (UTC)

Moin Moin @Mike Peel: , I will think, that you can run the bot again, I worked a lot. Regards --Crazy1880 (talk) 15:15, 24 November 2018 (UTC)

@Crazy1880: It's running again now for the three categories, it will take a day or so to complete. Thanks. Mike Peel (talk) 16:34, 25 November 2018 (UTC)

Moin Moin @Mike Peel: , could you ran it for a last time in this year? Thanks and happy christmas. --Crazy1880 (talk) 16:45, 24 December 2018 (UTC)

@Crazy1880: It's running now. Thanks. Mike Peel (talk) 17:08, 25 December 2018 (UTC)

@Crazy1880: It's finished now. Thanks. Mike Peel (talk) 10:09, 1 January 2019 (UTC)

Moin @Mike Peel: , first: I wish you a happy new year. Secondly: that was a long time and Infobox with no given name I will not believe. Ok I'm looking forward and hope I can work more. Regards --Crazy1880 (talk) 10:16, 1 January 2019 (UTC)

@Crazy1880: It's a slow process (~1 a second as currently coded), even slower when I'm running it intermittently on my laptop (I'm travelling at the moment). The given name one is now re-running. Thanks. Mike Peel (talk) 11:47, 1 January 2019 (UTC)

@Crazy1880: That's now re-run (it's the quickest one to run). Thanks. Mike Peel (talk) 11:52, 2 January 2019 (UTC)

Moin @Mike Peel: , I hope you came good to this year 2023 and I hope we will have another good teamwork together ;) Could you please purge "Uses of Wikidata Infobox with no instance of", I made some imports. Thanks --Crazy1880 (talk) 20:38, 1 January 2023 (UTC)

@Crazy1880: Is it OK if this waits until the week of the 9th? I'm traveling at the moment. Thanks. Mike Peel (talk) 20:42, 1 January 2023 (UTC)

Ahhh, have a good tour then, should i remember you then again? Yes, can wait. --Crazy1880 (talk) 20:43, 1 January 2023 (UTC)

@Crazy1880: Running now. Thanks. Mike Peel (talk) 18:55, 11 January 2023 (UTC)

Moin Mike, i hope you had a good trip then? Thanks for running. Someone flooded this category with "xxxx, Nagoya‎" things, i don't know how to handle that, perhaps you could have a look, that would be nice. Regards --Crazy1880 (talk) 19:01, 11 January 2023 (UTC)

They look correct, missing instance of (P31) values? Unless I'm missing something? Thanks. Mike Peel (talk) 19:18, 11 January 2023 (UTC)

@Crazy1880: Completed. It ran through 74,294 categories, I see there are now 71,864 remaining. Thanks. Mike Peel (talk) 21:09, 17 January 2023 (UTC)

This section is resolved and can be archived. If you disagree, replace this template with your comment. Mike Peel (talk) 21:11, 17 January 2023 (UTC)

Problem with Template Artwork

Moved from Category talk:Wikidata infobox maintenance. Mike Peel (talk) 21:10, 17 January 2023 (UTC)

Moin Moin Mike Peel, it seems, that there is a problem with the template Artwork. In the category "Uses of Wikidata Infobox with problems‎" are now 15 items where the infobox is installed by set the parameter "Wikidata" in the template "Artwork". I think it wasn't designed for that way, right? Could you check it, please? Thanks for advise. --Crazy1880 (talk) 19:18, 28 January 2019 (UTC)

@Crazy1880: fixed. Thanks. Mike Peel (talk) 22:35, 28 January 2019 (UTC)

Thanks Mike Peel, I could have come up with that, too. I fixed the rest of them --Crazy1880 (talk) 18:28, 29 January 2019 (UTC)

This section is resolved and can be archived. If you disagree, replace this template with your comment. Mike Peel (talk) 21:11, 17 January 2023 (UTC)

Option to collapse

Please add a parameter to allow the infobox to be initially collapsed (such as {{Wikidata Infobox|expand=no}}, effectively similar to {{Collapse|expand=no}}). Josh (talk) 21:29, 17 February 2023 (UTC)

Please do not. That would utterly defeat the point of an infobox. Users who do not wish to see them can add a line to their local CSS to hide them. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 21:55, 17 February 2023 (UTC)

Agree. Do NOT collapse the infobox. The collapsing pandemic has already made the internet mostly unusable. Taylor 49 (talk) 10:46, 12 March 2023 (UTC)

Not done Thanks. Mike Peel (talk) 20:20, 5 April 2023 (UTC)

This section is resolved and can be archived. If you disagree, replace this template with your comment. Mike Peel (talk) 20:20, 5 April 2023 (UTC)

How to make Wikidata infobox works across translations?

For example, the infobox is displayed nicely in Commons:Dewantara Kirti Griya Museum, but not in id, da, fr, and so on. Bennylin (yes?) 05:50, 2 March 2023 (UTC)

@Bennylin: It's linked to the user interface language, change that. E.g., [11] for id. Thanks. Mike Peel (talk) 07:37, 2 March 2023 (UTC)

Hi Mike, thank you for the answer, but I think I phrased the question incorrectly. I wanted the other translation pages also display the infobox. If you go to Commons:Dewantara_Kirti_Griya_Museum/id, for example, it doesn't display the infobox. This happened, even though the original code already specify the Q item - {{Wikidata Infobox|Q12499637}} (e.g. not automatically search based on page title) Bennylin (yes?) 07:45, 2 March 2023 (UTC)

@Bennylin: Ah, I see. You need to specify qid= - like this. That seems to have fixed it in most translations, but not id for some reason. Thanks. Mike Peel (talk) 08:35, 2 March 2023 (UTC)

It works, thanks! I would've thought that parameter {{{1}}} would be an alias to {{{qid}}}. Bennylin (yes?) 08:41, 2 March 2023 (UTC)

This section is resolved and can be archived. If you disagree, replace this template with your comment. Mike Peel (talk) 20:19, 5 April 2023 (UTC)

Wikipedia link in infobox

It appears there has been some kind of vandalism or such to the infobox, as the link to Wikipedia now reads "WikipediaW", but for the life of me I cannot find where this is happening. @Mike Peel — Huntster (t @ c) 15:08, 10 April 2023 (UTC)

@Huntster: It's in Wikipedia (Q52), this edit, since reverted - but I guess cache caught it. It should clear through given time... Thanks. Mike Peel (talk) 19:04, 10 April 2023 (UTC)

Bah, the one (most obvious) place I didn't consider. Thanks, Mike. — Huntster (t @ c) 20:10, 10 April 2023 (UTC)

This section is resolved and can be archived. If you disagree, replace this template with your comment. Taylor 49 (talk) 04:14, 12 April 2023 (UTC)

Automatic categorization by cause of death

{{Edit request}} It would be nice if we not only could show the Wikidata:Property:P509 (cause of death) but also put the page into a matching category, like Category:Deaths_from_pneumonia or Category:Deaths from cholera. Rettinghaus (talk) 11:00, 28 December 2022 (UTC)

Please don't use {{Edit request}} unless you have a specific change which can be copied into the template or module code. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 17:51, 30 December 2022 (UTC)

I have implemented this in the sandbox module. LennardHofmann (talk) 17:57, 1 January 2023 (UTC)

@Rettinghaus: This is now live. Thanks. Mike Peel (talk) 17:13, 4 July 2023 (UTC)

This section is resolved and can be archived. If you disagree, replace this template with your comment. Mike Peel (talk) 17:13, 4 July 2023 (UTC)

Atlas ID to be changed to Louvre Collections ID

Hello

In the external IDs for Art, the ID used for the Louvre Collections items is the Wikidata property https://www.wikidata.org/wiki/Property:P1212 for Atlas database. The base is no longer published since 2021. The links may make redirections to the new Louvre Collection database but many Atlas IDs are dead links. Example: http://cartelfr.louvre.fr/cartelfr/visite?srv=car_not_frame&idNotice=20688&langue=fr in Category:Chasse_d%27Alexandre_(Louvre,_Ma_858).

Furthermore the new Louvre collections database has its own ID on Wikidata https://www.wikidata.org/wiki/Property:P9394 and more Louvre items are linked in Wikidata with this ID. Example: Q20667952 https://collections.louvre.fr/ark:/53355/cl010279155

So the use of Wikidata Atlas ID/P1212 should be changed to Louvre Collections ID/P9394 ; modification

Best regards Shonagon (talk) 18:06, 14 January 2023 (UTC)

This is now live. Thanks. Mike Peel (talk) 16:56, 4 July 2023 (UTC)

This section is resolved and can be archived. If you disagree, replace this template with your comment. Mike Peel (talk) 16:56, 4 July 2023 (UTC)

Small fix to module: unbalanced tags

I have fixed unbalanced tags in the module sandbox. Please include this change in the live module when it is next updated. Jonesey95 (talk) 17:13, 19 January 2023 (UTC)

@Jonesey95: This is now live, thanks for the bugfix. Thanks. Mike Peel (talk) 16:56, 4 July 2023 (UTC)

This section is resolved and can be archived. If you disagree, replace this template with your comment. Mike Peel (talk) 16:56, 4 July 2023 (UTC)

Czech structural object ID

{{Edit request}} Please add Czech structural object ID (P11351) (8300+ cats) to the "Cultural heritage and architecture" group. Consider also adding Structurae structure ID (P454) (19000+ cats) and CTBUH Skyscraper Center building ID (P1305) (3100+ cats) to the same group. Jklamo (talk) 16:41, 24 January 2023 (UTC)

Tested in the {{Wikidata Infobox/sandbox}} (try Category:AZ Tower for example). Jklamo (talk) 13:53, 31 January 2023 (UTC)

Thanks, this looks fine, it'll go live in the next version. Thanks. Mike Peel (talk) 20:22, 5 April 2023 (UTC)

@Jklamo: It's now live. Thanks. Mike Peel (talk) 16:58, 4 July 2023 (UTC)

This section is resolved and can be archived. If you disagree, replace this template with your comment. Mike Peel (talk) 16:58, 4 July 2023 (UTC)

Add NSW Heritage listing authority

Hi all, this was discussed on the Village Pump some time back (I wasn't aware this was the correct place to ask!), but can we please added property ID P3449 to the authority control section of this infobox? The property is the NSW Heritage database ID. I have uploaded a lot of photos of these items which have infoboxes, would be very nice to see them in the infobox :-) I believe it is already in the sandbox. - Chris.sherlock2 (talk) 11:34, 25 February 2023 (UTC)

@Mike Peel: I was wondering if it would be ok to implement these changes now? - Chris.sherlock2 (talk) 17:50, 12 March 2023 (UTC)

@Chris.sherlock2: It's in {{Wikidata Infobox/sandbox}}, does that look OK to you? Thanks. Mike Peel (talk) 20:19, 5 April 2023 (UTC)

Looks great! thank you for implementing this Mike, I really appreciate it. - Chris.sherlock2 (talk) 22:19, 5 April 2023 (UTC)

@Chris.sherlock2: It's now live. Thanks. Mike Peel (talk) 16:58, 4 July 2023 (UTC)

This section is resolved and can be archived. If you disagree, replace this template with your comment. Mike Peel (talk) 16:58, 4 July 2023 (UTC)

relative (P1038) should be a part of the "human" group and always appear

What the title says. father (P22), mother (P25), child (P40) etc. are all in this group and all appear for all human items as listed here. relative (P1038) should appear too. OmegaFallon (talk) 20:13, 4 March 2023 (UTC)

@OmegaFallon: Added at {{Wikidata Infobox/sandbox}}, how does that look to you? Thanks. Mike Peel (talk) 20:17, 5 April 2023 (UTC)

Testing on Category:Ruby Rose (RWBY) looks alright to me. Apologies for the late reply; I was unable to access my computer for many days. OmegaFallon (talk) 18:36, 8 April 2023 (UTC)

@Mike Peel Any updates on this? It seems like a pretty non-controversial addition to the human group. OmegaFallon (talk) 18:50, 22 April 2023 (UTC)

@OmegaFallon: This is now live. Thanks. Mike Peel (talk) 17:10, 4 July 2023 (UTC)

This section is resolved and can be archived. If you disagree, replace this template with your comment. Mike Peel (talk) 17:10, 4 July 2023 (UTC)

Prefer collage over single image

@User:Multichill @User:Mike Peel See Category:Reptilia. Please prefer collage over single image, either unconditionally and always, or at least add a parameter to achieve this. A collage is far more useful to show the scope of a topic (Q-item, category, ...) than a single image of a fragment of the topic. For example, a collage showing a turle, a snake, a dino and a crocodile is much more appropriate to visualize the scope of reptilia than a picture of a single species. Taylor 49 (talk) 10:57, 12 March 2023 (UTC)

@Taylor 49: This makes sense to me, but media captions may be an issue. Implemented at {{Wikidata Infobox/sandbox}}, how does that look to you? Thanks. Mike Peel (talk) 20:15, 5 April 2023 (UTC)

Great. @User:Mike Peel: I see that you edited Module:Wikidata Infobox/sandbox and the changes are very minor. When previewing the cat Category:Reptilia, the caption was broken and Russian. But this can be fixed and has been fixed by adding a sane caption at WikiData. Maybe the module should sanitize the caption coming from WikiData a bit: unlink, and truncate if too long. Taylor 49 (talk) 19:23, 6 April 2023 (UTC)

@User:Multichill @User:Mike Peel Can we get this activated now? Taylor 49 (talk) 04:14, 12 April 2023 (UTC)

@Taylor 49: It's now live. Thanks. Mike Peel (talk) 17:00, 4 July 2023 (UTC)

This section is resolved and can be archived. If you disagree, replace this template with your comment. Mike Peel (talk) 17:00, 4 July 2023 (UTC)

Percent encoding problem

when i tried to create a new item for Category:Chua Lam's Dim Sum, the link https://www.wikidata.org/wiki/Special:NewItem?site=commonswiki&page=Category:Chua_Lam%26%2339;s_Dim_Sum&label=Chua+Lam%26%2339%3Bs+Dim+Sum wants to add a commons sitelink with percent encoding. i couldnt change the " & #39;s " to 's manually. RZuo (talk) 08:09, 11 April 2023 (UTC)

Is this resolved now? Taylor 49 (talk) 04:14, 12 April 2023 (UTC)

Fixed in this edit by replacing {{urlencode:{{PAGENAME}}}} with {{PAGENAMEE}}. LennardHofmann (talk) 13:57, 12 April 2023 (UTC)

@LennardHofmann thx a lot. looks good. RZuo (talk) 14:04, 13 April 2023 (UTC)

@RZuo and LennardHofmann: This is now live. Thanks. Mike Peel (talk) 17:07, 4 July 2023 (UTC)

This section is resolved and can be archived. If you disagree, replace this template with your comment. Mike Peel (talk) 17:07, 4 July 2023 (UTC)

No links if information is folded?

Normally it's possible to switch to other cats if there are items and Commonscats

It seems that isn't possible if the information is folded.

For example Category:Frederick II, Duke of Saxe-Gotha-Altenburg or his wife Category:Magdalena Augusta of Anhalt-Zerbst. You can't switch to the cats of children although they exist.

If you are in the category of one child Category:Frederick III, Duke of Saxe-Gotha-Altenburg you can switch to parents.

Can you fix it? Z ^thomas 07:20, 18 April 2023 (UTC)

Here are some detailed information. I hope you can use it

Frederick II, Duke of Saxe-Gotha-Altenburg (Q61447) and Princess Magdalena Augusta of Anhalt-Zerbst (Q64207) were married and they had 16 children.
- all of their children are added at their wikidata-items and they are shown in the wikida-infoboxes. but they aren't linked in the infoboxes. but you can link between Frederick II, Duke of Saxe-Gotha-Altenburg (Q61447) and Princess Magdalena Augusta of Anhalt-Zerbst (Q64207)
two of their children were Frederick III, Duke of Saxe-Gotha-Altenburg (Q65038) and Johann Adolf of Saxe-Gotha-Altenburg (Q1692285). they have 15 siblings (of course :-) )
- but only 6 siblings are added at their wikidata-items. they are shown in the infoboxes and the are linked. their parents Frederick II, Duke of Saxe-Gotha-Altenburg (Q61447) and Princess Magdalena Augusta of Anhalt-Zerbst (Q64207) are added at their wikidata-items and they are shown and linkes in the wikida-infobox.

Problem:

you can link from the infobox of Frederick III, Duke of Saxe-Gotha-Altenburg (Q65038) to the category of Frederick II, Duke of Saxe-Gotha-Altenburg (Q61447), Princess Magdalena Augusta of Anhalt-Zerbst (Q64207) and Johann Adolf of Saxe-Gotha-Altenburg (Q1692285)
but you can't link from Frederick II, Duke of Saxe-Gotha-Altenburg (Q61447) to Frederick III, Duke of Saxe-Gotha-Altenburg (Q65038) and Johann Adolf of Saxe-Gotha-Altenburg (Q1692285). you can only link to Princess Magdalena Augusta of Anhalt-Zerbst (Q64207)

Statement

at Frederick II, Duke of Saxe-Gotha-Altenburg (Q61447) the information about Frederick III, Duke of Saxe-Gotha-Altenburg (Q65038) and Johann Adolf of Saxe-Gotha-Altenburg (Q1692285) are folded. The information about Princess Magdalena Augusta of Anhalt-Zerbst (Q64207) is unfolded

at Frederick III, Duke of Saxe-Gotha-Altenburg (Q65038) the information about Frederick II, Duke of Saxe-Gotha-Altenburg (Q61447), Frederick III, Duke of Saxe-Gotha-Altenburg (Q65038) and Princess Magdalena Augusta of Anhalt-Zerbst (Q64207) are unfolded

Idea

the folder blocks the links Z ^thomas 14:07, 18 April 2023 (UTC)

@Z thomas: Your observation is correct: collapsed values are not linked. This is an intentional feature to drastically improve performance on some categories like 2010 FIFA World Cup (where the values have very large Wikidata items). The justification is that most readers will probably not look at the collapsed values, but slow page rendering affects every one. Would it help you if the collapsed values were linked to their Wikidata items? If the child (P40) links are important for your work we could also add an exception for that property so that its values are always linked. LennardHofmann (talk) 07:14, 19 April 2023 (UTC)

@LennardHofmann thanks for your answer. Yes this would be helpful, and for the property sibling (P3373) too. Z ^thomas 07:28, 19 April 2023 (UTC)

@Z thomas and LennardHofmann: It's now live. Thanks. Mike Peel (talk) 17:02, 4 July 2023 (UTC)

This section is resolved and can be archived. If you disagree, replace this template with your comment. Mike Peel (talk) 17:02, 4 July 2023 (UTC)

Louvre Collections ID

A request was made in january about a switch between the use of the old Atlas ID to the new Collection ID about Louvre Collections . This small improvement would have only advantages. Would it be possible to make the change? Best regards Shonagon (talk) 06:20, 1 June 2023 (UTC)

@Shonagon: This is now live. Thanks. Mike Peel (talk) 16:55, 4 July 2023 (UTC)

This section is resolved and can be archived. If you disagree, replace this template with your comment. Mike Peel (talk) 16:55, 4 July 2023 (UTC)

Lua error in Module:Wikidata_Infobox at line 160: attempt to index field 'datavalue' (a nil value).

I’m seeing the above error message on some category pages (e.g., Category:Animations of pornography). Can anyone figure out what’s wrong? --Zundark (talk) 08:14, 17 June 2023 (UTC)

@Zundark: It's being caused by "no value" statements in unexpected places on Wikidata, fixed with this edit. Thanks. Mike Peel (talk) 11:08, 17 June 2023 (UTC)

I think this is what was meant. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 18:44, 17 June 2023 (UTC)

Category:Videos from Polissons et galipettes has the same problem. The script error was fixed months ago in the sandbox. LennardHofmann (talk) 08:38, 18 June 2023 (UTC)

That said, on re-examining the file it has captions in English. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 18:56, 18 June 2023 (UTC)

@Zundark, Pigsonthewing, and LennardHofmann: New version of the infobox is now deployed, with Lennard's fix for this issue. Thanks. Mike Peel (talk) 16:53, 4 July 2023 (UTC)

This section is resolved and can be archived. If you disagree, replace this template with your comment. Mike Peel (talk) 16:53, 4 July 2023 (UTC)

wrong display of publication date

publication date (P577) can be used with qualifiers start time (P580) and end time (P582). Publication time spans are used e.g. for books series or periodicals like Biologisches Centralblatt (Q51447486), see the infobox at Category:Biologisches Centralblatt. The statement is currently displayed as
2nd millenniumdate QS:P,+1500-00-00T00:00:00Z/6 (1881–1916)
instead of
2nd millennium (1881–1916).
The display problem started yesterday, afaics. --AmsaTalla (talk) 10:12, 3 July 2023 (UTC)

@AmsaTalla: Thanks for reporting. This is the cause of this edit. @Mike Peel and Jarekt: Please copy Module:WikidataIB/sandbox to Module:WikidataIB. --LennardHofmann (talk) 11:26, 4 July 2023 (UTC)

Thanks for the quick fix @LennardHofmann: it's now live. That seems to have resolved the problem, @AmsaTalla: ? Thanks. Mike Peel (talk) 16:46, 4 July 2023 (UTC)

This section is resolved and can be archived. If you disagree, replace this template with your comment. Mike Peel (talk) 16:46, 4 July 2023 (UTC)

Wikidata property proposal "information sign"

On Wikidata I proposed a new property that could be included as media file into the Wikidata Infobox. So far only one other user has made a comment on the proposal. I think that many Commons users – especially, but not only, architectural and heritage monument photographers – could be interested in such a new property so I hope for some more responses.--Image-Improver Bonn (talk) 13:11, 21 October 2022 (UTC)

The new property information sign (P11702) has been added to the infobox, see e.g. Category:Bonn Minster. --LennardHofmann (talk) 14:42, 5 July 2023 (UTC)

This section is resolved and can be archived. If you disagree, replace this template with your comment. LennardHofmann (talk) 14:42, 5 July 2023 (UTC)

Add a test

{{Edit request}} Module:Wikidata Infobox produces an error on Category:Fièvre (1921 film) : Lua error in Module:Wikidata_Infobox at line 160: attempt to index field 'datavalue' (a nil value).

Could someone with editing rights add a test on the existence of qual.datavalue on that line? Thank you.

I made the change in the sandbox and checked it works. Seudo (talk) 08:06, 12 November 2022 (UTC)

@Seudo: There were some "no value" statements on Wikidata for some reason, now removed, and the infobox works as it is. Although your changes are probably a good idea for making sure the infobox continues to work in such cases, perhaps with a tracking category. Thanks. Mike Peel (talk) 08:44, 12 November 2022 (UTC)

Thanks, but I think it should at least display a more user-friendly message (such as "there is a problem with the X statement at Wikidata"). It's always a good idea to check that a Wikidata/Lua object exists before using it. Seudo (talk) 10:12, 12 November 2022 (UTC)

Thanks for reporting and fixing. The fix is now live! LennardHofmann (talk) 07:32, 5 July 2023 (UTC)

This section is resolved and can be archived. If you disagree, replace this template with your comment. LennardHofmann (talk) 07:32, 5 July 2023 (UTC)

rendering failures due to selfreferening of common categories

hi! https://commons.wikimedia.org/?curid=63916047 is fixed now. in the infobox the link to the wikidata item is now correct and not to the wikidata item of the commons category itself.
the fix was made by deletion of the value of the category from "in other multilingual projects". then this value could be added to the proper wikidata item about Sfânta Sava college.
in theory such errors can happen everywhere. can anybody check for similar misconfigurations? thanks in advance. gangleri aka lery raynhart aka 17:13, 24 November 2022 (UTC) no bias — קיין אומוויסנדיקע פּרעפֿערענצן — keyn umvisndike preferentsn ^{talk contribs} no bias — קיין אומוויסנדיקע פּרעפֿערענצן — keyn umvisndike preferentsn ^{talk contribs} 17:13, 24 November 2022 (UTC)

@קיין ומוויסנדיק פּרעפֿערענצן: The commons category link was correct, the problem was that Saint Sava College (Q3067523) and Category:Saint Sava National College alumni (Q8698590) weren't linked together using category combines topics (P971) and category's main topic (P301) - I've now done that. @LennardHofmann: do you think it would be feasible to add a tracking category for cases of instance of (P31)=Wikimedia category (Q4167836) that don't have category's main topic (P301) - and also, don't have category combines topics (P971), since those mostly wouldn't have corresponding topic items? Thanks. Mike Peel (talk) 07:41, 25 November 2022 (UTC)

The tracking category proposed by Mike Peel has been added in Special:Diff/709334144 and is live. See also #Add tracker category if category doesn't have enough information. LennardHofmann (talk) 07:32, 5 July 2023 (UTC)

This section is resolved and can be archived. If you disagree, replace this template with your comment. LennardHofmann (talk) 14:42, 5 July 2023 (UTC)

Please link "Author"

Please see Category:Die Vogelwarte Rossitten der Deutschen Ornithologischen Gesellschaft und das Kennzeichnen der Vögel (1910). I expect "Johannes Thienemann" as the author being linked to Category:Johannes Thienemann (at d:Q67915 Commons sitelink and P373 are ok afaik). thx AmsaTalla (talk) 18:25, 29 December 2022 (UTC)

Thanks for reporting. Authors not being linked was actually an issue on all category pages. This is now fixed in {{Wikidata Infobox/sandbox}}. —LennardHofmann (talk) 13:18, 31 December 2022 (UTC)

Ping@User:Mike Peel: For books and alike, editor (P98), illustrator (P110), publisher (P123), etc… all are linked in infoboxes, only author (P50) is unlinked. This is bad. Is there a chance that this will be fixed also for "real" infoboxes, not only in the sandbox? AmsaTalla (talk) 19:44, 17 April 2023 (UTC)

This section is resolved and can be archived. If you disagree, replace this template with your comment. LennardHofmann (talk) 07:32, 5 July 2023 (UTC)

Statements to be displayed

Please, display provisional house number (P6529) just in the same way as conscription number (P4856) is displayed. That is an alternative type of house numbers. Thank You. ŠJů (talk) 03:08, 29 July 2023 (UTC)

Added to {{Wikidata Infobox/sandbox}}. --LennardHofmann (talk) 10:41, 30 July 2023 (UTC)

@LennardHofmann and ŠJů: This is now live. Thanks. Mike Peel (talk) 13:28, 13 August 2023 (UTC)

This section is resolved and can be archived. If you disagree, replace this template with your comment. Mike Peel (talk) 13:28, 13 August 2023 (UTC)

OpenStreetMap link does not work?

Can it be that the OpenStreetMap links do not work?

Examples:

Molgreen (talk) 05:22, 10 August 2023 (UTC)

@Molgreen: Thanks for reporting. The examples you gave are small objects (modeled as nodes in OSM); the links work fine for bigger entities (ways and relations). I have fixed the issue with nodes in the sandbox module. The fix will go live in a few weeks or months. But even then it might still say "No results found" if the OSM element is missing the wikidata=Qxxx tag. --LennardHofmann (talk) 10:45, 10 August 2023 (UTC)

@LennardHofmann, Thanks for your feedback and the fix --Molgreen (talk) 17:13, 10 August 2023 (UTC)

@LennardHofmann and Molgreen: Thanks for the fix. It's now live. Thanks. Mike Peel (talk) 13:25, 13 August 2023 (UTC)

This section is resolved and can be archived. If you disagree, replace this template with your comment. Mike Peel (talk) 13:25, 13 August 2023 (UTC)

Category:Uses of Wikidata Infobox with no image - please exclude dates of months

Can dates of months, like Category:1 April and Category:16 August, also be excluded from this category? I think it is rather nonsensical to have images in Wikidata infoboxes of these categories. JopkeB (talk) 15:25, 13 June 2023 (UTC)

can https://www.wikidata.org/w/index.php?title=Q2812&diff=prev&oldid=1914441375 be a compromise solution? RZuo (talk) 15:44, 13 June 2023 (UTC)

Yes, but that means that 366 items should be adjusted. If there is a less time consuming way, I would rather have that. JopkeB (talk) 15:50, 13 June 2023 (UTC)

it's possible to batch edit wikidata items using d:Help:QuickStatements.

if wikidata users agree that this solution, "setting no image" for certain wikidata items, is acceptable, you can batch edit them, or you can also ask someone familiar with QS to do that for you. RZuo (talk) 15:59, 13 June 2023 (UTC)

As a Wikidata contributor: Setting no image is not acceptable. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 16:10, 13 June 2023 (UTC)

Of course such categories should have an image. If they're overwhelming the category under discussion, a sub-category should be created. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 16:10, 13 June 2023 (UTC)

set p18 for Category:16 August as an example to enlighten other users then. RZuo (talk) 18:13, 13 June 2023 (UTC)

Agree --JopkeB (talk) 03:53, 14 June 2023 (UTC)

Thanks, RZuo, for your answers.

1) How do I get permission for this solution? Where should I asked permission?

2) I have never used QuickStatements, but I do want to learn. So after there is permission, I'll first try to figure out how it works and then perhaps ask for help.

--JopkeB (talk) 03:51, 14 June 2023 (UTC)

you can raise the issue at d:Wikidata:Project_chat and see what they think is the solution to image (P18) for these kinds of abstract ideas. RZuo (talk) 06:51, 14 June 2023 (UTC)

Thanks, User:RZuo. I posed the question at d:Wikidata:Project chat#c:Category:Uses of Wikidata Infobox with no image - can dates of months be excluded?. JopkeB (talk) 08:20, 15 June 2023 (UTC)

In the mean time I found a solution, Andy Mabbett was right: there is a possibility for images, even for dates of months. We can use icons of calender sheets for each day. It is a lot of work, but it is not nonsensical to have them in Wikidata items for dates of months. They can be found in Category:Calendar icons (all icons of dates there now, have been better categorized and used in a Wikidata item). I used icon (P2910) instead of image (P18).

For over 300 dates there is not yet an icon. Who wants to help, can do so! You may choose yourself the color, layout, language (only Latin script and Arabic numerals) and extension. Take care that in Commons you give credit to the maker. Choose as Commons categories: (1) the date (a grandchild of Category:Days by month) and (2) Category:Calendar icons or a subcategory.

I withdraw my nomination

Thanks, RZuo for your input. JopkeB (talk) 14:59, 15 June 2023 (UTC)

yes i know this kind of icons could be an option, but is this a good choice for p18 for the abstract idea of a date?

off-topic: is there a design for "date icon" independent of languages? (we'll take arabic numerals for granted, even though some languages dont even use arabic numerals.) RZuo (talk) 15:31, 15 June 2023 (UTC)

i was aware of this problem, so i didnt use "1 april" as an example at the beginning, because an "april fools" image could be set for that, even though the concept of april fool's day also originated from european cultures, but it's now quite universally understood.

imo, for abstract ideas, p18 should be as universal as possible. it shouldnt rely on culture/language-specific contexts to understand. wikt:en:August#Translations quite many languages (including european languages like irish!) dont use a word that has the same origin as august. RZuo (talk) 15:43, 15 June 2023 (UTC)

in addition to p2910, montage image (P2716) can also be an option. RZuo (talk) 16:13, 15 June 2023 (UTC)

That is a good point you bring up. No, I do not think icons for dates can be universal and independant from culture and language. And a collage image certainly can be an alternative. But I think for now we should be practical, something is better than nothing, the alternative for now would be having no image at all (because uploading over 300 icons and include them in Wikidata items is already a lot of work, but searching for several icons and combining them to a collage image is a lot more and I won't do that). So for now, I am going on with uploading icons for datums, with European biased images, even somewhat broader than the rules for category names (should be in English). I hope people from other cultures can at least see the icon depicts a calender and gives them a clue about the subject. Whoever wants images that include other cultures and languages, can make them and replace the current ones. JopkeB (talk) 05:14, 16 June 2023 (UTC)

New topic created at d:Wikidata:Project_chat#c:Category:Uses_of_Wikidata_Infobox_with_no_image_-_can_dates_of_months_be_excluded?. Multichill (talk) 20:42, 15 June 2023 (UTC)

This section is resolved and can be archived. If you disagree, replace this template with your comment. Mike Peel (talk) 19:37, 8 September 2023 (UTC)

Military service

@Mike Peel Can we expand the infobox for military people? See: w:Douglas MacArthur versus Category:Douglas MacArthur. --RAN (talk) 21:27, 6 July 2023 (UTC) MacArthur

@Richard Arthur Norton (1958- ): Can you be more specific and name Wikidata property IDs that could be added, please? It's straightforward to add more Wikidata properties to the Infobox, but rather more complex to decipher them from the enwiki infobox. Thanks. Mike Peel (talk) 13:30, 13 August 2023 (UTC)

This section is resolved and can be archived. If you disagree, replace this template with your comment. Mike Peel (talk) 19:37, 8 September 2023 (UTC)

Requested move to Template:Wikidata infobox

{{Edit protected}} Hello, this template needs renaming (moving) to Template:Wikidata infobox. Rationale is that 'infobox' is not a proper noun, and all other 'infobox' templates on En.Wp use the lower-case 'second' (and additional) words in their title, such as w:Template:Infobox person, w:Template:Infobox road. Only proper nouns should be capitalised, such as w:Template:Infobox Pennsylvania historic site, w:Template:Infobox Philippine Congress, etc. Regards. Militum professio scriniarii (talk) 12:53, 8 August 2023 (UTC)

While I'd also like 'nice and tidy and grammatically correct', such a change doesn't really benefit the project, nor does it matter in the least how en.wiki formats their template titles. — Huntster (t @ c) 13:56, 8 August 2023 (UTC)

I Completely Agree That The Template Currently Has An Incorrect Name And Should Be Named Template:Wikidata infobox, But I Don't Think It's Worth The Effort. Multichill (talk) 19:24, 8 August 2023 (UTC)

So why the actual reluctance to rename? Bots can happily fix all the redirects. I am not sure what 'effort' is required (though if I have missed something, please enlighten). I also noticed this issue was raised before (I subsequently searched the archives after my original comment), and there was support for the rename, but it seems apathy wins! :p Militum professio scriniarii (talk) 19:01, 9 August 2023 (UTC)

@Militum professio scriniarii, Huntster, and Multichill: It's complicated. ;-) It's not apathy, but I should have provided more background in the earlier discussion.

I deliberately used Infobox starting with a capital letter since this is aimed at being the Wikidata Infobox here that applies to all categories and topics, as opposed to one of many infoboxes on different topic areas like the Wikipedias used - so it's more of a proper name than a description. Whether that was the right thing to do or not can always be debated. ;-)
The name is hard-coded in the various Python scripts that I use to deploy the Infobox, all of which would have to be updated if we renamed it. Possible, but extra work.
The Infobox is live in around 4.5 million categories - if we renamed it and wanted to avoid all of those uses going through a redirect, that would be a lot of edits to make!
Functionally, and bearing in mind all the work that would be needed, would it make a practical difference?

Thanks. Mike Peel (talk) 13:22, 13 August 2023 (UTC)

This section is resolved and can be archived. If you disagree, replace this template with your comment. Mike Peel (talk) 19:37, 8 September 2023 (UTC)

Add Wikidocumentaries link

Wikidocumentaries is a website that navigates Wikimedia content based on Wikidata items and properties. It is especially focused on displaying materials visually. See an example page that features an upload banner for Wiki Loves Monuments https://wikidocumentaries-demo.wmcloud.org/Q97440924.

In the coming week, we are adding a new feature to import media that has been found in connected external repositories into Wikimedia Commons with a simple upload process. This has been developed as Google Summer of Code 2023 project.

Wikidocumentaries can be extended to display information in many ways and to allow many tools to work with the content, and for anyone to add to the project. – Susanna Ånäs (Susannaanas) (talk) 13:29, 3 September 2023 (UTC)

looks like an amazing tool! thx a lot!

Support addition to wdib. RZuo (talk) 12:22, 4 September 2023 (UTC)

@Susannaanas and RZuo: Added. Thanks. Mike Peel (talk) 18:53, 8 September 2023 (UTC)

This section is resolved and can be archived. If you disagree, replace this template with your comment. Mike Peel (talk) 18:53, 8 September 2023 (UTC)

Add legal form P1454

Please add legal form https://www.wikidata.org/wiki/Property:P1454 - it helps to determine the type of object one is looking at.

Cf. https://www.wikidata.org/wiki/Special:WhatLinksHere/Property:P1454 77.183.118.104 11:54, 5 September 2023 (UTC)

Added. Thanks. Mike Peel (talk) 18:52, 8 September 2023 (UTC)

This section is resolved and can be archived. If you disagree, replace this template with your comment. Mike Peel (talk) 18:52, 8 September 2023 (UTC)

Severely broken now

evidence: preview this. Problem: links outside of the box. Taylor 49 (talk) 18:36, 7 September 2023 (UTC)

To my knowledge this only effects outreach: and ak: sitelinks, which are used rarely on Wikidata (mostly on Wikimedia-internal items). I've already taken of outreach links leaking out in the sandbox. I don't think that an exception for akwiki is needed, given that it has been closed so the Wikidata sitelinks to it will probably be deleted soon. --LennardHofmann (talk) 09:26, 8 September 2023 (UTC)

@LennardHofmann: I'll make the sandbox live this eve. Would it be worth adding ak in there temporarily? (I don't know how long the process of removing them from Wikidata will take, this isn't a usual situation.) Thanks. Mike Peel (talk) 15:34, 8 September 2023 (UTC)

@Taylor 49 and LennardHofmann: Now live. Thanks. Mike Peel (talk) 18:52, 8 September 2023 (UTC)

Why does this (broken links outside of the box) happen at all? Now live Well ... "outreach" is gone, broken "ak" link still there. Taylor 49 (talk) 16:26, 9 September 2023 (UTC)

See #Template inserting page name as plain text on every page. Thanks. Mike Peel (talk) 18:05, 9 September 2023 (UTC)

Yeah I see Commons:Village_pump/Archive/2023/09. Taylor 49 (talk) 19:22, 9 September 2023 (UTC)

This section is resolved and can be archived. If you disagree, replace this template with your comment. Taylor 49 (talk) 19:22, 9 September 2023 (UTC)

Capitalized title

{{Edit protected}} Hello. Could someone please add ~~{{lc:~~ to the title of the infobox? In Wikidata, terms are usually not capitalized in Slovene, which is then also displayed in lowercase in titles of Wikidata infoboxes here. Thank you. --TadejM ^(t/p) 11:16, 26 April 2023 (UTC)

@TadejM: This is a WONTFIX, you need to set labels appropriately on Wikidata, the infobox just makes use of them. I've tried selective title formatting here before, and it doesn't work well, since the infobox applies to all topics (should people names be lower case?), and all languages (should all languages be lower case?)... Thanks. Mike Peel (talk) 14:49, 26 April 2023 (UTC)

Mike Peel, do you know perhaps what is the current guideline on Wikidata? It seems unnatural to use capitalized common nouns as only proper nouns should be capitalized in Slovene. The same also applies to English as I see English common nouns are not capitalized in Wikidata either. On the other hand, it is grammatically incorrect to start a heading lowercase. --TadejM ^(t/p) 14:59, 26 April 2023 (UTC)

Mike Peel, it's a lapsus on my part. My apologies. Actually the request should be just the opposite, to start the heading uppercase. So the request is to add {{uc: or whatever works in the code. --TadejM ^(t/p) 15:02, 26 April 2023 (UTC)

@TadejM: The same issues still apply. Another example is, what to do with "iPhone"? It's an idea that sounds good, but is really difficult to implement - hence why it's best sorted out on Wikidata somehow. Suggest asking there at d:Wikidata:Project_chat. Thanks. Mike Peel (talk) 07:34, 27 April 2023 (UTC)

@Mike Peel: Thank you for the reply. I understand that there may be issues with certain names, such as iPhone. Would it be possible to implement the uppercase as default and the lowercase as an option? --TadejM ^(t/p) 12:12, 27 April 2023 (UTC)

Not really. E.g., what happens if you want uc in one language and lc in another? Thanks. Mike Peel (talk) 18:14, 27 April 2023 (UTC)

Would it be possible to implement this on a per language basis? The code would contain default uppercase capitalization and would allow override for individual languages or all languages. It really does not seem the correct way of action to change capitalization in Wikidata just for the purpose of correct display in infoboxes on Commons. --TadejM ^(t/p) 01:24, 28 April 2023 (UTC)

That sounds very messy and difficult to maintain, I suggest opening this up for wider discussion (perhaps village pump here, or project chat on Wikidata) to see what others think. Thanks. Mike Peel (talk) 18:39, 29 April 2023 (UTC)

@Mike Peel, this would be handled best and without unnecessary hassle by implementing this solution only for 'sl' and other languages may be later added as required. However, if you think a wider community discussion is required I will open a discussion. --TadejM ^(t/p) 22:09, 29 April 2023 (UTC)

This section is resolved and can be archived. If you disagree, replace this template with your comment. Mike Peel (talk) 10:49, 28 October 2023 (UTC)

Infobox where sitelink to commons is a gallery, not a category

Hi @Mike Peel: , as an example see Kufstein Fortress (Q700709), which has a site link to a commons gallery: Festung Kufstein and a Commons category (P373) with value category:Festung Kufstein. The Infobox in category:Festung Kufstein does not show the content of the WD-entry as long as there is no qid-Parameter added to the call of {{Wikidata Infobox}}: [12]. As manually maintaining qids is annoying, can you please change the implementation to use P373 in case the sitelink is a gallery. Or do something equivalent with the same result. best --Herzi Pinki (talk) 10:12, 18 August 2023 (UTC)

You create a Wikidata item for the category like Category:Festung Kufstein (Q121712186) and make the sitelink to Commons "Category:Festung Kufstein" with category's main topic (P301) of Kufstein Fortress (Q700709) and the reverse statement on Kufstein Fortress (Q700709) topic's main category (P910) of Category:Festung Kufstein (Q121712186). Then the template will show the information from the main item. --William Graham (talk) 22:51, 20 August 2023 (UTC)

This is the workaround, isn't it? --Herzi Pinki (talk) 04:30, 24 August 2023 (UTC)

@Herzi Pinki and William Graham: This is the way it has to work. The category on Commons can only see the connected Wikidata item when the sitelink exists, P373 is a query away. This is why sitelinks are so important and P373, um, isn't and should be deleted. It's best to set up the category items on Wikidata. Thanks. Mike Peel (talk) 18:57, 8 September 2023 (UTC)

@Mike Peel: your proposal, which I don't fully understand, is way more complicated than explicitly adding the Qid to the infobox (as in [13]). Or way more complicated as compared to replacing the sitelink to a commons gallery by the corresponding commons category. I can live with empty infoboxes on commons, there will be someone else to follow these tedious manual steps. --Herzi Pinki (talk) 19:47, 8 September 2023 (UTC)

@Herzi Pinki: Sitelinks are the established way to go here (they're the way that 4m+ infoboxes are working), and they aren't that complicated. Add manual qids if you need, and I'll try to clean them up later. Thanks. Mike Peel (talk) 19:50, 8 September 2023 (UTC)

sitelinks do work perfectly if they link to the corresponding commons category. Maybe one in 1000 sitelinks links to a commons gallery. So your proposal is to artificially create non-real-world-objects für categories in the other 999 cases? This expects endless resources and endless time, which I do not see and which I'm from day to day less willing to spend. best --Herzi Pinki (talk) 20:00, 8 September 2023 (UTC)

@Herzi Pinki: No, for the 999 cases, just link to the Commons category in the sitelink. For the 1/1000th case, create a new category item. It's the best practical solution that I've found so far. Thanks. Mike Peel (talk) 20:03, 8 September 2023 (UTC)

This section is resolved and can be archived. If you disagree, replace this template with your comment. Mike Peel (talk) 10:49, 28 October 2023 (UTC)

Edit request: fix iw.toolforge.org link

{{Edit request}} Please apply this sandbox diff to the module, so that the infobox links directly to kmlexport.toolforge.org and skips the iw.toolforge.org/kmlexport redirect. This should be a tiny bit faster for users, and more importantly integrates better with Special:LinkSearch. (In the longer term, we could also consider a dedicated interwiki for this, see related discussion; but I’d like to fix the iw.toolforge.org link first.) Pinging Mike Peel as the main maintainer; also, note to any fulfilling admin: the sandbox has a few additional changes that weren’t added to the main module yet, so don’t copy the whole contents unless you also want to add those changes :) Lucas Werkmeister (talk) 15:53, 29 September 2023 (UTC)

@Lucas Werkmeister: Thanks for the edit. Unless this is urgent, I'd like to wait a bit and make it live in the next batch update, if that's OK? Thanks. Mike Peel (talk) 09:04, 30 September 2023 (UTC)

@Mike Peel: Works for me as long as the next batch update is not, like, several months away ^^ thanks! Lucas Werkmeister (talk) 15:47, 1 October 2023 (UTC)

@Lucas Werkmeister: Now live. Thanks. Mike Peel (talk) 10:48, 28 October 2023 (UTC)

This section is resolved and can be archived. If you disagree, replace this template with your comment. Mike Peel (talk) 10:48, 28 October 2023 (UTC)

Outside link

In the Category:Pages with script errors the template generates an outside link towards f:Category:Pages with script errors, but only when included in category pages (this also happens with {{Wikidata Infobox|qid=Q7192108}}). --ZandDev (talk) 19:22, 25 October 2023 (UTC)

Already fixed in the sandbox. Thanks for reporting anyway. LennardHofmann (talk) 07:57, 26 October 2023 (UTC)

The fix is now live. Thanks. Mike Peel (talk) 10:47, 28 October 2023 (UTC)

This section is resolved and can be archived. If you disagree, replace this template with your comment. Mike Peel (talk) 10:47, 28 October 2023 (UTC)