Wikimedia Commons

Template talk:Wikidata Infobox/Archive 2

< Template talk:Wikidata Infobox
Latest comment: 4 years ago by Pigsonthewing in topic Population

(given name) category

Latest comment: 5 years ago8 comments4 people in discussion

Hi, I noticed my new category Category:Félix_Mesnil (for example) had the infobox added and now the automatically added "Category:Félix (given name)" precedes whatever other categories are there. As this is an arbitrary category (it has nothing to do with the person, it relays no information about them), would it be possible to move it to the end or hide it? I would even suggest to remove it altogether. If there is a discussion about this already, can you point me to it please? Thanks -- Deadstar (msg) 19:05, 11 June 2018 (UTC)

@Deadstar: Since the infobox is at the top of the page, the categories it adds end up at the start of the list. I can easily tweak the code to put it after the date of birth/death categories if that would help. Hiding or deleting the categories would probably be best done as a site-wide discussion, as I understand that some people find them useful, and that's a wider discussion than just this infobox. Note that the infobox also adds a family name category, such as Category:Mesnil (surname), where available - I guess that's more useful though since it groups families/relations? Thanks. Mike Peel (talk) 00:57, 12 June 2018 (UTC)
Thanks Mike - and after the birth/death would be a great improvement. (So birth/death/firstname/lastname/other cats?). As for usefulness... it's all in the eye of the beholder I guess! Thanks for your help & quick reply. -- Deadstar (msg) 07:40, 12 June 2018 (UTC)
@Deadstar: The order has now been swapped, how does that look? Thanks. Mike Peel (talk) 00:23, 13 June 2018 (UTC)
Great - that looks a lot better. Thanks so much! -- Deadstar (msg) 08:38, 13 June 2018 (UTC)
It will be a big progress again a time. And why not a categorisation with the place of burial. Jérémy-Günther-Heinz Jähnick (talk) 09:02, 13 June 2018 (UTC)
This section was archived on a request by: Mike Peel (talk) 19:11, 29 October 2018 (UTC)

Interstate 77

Latest comment: 5 years ago8 comments2 people in discussion

Category:Interstate 77 runs through five states; South Carolina, North Carolina, Virginia, West Virginia, and Ohio. Why is only Ohio included in the Wikidata Infobox? ----DanTD (talk) 12:05, 29 September 2018 (UTC)

@DanTD: It's due to the current code to extract the chain of locations, which assumes only one value for located in the administrative territorial entity (P131). I've written a work-around in {{Wikidata Infobox/sandbox}} that seems to work OK here (please test it!), will be deployed soon. Thanks. Mike Peel (talk) 21:30, 29 September 2018 (UTC)
It's now live. Thanks. Mike Peel (talk) 21:48, 29 September 2018 (UTC)
Sorry, but it isn't. Category:Interstate 95 has every state it goes through listed here. ----DanTD (talk) 23:14, 29 September 2018 (UTC)
UPDATE -- Okay, now I see the states, but it still only has the Ohio DOT as the owners. ----DanTD (talk) 23:16, 29 September 2018 (UTC)
@DanTD: That's because Interstate 77 (Q94764) only has owned by (P127)=Ohio Department of Transportation (Q4955209), add more values on Wikidata and they should be displayed. Thanks. Mike Peel (talk) 23:23, 29 September 2018 (UTC)
Okay, so far so good. As soon as I can find a way to add the numbered highway lists from other states and add the note that it's not in Spanish, I should be done. ----DanTD (talk) 05:28, 1 October 2018 (UTC)
This section was archived on a request by: Mike Peel (talk) 18:42, 29 October 2018 (UTC)

Species and other taxons: Sitelinks from synonyms

Latest comment: 5 years ago9 comments3 people in discussion

In a recent discussion at Wikidata, it was mentioned that there may be interest in having sitelinks to Wikipedia articles generally considered synonyms, if there is no article about the taxon on a page (or a category in this case). This can be done with Template:Interwikis from P1420 adapted for Wikidata d:property:P1420.

This query shows potential additional sitelinks that would be displayed (obviously, not all these pages have the infobox).

If you are interested in this, please add {{Interwikis from P1420}} to this infobox. Jura1 (talk) 00:52, 24 October 2018 (UTC)

@Jura1: It's now in {{Wikidata Infobox/sandbox}} with this edit. Please can you check that it is working as you expect it to in some categories with taxon synonym (P1420)? @Christian Ferrer and Liné1: if you have a minute, please can you also test this as a taxon-specific change? Thanks. Mike Peel (talk) 06:43, 24 October 2018 (UTC)
It seems fine, thanks you, currently tested in Category:Rhodophana nitellina, ping @Strobilomyces: who will likely be interested. Christian Ferrer (talk) 17:07, 24 October 2018 (UTC)
This section was archived on a request by: Mike Peel (talk) 18:35, 29 October 2018 (UTC)

URL taking too much space

Latest comment: 5 years ago8 comments3 people in discussion

Dear all,
I have remarked for example in Category:Bordj el Kebir fort (Mahdia) that the template currently returns a URL from Wikidata. However, because of the link length, this makes the box quite invasive on the screen. Is there anyway we can avoid this link to show here or at least replace with a generic [URL link]? Moumou82 (talk) 20:36, 25 October 2018 (UTC)

@Moumou82: It worked OK in Firefox for me, but I could see the problem in Safari, so I've now implemented a fix in {{Wikidata Infobox/sandbox}}, which is temporarily in use in that category. Does that look better? Thanks. Mike Peel (talk) 08:35, 27 October 2018 (UTC)
@Mike Peel: Thank you for looking into this. I see the link is now cut in different pieces so that it fits into the box but the picture is now overflowing from the box (on the right). Would it not be simpler not to show such link? I would expect the goal is to show the actual value and keep references and details for Wikidata. Moumou82 (talk) 13:30, 27 October 2018 (UTC)
@Moumou82: The image positioning should be fixed. I'm not sure why the URL is there rather than as a reference, perhaps @André Costa (WMSE): can explain why his bot added it as a qualifier instead of a reference. Thanks. Mike Peel (talk) 16:11, 27 October 2018 (UTC)
It would seem to be because the qualifier used is described at URL (P973), while the reference uses reference URL (P854) for a different url. If folks are going to put giant urls into qualifiers, then I guess we have to cope with having giant urls in our infoboxes. Or do you want me to write yet more code that truncates any value greater than a certain size, or recognises urls and replaces them with a link that has shorter display text (if so, what text)? It's the usual problem with Wikidata: all of the thought goes into how as much data as possible can be imported, and none of the thought goes into how that data can be exported. I'm increasingly coming to the conclusion that we're creating the biggest white elephant ever built. --RexxS (talk) 17:05, 27 October 2018 (UTC)
I think we cope with it as-is in the infobox. Hopefully it shouldn't happen too often as it is causing a constraint violation on Wikidata. I disagree about the white elephant bit - I'm still optimistic overall. :-) Thanks. Mike Peel (talk) 17:27, 27 October 2018 (UTC)
@Moumou82: This is now live. Thanks. Mike Peel (talk) 18:39, 29 October 2018 (UTC)
This section was archived on a request by: Mike Peel (talk) 18:39, 29 October 2018 (UTC)

Wrong representation

Latest comment: 5 years ago4 comments2 people in discussion
 
Screenshot

Moin Moin together, for some days, text from the infobox overlaps. In the screenshot you will see the problem. Could you fix it? Regards --Crazy1880 (talk) 09:35, 31 October 2018 (UTC)

@Crazy1880: I've tweaked the formatting, can you check again and see if it still has an issue? (and/or point me to the category where this is happening.) Thanks. Mike Peel (talk) 20:53, 31 October 2018 (UTC)
Moin Mike Peel, at the moment I work with the categories people, Wikidata Infobox (all around) and Media needing categories. It looks much better now. Big thanks --Crazy1880 (talk) 19:17, 1 November 2018 (UTC)
This section was archived on a request by: Mike Peel (talk) 19:26, 1 November 2018 (UTC)

Units

Latest comment: 5 years ago6 comments3 people in discussion

Hi,

Right now, this template give the name of the unit without putting a plural : « 2 metre » in English or « 2 mètre » in French. Grammatically, this is wrong. I see at least two possible solutions :

  • a simple one would be to put the symbol (« 2 m »)
  • a better but more complex one would be to put the plural (« 2 metres », « 2 mètres » )

Cheers, VIGNERON (talk) 08:29, 10 October 2018 (UTC)

@VIGNERON: The module has had the capability to show abbreviations for some time, but I've taken the opportunity to internationalise it by using unit symbol (P5061) in Wikidata along with the language fallbacks:
  • {{#invoke:WikidataIB/sandbox |getValue |P2386 |qid=Q1513315 |fwd=ALL |osd=n}} → 10 metre, 1 metre  
  • {{#invoke:WikidataIB/sandbox |getValue |P2386 |qid=Q1513315 |fwd=ALL |osd=n |unitabbr=yes}} → 10 m, 1 m  
  • {{#invoke:WikidataIB/sandbox |getValue |P2386 |qid=Q1513315 |fwd=ALL |osd=n |lang=bn}} → ১০ মিটার, ১ মিটার  
  • {{#invoke:WikidataIB/sandbox |getValue |P2386 |qid=Q1513315 |fwd=ALL |osd=n |unitabbr=yes |lang=bn}} → ১০ m, ১ m  
The lang parameter only affects the unit symbol, so you'll see "metre" in your own language.
Plurals is a different issue. I don't think I can write a fully internationalised routine that provides the plural of every possible unit name in every supported language. I suppose I could do all the ones that just suffix an 's' in a lookup table. I'll have a think about it. --RexxS (talk) 16:21, 10 October 2018 (UTC)
[Further] @VIGNERON: actually, it's not so bad for English. I've made a module to return plurals of units at Module:Plural for now. I've only done English units, but it should be easily expandable for other, similar languages. Here are some tests:
  • {{#invoke:Plural |main |unit=square foot}} → square feet
  • {{#invoke:Plural |main |unit=square foot |lang=en}} → square feet
  • {{#invoke:Plural |main |unit=mile}} → miles
  • {{#invoke:Plural |main |unit=horsepower}} → horsepower
  • {{#invoke:Plural |main |unit=mile per hour}} → miles per hour
  • {{#invoke:Plural |main |unit=inch per second}} → inches per second
  • {{#invoke:Plural |main |unit=mètre |lang=fr}} → mètre
  • {{#invoke:Plural |main}} →
@Mike Peel: That looks like it might be a way forward, possibly? I will have to require() it to use it in WikidataIB, of course, if it's satisfactory. --RexxS (talk) 20:37, 10 October 2018 (UTC)
@VIGNERON and RexxS: Unit abbreviations are now in {{Wikidata Infobox/sandbox}} for testing. That's probably better than plurals here as it is more compact. Please test and post here if there are any problems. Thanks. Mike Peel (talk) 19:05, 29 October 2018 (UTC)
@VIGNERON: This is now live. Thanks. Mike Peel (talk) 21:13, 2 November 2018 (UTC)
This section was archived on a request by: Mike Peel (talk) 21:13, 2 November 2018 (UTC)

Logo language

Latest comment: 5 years ago8 comments3 people in discussion

Category:Yandex.Music

Why am I not seeing the English logo? (I use Commons in English) - Alexis Jazz ping plz 14:21, 10 October 2018 (UTC)

@Alexis Jazz: The infobox uses the first logo it fetches from Wikidata, not looking at the language. I'll see if I can modify that soon. BTW, it's best to raise this kind of issue at Template talk:Wikidata Infobox to keep them all in one place. Thanks. Mike Peel (talk) 14:51, 10 October 2018 (UTC)
Copied it here, I'll try to remember next time. Thanks. - Alexis Jazz ping plz 14:55, 10 October 2018 (UTC)
We already have a function that works if the logo exists in the user's language. See Yandex Music (Q4537983) logo image (P154):
{{#invoke:WikidataIB |getValueByLang |P154 |fwd=ALL |osd=n |qid=Q4537983}} → Yandex Music EN logo 2023.svg  
{{#invoke:WikidataIB |getValueByLang |P154 |fwd=ALL |osd=n |lang=en |qid=Q4537983}} → Yandex Music EN logo 2023.svg  
{{#invoke:WikidataIB |getValueByLang |P154 |fwd=ALL |osd=n |lang=ru |qid=Q4537983}} → Yandex Music logo 2023.svg  
{{#invoke:WikidataIB |getValueByLang |P154 |fwd=ALL |osd=n |lang=fr |qid=Q4537983}} →
{{#invoke:WikidataIB |getValueByLang |P154 |fwd=ALL |osd=n |lang=en-gb |qid=Q4537983}} →
Still might need some sorting out, depending on what behaviour you want for (e.g.) en/en-gb/en-us. For the other side of the problem, see:
In meat (Q10990), the value of the property pronunciation audio (P443) which has the fixed qualifier "language of work or name" equal to a given language code (or default) is:
{{#invoke:WikidataIB |getValueByLang |qid=Q10990 |P443 |fwd=ALL |osd=no |noicon=true}}
{{#invoke:WikidataIB |getValueByLang |qid=Q10990 |P443 |fwd=ALL |osd=no |noicon=true |lang=sv}}
{{#invoke:WikidataIB |getValueByLang |qid=Q10990 |P443 |fwd=ALL |osd=no |noicon=true |lang=en}}
{{#invoke:WikidataIB |getValueByLang |qid=Q10990 |P443 |fwd=ALL |osd=no |noicon=true |lang=en-gb}}
{{#invoke:WikidataIB |getValueByLang |qid=Q10990 |P443 |fwd=ALL |osd=no |noicon=true |lang=en-us}}
I suppose you could use {{If then show}} to supply the one in the user language or the first image if the the one in the user language doesn't exist. Thoughts? --RexxS (talk) 16:44, 10 October 2018 (UTC)
@Alexis Jazz and RexxS: This is now in {{Wikidata Infobox/sandbox}} and mostly works. I was expecting [1] to work for en-gb, but it doesn't seem to. However, that's probably a minority of use, so the current behaviour is probably fine for now, if you agree? Thanks. Mike Peel (talk) 18:58, 29 October 2018 (UTC)
@Mike Peel: I'm not really sure what this means so I can't really say, but Category:Yandex.Music looks fine. - Alexis Jazz ping plz 19:15, 29 October 2018 (UTC)
@Alexis Jazz: This is now live. Thanks. Mike Peel (talk) 21:12, 2 November 2018 (UTC)
This section was archived on a request by: Mike Peel (talk) 21:12, 2 November 2018 (UTC)

Dates, more tweaking

Latest comment: 5 years ago15 comments4 people in discussion

Hi, When a qualifier is specified, it is not displayed properly, cf. Category:James S. Ogilvy. The qualifier for the date of birth is before 1850, while the infobox displays only 1850. You can see that the Creator template does it right. Regards, Yann (talk) 17:40, 15 October 2018 (UTC)

@Mike Peel: What do you think? Regards, Yann (talk) 17:33, 19 October 2018 (UTC)
  Support for using Module:Complex date as {{Creator}} does. Date display of this template is really all but nice. --Marsupium (talk) 22:27, 25 October 2018 (UTC)
Complex date should already be in use here. It might need a special case coding in to WikidataIB to handle it, though - @RexxS: something you could have a look at? Thanks. Mike Peel (talk) 08:36, 27 October 2018 (UTC)
@Mike Peel, Yann, and Marsupium: The complication is that latest date (P1326) was added as a special case by Ans before the code handled qualifiers more generally. Implementing qualifiers supplied by parameter meant excluding P1326 from that, so it isn't passed to complex_date. Because the code in WikidataIB is general, not set for one specific purpose, the code returns the qualifier "value" in parentheses, but not the property label of the qualifier, as I assumed that the shortest representation would be preferred. I've amended it so that it catches P1326 and adds the "before" then passes it to complex date for internationalisation. For James S. Ogilvy (Q57338643), date of birth (P569):
  • {{#invoke:WikidataIB/sandbox |getValue |P569 |qid=Q57338643 |ps=1 |qual=P1326}} → 19th century (before 1850)
  • {{#invoke:WikidataIB/sandbox |getValue |P569 |qid=Q57338643 |ps=1 |qual=P1326 |lang=fr}} → XIXe siècle (avant 1850)
  • {{#invoke:WikidataIB/sandbox |getValue |P569 |qid=Q57338643 |ps=1 |qual=P1326 |lang=nl}} → 19e eeuw (voor 1850)
The downside is that previous uses that relied on the module supplying latest date qualifier by default will now need to set |qual=P1326. Sorry, but I can't see a way of avoiding that and keeping it clean. Naturally, these changes are only in sandbox. --RexxS (talk) 16:51, 27 October 2018 (UTC)
Thanks @RexxS: it's now in {{Wikidata Infobox/sandbox}} and at Category:James S. Ogilvy. I'm using "qual=ALL, P1326" - not sure if that's what you were intending, but it seems to work! Thanks. Mike Peel (talk) 17:21, 27 October 2018 (UTC)
@Mike Peel: That won't work, as setting |qual=ALL, P1326 will simply ignore the 'ALL'. Have a think about what behaviour you want. At present we can return ALL the qualifiers (including P1326 without "before"), or a list of qualifiers (which will cause P1326 to prefix the word "before"), which gives flexibility. If you're sure we will never want P1326 without the "before", I can implement that, but it loses that option. --RexxS (talk) 17:30, 27 October 2018 (UTC)
@RexxS: Aah, I see. In that case, I'd say that latest date (P1326) should always show "before", as it's more valuable to be able to show all qualifiers rather than a list of some of them at this point in time. Thanks. Mike Peel (talk) 17:32, 27 October 2018 (UTC)
Can we use Module:Wikidata date and by that Module:Complex date indirectly? It does its job reasonably well. The qualifiers that should be taken in consideration for all "Time" datatype statements are listed at Module:Wikidata date#Properties. Module:Wikidata date does this automatically. Mike, do you have an example where a qualifier not among those would be a big loss? --Marsupium (talk) 18:11, 31 October 2018 (UTC)
The infobox already has too many dependencies, I'm not keen to add another... The issue here should be fixed in sandbox now. Thanks. Mike Peel (talk) 20:57, 31 October 2018 (UTC)
Hm, what's the problem with dependencies? Lua memory usage isn't an issue for some template/statement cluttered categories I've just checked, the winner, Category:United States, consuming "22.84 MB/50 MB". --Marsupium (talk) 23:41, 31 October 2018 (UTC)
@Marsupium: It makes copying it to other wikis more difficult. Consider that Module:WikidataIB (where this change would have to be made) is widely used across many different Wikimedia projects, and it's already difficult enough keeping them in sync. Thanks. Mike Peel (talk) 19:28, 1 November 2018 (UTC)
Hm, I see, I didn't know, bad situation, but that's a value! Thanks for the explanation! --Marsupium (talk) 19:50, 1 November 2018 (UTC)
@Yann and Marsupium: This is now live. Thanks. Mike Peel (talk) 21:11, 2 November 2018 (UTC)
This section was archived on a request by: Mike Peel (talk) 21:11, 2 November 2018 (UTC)

empty "location" field

Latest comment: 5 years ago3 comments2 people in discussion

please see Category:Nord-Süd-Leitung and notice the empty "location" field. North-South power line (Q876731) has correct country (P17) information (Germany and Austria). --Te750iv (talk) 00:17, 3 November 2018 (UTC)

@Te750iv: Thanks for reporting the bug, it should now be fixed. Thanks. Mike Peel (talk) 14:38, 3 November 2018 (UTC)
This section was archived on a request by: Mike Peel (talk) 14:38, 3 November 2018 (UTC)

Displaying Property:P276

Latest comment: 5 years ago6 comments2 people in discussion

Hello! I've been messing around with churches' categories using this template and, since now, in all the churches' elements on Wikidata I set the actual settlement (town/city/etc) as the location of the churches (P131); I've been told on Wikidata, though, that P131 should be only used for the municipality, and that for the exact location I should use P276; the problem is that P276 it's not displayed by the template, so we lack an important information - for example, here it shows only "Trento", but Trento is a 157km² municipality comprising not only the city of Trento, but also almost 50 villages, some of them quite far away from the city. Would it be possible to show it? -- Syrio posso aiutare? 21:15, 19 November 2018 (UTC)

@Syrio: Where were you told only to use located in the administrative territorial entity (P131) for the municipality, please? That doesn't match my understanding of how it's used. Thanks. Mike Peel (talk) 21:57, 19 November 2018 (UTC)
Here and then here. -- Syrio posso aiutare? 22:11, 19 November 2018 (UTC)
@Mike Peel: I brought up the matter here (I pinged you there but apparently it didn't work). -- Syrio posso aiutare? 11:44, 28 November 2018 (UTC)
I've commented there. I think this is an issue that needs sorting out on Wikidata rather than here, at least for now. Thanks. Mike Peel (talk) 21:10, 30 November 2018 (UTC)
This section was archived on a request by: Mike Peel (talk) 21:10, 30 November 2018 (UTC)

Errors

Latest comment: 5 years ago2 comments2 people in discussion

Some new errors pop up today on few Grand Theft Auto related categories, like Category:Grand Theft Auto. In the past I fixed some issues like that by fixing some nonsense Wikidata entry, but this time I do not see any issues with the data. --Jarekt (talk) 03:15, 28 November 2018 (UTC)

@Jarekt: It was vandalism in a linked entry, now reverted. I think the thing that caused the Lua error was that Commons category (P373) had been set to "no value".
This section was archived on a request by: Mike Peel (talk) 21:09, 30 November 2018 (UTC)

located in or next to body of water (P206)

Latest comment: 5 years ago4 comments2 people in discussion

Hello. This should be displayed. Thierry Caro (talk) 01:57, 17 November 2018 (UTC)

@Thierry Caro: It's now in the sandbox, please test it to make sure it works as you expect it to. Thanks. Mike Peel (talk) 21:44, 30 November 2018 (UTC)
@Thierry Caro: It's now live. Thanks. Mike Peel (talk) 21:28, 3 December 2018 (UTC)
This section was archived on a request by: Mike Peel (talk) 21:28, 3 December 2018 (UTC)

Latest comment: 5 years ago6 comments3 people in discussion

This infobox is being used at Category:United States Soccer Federation (which is linked to United States Soccer Federation (Q222131)), but the logo is not showing up correctly. The logo is rendered like this: File:Not string ([[File:Not string|110px]]). My guess is that the issue is related to USSF having multiple "logo image" properties; however, only one of the logos is set to preferred rank, so the infobox should be able to use that one. Could someone please take a look at this issue? Thanks, IagoQnsi (talk) 17:33, 30 November 2018 (UTC)

It looks like the problem is that {{#invoke:WikidataIB |getValueByLang |P154 |fwd=ALL |osd=no |qid=Q222131 | noicon=yes | maxvals=1}} gives "no string" in this case rather than being blank. @RexxS: can you have a look please? Thanks. Mike Peel (talk) 21:08, 30 November 2018 (UTC)
@Mike Peel:
  • {{#invoke:WikidataIB |getValueByLang |P154 |rank=b |fwd=ALL |osd=no |qid=Q222131 | noicon=yes | maxvals=1}} →
  • {{#invoke:WikidataIB/sandbox |getValueByLang |P154 |rank=b |fwd=ALL |osd=no |qid=Q222131 | noicon=yes | maxvals=1}} →
  • {{#invoke:WikidataIB |getValue |P154 |rank=b |fwd=ALL |osd=no |qid=Q222131 | noicon=yes | maxvals=1}} → United States Soccer Federation logo 2016.svg
If you remember, we used getValueByLang to fetch the logo appropriate to the reader's own language. However, that depends on the logo having a qualifier language of work or name (P407), which in United States Soccer Federation (Q222131), it does not. Hence the message telling us that there's no string value with that qualifier. As you can see above, I've suppressed that in the sandbox.
To fix the issue, we will either have to ensure that every logo has a qualifier language of work or name (P407) on Wikidata, or you'll need to use something in the template like:
  • {{if then show | {{#invoke:WikidataIB |getValueByLang |P154 |fwd=ALL |osd=n |qid=Q222131 | noicon=y | maxvals=1}} | {{#invoke:WikidataIB |getValue |P154 |fwd=ALL |osd=n |qid=Q222131 | noicon=y | maxvals=1}}
(assuming you update the main module from the sandbox). Cheers --RexxS (talk) 22:22, 30 November 2018 (UTC)
@RexxS: Thanks, I've updated Module:WikidataIB from the sandbox, and that's sorted it. @IagoQnsi: Better now? Thanks. Mike Peel (talk) 21:15, 3 December 2018 (UTC)
@Mike Peel: Beautiful; thanks! –IagoQnsi (talk) 21:16, 3 December 2018 (UTC)
This section was archived on a request by: Mike Peel (talk) 21:28, 3 December 2018 (UTC)

Error at Category:Santa Maria Assunta (Giovinazzo)

Latest comment: 5 years ago5 comments2 people in discussion

There is an error at Category:Santa Maria Assunta (Giovinazzo) which I am not sure how to fix. --Jarekt (talk) 04:04, 3 December 2018 (UTC)

@Jarekt: Vandalism in a related entry again, this time Giovinazzo (Q51828), now reverted. Thanks. Mike Peel (talk) 09:27, 3 December 2018 (UTC)
I was assuming that only one wikidata item needs to be checked: Santa Maria Assunta (Q1112203), but I see Category:Santa Maria Assunta (Giovinazzo) pulls statements from 8 items and all should be checked. --Jarekt (talk) 13:28, 3 December 2018 (UTC)
@Jarekt: It's more complex than that in the case of Commons category (P373) vandalism, and label vandalism, where every wikidata item linked to might need to be checked. But knowing which part of the infobox is showing the error helps narrow down the items to check considerably - in this case, it was following the located in the administrative territorial entity (P131) chain. Thanks. Mike Peel (talk) 15:43, 3 December 2018 (UTC)
This section was archived on a request by: Mike Peel (talk) 21:28, 3 December 2018 (UTC)

Insert "pseudonym/alias" ?

Latest comment: 5 years ago5 comments2 people in discussion

Have we considered inserting the "pseudonym/name alias" for categories of people with creative works? I would like to get rid of the free text such as used at Category:Daniel Maclise.  — billinghurst sDrewth 03:55, 10 December 2018 (UTC)

@Billinghurst: It's now in the sandbox, please test {{Wikidata Infobox/sandbox}}. Thanks. Mike Peel (talk) 10:06, 10 December 2018 (UTC)
Works  [OK] Shows through in searches {tick}}. I do note that {{Creator}} shows up all the alias descriptions.  — billinghurst sDrewth 23:03, 10 December 2018 (UTC)
@Billinghurst: This is now live. Thanks. Mike Peel (talk) 11:33, 13 December 2018 (UTC)
This section was archived on a request by: Mike Peel (talk) 11:33, 13 December 2018 (UTC)

Sport discipline

Latest comment: 5 years ago9 comments2 people in discussion

Hi! Would it be possible to add the sport discipline (P2416)? It would greatly help when categorizing people… I need it for figure skaters (singles/pairs/ice dance) but I think it would be useful for other sports too --Harmonia Amanda (talk) 15:15, 10 December 2018 (UTC)

@Harmonia Amanda: It's now in the sandbox, please test {{Wikidata Infobox/sandbox}} to make sure that works as expected. Thanks. Mike Peel (talk) 16:41, 10 December 2018 (UTC)
Tested in preview on several figure skaters, it works! --Harmonia Amanda (talk) 16:50, 10 December 2018 (UTC)

While we are at it, can we add "sport nationality" (P1532)? It seems that Commons categorize as "from" the countries which were represented in sports, even if the person don't have the citizenship, so having this information in the infobox help to make sense of the categorization… --Harmonia Amanda (talk) 19:42, 10 December 2018 (UTC)

@Harmonia Amanda: country for sport (P1532) is now also in the sandbox, how does that look? Let me know if the rows should be moved up/down compared to others. Thanks. Mike Peel (talk) 21:48, 10 December 2018 (UTC)
@Mike Peel: look good! I would place "country for sport" just below "country of citizenship" and "sport discipline" just below "occupation"? I think it makes more sense to group the countries together, since Commons doesn't make a difference when categorizing? What do you think? --Harmonia Amanda (talk) 21:52, 10 December 2018 (UTC)
@Harmonia Amanda: OK, rearranged. I'll update the main version later this week (combined with a few other changes). Thanks. Mike Peel (talk) 21:58, 10 December 2018 (UTC)
@Harmonia Amanda: It's now live. Thanks. Mike Peel (talk) 11:31, 13 December 2018 (UTC)
This section was archived on a request by: Mike Peel (talk) 11:31, 13 December 2018 (UTC)

Insert P6230 and P4266

Latest comment: 5 years ago9 comments2 people in discussion

Please get added P4266 (Bayerische Geotop-ID) and P6230 (Bayerische Schutzgebiete-ID) and displayed in section "Normdatei" similar to P809 (WDPA-ID). Many thx in advance. --Derzno (talk) 15:14, 12 December 2018 (UTC)

@Derzno: I've added them to the sandbox, please test {{Wikidata Infobox/sandbox}} to make sure it works as you expect it to. Do any tracking categories need adding? (e.g., like Category:Uses of Wikidata Infobox providing WDPA ids or Category:HPIP with known IDs). Thanks. Mike Peel (talk) 17:08, 12 December 2018 (UTC)
@Mike Peel: thx. I'm not sure if I'm a part of the problem and made some mistakes. I'd added 3 boxes and in the 1st one should pop up somehow "LSG-00105.06", 2nd "NSG-00024.01" and 3rd "779H001" AND "NSG-00207.01". For tracking I think no need of any cat and can be sorted out by a SPARQL. --Derzno (talk) 17:53, 12 December 2018 (UTC)
@Derzno: I've added the sandbox version of the template to Category:Buchberg (LSG) and Category:Ofnethöhlen, how does that look? The third one doesn't seem to have a Commons category yet. Thanks. Mike Peel (talk) 17:58, 12 December 2018 (UTC)
@Mike Peel: got it and thx for support. It looks good and it's what I'd want. --Derzno (talk) 18:00, 12 December 2018 (UTC)
@Mike Peel: So sorry for this stupid question but I don't know the release flow. What's next? Do I need to use from know on within "my" cats Wikidata Infobox/sandbox template only? Do I need to initiate possibly a patch by a BOT for all old stuff? Should I wait and this will be moved to the "offical" template? --Derzno (talk) 05:43, 13 December 2018 (UTC)
@Derzno: I'll update the main version of the template shortly. I try to minimise the number of times I do that as the template is now used in around 2 million categories, so I try to group changes together, and there's a change to the map code that's not finished yet. I might leave the map code change to the next version, though. Thanks. Mike Peel (talk) 10:09, 13 December 2018 (UTC)
@Derzno: It's now live. Thanks. Mike Peel (talk) 11:30, 13 December 2018 (UTC)
This section was archived on a request by: Mike Peel (talk) 11:30, 13 December 2018 (UTC)

Things to know

Latest comment: 5 years ago4 comments2 people in discussion

Moin Moin @Mike Peel: , I noticed things in the infobox or in the source code, I would like to know.

  • unnecessary redirect from "Template:Ubl" to "Template:Unbulleted list"
  • unused Modules: "Module:Wikidata2/i18n" and "Module:WikidataIB/i18n"

Thanks --Crazy1880 (talk) 20:13, 12 December 2018 (UTC)

One of the reasons for having redirects is so that we can use a convenient abbreviation. In the case of {{Ubl}}, it means we can save writing |list=unbulleted list 236 times at present in this infobox. Functionally, it makes no difference, as redirects consume very little resources, so it's just a convenience for the infobox maintainer.
Because the main modules were intended to be usable in any language wiki-site, these modules provide the ability to over-ride the default (English) error messages and some other localised text with whatever is contained in those sub-modules. Because Commons uses English as its site-language, those sub-modules remain unused here. HTH --RexxS (talk) 21:43, 15 December 2018 (UTC)
Thanks Rexxs, I see it now more clearly. Regards --Crazy1880 (talk) 18:45, 16 December 2018 (UTC)
This section was archived on a request by: Crazy1880 (talk) 18:45, 16 December 2018 (UTC)

Quick fix needed

Latest comment: 5 years ago3 comments2 people in discussion

{{Edit request}}@Mike Peel: Last night's quick fix is lacking an html section closure:

award auto-cat --><div style="display:none;">...<div style="display:none;">

should rather be

award auto-cat --><div style="display:none;">...</div>

similar to this change in the sandbox.

The impact is pretty large, as all text on any page with Wikidata infobox has vanished. Laddo (talk) 12:55, 14 December 2018 (UTC)

Oops! That's one way to tidy up commons categories Fixed! Thanks. Mike Peel (talk) 13:20, 14 December 2018 (UTC)
This section was archived on a request by: Laddo (talk) 02:22, 17 December 2018 (UTC)

Category:Sea cucumbers of the genus Stichopus Brandt, 1835 (Holothuroidea, Stichopodidae) in Straits of Malacca with description of a new species

Latest comment: 5 years ago6 comments2 people in discussion

Hello, I have two requests please

1/ add DOI (P356) and ZooBank publication ID (P2007) to the infobox
2/ there is a little issue, Sea cucumbers of the genus Stichopus Brandt, 1835 (Holothuroidea, Stichopodidae) in Straits of Malacca with description of a new species (Q22675045) has 5 authors, but only the one that have a wikidata item is quoted in the infobox. Can we fix that?

Regards, Christian Ferrer (talk) 11:28, 11 December 2018 (UTC)

@Christian Ferrer: Both are now in the sandbox, try {{Wikidata Infobox/sandbox}} to make sure that's working as you expect. Thanks. Mike Peel (talk) 17:22, 11 December 2018 (UTC)
Thanks you, for properties relating to "Authority control", that's good. For the authors, that should be ok too, though the display of the number "serie ordinal" is a bit boring in the Infobox IMO. Note that I just removed "stated as" otherwise the first author was quoted 2 times, but it is a bad solution because it would be necessary/better to find the way to avoid this redundancy without removing the property "stated as". Regards, Christian Ferrer (talk) 22:33, 11 December 2018 (UTC)
@Christian Ferrer: It's now live. With the series ordinal, these can be removed by not showing the qualifiers, but I'm reticent to do that as I'm not sure if they display useful information elsewhere. Shall we see how this goes and revisit it in the future? Thanks. Mike Peel (talk) 11:32, 13 December 2018 (UTC)
Ok, thanks you. Christian Ferrer (talk) 16:16, 13 December 2018 (UTC)
This section was archived on a request by: Mike Peel (talk) 17:04, 25 December 2018 (UTC)

P2961

Latest comment: 5 years ago7 comments2 people in discussion

Hi! It would be great having BVPH publication ID (P2961) as identifier here. A hidden tracking category such as Category:Periodicals in the Biblioteca Virtual de Prensa Histórica would be nice too. Strakhov (talk) 22:23, 14 December 2018 (UTC)

@Strakhov: It's now in the sandbox, please test {{Wikidata Infobox/sandbox}} to see if that works as expected. Thanks. Mike Peel (talk) 16:54, 16 December 2018 (UTC)
@Mike Peel: tested twice through page preview+wikidata infobox sandbox, it worked great, both the infobox and the tracking category. Thank you. Strakhov (talk) 17:03, 16 December 2018 (UTC)
Great! Unless it's needed urgently, I'll move it to the main template sometime next week, along with other changes. Thanks. Mike Peel (talk) 18:20, 16 December 2018 (UTC)
No hurry! Strakhov (talk) 20:08, 16 December 2018 (UTC)
@Strakhov: This is now live. Thanks. Mike Peel (talk) 08:54, 26 December 2018 (UTC)
This section was archived on a request by: Mike Peel (talk) 08:54, 26 December 2018 (UTC)

P373

Latest comment: 5 years ago5 comments2 people in discussion

Some WD items like Q1368093 have P373 (Commons category) which is not considered by the template. What is the reason behind it? --Arnd (talk) 17:02, 17 December 2018 (UTC)

@Aschroet: Sorry for not replying more quickly. It seems to show a link OK at Category:St. Crucis (Espenfeld). It might depend on which field of the infobox it's appearing in, is there a specific example where you can see the issue? Thanks. Mike Peel (talk) 17:01, 25 December 2018 (UTC)
It works because of this edit. Maybe the property is redundant then. --Arnd (talk) 17:54, 25 December 2018 (UTC)
Ah, OK. We're slowly heading towards using sitelinks rather than P373 anyway, so if it works now then that's fine, although I thought that we still relied on P373 where available... Thanks. Mike Peel (talk) 18:03, 25 December 2018 (UTC)
This section was archived on a request by: Mike Peel (talk) 08:53, 26 December 2018 (UTC)

P466

Latest comment: 5 years ago5 comments2 people in discussion

Hi! It would be nice having the opposite of headquarters location (P159) (headquarters)... I mean -> occupant (P466) (occupant) displayed in the infobox. The dichotomy "organization vs building" would be way better managed. Thanks! Strakhov (talk) 22:42, 18 December 2018 (UTC)

@Strakhov: it's in {{Wikidata Infobox/sandbox}} for testing. Thanks. Mike Peel (talk) 17:03, 25 December 2018 (UTC)
@Mike Peel: It works fine. Thanks! Strakhov (talk) 20:36, 25 December 2018 (UTC)
@Strakhov: This is now live. Thanks. Mike Peel (talk) 08:53, 26 December 2018 (UTC)
This section was archived on a request by: Mike Peel (talk) 08:53, 26 December 2018 (UTC)

Categorize award recipients

Latest comment: 5 years ago28 comments3 people in discussion

I recently created Category:Recipients of the Ernst Reuter Medal and it remains empty... It would be very useful if the infobox could categorize award recipients automatically.

Picking Ernst Reuter Medal (Q1357178) as an example, Wikidata already relates recipients (all these) to a recipient category in Commons. Say, for Tilla Durieux (Q78793) : 

Tilla Durieux (Q78793) award received (P166) Ernst Reuter Medal (Q1357178)
Ernst Reuter Medal (Q1357178) category for recipients of this award (P2517) Category:Recipients of the Ernst Reuter Medal (Q9143958)
Category:Recipients of the Ernst Reuter Medal (Q9143958) links to Commons Category:Recipients of the Ernst Reuter Medal

Is it possible to use this scheme for Commons categorization?

-- Laddo (talk) 13:35, 8 December 2018 (UTC)

@Laddo: I can't think of a straightforward way to do this at the moment. It's complex in the single award case that you've described, but becomes more complex if the person has received multiple awards. @RexxS: Any thoughts? Thanks. Mike Peel (talk) 14:24, 10 December 2018 (UTC)
@Mike Peel and Laddo: yes, I can write a new function, let's call it getPropOfProp, that: finds the value(s) of property1; and if they are wikibase-entities, fetches the value(s) of property2 for each of them; then assembles the results into some sort of list. For Laddo's general case, property1=P166 and property2=P2517. That would produce categories for every award received that has a category for recipients of this award (P2517) set. Is that what is wanted, or is the intention to limit it to just one award at a time (such as Ernst Reuter Medal (Q1357178))? I'll make a start on the function while you're thinking about it. --RexxS (talk) 17:27, 10 December 2018 (UTC)
[Update:]
Obviously, you don't use the linkprefix (lp) if you want to set categories, rather than display them. --RexxS (talk) 19:18, 10 December 2018 (UTC)
@RexxS: Nice, thank you! @Laddo: It's in the infobox sandbox, please test {{Wikidata Infobox/sandbox}} and see if that works as expected. Thanks. Mike Peel (talk) 21:53, 10 December 2018 (UTC)

@RexxS and Mike Peel: Nice!! All items I tested are entered in the right categories... but for some reason they all end up listed under letter "C" in recipient categories (see this one and this one. Could you please double-check that their sort keys are their family names? Thanks! Laddo (talk) 23:55, 10 December 2018 (UTC)

@Mike Peel: :
See if that supplies the family name as sort key accurately. --RexxS (talk) 01:03, 11 December 2018 (UTC)
@RexxS and Laddo: That's now in {{Wikidata Infobox/sandbox}}, but I'm not sure it's changed anything... Thanks. Mike Peel (talk) 17:24, 11 December 2018 (UTC)
@Mike Peel: Thinking about it, it probably won't, because the linking already uses a pipe character, so I can't insert a sort key into the linked text, only into the displayed text. I'll re-write the function later. --RexxS (talk) 18:02, 11 December 2018 (UTC)
@Mike Peel and Laddo: I had to re-write the code that displays a wikibase-entity. There's a new parameter |displaytext= (alieas |dt=). It's been worthwhile though, as it now allows us to display whatever we want for the links while retaining the link target. A category with a sort key looks like a piped link to the category with the sort key as the displayed text, like [[ Category:Catname | sortkey ]]. The first example below just shows the categories linked displaying a fixed piece of text, but the second gives the categories linked displaying the given name(s). If you remove the |lp=":" from the second example, we should get a link to each category using the given name(s) as sort key:
Check that each of those links goes to a different category. I've previewed it without the |lp=":" and the page shows the appropriate categories, so I'm optimistic. Let me know how that goes. --RexxS (talk) 16:18, 12 December 2018 (UTC)
@RexxS: That seems to do the trick! @Laddo: Can you do some more testing of it please? Thanks. Mike Peel (talk) 17:01, 12 December 2018 (UTC)
@RexxS and Mike Peel: Sort is now fine, you may release the new feature! The only glitch I could identify is when the Commons page name is radically different from the person's name (Frauke Petry born Frauke Marquardt, gets sorted under the letter M). If you know of a scheme to pass the actual DEFAULTSORT key to the new "displaytext" function, let me know ;) Thanks for the speedy improvement! Laddo (talk) 23:08, 12 December 2018 (UTC)
Thanks for the fixes in the sandbox @Laddo! If no sort key is added, then the defaultsort would be used, which would probably be better - @RexxS: would that happen if displaytext was set to blank? I'm not sure yet whether to release a partial update of the infobox tomorrow (the new coordinate logic to handle non-earth coordinates isn't quite ready yet), or wait until Sunday or so to do a full update (I'll be unavailable for most of Saturday should any issues arise with the deployment). Thanks. Mike Peel (talk) 00:10, 13 December 2018 (UTC)
@Laddo: This is now live, let's see how it goes. We can continue making tweaks in the sandbox and update them in the next version (nominally next week, unless urgent changes are needed). Thanks. Mike Peel (talk) 11:37, 13 December 2018 (UTC)
@RexxS: I found an oddity, {{#invoke:WikidataIB/sandbox |getPropOfProp |prop1=P166 |prop2=P2517 |fwd=ALL |osd=n |noicon=y |qid=Q9960 |sep=" " |displaytext={{wdib|ps=1|P734|noicon=y|linked=n|qid=Q9960 }} |lp=:}} -> Category:Honorary citizens of Berlin Category:Knights Grand Cross of the Order of the Bath Category:Recipients of the Order of the White Eagle Category:Collars of the Order of the White Lion Category:Presidential Medal of Freedom recipients Category:Congressional Gold Medal recipients Category:Doublespeak Award recipients Q116983321 Category:Horatio Alger Award recipients Category:Hollywood Walk of Fame honorees Category:Grand Crosses 1st class of the Order of Merit of the Federal Republic of Germany Category:Grand Crosses of the Order of Merit of the Republic of Poland Q8944295 Category:Doublespeak Award recipients Category:Recipients of the Grand Cordon of the Supreme Order of the Chrysanthemum Q7864449 Q19849010 Category:World War II Victory Medal recipients Category:Recipients of the Order of the White Lion Category:Recipients of the Order of the Chrysanthemum Category:Recipients of the Order of Merit (Sovereign Military Order of Malta) Category:Recipients of the Order of Merit of the Republic of Poland Category:Honorary citizens of Vilnius Category:Honorary citizens of Gdańsk - that unlinked 'Reagan' then shows up in Category:Ronald Reagan. I think it's because Francis Boyer Award (Q5480301) has no category for recipients of this award (P2517) - is there a way to exclude cases like that? Thanks. Mike Peel (talk) 15:36, 13 December 2018 (UTC)
@RexxS and Mike Peel: Similarly, Category:Henry Kissinger has two "Kissinger" at the top of the page as a result of the same problem. Not clear to me if it's due to items not having category for recipients of this award (P2517) at all, like Francis Boyer Award (Q5480301) or Eric M. Warburg Award (Q969644), or if it's related to awards having a WD recipient category with no matching Commons category, such as Order of Tomáš Garrigue Masaryk (Q1548060) having category for recipients of this award (P2517) pointing to Category:Recipients of the Order of Tomáš Garrigue Masaryk (Q8482348)... In the latter case, it would be nice for Wikidata infobox to display a red category link ;) -- Laddo (talk) 00:59, 14 December 2018 (UTC)
Slightly different: Category:Armand Dufrénoy displays "Category:Wollaston Medal winners" at the top. Laddo (talk) 01:53, 14 December 2018 (UTC)
That one went away with this edit to add the commons category - perhaps the enwp category link leaked through somehow? (Feel free to revert my edit for testing.) Thanks. Mike Peel (talk) 02:05, 14 December 2018 (UTC)
Noted. In Category:Jules-Napoléon Ney, the top of the page displays "Q7795935" in between two more categories having no Commons counterpart. No way to create a red link using a QID :) Laddo (talk) 02:21, 14 December 2018 (UTC)
OK, I've wrapped the category code with <div style="display:none;">...</div> - that hides the text, but the categories should still appear. That should do as a temporary solution until RexxS can have a look at this. Thanks. Mike Peel (talk) 10:34, 14 December 2018 (UTC)

@Mike Peel and Laddo: Right. I'm really sorry for the issues, but it's obvious that there are too many exceptions to categories using sort keys for a generic function to cope with all of them. So I've bit the bullet and wrote a bespoke function, just to do this job. I called it getAwardCat. It takes an extra optional parameter, |sortkey= (alias |sk=), which strips out quotes so it can contain spaces. If no sort key is provided, it looks for a family name and uses the sitelink (for preference) or the label for that. If those are not there, it has no sort key. The categories returned similarly prefer the sitelink to the label (for anti-vandalism reasons).

In the infobox code, you'll have to accept a |sortkey= and code it as something like {{#invoke:WikidataIB/sandbox |getAwardCat |fwd={{{fetchwikidata|ALL}}} |osd={{{onlysourced|no}}} |noicon=y |qid=whatever |sortkey={{{sortkey|}}} }}, so that on Category:Frauke Petry, you can use {{Wikidata Infobox |sortkey=Petry}}.

Sorry to have to ask you to do the testing again, but unfortunately it's above my pay grade. --RexxS (talk) 22:24, 14 December 2018 (UTC)

@RexxS: It's me who's sorry for using so much of your time, but this feature has pretty quietly categorized hundreds of thousands of people in award categories. I feel it's been worth it.
Indeed I much prefer that you use sitelinks rather properties when applicable! Don't worry with the testing, that's the easy part I'll be happy to take care of. Laddo (talk) 20:07, 15 December 2018 (UTC)
@RexxS: I'm afraid I preferred the more general function, sorry! There are also category for people buried here (P1791) and category for employees of the organization (P4195) that might be worth adding here in the same way in the future... Thanks. Mike Peel (talk) 18:26, 16 December 2018 (UTC)
@Mike Peel: I took the liberty of adding the call to the new function getAwardCat in the sandbox, though I have no idea about the purpose of parameters {{{fetchwikidata}}} and {{{onlysourced}}}. One side effect is that WikidataIB now supports an undocumented extra parameter {{{sortkey}}}. Please double-check my edit. I found nothing but positive improvements: red links for missing Commons categories (see Jules-Napoléon Ney), corrected sorts (either explicit like Frauke Petry or implicit like Kabayama Sukenori that was listed under letter C, like many others, in Grand Cordons of the Order of the Chrysanthemum and so on. The new service sounds OK to me. Laddo (talk) 18:56, 16 December 2018 (UTC)
@Mike Peel: unfortunately getPropOfProp shares a lot of code with getValue and therefore can't produce a category that has no sort key, so it will never be able to match the functionality of getAwardcat, which has bespoke code to generate categories. However, the code is capable of using other properties beyond award received (P166) and category for recipients of this award (P2517) as they are simply defined once in the opening lines. Instead we could pass a pair of parameters to an expanded function, if and when other auto-categorisations are requested, and turn getAwardCat into an alias to that in order to implement award categorisations. In the meantime, it's important to get the testing done on the new code because it differs significantly from getValue. --RexxS (talk) 20:08, 16 December 2018 (UTC)
@Laddo: The new code is now live, see how that goes? Thanks. Mike Peel (talk) 08:55, 26 December 2018 (UTC)
@RexxS and Mike Peel: All nice and fine, I believe. Impressive to see the new categorization at work! Thanks for the successful work :) Laddo (talk) 17:12, 27 December 2018 (UTC)
This section was archived on a request by: Mike Peel (talk) 17:14, 27 December 2018 (UTC)

Historical nationalities

Latest comment: 5 years ago4 comments2 people in discussion

Hi, I don't know if this was discussed before, but historical nationalities are not displayed properly. Category:T. Ganapati Sastri is certainly Indian, by any definition of the name, but we can't add "India" as his nationality, because he lived at the time of British India. The nationality should show "Indian" in the Infobox. Similar issue for Category:Bhāsa, but this case may be controversial. Regards, Yann (talk) 11:44, 2 January 2019 (UTC)

@Yann: The infobox displays country of citizenship (P27), which looks right in these cases? The text at the top is the description on Wikidata, and you'd need to edit it manually there, it's not something that the infobox assembles. Thanks. Mike Peel (talk) 11:51, 2 January 2019 (UTC)
Ah yes, right. The issue is in the Creator template. Regards, Yann (talk) 11:55, 2 January 2019 (UTC)
This section was archived on a request by: Mike Peel (talk) 12:09, 2 January 2019 (UTC)

Filtering some qualifiers

Latest comment: 5 years ago7 comments3 people in discussion

I noticed in Category:Angela Merkel that the field "educated at" supplies the full title of her Ph.D. The request is as follows

educated at -->{{Wikidata Infobox/line | P69 | {{#invoke:WikidataIB | getValue | rank=best | P69 | name=educated at | linkprefix=":" | qlinkprefix=":" | list=ubl | qid={{#invoke:WikidataIB |getQid |qid={{{qid|}}} }} | spf={{{suppressfields|}}} | fwd=ALL | osd=no | noicon=yes | qual=ALL}}

leading to

  • Polytechnic Secondary School Templin (1961–)
  • Extended Secondary School Templin (–1973)
  • Leipzig University (Diplom, physics, 1973–1978)
  • Academy of Sciences of the GDR (Examination of the mechanism of decays with singular bond breaking and calculation of their coefficient of reaction rate on the basis of quantum mechanical and statistical methods, doctor rerum naturalium, Lutz Zülicke, 1986)

(Note the awkward order of values; neither {{{sorted}}} or {{{qsorted}}} seem able to sort the output.)

I believe it might be appropriate to either filter out academic thesis (P1026) and specific others (like doctoral advisor (P184) or opponent during disputation (P3323)!!) using {{{suppressfields}}}, or to restrict that field to an explicit qualifier list via {{{qual}}}, such as DATES and academic degree (P512). I personally prefer the latter:

educated at -->{{Wikidata Infobox/line | P69 | {{#invoke:WikidataIB | getValue | rank=best | P69 | name=educated at | linkprefix=":" | qlinkprefix=":" | list=ubl | qid={{#invoke:WikidataIB |getQid |qid={{{qid|}}} }} | spf={{{suppressfields|}}} | fwd=ALL | osd=no | noicon=yes | qual=P580,P582,P585,P512,P812 }} →

Laddo (talk) 19:36, 27 December 2018 (UTC)

@Laddo: Isn't this something that needs to be fixed on Wikidata? I'm surprised to see academic thesis (P1026) and doctoral advisor (P184) used as qualifiers rather than main properties. Is this something that is common? Thanks. Mike Peel (talk) 09:25, 28 December 2018 (UTC)
@Mike Peel: One given individual my have multiple alma maters, degrees and thesis, associated to different times and academic fields. It is correct, I believe, to associate some qualifiers with each educational institution listed in P69.
Property qualifier counts can be checked using the pre-canned query linked by "List of qualifiers" at the top right of the WD {{Property documentation}} of each property, such as in wikidata:Property_talk:P69#Documentation.
In the case of educated at (P69), the query reports no less than 97 different qualifiers: on 962611 humans using P69 (and a few hundred fictional ones), only the 5 properties that I used in the example above are used more than 5000 times. Most others are either unsignificant or irrelevant, even those used over 1000 times. I believe it would be more appropriate to whitelist only the properties that we find adequate in the context of an infobox, IMHO.
Sorted use of qualifiers on P69 "Educated at"
qual ------------------------------------- qualLabel --------- count
http://www.wikidata.org/entity/P582 end time 28506
http://www.wikidata.org/entity/P512 academic degree 18446
http://www.wikidata.org/entity/P580 start time 13335
http://www.wikidata.org/entity/P812 academic major 8512
http://www.wikidata.org/entity/P585 point in time 5562
http://www.wikidata.org/entity/P3831 object has role 1294
http://www.wikidata.org/entity/P276 location 944
http://www.wikidata.org/entity/P184 doctoral advisor 477
http://www.wikidata.org/entity/P1066 student of 198
http://www.wikidata.org/entity/P31 instance of 166
http://www.wikidata.org/entity/P1026 doctoral thesis 134
http://www.wikidata.org/entity/P69 educated at 122
http://www.wikidata.org/entity/P1352 ranking 91
http://www.wikidata.org/entity/P811 academic minor 90
http://www.wikidata.org/entity/P1932 stated as 70
http://www.wikidata.org/entity/P1476 title 64
http://www.wikidata.org/entity/P4536 EThOS thesis ID 57
http://www.wikidata.org/entity/P1534 end cause 36
http://www.wikidata.org/entity/P642 of 30
http://www.wikidata.org/entity/P2578 studies 23
http://www.wikidata.org/entity/P1545 series ordinal 20
http://www.wikidata.org/entity/P166 award received 19
http://www.wikidata.org/entity/P131 located in the administrative territorial entity 19
http://www.wikidata.org/entity/P1326 latest date 15
http://www.wikidata.org/entity/P2868 subject has role 13
http://www.wikidata.org/entity/P1480 sourcing circumstances 13
http://www.wikidata.org/entity/P1264 valid in period 13
http://www.wikidata.org/entity/P2047 duration 11
http://www.wikidata.org/entity/P1319 earliest date 11
http://www.wikidata.org/entity/P921 main subject 11
http://www.wikidata.org/entity/P859 sponsor 11
http://www.wikidata.org/entity/P444 review score 10
http://www.wikidata.org/entity/P805 statement is subject of 9
http://www.wikidata.org/entity/P39 position held 9
http://www.wikidata.org/entity/P1184 handle 8
http://www.wikidata.org/entity/P463 member of 8
http://www.wikidata.org/entity/P1810 named as 7
http://www.wikidata.org/entity/P2579 studied by 6
http://www.wikidata.org/entity/P828 has cause 6
http://www.wikidata.org/entity/P957 ISBN-10 5
http://www.wikidata.org/entity/P813 retrieved 5
http://www.wikidata.org/entity/P793 significant event 5
http://www.wikidata.org/entity/P518 applies to part 5
http://www.wikidata.org/entity/P361 part of 5
http://www.wikidata.org/entity/P17 country 5
http://www.wikidata.org/entity/P2650 interested in 4
http://www.wikidata.org/entity/P243 OCLC control number 4
http://www.wikidata.org/entity/P2699 URL 3
http://www.wikidata.org/entity/P1780 school of 3
http://www.wikidata.org/entity/P577 publication date 3
http://www.wikidata.org/entity/P304 page(s) 3
http://www.wikidata.org/entity/P5102 nature of statement 2
http://www.wikidata.org/entity/P5021 test taken 2
http://www.wikidata.org/entity/P3005 valid in place 2
http://www.wikidata.org/entity/P2315 comment (DEPRECATED) 2
http://www.wikidata.org/entity/P2241 reason for deprecation 2
http://www.wikidata.org/entity/P1995 health specialty 2
http://www.wikidata.org/entity/P953 full work available at 2
http://www.wikidata.org/entity/P837 day in year for periodic occurrence 2
http://www.wikidata.org/entity/P749 parent organization 2
http://www.wikidata.org/entity/P737 influenced by 2
http://www.wikidata.org/entity/P355 subsidiary 2
http://www.wikidata.org/entity/P212 ISBN-13 2
http://www.wikidata.org/entity/P106 occupation 2
http://www.wikidata.org/entity/P5460 grants 1
http://www.wikidata.org/entity/P4241 refine date 1
http://www.wikidata.org/entity/P3415 start period 1
http://www.wikidata.org/entity/P2416 sports discipline competed in 1
http://www.wikidata.org/entity/P2392 teaching method 1
http://www.wikidata.org/entity/P2308 class 1
http://www.wikidata.org/entity/P2184 history of topic 1
http://www.wikidata.org/entity/P2032 work period (end) 1
http://www.wikidata.org/entity/P1683 quote 1
http://www.wikidata.org/entity/P1478 has immediate cause 1
http://www.wikidata.org/entity/P1448 official name 1
http://www.wikidata.org/entity/P1366 replaced by 1
http://www.wikidata.org/entity/P1365 replaces 1
http://www.wikidata.org/entity/P1351 number of points/goals/set scored 1
http://www.wikidata.org/entity/P1344 participant of 1
http://www.wikidata.org/entity/P1013 criterion used 1
http://www.wikidata.org/entity/P937 work location 1
http://www.wikidata.org/entity/P840 narrative location 1
http://www.wikidata.org/entity/P803 professorship 1
http://www.wikidata.org/entity/P802 student 1
http://www.wikidata.org/entity/P641 sport 1
http://www.wikidata.org/entity/P571 inception 1
http://www.wikidata.org/entity/P570 date of death 1
http://www.wikidata.org/entity/P559 terminus 1
http://www.wikidata.org/entity/P527 has part 1
http://www.wikidata.org/entity/P478 volume 1
http://www.wikidata.org/entity/P425 field of this occupation 1
http://www.wikidata.org/entity/P410 military rank 1
http://www.wikidata.org/entity/P199 business division 1
http://www.wikidata.org/entity/P135 movement 1
http://www.wikidata.org/entity/P108 employer 1
http://www.wikidata.org/entity/P40 child 1
http://www.wikidata.org/entity/P37 official language 1

Laddo (talk) 19:29, 28 December 2018 (UTC)
I hadn't spotted that link, that's a useful tool! I'm happy for you to make the change in the sandbox if you want, and we can see how that goes. The danger is that the uses on Wikidata change significantly, which qual=ALL would handle, but we can always modify the list of qualifiers if needed. Thanks. Mike Peel (talk) 19:36, 28 December 2018 (UTC)
I have difficulty in implementing filtering in general inside a module. It almost means writing a query language in Lua, simply to have filtered results available in wikitext, and the number of parameters needed to control filtering by value would probably be extreme. For now, I'd recommend using a qualifier list as Laddo suggests, because we at least have a simple mechanism of controlling which qualifiers are to be displayed as well as their order. As Wikidata moves more and more data into qualifiers instead of properties, so the complexity of getting the values we want increases.
I will take a look at the sorting algorithms. At present we just use the simplest alphabetic sort on the wikitext, so linked values sort as "[[...", etc. I intend at some point to implement sorting by series ordinal where it is present, so that might be a mechanism to give us customisable sorting (at the expense of having to specify the order for each statement/qualifier in Wikidata). Cheers --RexxS (talk) 23:39, 30 December 2018 (UTC)

I implemented | qual=P580,P582,P585,P512,P812 for P69 in the sandbox. Let me know if you feel other qualifiers would be necessary. Laddo (talk) 23:42, 5 January 2019 (UTC)

This section was archived on a request by: Laddo (talk) 16:40, 6 January 2019 (UTC)

Awards bug

Latest comment: 5 years ago15 comments7 people in discussion

Hi. There is a bug in connection with awards, which creates one or more red links: see Category:Nikolaj Pirnat or Category:Jože Borštnar. --Sporti (talk) 12:15, 1 January 2019 (UTC)

@Sporti: I'm not sure I understand, can you be more specific? If it's the appearance of the redlink to Category:Recipients of the Order of the People's Hero, then that's deliberate as that category should either exist, or the correct category should be added as a commons sitelink to Category:Recipients of the Order of the People's Hero (Q7866287). Also pinging @Laddo: for info. Thanks. Mike Peel (talk) 06:35, 2 January 2019 (UTC)
In Slovenian (sl) language I see three red links "Borštnar Borštnar Borštnar" at Borštnar's category in the top left. It doesn't appear in en or de, but once in hr. --Sporti (talk) 07:17, 2 January 2019 (UTC)
Ah, that's a bug. @RexxS: can you have a look please? I think we need to enforce "lang=en" in this part of the code, but it doesn't look like getAwardCat supports that (I've just added the option in the sandbox, and the sandbox to [2], but still see this issue). Thanks. Mike Peel (talk) 07:57, 2 January 2019 (UTC)
I imposed English language when building Commons sitelink in getAwardCat() of WikidataIB/sandbox. It's now OK on Slovenian Borštnar category. Please @RexxS: double-check if my change is complying with programming rules ;) Laddo (talk) 12:52, 2 January 2019 (UTC)
@Mike Peel: that fixes it, I think. Thanks, Laddo. I had some other changes to incorporate (fixing a bug when getting qualifiers of an unsourced property), so I've simplified your code to sitelink = sitelink or mw.wikibase.getLabelByLang(qid3, "en"), which I think produces the same result. I'm still not sure how it will behave when there is a different sitelink for the root of the category in a different language, but we can wait for an example to show up, I guess.
With last change 2 of 3 links are back. --Sporti (talk) 14:35, 2 January 2019 (UTC)
I can't see the red links in the pages mentioned, but (in Dutch) Category:Jules Anthone shows a red link to a non-existent Categorie:Prix de Rome. I have no clue as to what is the cause. Is there perhaps a connection to the (removed) 'Creator'-template? Jürgen Eissink (talk) 16:44, 2 January 2019 (UTC).
Same for a few other languages like French, where it adds Catégorie:Prix de Rome, but lacks Category:Prix de Rome winners. --HyperGaruda (talk) 20:20, 2 January 2019 (UTC)
@Mike Peel: That was my fault. I left in the call to the label in the local language as a fallback when the English label was unavailable, so the latest sandbox version might fix the issues, it's hard for me to test. --RexxS (talk) 22:14, 2 January 2019 (UTC)
@RexxS: I still see the red link using French interface. You can test it by either setting the Commons interface language to French, or turning on the live preview (Show preview without reloading the page on the Editing page of the preferences), and simply appending &uselang=fr to the edit URL. (I use this latter, and it’s incredibly fast compared to the normal preview in everyday use as well.) —Tacsipacsi (talk) 22:28, 2 January 2019 (UTC)
Sorry, I forgot to change the template name before previewing, so it was wrong of course. ;) It seems to work with the sandbox version, at least in French. —Tacsipacsi (talk) 22:30, 2 January 2019 (UTC)
Maybe the problem I mentioned (Category:Jules Anthone) is a different one, because the problem is still there. Jürgen Eissink (talk) 06:32, 3 January 2019 (UTC).
@RexxS: I've synced Module:WikidataIB with the sandbox, but this one is still there. In Category:Jules Anthone, it's adding 'Category' to a label that already contains 'Category', so it tries to link to Category:Category:Prix de Rome winners. That's causing a redlink, while Category:Prix de Rome winners actually already exists (but isn't linked to from Category:Prix de Rome winners (Q9240509)). Thanks. Mike Peel (talk) 08:18, 3 January 2019 (UTC)
@Mike Peel: Okay. Category:Prix de Rome winners (Q9240509) has no sitelink to Commons, but has an English label that already has the prefix "Category:". I've now amended the sandbox version to check whether the English label already has the prefix "Category:", and only add it if it's missing. So:
Let's hope we've caught all of the possible combinations of sitelinks and labels. --RexxS (talk) 16:30, 3 January 2019 (UTC)
This section was archived on a request by: Mike Peel (talk) 07:04, 7 January 2019 (UTC)

Odd infobox behavior

Latest comment: 5 years ago8 comments5 people in discussion

The infobox in place at Category:Richard Overton creates a piped redlink to "World War II Victory Medal recipients" at the top left, presumably intended to be "Category:World War II Victory Medal recipients". Could someone please fix this? Thanks. --Animalparty (talk) 18:17, 2 January 2019 (UTC)

Hmm, that's because Category:World War II Victory Medal recipients (Q7865118) has no English link, so it's using the label but getting it wrong somehow. @RexxS: another issue to look at please, probably related to the one above? Thanks. Mike Peel (talk) 20:14, 2 January 2019 (UTC)
@Mike Peel: It should have explicitly added the "Category:" part before the label. The latest update should have fixed that now. --RexxS (talk) 22:17, 2 January 2019 (UTC)
[Update:] Compare the English label for Category:World War II Victory Medal recipients (Q7865118) with the English label for Category:Prix de Rome winners (Q9240509). I've now fixed the code to handle both cases. --RexxS (talk) 16:36, 3 January 2019 (UTC)

Looks like it's fixed. There is also a related issue of: just because we can categorize stuff like this, should we? I'm not totally in love with purely displaying data for the sake of data (humans use Commons too, not just robots), and the World War II Victory Medal (United States) appears to have been awarded to virtually every single U.S. service member who served between 7 December 1941 and 31 December 1946, over 12 million eligible recipients, and thus Category:World War II Victory Medal recipients is largely synonymous with Category:World War II veterans of the United States. Now, I'm sure Wikidata could make a category for every conceivable data morsel (people who own dogs, people with 3 children, ad infinitum), and every intersection between them, but should we? --Animalparty (talk) 23:24, 3 January 2019 (UTC)

I see your point, and I had similar thoughts about the purpose of categorization in the context of Commons. Two extreme positions: either we end up reproducing the entire set of categories from Wikipedias (plus media-related categories like "photographs of people with pimples on the nose"), or we only categorize what directly relates to each media and give up categories like Category:Women by name...
At the moment my feeling is: it doesn't hurt to support too many categories, and it may help people locating the media they are looking for, so... let's continue  ;) Laddo (talk) 17:32, 4 January 2019 (UTC)
+1 from me, please go on. This is the first part of hole structered data ;) --Crazy1880 (talk) 17:35, 5 January 2019 (UTC)
This section was archived on a request by: Mike Peel (talk) 07:03, 7 January 2019 (UTC)

Category:Minsk

Latest comment: 5 years ago5 comments4 people in discussion

Hi! 1st I'd like to thank Mike Peel for this huge work. I think it is worth recongition.

My issue is that Category:Minsk is added to Category:Category:Hero Cities of the Soviet Union which is because the wikidata from categories main topic d:Q2280 is instance of d:Q159438. Can you please remove the duplicate of the word "category:" in the template? --Jarash (talk) 10:11, 3 January 2019 (UTC)

This problem is already under discussion in #Awards bug above. —Tacsipacsi (talk) 10:22, 3 January 2019 (UTC)
@Jarash: The sandbox at Module:WikidataIB/sandbox now fixes the problem, so we're just waiting for an admin to update Module:WikidataIB from it.
@Mike Peel: when you get a chance. --RexxS (talk) 16:44, 3 January 2019 (UTC)
@RexxS: Done, thanks for the fix! Mike Peel (talk) 19:33, 3 January 2019 (UTC)
This section was archived on a request by: Mike Peel (talk) 07:02, 7 January 2019 (UTC)

Attempt to index field 'datavalue' (a nil value)

Latest comment: 5 years ago8 comments3 people in discussion

On Category:Franklin Pierce 1853 presidential inauguration, the “previous“ field fails with the above error message (referring to Module:WikidataIB, line 526). I haven’t looked into it deeper, but I think it’s caused by the Commons category (P373): novalue statement on inauguration of Millard Fillmore (Q16847047). —Tacsipacsi (talk) 19:06, 5 January 2019 (UTC)

@Tacsipacsi: Yup, it was the "novalue". That's not any use on Wikidata, so removing it is the simplest way to fix this. Thanks. Mike Peel (talk) 19:31, 5 January 2019 (UTC)
But not the best. Such statements will come up every now and then, and the template should not fail, especially not with a such error message. It can add some tracking category, but it should be able to handle it. Adding an extra test is easy and cheap, and prevents such errors. —Tacsipacsi (talk) 19:42, 5 January 2019 (UTC)
Up to @RexxS: . IMO, these are rare enough that they can be spotted and fixed easily when they pop up in Category:Pages with script errors. Thanks. Mike Peel (talk) 19:56, 5 January 2019 (UTC)
I'm quite happy to fix it, but it's difficult to anticipate all of the quirks that editors may come up with. The 'novalue' value should only be used when there cannot be a value, and not when a value hasn't been provided yet, especially when it's a sitelink. We don't write 'novalue' for the sitelinks for all 300 language Wikipedias just because they don't currently have an entry. I'll have to revert Mike so that I can see where the problem manifests itself in the code and to make sure that whatever solution I can find actually works. --RexxS (talk) 20:43, 5 January 2019 (UTC)
@Mike Peel: Sorted and checked by using Template:Wikidata Infobox/sandbox on Category:Franklin Pierce 1853 presidential inauguration.
  • {{#invoke:WikidataIB/sandbox |getValue |ps=1 |P155 |qid=Q6013726}} → inauguration of Millard Fillmore
Just needs updating from sandbox to main module. I've left the erroneous Wikidata value in place, so that you can check that the error clears after the module update. Please revert my Wikidata edit when you're satisfied. Thanks for the catch, Tacsipacsi! --RexxS (talk) 21:21, 5 January 2019 (UTC)
It's now live. Thanks. Mike Peel (talk) 07:01, 7 January 2019 (UTC)
This section was archived on a request by: Mike Peel (talk) 07:01, 7 January 2019 (UTC)

Over 100 pages in Category:Pages with script errors with {{Wikidata Infobox}} related errors

Latest comment: 5 years ago4 comments2 people in discussion

There is suddenly over 100 pages in Category:Pages with script errors with {{Wikidata Infobox}} related errors all of them related to {{Wikidata Infobox}} with qid parameter. --Jarekt (talk) 04:01, 11 January 2019 (UTC)

@Jarekt: Thanks for spotting it, it should be fixed with this edit. I'll null edit the affected categories now. Thanks. Mike Peel (talk) 07:34, 11 January 2019 (UTC)
All sorted now. Thanks. Mike Peel (talk) 08:23, 11 January 2019 (UTC)
This section was archived on a request by: Mike Peel (talk) 08:23, 11 January 2019 (UTC)

Page name not same as true subject name

Latest comment: 5 years ago5 comments2 people in discussion

See, for example, Category:Lad, A Dog (book). Something obviously suppresses the qualifier "(book)" in titling the Infobox. But in fact the comma should also change to a colon. I suppose there are two ways to approach this:

This section was archived on a request by: Mike Peel (talk) 21:59, 22 January 2019 (UTC)

Default sort key conflict warning

Latest comment: 5 years ago4 comments2 people in discussion

Whenever the Wikidata infobox (praise be its name) is inserted or inserts itself into a category with a sensible, human-crafted default sort template that doesn't comply with what Wikidata (praise be its name) thinks the default should be, humans are faced with the bright red "Warning: Default sort key "_____" overrides earlier default sort key "_____". Now, surely this is a minor inconvenience for robots and people who act like them, but I posit that this is not a vital emergency worth screaming from the top of a category. No one will lose life, limb, or property because John Quincy Smith is sorted as John Smith, or vice versa. It's fine to place such categories in Category:Pages with DEFAULTSORT conflicts, where ostensibly User:Pi bot will rectify the conflict "every day or so". However, picking two at random I find Category:Ken-Ichiro Kobayashi Category:Plume Latraverse have been unresolved since May 2018. Can we please make the warning less obnoxious? Thank you. --Animalparty (talk) 20:32, 17 January 2019 (UTC)

@Animalparty: Both of your examples only gained the conflict this month, due to these edits on Wikidata to add the name info: [3] [4]. Pi bot is running less regularly at the moment as I'm traveling (the raspberry pi's crashed, so I'm running it on my laptop when I can until I can reboot the pi) - it's running now, let's see if that fixes the two examples. I have no objections to the warning being made less obnoxious, though, if you can find out where it's styled (the conflict comes from the infobox, but the error message doesn't). Thanks. Mike Peel (talk) 21:22, 17 January 2019 (UTC)
Looks like the bot's caught both of those two (without any tweaking), sorry for the delay there. Thanks. Mike Peel (talk) 21:47, 17 January 2019 (UTC)
This section was archived on a request by: Mike Peel (talk) 21:58, 22 January 2019 (UTC)

Authority control

Latest comment: 5 years ago3 comments2 people in discussion

Authority control displays the list of items next to each other. Can that be changed to a line break after each item? For example Category:Felice Varini has a lot of items which is difficult to read with all items next to each other. Behanzane (talk) 17:59, 24 July 2018 (UTC)

@Behanzane: The latest change to the infobox has implemented this - sorry it took so long! Thanks. Mike Peel (talk) 19:47, 5 February 2019 (UTC)
This section was archived on a request by: Mike Peel (talk) 19:47, 5 February 2019 (UTC)

Wikidata Infobox adds irrelevent categories to pages

Latest comment: 5 years ago14 comments7 people in discussion

Hello,

I have noticed that the Wikidata Infobox adds irrelevent categories to pages. You can see an instance of the problem with Category:Bes-N 5141, which is categorised in Category:Establishments in France. This category is not called in the wikicode of Category:Bes-N 5141, and this diff shows that the extra category stems from invoking {{Wikidata Infobox}}.

Can someone advise ? thanks ! Rama (talk) 10:31, 4 September 2018 (UTC)

I think the problem is that the wikidata item Bes-N 5141 (Q56458656) to which Category:Bes-N 5141 is tied has an inception (P571) property, which is nominally the date or point in time when an organization was founded. However d:Wikidata:WikiProject_Visual_arts/Item_structure seems to suggest that it might also be used for works of art. On Commons the structured data project is proposing using P571 for date a file was created as well as for the date of creation of the depicted content (see Commons:Structured data/Properties table), so I definitely think Wikidata is planning on expanding the P571/Inception property beyond just organizations. The template code for {{Wikidata Infobox}} assumes that the existence of a P571 property implies that the item is an organization/establishment, which appears to no longer be true. —RP88 (talk) 10:57, 4 September 2018 (UTC)
fascinating, thank you! Rama (talk) 12:27, 4 September 2018 (UTC)
This auto-categorisation was added at @Crazy1880: 's request, see the discussion above. As it's causing problems and I'm not too sure how to resolve them, I've disabled it. You might still see the categories being added until the server cache catches up (try ?action=purge at the end of the URL to see if that is the case or not). Thanks. Mike Peel (talk) 12:46, 4 September 2018 (UTC)
Moin Moin together, @Rama: , yes, the mindset was as @RP88: described it. Thanks at @Mike Peel: deactivate this categories. Is there a way, for example, to restrict for buildings? Regards --Crazy1880 (talk) 18:57, 4 September 2018 (UTC)
@Crazy1880: : that would only be possible if we could identify some Wikidata property value that was present for all buildings, but absent for all non-buildings. Looking at Castleton (Q5050630), for example, which is a railway station opened in 2010, the only possible thing I can see is instance of (P31) which is railway station (Q55488). If we could create an exhaustive list of all property values that represented buildings, we might be able to check instance of (P31) against the list in order to identify a "building", but frankly Wikidata isn't structured consistently enough to have much hope of that working reliably. --RexxS (talk) 15:50, 6 September 2018 (UTC)
@RexxS: If this were an important requirement, would it be possible to track up the subclass of (P279) chains a little way, and look for architectural structure (Q811979) ? Jheald (talk) 19:51, 6 September 2018 (UTC)
@Jheald: I actually looked at that, but wasn't convinced that it would be present in every case, especially when there are so many values of subclass of (P279) to check against. I suppose I ought to knock up some test code or at least write a SPARQL query to see what sort of results we'd get. I'll put it on the to-do list. --RexxS (talk) 20:42, 6 September 2018 (UTC)
@Mike Peel: that auto categorization feature is still causing problems as discussed here. Can you confirm it is currently disabled? Thanks, --Joschi71 (talk) 15:54, 6 December 2018 (UTC)
@Joschi71: It's a different issue, should now be fixed with this edit. Thanks. Mike Peel (talk) 17:34, 6 December 2018 (UTC)
@Mike Peel: thanks for the fast reply, but unfortunately category:Volkswagen Polo III is still listed in category:Germany, even with action=purge. I suspected the starttime attribute, but with your amendments it now looks the same as endtime. Could you please have a 2nd look? --Joschi71 (talk) 21:45, 6 December 2018 (UTC)
@Joschi71: I did a null edit (open edit window, then save without changing anything) to the VW Polo category, it's no longer in the German category. Thanks. Mike Peel (talk) 01:10, 7 December 2018 (UTC)
@Mike Peel: great, thanks a lot! --Joschi71 (talk) 07:50, 7 December 2018 (UTC)
This section was archived on a request by: Mike Peel (talk) 19:48, 5 February 2019 (UTC)

drainage basin (P4614)

Latest comment: 5 years ago4 comments2 people in discussion

Hello. Would it be possible to have this displayed? That'd be useful for rivers and lakes, among other things. Thierry Caro (talk) 06:27, 19 January 2019 (UTC)

@Thierry Caro: It's now in the sandbox, please test {{Wikidata Infobox/sandbox}} to make sure it looks OK. Thanks. Mike Peel (talk) 21:57, 22 January 2019 (UTC)
@Thierry Caro: This is now live. Thanks. Mike Peel (talk) 19:44, 5 February 2019 (UTC)
This section was archived on a request by: Mike Peel (talk) 19:44, 5 February 2019 (UTC)

Natura-2000-ID

Latest comment: 5 years ago6 comments2 people in discussion

Could you please add that show up the Natura-2000-ID (P3425) similar to WDPA-ID (P809). Many thx in advance. --Derzno (talk) 09:18, 29 January 2019 (UTC)

Some background on this for making decission much easier. I'd added 4500 SAC and 800 SPA in Wikidata to show up in cats. --Derzno (talk) 09:30, 29 January 2019 (UTC)
@Derzno: It's in the sandbox, please test {{Wikidata Infobox/sandbox}} and see if that works as expected. Let me know if a tracking category for the property is needed here (e.g., see Category:HPIP with known IDs). Thanks. Mike Peel (talk) 12:56, 29 January 2019 (UTC)
@Mike Peel: it looks perfect! No need for for any tracking and many thx. --Derzno (talk) 13:13, 29 January 2019 (UTC)
@Derzno: This is now live. Thanks. Mike Peel (talk) 19:43, 5 February 2019 (UTC)
This section was archived on a request by: Mike Peel (talk) 19:43, 5 February 2019 (UTC)

RegiowikiAT ID (P6228)

Latest comment: 5 years ago13 comments3 people in discussion

@Karl Gruber: asked me to ask on his behalf: Can you please add RegiowikiAT ID (P6228) as RAT to the authority data (like GND) in the infobox? best --Herzi Pinki (talk) 16:25, 31 January 2019 (UTC)

@Karl Gruber and Herzi Pinki: This is now in the sandbox, please test {{Wikidata Infobox/sandbox}} and see if that works as expected. Let me know if a tracking category for the property is needed here (e.g., see Category:HPIP with known IDs). Thanks. Mike Peel (talk) 09:17, 1 February 2019 (UTC)
@Mike Peel: I have inserted in the Category:Fritz Lange (Author), but I can't see the link to RAT ;-) - where should it be? thx K@rl (talk) 09:39, 1 February 2019 (UTC)
as authority data is restricted to persons, maybe my request was too narrow. RegioWiki also has articles about non-persons, the property RegiowikiAT ID (P6228) should show up in any case it is defined. --Herzi Pinki (talk) 11:12, 1 February 2019 (UTC)
@Karl Gruber and Herzi Pinki: Ah, this runs into the same issue as below then. I've added it to the list for non-people categories only. I'll look into this more next week. Thanks. Mike Peel (talk) 13:50, 1 February 2019 (UTC)
Okay, many thanks, regards K@rl (talk) 13:51, 1 February 2019 (UTC)
@Karl Gruber and Herzi Pinki: I've reworked the authority control code, please test {{Wikidata Infobox/sandbox}} to see how that looks now. Thanks. Mike Peel (talk) 22:00, 4 February 2019 (UTC)
@Mike Peel: It looks like okay, but it's only necessary to write RegiowikiAT not the complete of authority control code. Also it's possible to hide the number with [Number RegiowikiAT] - so the field is not so large --K@rl (talk) 22:09, 4 February 2019 (UTC)
I've tweaked the text by editing the property label. Whether to show or to hide the number is kinda controversial, so the current convention is to show it. Thanks. Mike Peel (talk) 22:14, 4 February 2019 (UTC)
So it's okay, thx. Please make it to a regurare infobox. regards K@rl (talk) 08:12, 5 February 2019 (UTC)
@Karl Gruber: This is now live. Thanks. Mike Peel (talk) 19:43, 5 February 2019 (UTC)
Zhanks too --K@rl (talk) 19:44, 5 February 2019 (UTC)
This section was archived on a request by: Mike Peel (talk) 19:43, 5 February 2019 (UTC)

Wikidata Item-id

Latest comment: 5 years ago12 comments4 people in discussion

The infobox links to the WD Q item-id via the wikidata icon only. To retrieve the Q-id from the infobox it is either necessary to follow that link or to copy the link and cut the id. That is not that practical. Can you add the Q-id aside to the icon for easier copying that id? We use ids to identify table rows in lists of objects (e.g. cultural heritage, notable buildings by architect, etc.) and have to set the Q-ids manually for each row. @Thomas Ledl: as the owner of that request. best --Herzi Pinki (talk) 16:25, 31 January 2019 (UTC)

@Herzi Pinki: The QID is right beside the wikidata icon, first line of the "autority control" section of the infobox, see Category:Jain (singer) for example. Can you point to an example where it does not appear? Laddo (talk) 01:20, 1 February 2019 (UTC)
Hi, thanks for the answer, so the QID is only missing in cases: e.g. Category:Matterhorn (a mountain) or Category:St. Stephen's Cathedral, Vienna (a protected building, a church). best --Herzi Pinki (talk) 07:50, 1 February 2019 (UTC)
It appears for categories about humans (since the code then uses Module:Authority control, but not for categories about anything else (the code uses Template:Wikidata ID and just shows Wikidata icon without a QID). I'm going to try to unify that soon (probably dropping Module:Authority control to reduce dependencies), and can make sure the QID is always shown then, but it won't be this weekend.
Out of curiosity, what software are you using to gather the info? I'd recommend using the sitelink to get the Wikidata ID rather than getting it from the infobox if you can. Thanks. Mike Peel (talk) 09:15, 1 February 2019 (UTC)
As far as I know, no one of us adding QIDs (about 3-4 people I know in that context) is using any software. We eventually use private scripts, but no known software. Is there a software that allows to add QIDs to any table row (for each object) e.g. in de:Liste der denkmalgeschützten Objekte in Leoben, or de:Ernst Epstein. Normally, we do have links to commons categories, so the ids are only one click away, if shown in the infobox. In general, there might be an image or not, an article for the row or not, a commons category or not, an infobox in the commons category or not. So information is retrieved and added depending on the information we do have. If this can be done automatically, it would help a lot. --Herzi Pinki (talk) 11:00, 1 February 2019 (UTC)
@Herzi Pinki: You might want to look into Template:Wikidata list / de:Vorlage:Wikidata list, which lets you generate lists using Wikidata. It seems to be controversial to use that in mainspace, but it's a useful tool that can at least be used in userspace. Thanks. Mike Peel (talk) 13:52, 1 February 2019 (UTC)
thanks, there is a kind of hen and egg problem, most of our lists have been created before the advent of wikidata. Part of our lists have been extracted and put to wikidata (e.g. the objects from the monument database), but the result is incomplete, partly wrong, not incrementally maintained, and thus not that usable as expected. The templates you mentioned above will not help, as they just allow to create lists from a set of wikidata entries (a sparkl query result), but there is no concept to merge data from Wikidata and e.g. local descriptions in a multi language environment. --Herzi Pinki (talk) 14:16, 1 February 2019 (UTC)
@Herzi Pinki: In Module:WikidataIB we have two functions that return Wikidata entity-ids. They are available via Template:Qid and Template:GetQID. Just pasting {{Qid}} into a page will render its Wikidata entity-id (although it can do more complex tasks if required). Is that the functionality you're looking for? --RexxS (talk) 22:23, 4 February 2019 (UTC)
I've change the display of the wikidata link in {{Wikidata Infobox/sandbox}} as part of the authority control change, which hopefully will solve this issue. Thanks. Mike Peel (talk) 22:31, 4 February 2019 (UTC)
works as expected. thanks --Herzi Pinki (talk) 00:07, 5 February 2019 (UTC)
@Herzi Pinki: This is now live. Thanks. Mike Peel (talk) 19:42, 5 February 2019 (UTC)
This section was archived on a request by: Mike Peel (talk) 19:42, 5 February 2019 (UTC)

Internet Archive ID (P724)

Latest comment: 5 years ago5 comments2 people in discussion

Hi! ...It would be great having Internet Archive ID (P724) as identifier. Strakhov (talk) 16:10, 3 February 2019 (UTC)

@Strakhov: This is now in {{Wikidata Infobox/sandbox}}, please test it! Thanks. Mike Peel (talk) 20:46, 4 February 2019 (UTC)
@Mike Peel: Tested. It works perfectly. Thanks! Strakhov (talk) 05:32, 5 February 2019 (UTC)
@Strakhov: This is now live. Thanks. Mike Peel (talk) 19:41, 5 February 2019 (UTC)
This section was archived on a request by: Mike Peel (talk) 19:41, 5 February 2019 (UTC)

Different coordinates in wikidata and wikidata infobox

Latest comment: 5 years ago5 comments3 people in discussion

Hi, does anybody knows, why in Category:Estación de Estadio Metropolitano the Infobox shows wrong coordinates (40° 24′N, 3° 36′W) although the connected wikidata object Estadio Olímpico has the right coordinates (40°29'N, 3°40'W)? Thx! --W like wiki good to know 22:21, 4 February 2019 (UTC)

@W like wiki: The Wikidata item's coordinates had an accuracy of 0.1 degrees, which caused the discrepancy. However, neither seemed to be right, so I've re-entered the coordinates from en:Estadio Metropolitano (Madrid Metro) with a more reasonable coordinate accuracy, how does that look now? Thanks. Mike Peel (talk) 22:28, 4 February 2019 (UTC)
(Edit conflict) If you examine what is stored in Wikidata, you find:
table#1 {
    table#2 {
        ["id"] = "Q2244081$a71aa5dd-437b-5fa5-4a3b-ae9f9be12d52",
        ["mainsnak"] = table#3 {
            ["datatype"] = "globe-coordinate",
            ["datavalue"] = table#4 {
                ["type"] = "globecoordinate",
                ["value"] = table#5 {
                    ["globe"] = "http://www.wikidata.org/entity/Q2",
                    ["latitude"] = 40.4333937,
                    ["longitude"] = -3.6001502,
                    ["precision"] = 2.77778e-05,
                },
            },
            ["property"] = "P625",
            ["snaktype"] = "value",
        },
        ["rank"] = "normal",
        ["references"] = table#6 {
            table#7 {
                ["hash"] = "fa278ebfc458360e5aed63d5058cca83c46134f1",
                ["snaks"] = table#8 {
                    ["P143"] = table#9 {
                        table#10 {
                            ["datatype"] = "wikibase-item",
                            ["datavalue"] = table#11 {
                                ["type"] = "wikibase-entityid",
                                ["value"] = table#12 {
                                    ["entity-type"] = "item",
                                    ["id"] = "Q328",
                                    ["numeric-id"] = 328,
                                },
                            },
                            ["property"] = "P143",
                            ["snaktype"] = "value",
                        },
                    },
                },
                ["snaks-order"] = table#13 {
                    "P143",
                },
            },
        },
        ["type"] = "statement",
    },
}
The precision has been manually set to the value of 0.118019 degrees. That's 7 minutes, so the coordinates represent a location somewhere in the area defined by 40° 22' to 40° 36' North and 3° 33' to 3° 47' West. That's a rectangle around 25 km each way. As the rounding algorithm I use in WikidataIB to display these values obviously differs from that used by the Wikidata UI, you see a different value, namely 40°26′0.2″N 3°36′0.5″W. But it's still pretty close to the middle of that rectangle. If anybody knows the coordinates of Estadio Metropolitano (Q2244081) to a better precision than plus or minus 12 km, it would be worth fixing the Wikidata entry to give a better precision. If it's any help, 1 second of lat/long is around 30 metres. Cheers --RexxS (talk) 22:51, 4 February 2019 (UTC)
wow, thx you both for the fast answer and solution!! The fact with the precision for the coordinates was completly new for me. Mike Peel already did the correction in the wikidata object at 22:25 (UTC). --W like wiki good to know 23:10, 4 February 2019 (UTC)
This section was archived on a request by: Mike Peel (talk) 19:41, 5 February 2019 (UTC)

Emergency: DEFAULTSORT now missing for people

Latest comment: 5 years ago4 comments2 people in discussion

Hi, since the last update, the DEFAULTSORT:surname, given name seems to be missing in peoples cats. @User:Mike Peel Please investigate. Thx. --JuTa 01:54, 7 February 2019 (UTC)

@JuTa: Thanks for spotting that! this edit should have fixed it. It will take a while for the caches to update, though, sorry... Thanks. Mike Peel (talk) 11:56, 7 February 2019 (UTC)
Thx Mike. It looks fine now. --JuTa 12:33, 7 February 2019 (UTC)
This section was archived on a request by: Mike Peel (talk) 20:26, 16 February 2019 (UTC)

Recent changes seem to make an ugly mess

Latest comment: 5 years ago11 comments4 people in discussion

In the past few days I have noticed that a lot of Commons categories using this template seem to have become rather messy. I don't recall exactly how they looked before but I am pretty sure the infobox was over on the right and the contents of the infobox was kept distinct from any {{En}} descriptions whereas now they seem to be running into each other (was there a border around the infobox before?). Could they at least be put back over on the right please? Kerry Raymond (talk) 05:05, 10 February 2019 (UTC)

@Kerry Raymond: Can you point out some examples, please? Also, which browser are you using? Thanks. Mike Peel (talk) 12:35, 10 February 2019 (UTC)
@Mike Peel: I've looked a few random categories and I'm not seeing the infobox anywhere other than on the right. However, I did find a "messy" implementation at Category:Gemeentelijke monumenten in Gendringen (Municipal monuments in Gendringen), which has a {{See also}} that puts its shaded band beneath the infobox caption. I think you need to set a non-transparent background (and perhaps a border) to either the caption or to a div that wraps the entire infobox. --RexxS (talk) 12:57, 10 February 2019 (UTC)
@RexxS: That's tweaked in the infobox sandbox now, but that's not a new issue. Thanks. Mike Peel (talk) 13:33, 10 February 2019 (UTC)
Well, as of late last night, the infobox went back over to the right and with a box around it. I didn't change anything I was doing; I assumed someone had fiddled with the definition of {{Wikidata infobox}} in reaction to my message above. I am using 'Chrome 72.0.3626.96 (Official Build) (64-bit)" and I updated to it on Friday about noon (UTC+10). But I was seeing the problem before that which is why I updated my browser but it didn't seem to change anything. 21:51, 10 February 2019 (UTC)
@Kerry Raymond: That's very odd - I changed things in the sandbox, but not the main template, so it should still look the same! Perhaps it was a caching issue. If it happens again, please post again here, and perhaps try adding "?action=purge" onto the end of the URL to clear the server cache. Thanks. Mike Peel (talk) 10:44, 11 February 2019 (UTC)

@Kerry Raymond and Mike Peel: FYI the option for purging the cache is now easier to use: the "More" menu at the top right of each page now shows a "Purge" action. Laddo (talk) 23:54, 12 February 2019 (UTC)

@Laddo: I think you first have to enable ExtraTabs2 in Preferences → Gadgets → Interface: Other. --RexxS (talk) 00:53, 13 February 2019 (UTC)
@RexxS: I can see the Purge menu item despite that ExtraTabs2 is not activated in my preferences. Not the same for you? Laddo (talk) 01:12, 13 February 2019 (UTC)
@Laddo: Not the same for me. --RexxS (talk) 01:18, 13 February 2019 (UTC)
@RexxS: OK I got it: I have another gadget activated, "Page Purge", that adds this option under the "More" submenu. I tought it was available by default for everyone, sorry. Laddo (talk) 01:55, 13 February 2019 (UTC)
This section was archived on a request by: Mike Peel (talk) 20:28, 16 February 2019 (UTC)

File annotations in Infobox image

Latest comment: 5 years ago4 comments3 people in discussion

Images with annotations popup in infobox images (see Category:Luis E. Fonseca, Jr., and assume for the sake of demonstration that it's worthwhile to annotate the subject's face by name, even though it's not). Much like the forced Wikidata captions, but even more so, I think this is just silly, ugly, and distracting. Can we make the infobox images static? Thankfully, it appears that the yellow popup windows are suppressed for images with multiple annotations, as in Category:Alajos Károlyi. Something like that for all annotated images in this infobox would be less obnoxious. --Animalparty (talk) 19:25, 14 February 2019 (UTC)

Might this be a platform/browser specific issue? I don't have any issues with this image, except when hovering the pointer over the image.
Also, this does not seem to be related to this specific issue, but since the OP brings it up; captions in infoboxes serve a purpose, for instance in setting the context for the reader. Attribution is also a legal requirement in some jurisdictions and various wiki-projects have accommodated this by adding the attribution in the image caption.
Edit: If the personal taste for what is "silly, ugly, and distracting" should dictate what information is presented in an infobox the discussion can easily be expanded to include other types of information as well. Toresetre (talk) 07:57, 15 February 2019 (UTC)
@Animalparty: as @Toresetre: says, the yellow borders should only appear when hovering your mouse over the image. If that's not the case for you, please let me know your browser/OS and I can try to reproduce it. As things stand, I don't think it hurts, so I'm inclined to leave it in unless there's consensus against having them. Thanks. Mike Peel (talk) 20:35, 16 February 2019 (UTC)
This section was archived on a request by: Mike Peel (talk) 22:01, 18 February 2019 (UTC)

Error handling: power line/taxon mixture

Latest comment: 5 years ago17 comments4 people in discussion

Please see Category:110-kV-Leitung Lauchhammer–Riesa and expand "Common name" in the infobox. It currently states "Error in Wikidata: wikidata item" and gives weird entries like 'monotypic fossil taxon'. I don't find a reason on Wikidata. --Te750iv (talk) 11:53, 18 February 2019 (UTC)

The call to Template:VNNoDisplay returns an error message rather than a blank value. I have provided a fix in Template:Wikidata Infobox/core/sandbox and it just needs an administrator to copy the sandbox to Template:Wikidata Infobox/core. --RexxS (talk) 13:43, 18 February 2019 (UTC)
@RexxS: It also still needs to check for blank values (or ideally also cases where it's only returning category links without any content). Thanks. Mike Peel (talk) 14:13, 18 February 2019 (UTC)
@Mike Peel: I don't see documentation for Template:VNNoDisplay that tells me what I can expect. You're saying that it can return any of (1) a list of common names; (2) an error message; (3) a blank value; (4) an empty category link. Are there examples of these?
Can I ask why you didn't just use getvalue? --RexxS (talk) 14:33, 18 February 2019 (UTC)
@RexxS: There's more documentation at {{VN}}. I think the idea is that it uses a mix of sources, like taxon common name (P1843), and the aliases, to get the common names. It's messy, and TBH I'm inclined to just remove it as it stands. For examples of it live, look through Category:Uses of Wikidata Infobox for taxons - two example cases are Category:Abraliopsis morisii (showing a short list) and Category:Abraliopsis felis (showing blank/categories only). Thanks. Mike Peel (talk) 14:39, 18 February 2019 (UTC)
Mike, it's me you're talking to - you should know I already read the documentation at {{VN}} and at Module:Wikidata4Bio before I tried to fix the problem. None of it tells you what all the possible outputs are.
If you paste →{{VNNoDisplay|useWikidata={{#invoke:WikidataIB |getQid |qid={{{qid|}}} }} }}← into Category:Abraliopsis morisii and preview it, you get five common names (in foreign languages).
If you do the same in Category:Abraliopsis felis, you get a blank value returned. I'm not seeing the categories with empty values anywhere, so I'll fix the sandbox to drop empty values as well.
[Update:] Nope, can't do it. {{VNNoDisplay}} is producing some invisible output that means {{#if: treats it as non-blank, and {{#ifeq: doesn't match it to blank either. --RexxS (talk) 15:43, 18 February 2019 (UTC)
Sorry, I think you know as much as me about this then. I was hoping there would be more clues in the Lua code. All I can do is ping @Liné1 and Christian Ferrer: . Thanks. Mike Peel (talk) 16:26, 18 February 2019 (UTC)
Understood the issue, let me one minute. Christian Ferrer (talk) 17:10, 18 February 2019 (UTC)
@Christian Ferrer: Sorry I've overwritten your sandbox code, but you can't just test for taxon common name (P1843) because that will suppress the common name display for items like Category:Abraliopsis morisii - the whole point of using {{VNNoDisplay}}.
@Mike Peel: I've now tested for {{VNNoDisplay}} returning a string starting with a link to 'Category' and suppressed the row if that happens (as that is what it seems to return even when there is no common name). The sandbox works in Category:Abraliopsis morisii and Category:Holothuria austrinabassa. Let me know if you spot any issues with that. Cheers --RexxS (talk) 17:37, 18 February 2019 (UTC)
(unindent) @RexxS and Christian Ferrer: Thanks, I'll try to check through the changes shortly and make them live. There seems to be a formatting issue with the bottom of the taxonomy bit at Category:Holothuria austrinabassa though (in the sandbox version). Thanks. Mike Peel (talk) 17:42, 18 February 2019 (UTC)
@Mike Peel: That's because Template:Wikidata Infobox/core/sandbox uses the styles from Template:Wikidata Infobox/sandbox/styles.css, which hadn't been updated to the recent changes. I've done that now. --RexxS (talk) 18:05, 18 February 2019 (UTC)
Ah, right, that's Christian's mistake for not using the sandbox for those changes. I'll add back the other pending change to the sandbox/styles.css. Thanks. Mike Peel (talk) 18:07, 18 February 2019 (UTC)

@Christian Ferrer and RexxS: That made this significantly worse, it was appearing in e.g., Category:Observatório Astronômico Frei Rosário. I've reverted the edit for now. Thanks. Mike Peel (talk) 20:01, 18 February 2019 (UTC)

  • IMO we should restore other advances but without {{VNNoDisplay}} which is the cause of boredom + anywway the vertical format of the infobox is not really adapted to the display of a lot of values, as it is sometimes the cases for the common taxon names. {{VN}} is widely enough IMO, for me it is not necessary to integrate {{VNNoDisplay}} nor the property "taxon common name" to the infobox. Regards, Christian Ferrer (talk) 20:24, 18 February 2019 (UTC)
    Let me check through the code later this eve to see if I can find the issue, I suspect it's linked to the main version vs. sandboxes getting a bit out of sync. Thanks. Mike Peel (talk) 20:27, 18 February 2019 (UTC)
The bug appeared with my edit because before that {{VNNoDisplay}} was placed within the table "taxon header", therefore it was called in the infobox only when the table was called. But it is not its place IMO. Christian Ferrer (talk) 21:12, 18 February 2019 (UTC)
Yes, it was the combination of that, and RexxS's tweaks to the checking code not being synced over. It's hopefully all sorted and live now. Thanks. Mike Peel (talk)
This section was archived on a request by: Mike Peel (talk) 21:57, 18 February 2019 (UTC)

calendar

Latest comment: 5 years ago14 comments3 people in discussion

As discussed at d:Wikidata:Project_chat#Julian_or_Gregorian_calendar {{Wikidata Infobox}} on Category:Anton Pavlovich Chekhov has misleading dates, since they do not inform people that julian calendar is being used. You might want to look into the way template:Creator handles it using code analogous to {{#invoke:Wikidata date|date|item=Q5685|property=P569|lang=en}} -> . --Jarekt (talk) 14:41, 7 February 2019 (UTC)

I think we used to mark Julian dates in the infobox, but perhaps it was lost when @RexxS: reworked the date code? Thanks. Mike Peel (talk) 15:43, 7 February 2019 (UTC)
@Mike Peel and Jarekt: I've no recollection of ever displaying any indication of Julian dates. However it would not be difficult to do so, but you will have to tell me how you want it indicated and under what circumstances. I can see some options:
  • Add (Julian) after the date; or (in Julian calendar) or something similar? Maybe linked? Bear in mind that this would apply to all dates (in qualifiers as well) and that we're trying to cram it into an infobox.
  • Add the indication to all Julian dates; or only to those between 1582 and 1923 (where the ambiguity is likely to occur); or to those from 1582 to the present (just in case we get a date from the Armenian Patriarchate of Jerusalem)?
Let me know your wishes and I'll knock up the code. --RexxS (talk) 22:37, 7 February 2019 (UTC)
Personally I quite like the way it's set up on Wikidata, e.g. at Anton Chekhov (Q5685), but @Jarekt: may have different views? It needs to use the info on Wikidata about the date system used, rather than date ranges. Thanks. Mike Peel (talk) 22:49, 7 February 2019 (UTC)
Ok try this:
Let me know what changes you want made. --RexxS (talk) 22:55, 7 February 2019 (UTC)
I think we never resolved on Wikidata, if the same date should be in stored twice using 2 calendars or only one using one of them, so the data stored there might be quite inconsistent. I like using Module:Complex date through Module:Wikidata date because we have terms like "julian" calendar (and other date related phrases) translated into 40-50 languages. --Jarekt (talk) 13:09, 8 February 2019 (UTC)
@Jarekt: yes, my first instinct was to try to make use of Module:Complex date as WikidataIB already loads it to do date localisation. Unfortunately, Template:Complex date/doc doesn't show any way of indicating Julian Calendar, so I had to settle for doing that internally in WikidataIB. --RexxS (talk) 17:12, 8 February 2019 (UTC)
It is documented in the "example" section {{complex date|Julian|1865-01-19|1865-01-07}} -> 19 January 1865 (7 January 1865 in Julian calendar). Module:Wikidata date skips the second date so that {{complex date|Julian|1865-01-07}} -> 7 January 1865 (in Julian calendar). --Jarekt (talk) 17:22, 8 February 2019 (UTC)
Ah yes - I've found it now under the heading "date notations with two dates". I must have skipped over that as I only wanted one date. So you're using the conj parameter to indicate that it's in the Julian Calendar. The example uses the second date date to pass the Julian value, but it seems we can use it with just a single date:
  • {{complex date|julian|1865-01-19}} → 19 January 1865 (in Julian calendar)
  • {{complex date|julian|1865-01-19|lang=fr}} → 19 janvier 1865 (dans le calendrier julien)
That means I can make use of that directly in WikidataIB by passing 'julian" as the first parameter to the call to complex date.
That gives the localisation at the cost of being more verbose than just "(Julian)", which can be a nuisance in an infobox. @Mike Peel: any preferences? --RexxS (talk) 17:50, 8 February 2019 (UTC)
@RexxS: Sorry for the slow reply. That should be fine. @Jarekt: Just to double-check, it's in {{Wikidata Infobox/sandbox}}, see how that looks. Thanks. Mike Peel (talk) 20:44, 16 February 2019 (UTC)
@RexxS: One issue: at Category:Anton Pavlovich Chekhov the categories for the birth/death years don't work. It still works at e.g., Category:Rod Davies, so it's just an issue with Julian dates. To be specific, {{#invoke:WikidataIB | getValue | rank=best | P569 | name=birth | qid=Q5685 | fwd=ALL | osd=no | noicon=yes | df=y |pd=adj | lang=en}} returns 1860 - and Category:1860 doesn't exist. Thanks. Mike Peel (talk) 22:08, 18 February 2019 (UTC)
@Mike Peel: ah yes. That would happen. How about if I used the plaindate parameter to also suppress the Julian stuff?
  • {{#invoke:WikidataIB/sandbox | getValue | rank=best | P569 | name=birth | qid=Q5685 | fwd=ALL | osd=no | noicon=yes | df=y |pd=adj | lang=en}} returns 1860
  • [[:Category:{{#invoke:WikidataIB/sandbox | getValue | rank=best | P569 | name=birth | qid=Q5685 | fwd=ALL | osd=no | noicon=yes | df=y |pd=adj | lang=en}}]] → Category:1860
I can't see that we would want the extra guff when we ask for a 'plaindate'. --RexxS (talk) 23:13, 18 February 2019 (UTC)
@RexxS: I lost track of this, but looking back it seems to be working nicely, thanks! Mike Peel (talk) 23:12, 8 March 2019 (UTC)
This section was archived on a request by: Mike Peel (talk) 23:12, 8 March 2019 (UTC)

Displaying of non-administrative locations

Latest comment: 5 years ago6 comments3 people in discussion

Currently, location (P276) isn't displayed any more in the infobox if located in the administrative territorial entity (P131) is also present. That means that (small) villages and other populated places which are not administrative territorial entities are missing in the infobox (see Category:Sieben Schmerzen Mariens (Uckendorf) as an example where location Uckendorf (Q1334454) is not displayed). I guess that should be changed so the most precise location info is presented. The same desirable result in the infobox is achieved right now when one deletes located in the administrative territorial entity (P131) from the item but I doubt this property is seen as redundant when the geographically more precise non-administrative location is stated.--Leit (talk) 19:37, 14 February 2019 (UTC)

@Leit: As Wikidata allows several different properties to represent locations, I've made the code look for located in the administrative territorial entity (P131), then location (P276), then located in/on physical feature (P706) at each step as it goes up the chain of locations until reaches a country (Q6256). Since it is quite possible that more than one of these may be set in a particular entity, I had to decide an order of preference and chose the order located in the administrative territorial entity (P131), location (P276), located in/on physical feature (P706).
Now, if you think it would improve the algorithm to prefer location (P276) over located in the administrative territorial entity (P131), then we can use the change of order I've now made in Module:WikidataIB/sandbox. For reference:
Do you have more examples where we could test the modification to ensure it's an improvement? --RexxS (talk) 23:26, 19 February 2019 (UTC)
@RexxS: The change you've made in the sandbox would be the desired outcome. Certainly I do have more examples but they are all similar – in short, all geographical objects (buildings, sculptures, streets etc.) whose primary location (most often a village or smaller human settlement) is non-administrative. For instance, the smallest administrative territorial entity in Germany is a municipality (numbering around 10,000), but there is a multiple number of villages, hamlets and smaller settlements that belong to a (superior) municipality. All Wikidata objects that are located there should have both location (P276) and located in the administrative territorial entity (P131) and, of course, both should be shown in the infobox. --Leit (talk) 20:52, 21 February 2019 (UTC)
@Leit: I guessed that would be the case. My only concern would be if a small place had both a location (P276) and a located in the administrative territorial entity (P131) going to different places, and the location (P276) route lead to a dead end. Although, that should be easily fixed by adding a parent location to wherever it stops. There's no real way to generate test cases for that sort of problem. I'm going to suggest to Mike Peel that he updates Module:WikidataIB from its sandbox, and see if anybody reports anything. --RexxS (talk) 21:42, 21 February 2019 (UTC)
@RexxS and Leit:   Done, let's see how that goes. Thanks. Mike Peel (talk) 10:39, 22 February 2019 (UTC)
This section was archived on a request by: Mike Peel (talk) 23:06, 8 March 2019 (UTC)

defaultsort option in award categories

Latest comment: 5 years ago6 comments3 people in discussion

Items with defaultsort=no are getting sorted under N in award categories, e.g., see Category:Henryk Jerzy Chmielewski and others in Category:Recipients of the Medal for Merit to Culture – Gloria Artis. --ghouston (talk) 06:13, 19 February 2019 (UTC)

This seems fixed now. Laddo (talk) 12:06, 23 February 2019 (UTC)
Only for Category:Henryk Jerzy Chmielewski, because somebody removed the defaultsort=no option, but not for the problem in general. --ghouston (talk) 22:21, 23 February 2019 (UTC)
@Ghouston and Laddo: I think this edit fixes it - it seems to work at Category:Witold Sobociński. Try {{Wikidata Infobox/sandbox}} for now. I'll make that change live soon, but it'll take a bit of time for the cache to update after then. Thanks. Mike Peel (talk) 23:00, 8 March 2019 (UTC)
This is now live. Thanks. Mike Peel (talk) 16:43, 9 March 2019 (UTC)
This section was archived on a request by: Mike Peel (talk) 16:43, 9 March 2019 (UTC)

Uses of Wikidata Infobox with no image

Latest comment: 5 years ago5 comments3 people in discussion

Moin Moin together, there are more than 800000 cases in this category, a not inconsiderable part of which consists of BKLs and category pages. Would it be possible not to run certain pages in this category in the first place? Examples: P31 = Q101352 (family name), P31 = Q202444 (given name), P31 = Q4167410 (BKL), P31 = Q4167836 (Category). Would that make sense? Regards --Crazy1880 (talk) 17:07, 22 February 2019 (UTC)

@Crazy1880: Probably one would want to keep most of the P31 = Q4167836 (Category) cases, because they probably have a category's main topic (P301) statement linking to a topic which should indeed have a picture. But excluding family name categories, given name categories, and DAB categories from the maintenance categorisation might well make sense. Jheald (talk) 22:48, 25 February 2019 (UTC)
@Crazy1880 and Jheald: This change is now in the sandbox, please test {{Wikidata Infobox/sandbox}} to make sure it works as you want. I haven't included P31 = Q4167836, but the other three are there. Thanks. Mike Peel (talk) 22:54, 8 March 2019 (UTC)
This is now live. Thanks. Mike Peel (talk) 16:43, 9 March 2019 (UTC)
This section was archived on a request by: Mike Peel (talk) 16:43, 9 March 2019 (UTC)

located on street (P669) not displayed

Latest comment: 5 years ago7 comments4 people in discussion

There is an issue with the displaying of this property. See Category:Kirchstraße 54 (Bonn) as an example.--Leit (talk) 14:38, 25 February 2019 (UTC)

Personally I don't see:
as an improvement on:
Why would we want to repeat the street (which is obvious) and miss out on the districts? --RexxS (talk) 02:54, 26 February 2019 (UTC)
See Category:Palác U Stýblů. At item located on street (P669), house number (P670) and conscription number (P4856) is filled, but "Located at street address" is empty.Jklamo (talk) 09:04, 26 February 2019 (UTC)
Sorry, I forgot to mention that until recently located on street (P669) was displayed in the located at street address field. street address (P6375) is not neccessary (one could also say, only optional) if the street has an own item.--Leit (talk) 10:52, 26 February 2019 (UTC)
@Leit, RexxS, and Jklamo: I think this was caused by a stray "|", should be fixed in {{Wikidata Infobox/sandbox}}. Thanks. Mike Peel (talk) 22:46, 8 March 2019 (UTC)
This fix is now live. Thanks. Mike Peel (talk) 16:42, 9 March 2019 (UTC)
This section was archived on a request by: Mike Peel (talk) 16:42, 9 March 2019 (UTC)

montage image (P2716)

Latest comment: 5 years ago6 comments3 people in discussion

in some cases there are no images that on wikidata can represent an element well, but they can have a collage image (montage image (P2716)). Is it possible to see in the Wikidata Infobox the collage image when there isn't a value for image (P18)? --Yiyi (Dimmi!) 15:53, 3 March 2019 (UTC)

Yes, please. Thierry Caro (talk) 00:31, 4 March 2019 (UTC)
@Yiyi and Thierry Caro: It's now in the sandbox, please test {{Wikidata Infobox/sandbox}} to see if that works OK. It just displays the image where the property is set without checking for P18 - in the longer term I hope to improve the display of multiple images in the infobox, but I hope this is ok for now. Thanks. Mike Peel (talk) 00:23, 5 March 2019 (UTC)
Thank you! It's perfect :-) --Yiyi (Dimmi!) 09:36, 5 March 2019 (UTC)
@Yiyi: This is now live. Thanks. Mike Peel (talk) 16:41, 9 March 2019 (UTC)
This section was archived on a request by: Mike Peel (talk) 16:41, 9 March 2019 (UTC)

Insert P3974, PP6560, P6478, P6280 and P5965

Latest comment: 5 years ago5 comments2 people in discussion

Please add P3974, PP6560, P6478, P6280 and P5965 similar to this request to be displayed in the section "Normdatei". Many thx in advance. --Derzno (talk) 14:42, 5 March 2019 (UTC)

@Derzno: done in the sandbox, please test {{Wikidata Infobox/sandbox}} to make sure they work as expected. Thanks. Mike Peel (talk) 22:36, 8 March 2019 (UTC)
@Mike Peel: I'd just tested and it looks pretty good. Thx an lets go with. --Derzno (talk) 14:46, 9 March 2019 (UTC)
@Derzno: This is now live. Thanks. Mike Peel (talk) 16:41, 9 March 2019 (UTC)
This section was archived on a request by: Mike Peel (talk) 16:41, 9 March 2019 (UTC)

Removal of a caption related style

Latest comment: 5 years ago5 comments2 people in discussion

I added a rule to make the caption centered for the MinervaNeue skin , which should be removed after phab:T168861 is fixed. However I have no rights to do it now, who can help me? --Great Brightstar (talk) 15:59, 13 April 2019 (UTC)

@Great Brightstar: Can you add it in the sandbox so that we can test it? Template:Wikidata Infobox/sandbox/styles.css, Template:Wikidata Infobox/sandbox, or Template:Wikidata Infobox/core/sandbox as appropriate. Thanks. Mike Peel (talk) 16:16, 13 April 2019 (UTC)
OK, I did. You can see it in this link. --Great Brightstar (talk) 16:19, 13 April 2019 (UTC)
OK, now live. Thanks. Mike Peel (talk) 16:32, 13 April 2019 (UTC)
This section was archived on a request by: Mike Peel (talk) 19:23, 19 April 2019 (UTC)

Rheinland-Pfalz Schutzgebiete-ID (P6602) / Baden-Württemberg Schutzgebiete-ID (P6659)

Latest comment: 5 years ago3 comments2 people in discussion

Please add P6602 and P6659 similar to this request to be displayed in the section "Normdatei". Many thx in advance. --Derzno (talk) 17:29, 25 March 2019 (UTC)

@Derzno: Done, sorry for the delay. Thanks. Mike Peel (talk) 18:57, 23 April 2019 (UTC)
This section was archived on a request by: Mike Peel (talk) 18:57, 23 April 2019 (UTC)

Men/Women by name

Latest comment: 5 years ago5 comments3 people in discussion

Can this template apply:

as appropriate? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 22:07, 9 April 2019 (UTC)

Doesn't it already? I think Gender by name, as well as Category:Deceased people by name and Category:People by name are added automatically, assuming the corresponding Wikidata property exists. --Animalparty (talk)
Indeed it does already. Laddo (talk) 01:50, 10 April 2019 (UTC)
@Pigsonthewing: Yes, this is already there, as long as sex or gender (P21) is set to either female (Q6581072) or male (Q6581097), and the infobox is used in a category. I'm reworking the code to also include Category:LGBT people by name in {{Wikidata Infobox/sandbox}}, at the moment supporting trans man (Q2449503) and trans woman (Q1052281) - pointers to the other items to add there would be useful. Thanks. Mike Peel (talk) 13:32, 10 April 2019 (UTC)
That's odd; I'm sure I found a case yesterday where it did not - but I cannot now recall where. Sorry for the bother. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 16:23, 10 April 2019 (UTC)
This section was archived on a request by: Mike Peel (talk) 18:56, 23 April 2019 (UTC)

Removal

Latest comment: 5 years ago7 comments2 people in discussion

Please remoe in Template:Wikidata Infobox/core "&lang=en" ("https://www.wikidata.org/wiki/Special:NewItem?site=commonswiki&page=Template_talk:Wikidata_Infobox/Archive_2&label=Wikidata+Infobox%2FArchive+2&lang=en Create new Wikidata item") in Row 14. Atamari (talk) 15:09, 19 April 2019 (UTC)

@Atamari: Why? Mike Peel (talk) 18:35, 19 April 2019 (UTC)
unnecessary for en-users; disturbing and disabling for users who do not have en-as standard. They switch to their language version each time. I think removing it makes it more comfortable for users of other languages and is not subject to coercion. On the Wikidata you can still change the language version. Atamari (talk) 18:41, 19 April 2019 (UTC)
@Atamari: Aah, just the "lang=en" part, not the link itself? That's now done in the sandbox, please can you try {{Wikidata Infobox/sandbox}} to make sure it works as you want it to? Thanks. Mike Peel (talk) 19:10, 19 April 2019 (UTC)
Yes, only the "lang=en" part. It works for me (there on wikidata) as de-user as it should. And for en-users, it has no negative impact, or? Atamari (talk) 19:17, 19 April 2019 (UTC)
@Atamari: I couldn't see any negative effects, so it's now done. Thanks. Mike Peel (talk) 18:55, 23 April 2019 (UTC)
This section was archived on a request by: Mike Peel (talk) 18:55, 23 April 2019 (UTC)

Display image of tomb / display qualifiers

Latest comment: 5 years ago13 comments5 people in discussion

Hi. I made an edit to display the image of tomb at the bottom of the infobox following the line of image (P18), see Category:Georges Hage and Category:Rudolf von Delbrück, but I don't know if you prefer this display at the top of the infobox, following the image, or at its bottom, as we do on FR Wiki. I have no specific opinions about this.

On another hand, I am interested to display qualifiers for some fields, but I am not able to do this (it is more easy for me with Lua). Jérémy-Günther-Heinz Jähnick (talk) 18:02, 4 April 2018 (UTC)

My personal opinion is that I would be cautious not to have too many pictures in one box, because then the whole thing gets very large and the crucial elements (like dates of birth/death etc.) are quite far away from the top. We're on Commons anyway, so people can access those pictures with ease. In case of people, who have coats of arms (like aristocrats or bishops) this will be the third picture in the box. I'm slightly against adding the image of tomb. Powerek38 (talk) 22:00, 4 April 2018 (UTC)
I agree, I think that one picture in the infobox is enough. I prefer to not add an image of the tomb to the infobox, but I have no problem to show an image of the tomb in a case, where there is no P18.--Jklamo (talk) 08:08, 5 April 2018 (UTC)
By the way, please take a look here. There's clearly a bug in the code section, which diplays the tomb images. Powerek38 (talk) 09:30, 5 April 2018 (UTC)
@Powerek38: The issue there is that P18 existed, but was set to "no value". So it was triggering the check for P18, but then returning nothing. As far as I'm aware, that's not a valid thing to do on Wikidata, so I removed it and that fixed it. Maybe @Jklamo: , who added it there in the first place, has a comment on this? Thanks. Mike Peel (talk) 11:13, 5 April 2018 (UTC)
One thing I was playing around with a few months back was to use Javascript to have a switch between different image options, see User:Mike Peel/Sandbox2. The downside is that the javascript has to be loaded by MediaWiki by default, it can't just be added for this template. But if this approach is of interest then it can be improved upon a bit more (checkboxes as a horizontal list for example) and we can see if it can be added to the main javascript repository. Thanks. Mike Peel (talk) 11:13, 5 April 2018 (UTC)
... of course, if you want to see that working, then you need to have the javascript. That's at [5] - either include that javascript page in your own, or copy-paste that to your own common.js to try it out. Or, have a look at en:London - in the infobox, there are a series of location maps you can switch between, it's the same setup here. Thanks. Mike Peel (talk) 11:30, 5 April 2018 (UTC)
Yes, we also use this solution for location maps at plWiki, I think it's a good idea to solve it this way. Powerek38 (talk) 13:15, 5 April 2018 (UTC)

I will not open a new section just for that : this morning, I add the idea to add number of casualties (P1590), number of deaths (P1120), number of missing (P1446) and number of injured (P1339). So I copy paste, but there is not display on c:Category:Phnom Penh stampede. Jérémy-Günther-Heinz Jähnick (talk) 12:17, 5 April 2018 (UTC)

@Jérémy-Günther-Heinz Jähnick: You added it to the part that shows for categories about humans, not the part for everything else. I've moved the code down the page, and that seems to work OK now. [6]. Thanks. Mike Peel (talk) 14:00, 5 April 2018 (UTC)
Moin Moin Jérémy-Günther-Heinz Jähnick, is this part done? Could you then please set {{Section resolved|1=~~~~}} to this part? Thanks --Crazy1880 (talk) 13:15, 28 April 2019 (UTC)
Hi @Crazy1880: . Yes, it is done. I am happy to see the success of this template one year after. Jérémy-Günther-Heinz Jähnick (talk) 14:27, 28 April 2019 (UTC)
This section was archived on a request by: Jérémy-Günther-Heinz Jähnick (talk) 14:27, 28 April 2019 (UTC)

Layout problem

Latest comment: 5 years ago5 comments3 people in discussion

The following article has a strange layout Category:Museum_De_Moriaan. Does someone know why? It looks like something is changed recently, because normally putting the gps location on top fixes layout problems. Rudolphous (talk) 19:49, 10 July 2018 (UTC)

@Rudolphous: {{Building address}} is broken, apparently intentionally. See the discussion at Template_talk:Building_address#Bug_with_this_template. I've removed that from the page, and all looks OK now. Thanks. Mike Peel (talk) 20:34, 10 July 2018 (UTC)
Hi Mike, thanks for your fix. There are many others too: For example [7]. Is there no way the buildingblock address template can be fixed? A couple of days ago all these monuments where correctly styled if I remember correctly. Rudolphous (talk) 20:44, 10 July 2018 (UTC)
@Rudolphous: It seems that fixing the HTML so that it works right on its own would then break it when it's used inside the information template. The ideal thing would be to (manually or automatically) move the info onto Wikidata and remove the template from the category, as I did at Category:Museum_De_Moriaan. Thanks. Mike Peel (talk) 20:59, 10 July 2018 (UTC)
This section was archived on a request by: Crazy1880 (talk) 13:02, 28 April 2019 (UTC)

Questions ans wishes

Latest comment: 5 years ago11 comments4 people in discussion

Hello together, since a few days I worked with this infobox, I've asked me a few questions and became wishes.

  • Is it possible to realize a category automated, and thus similar to "born on", for inception (P571)?
  • On the page Commons:Categories you should mention this box and also that these categories are inserted independently.
  • Otherwise, nice thing, congratulations

Thanks for answers --Crazy1880 (talk) 18:20, 1 August 2018 (UTC)

@Crazy1880: Sorry for not replying sooner. It is possible to add additional automated categories, do you have a category tree in mind? I've added a mention of the infobox to Commons:Categories at [8] - please edit that page if you can think of a better way to talk about it. Thanks. Mike Peel (talk) 23:51, 28 August 2018 (UTC)
Moin Moin @Mike Peel: ,
Regards --Crazy1880 (talk) 18:32, 29 August 2018 (UTC)
@Crazy1880: I guess we could use inception (P571) and country (P17) to automatically add "Category:<P571> establishments in <P17>" - or if that category doesn't exist then it could be added to "Category:<P571> establishments". Would that make sense? Thanks. Mike Peel (talk) 23:07, 29 August 2018 (UTC)
@Mike Peel: Could we do both? On the one hand "<P571> establishments‎" and on the other hand (if it exists) "<P571> establishments in <P17>". For inaccurate information, such as decade there were "<P571>s establishments in <P17>" (Example). Regards --Crazy1880 (talk) 06:11, 30 August 2018 (UTC)
@Crazy1880: It's now in the sandbox, please can you test {{Wikidata Infobox/sandbox}} to see if it's working as expected? E.g. at Category:Wikidata it would add Category:2012 establishments, and at Category:Gare de Lyon-Gorge-de-Loup it adds Category:1983 establishments in France. Thanks. Mike Peel (talk) 11:51, 30 August 2018 (UTC)
@Mike Peel: Works good, tested with Louvre und Burj Khalifa. Thanks --Crazy1880 (talk) 12:07, 30 August 2018 (UTC)
@Crazy1880: OK, it's now live, let's see how it goes. Thanks. Mike Peel (talk) 12:18, 30 August 2018 (UTC)
I have a problem with Category:State Government Offices, Melbourne: I put it in a category Category:Built in Australia in 1877, as usual, but the template is also adding Category:1877 establishments in Australia, which I don't think is wanted for a building. --ghouston (talk) 10:26, 31 August 2018 (UTC)
Please consider the template does not fit for every cat. see Category talk:Three Musicians by the Master of the Female Half-Lengths Oursana (talk) 00:47, 4 September 2018 (UTC)
This section was archived on a request by: Crazy1880 (talk) 13:03, 28 April 2019 (UTC)

Problems with P131 chains in case of more than one administrative unit

Latest comment: 5 years ago6 comments4 people in discussion

Please see the infobox at Category:Windpark Kandrich and Kandrich wind farm (Q56558844). The wind farm is located in 4 municipalities, which belong to different districts within the state of Rhineland-Palatinate of Germany:

Problem: taken from the first statement for located in the administrative territorial entity (P131), only the Daxweiler chain is given in the infobox. The rest is missing.
P131 statements like in this case are quite regular ("cross-border" objects located in more than one administrative unit), and they are wanted on Wikidata (be "as exact as possible").
The only solution for a correct infobox on Commons at the moment would be to add the state Rhineland-Palatinate (Q1200) instead of the 4 municipalities, but that would mean loss of precise location information on Wikidata (unwanted).
To add the next higher administrative unit (3 districts) instead of the 4 municipalities, would also be no solution, because the effect would be the same (only the first district would be given). And it would also mean loss of precise location information on Wikidata (please note that there are 118 municipalities in Bad Kreuznach district, 137 in Rhein-Hunsrück-Kreis, and 66 in Mainz-Bingen district, so stating the only relevant 4 municipalities really makes sense).
Another, maybe even better example is Belgium–Germany–Luxembourg tripoint (Q27344570) and the infobox at Category:Tripoint Belgium Germany Luxembourg. Only one municipality and only one country is given in the infobox.
I hope someone can fix this issue. --Te750iv (talk) 18:42, 10 September 2018 (UTC)

@Te750iv: I agree that we lose some information in the infobox when there are multiple values of located in the administrative territorial entity (P131). However, I'm not sure how you want it fixed. At present the call to location for Kandrich wind farm (Q56558844) produces this list:
If you could write exactly what you wanted to see as the list, perhaps I could work out an algorithm to display it. --RexxS (talk) 21:58, 10 September 2018 (UTC)
@RexxS: Sorry for being not clear enough. I want the actual P131 statements (for Q56558844: 4 municipalities), and all countries (if more than one, as in the above tripoint example) to be displayed. This is the correct information.
Such statements were no problem for infoboxes a few weeks ago. The behaviour changed. Displaying only the first P131 statement gives incomplete and incorrect information for numerous affected items/categories, e.g. for linear objects like rivers, roads or railway lines, or for non-administrative areas like mountains, beaches, heritage properties, even for some building or industrial complexes (if located on state or municipal borders like Uchtelfangen substation (Q1515772)). For another prominent example see U.S. Route 66 (Q79934) and Category:U.S. Route 66: per infobox now exclusively located in California, and in no country (don't know why "United States" is missing there).
If I follow the discussions here correctly, you and others have given careful thought and put much work into development of a smart method for displaying complex location chains in infoboxes. I was impressed when I noticed it, and am still astonished what is possible. But the current method of fetching data obviously is highly "automated" and depends on basic assumptions, which are are not (and cannot) be true in too many cases. The main wrong assumption is: everything is located in only one administrative unit. As a result the chosen method has unwanted side effects: loss of information, either on Wikidata by changing P131 statements to less precise levels, or on Commons by displaying precise, but incomplete and only random (=the first) bits of information.
Back to the Kandrich wind farm (Q56558844) example: From my point of view the 4 municipalities and the country (Germany) are the basic and most important information. Displaying location chains completely from low levels upwards is "nice to have", but not a must. The length of chains can be more or less complex (example for Germany: >municipality >collective municipality >district >regional administrative division >state >country). And if you could find a way to display all municipalities including their individual chains, a new problem may arise: what about redundant parts? (often occuring upwards from some administrative unit in the middle; in the given example "Rhineland-Palatinate, Germany" would be identical 4 times). Is it possible to eliminate redundant parts from chains?
So even if I really like seeing location chains in infoboxes, in case I have to choose between the two display variants (complicated but incomplete/ramdom information vs. only basic but correct information), I prefer the latter. Therefore I think a step back and a more conservative approach with less automation is appropriate. --Te750iv (talk) 08:04, 11 September 2018 (UTC)
@Te750iv and RexxS: I've coded up a work-around here, in {{Wikidata Infobox/sandbox}} - please test it to make sure it behaves as expected. Basically, if there are multiple values for located in the administrative territorial entity (P131), then the template falls back to the old {{Wikidata location}}. Hopefully in the long term the Lua code can be modified to handle this directly, but this should do for now. Thanks. Mike Peel (talk) 21:37, 29 September 2018 (UTC)
@Mike Peel: Tested, works as expected. A good solution for now. Thanks very much. --Te750iv (talk) 21:48, 29 September 2018 (UTC)
This section was archived on a request by: Crazy1880 (talk) 13:08, 28 April 2019 (UTC)

People with double given and/or surnames

Latest comment: 5 years ago49 comments6 people in discussion

Hi, there are a lot of cats for people with double, tripple or even more given or surnames. On wikidata they often not claimed as such doubles names, but seperatly to diffenent names. I.e. a person called John Peter Smith Brown doesnt has the claim "John Peter" on commons but seperatly "John" and "Peter". This results this person is sorted into Category:John (given name) and not into Category:John Peter (given name) nor Category:Peter (given name). The same applies to the surname(s). I.e. Category:John Peter Altgeld is now sorted into Category:John (given name) through the infobox and manually Category:John Peter (given name), which is suboptimal. Up to now I fixed that by creating an item on wikidata for such double names see i.e. Gustaf Wilhelm (on wikidata). Bute there a now complains and deletion requests on wikidata to such items - see d:Wikidata:Requests_for_deletions#Q56525307. Is it possible to combine such double claimes on wikidata to one given or surname category here on commons? It would be even OK if the people just get sorted in both (or more) sur- or given name cats. Any coder able and willing to do such a change? Thx in advance --JuTa 19:07, 12 September 2018 (UTC)

@JuTa: It's possible, but it needs some more thinking about. In your example, if 'John', 'Peter' and 'Smith' were all given names on Wikidata, how would you want it handled? What if the 'John Peter (given name)' category doesn't exist, what should the fallback be? Thanks. Mike Peel (talk) 23:34, 12 September 2018 (UTC)
Then leave it out like if single names cats does not exist. I'm busy since years to check people cats and create missing ur- and given name cats. It could be done per bot as well. Laddo initiated a huge bot-run recently - see Commons:Bots/Work_requests#Batch_create_"surname"_categories. Currently I'm rechecking some of them and during that the complaints on wikidate appeared. regards. --JuTa 02:15, 13 September 2018 (UTC)
@Mike Peel: Hi Mike, indeed JuTa's suggestion seems applicable. Simply categorize in all given name categories matching each Wikidata given name property entries (P735). However I'm not sure I understand; you seem to suggest that {{Wikidata infobox}} normally parses the given name from some full name label - or from the Commons page title? If you rely on Wikidata, then there is no issue picking (all the) appropriate given name category/ies.
@JuTa: Regarding WD items for given name combinations like Gustaf Wilhelm (Q56525307), I would also suggest to avoid that, except when such names are linked by dashes (Mary-Laure (Q19689498)) - there are just too many combinations to create an item for each pair. IMHO, rather use multiple given name (P735) entries qualified with series ordinal (P1545), such as in Mary Beth Peil (Q449134). I've seen that a lot in WD already. If Mike can improve given name categorization, the right categorization would be straightforward (e.g. Category:Mary (given name) Category:Beth (given name) for Mary Beth Peil (Q449134)).
Laddo (talk) 02:45, 13 September 2018 (UTC)
Note there is also second family name in Spanish name (P1950) and maybe more similar. People using this claim should be sorted into both surname cats and not into the comibation one. regards. --JuTa 02:55, 13 September 2018 (UTC)
@Laddo: Adding all of the given name categories separately would work, but that wouldn't solve @JuTa: 's request to support Category:John Peter (given name) *unless* that is a specific given name (P735) value on Wikidata. The infobox uses given name (P735) and family name (P734), not the full name label or the commons page title for this. It's the same with second family name in Spanish name (P1950), that can be done, would they just go into the current 'Category:Rodriguez (surname)' format or is there a different format for those? Thanks. Mike Peel (talk) 10:34, 13 September 2018 (UTC)
@Mike Peel: Given name category handling is simpler and cleaner if you simply follow WD's given name (P735) entries. WD and Commons should follow a similar reasoning and policy regarding categories of paired given names like Category:John Peter (given name) : deleting such "double" categories and simply relying on individual given names. WD infobox should categorize in "paired" given name categories only if WD supports one, like for Mary-Laure (Q19689498), IMO. @JuTa: What do you think of avoiding Commons categories like Category:John Peter (given name) altogether ? -- Laddo (talk) 12:29, 13 September 2018 (UTC)
Would be fine for me if this get handeled consequently for all the thousends double name cats, can take a while but there should be a plan to do that including peoples cats which are not yet wikidata connected. regards --JuTa 12:53, 13 September 2018 (UTC)
The first step is to ensure that WD infobox categorizes for all given names, not only the first one. Mike? Laddo (talk) 13:26, 13 September 2018 (UTC)
So, the simplest thing to do is to use the commons sitelinks. Then we can just use {{#invoke:WikidataIB|getValue|rank=best|P735|linked=yes|name=forename|qid={{getQID|qid={{{qid|}}}}}|spf={{{suppressfields|}}}|fwd=ALL|osd=no|noicon=yes|lang=en}} - however, we have more categories here than sitelinked given names right now. How big an issue is that? I was hoping that something like {{#invoke:WikidataIB|getValue|rank=best|P735|linked=no|name=forename|qid={{getQID|qid={{{qid|}}}}}|spf={{{suppressfields|}}}|fwd=ALL|osd=no|noicon=yes|lang=en|prefix="[[Category:"|postfix=" (given name)]]"}} would work - but it just prints out the name, not the prefix or postfix. (Plus, the ifexists check complicates things further). Pinging @RexxS: to see if he can do something magical in Lua / has any thoughts about how to do this with the existing options. Thanks. Mike Peel (talk) 14:09, 13 September 2018 (UTC)
Thx, but sorry, I have now clew of these #invoke things. Thats the reason I'm other people for help :) --JuTa 18:27, 13 September 2018 (UTC)
@Mike Peel: I've enabled unlinked wikibase items to use prefix and postfix now. But that doesn't help much you as you can't pass [[ in a parameter because the wiki-parser immediately creates a link before the invoke is called. I'm not really sure what you want to do, but this formula seems to me to do something in Gustaf Wilhelm af Tibell (Q4457034):
  • {{#invoke:WikidataIB |getValue |rank=b |P735 |qid=Q4457034 |fwd=ALL |osd=no |noicon=yes |linkprefix=":" |prefix="Category:" |postfix=" (given name)"}} → Category:Gustaf (given name), Category:Wilhelm (given name) Naturally, you set linkprefix to "" (or leave it out) if you want to add the page to the category, rather than just create the link as I've done here. On the other hand, I'm not sure if will always work or whether it depends on the presence of a commons category. I really need more examples to test on. Maybe play around with the format to see if you can consistently get what you want (whatever that is). Cheers --RexxS (talk) 23:23, 20 September 2018 (UTC)

On the other hand cats like Category:Paul Bailliart would be sorted into Category:Alfred (given name) and Category:Marie (given name) thou the lemma doe not contain Alfred Marie on any project - see d:Q3370547. We would need to either to move the commons cat or throw out the extra given names on WD. --JuTa 21:54, 14 September 2018 (UTC)

Hi, any progress regarding this case? I noticed that the defaultsort allready covers double given/surnames from wikidata except there is a comma too much between the 2 nameparts. That part of the code could be fixed and used to sort the people to the name cats as well, I hope. thx. --JuTa 11:09, 24 September 2018 (UTC)
Sorry, am trying to get a few other things with the infobox sorted out first (there are many changes in the sandbox right now), then will circle back round to this. Thanks. Mike Peel (talk) 11:21, 24 September 2018 (UTC)
@JuTa: It's now in {{Wikidata Infobox/sandbox}} - please test that and see how it works. Thanks. Mike Peel (talk) 23:31, 24 September 2018 (UTC)
@Mike Peel: , I'll do, thx. Please look at #new bug with surnames again. This seems not to be fixed.
@Mike Peel: , tested it. It looks like some brackets are mising - see this version. please reinvestivate. Thx. --JuTa 23:44, 24 September 2018 (UTC)
@RexxS: Somehow this seems to depend on the Commons sitelinks. Compare:
{{#invoke:WikidataIB |getValue |rank=best |P735 |qid=Q47001248 |fwd=ALL |osd=no |noicon=yes | linkprefix=:|prefix="Category:" |postfix=" (given name)"}} -> Category:Luca (given name), Category:Maria (given name)
{{#invoke:WikidataIB |getValue |rank=best |P735 |qid=Q4457034 |fwd=ALL |osd=no |noicon=yes | linkprefix=:|prefix="Category:" |postfix=" (given name)"}}Category:Gustaf (given name), Category:Wilhelm (given name)
I'm not sure what to do here. Thanks. Mike Peel (talk) 00:13, 25 September 2018 (UTC)
Sorry, Mike, the logic does depend on the Commons category (P373) available on Wikidata. I have to get the text to return from somewhere.
Commons category (P373), Gustaf (Q15646212), Wilhelm (Q11027623), Luca (Q1872944), Maria (Q25413386)
  • {{wdib |P373 |qid=Q15646212 |fwd=ALL |osd=n |noicon=y}} → Gustaf (given name)
  • {{wdib |P373 |qid=Q11027623 |fwd=ALL |osd=n |noicon=y}} → Wilhelm (given name)
  • {{wdib |P373 |qid=Q1872944 |fwd=ALL |osd=n |noicon=y}} → Luca (given name)
  • {{wdib |P373 |qid=Q25413386 |fwd=ALL |osd=n |noicon=y}} →
When we request the given name (P735) for Gustaf Wilhelm af Tibell (Q4457034) the logic in WikidataIB goes like this:
  1. We get the qid for Gustaf (Q15646212) and need to find the text to display, so we look at Q15646212 for a Commons category (P373)
  2. That gives "Gustaf (given name)", so we use it to create a link to [[ linkprefix Category: Gustaf (given name) linkpostfix ]] and use the label ("Gustaf") as display text for the link.
However, when we try the same with Luca Maria Bonisoli (Q47001248), there is no Commons category (P373) for Luca, so it looks for a sitelink and there is one in English, so it uses that for the link target - but that will fail for most other languages and we just get the unlinked label.
That is the best we can do for a stand-alone value, but when you're trying to create a compound value, we need a consistent style of output, so you need to avoid requesting linked items and cheat to pass the [[, remembering that the code strips out any double quotes:
That merely depends on the presence of an English label for the name.
In this application, it's probably not essential, but I recommend fixing language as English because all Commons categories are named in English. Does that do the trick? --RexxS (talk) 11:19, 25 September 2018 (UTC)
Thanks RexxS, that seems to do the trick. @JuTa and Laddo: can you test {{Wikidata Infobox/sandbox}} to see if that's working as expected? Thanks. Mike Peel (talk) 18:07, 25 September 2018 (UTC)
@Mike Peel: , looks better, but in the defaultsort there is still a comma to much, see Category:Luca Maria Bonisoli. --JuTa 22:04, 25 September 2018 (UTC)
@JuTa: should be fixed now. Thanks. Mike Peel (talk) 22:08, 25 September 2018 (UTC)
Yep, thx. --JuTa 22:10, 25 September 2018 (UTC)
Agreed, seems excellent. Thanks! -- Laddo (talk) 22:44, 25 September 2018 (UTC)
Sorry, but I now saw, that for surnames 1. The second surname cat is missing and 2. the defaultsort value is incorrect. Mike Peel: Have another look please - see Category:Alfredo Pérez Rubalcaba. Thx. --JuTa 22:48, 25 September 2018 (UTC)
@JuTa: In that case, there is a value for second family name in Spanish name (P1950), which the infobox uses, and which that's hy the defaultsort now looks odd. The issue with supporting multiple surnames is that you want a custom sort key for those surnames - I'm not sure that WikidataIB can cope with using a postfix value that depends on another WikidataIB call. @RexxS: any thoughts on that? E.g. from a QID that has "Bob" as the first name and both "Smith" and "Johnson" for the surname, we'd want to create something like [[Category:Smith (surname)|Bob]][[Category:Johnson (surname)|Bob]] - but only if those categories exist (and not relying on Commons category (P373)). Thanks. Mike Peel (talk) 22:59, 25 September 2018 (UTC)
@Mike Peel: WikidataIB is quite good at coping nowadays. You can indeed use the result of one call as a parameter in another call. Using Gabriel Gonzáles Videla (Q815):
  • {{wdib |rank=b |P734 |qid=Q815 |fwd=ALL |osd=n |noicon=y |linked=n |prefix="[""[:Category:" |postfix=" (surname){{!}}{{wdib|rank=b|P735|qid=Q815|fwd=ALL|osd=n|noicon=y|linked=n}}]]" |lang=en}} → Gabriel
  • {{wdib |rank=b |P1950 |qid=Q815 |fwd=ALL |osd=n |noicon=y |linked=n |prefix="[""[:Category:" |postfix=" (surname){{!}}{{wdib|rank=b|P735|qid=Q815|fwd=ALL|osd=n|noicon=y|linked=n}}]]" |lang=en}} → Gabriel
You'll have to jiggle with it to get what you want because I'm not sure just what is required. Just remember that you have to encode a pipe character "|" as {{!}} to pass it in a parameter. --RexxS (talk) 23:38, 25 September 2018 (UTC)
@RexxS: Wow, that's impressive! @JuTa: please give the latest version of the sandbox a spin, see how that looks. Thanks. Mike Peel (talk) 23:56, 25 September 2018 (UTC)

@Mike Peel: You may be as sick as I am with typing all those parameters in, so I've implemented "parameter sets" to store your favourite set of parameters. Parameter set 1 makes: rank="best"; fetchwikidata="ALL"; onlysourced="no"; noicon="true". Just use |ps=1

  • {{wdib |ps=1 |P734 |qid=Q815 |linked=n |prefix="[""[:Category:" |postfix=" (surname){{!}}{{wdib|ps=1|P735|qid=Q815|linked=n}}]]" |lang=en}} → Gabriel
  • {{wdib |ps=1 |P1950 |qid=Q815 |linked=n |prefix="[""[:Category:" |postfix=" (surname){{!}}{{wdib|ps=1|P735|qid=Q815|linked=n}}]]" |lang=en}} → Gabriel

Tell me if you like the idea. --RexxS (talk) 00:25, 26 September 2018 (UTC)

@RexxS: I'm ... hesitant, sorry. I like the compactness, but I'm worried that this makes it more difficult for others to make sense of what the module call is doing. I'm hoping that others will be maintaining this infobox in a year or so's time, and I'd like to keep it clear what call is doing what, as much as possible. Thanks. Mike Peel (talk) 00:38, 26 September 2018 (UTC)
Sure, Mike, you only need use features you're comfortable with, and I understand your thinking. However, on Commons  – unlike on enwp  – we're rarely concerned with opt-in/opt-out or with sourcing (which is often "sky is blue"), so the commonest setting for several parameters is going to be different. I want others to be able to use/maintain the modules as well, but my view is that they would be better concentrating on the important ones and not be distracted by irrelevant |rank=best |fwd=ALL |osd=no |noicon=yes in every call. But I won't worry over it. --RexxS (talk) 09:37, 26 September 2018 (UTC)
@Mike Peel, Category:Alfredo Pérez Rubalcaba look fine now using the sandbox. Thx a lot. --JuTa 06:54, 26 September 2018 (UTC)
I did another test with Category:Maria Cristina of Naples and Sicily which looks fine too. --JuTa 07:09, 26 September 2018 (UTC)
@Mike Peel, 2 other things I noticed when Im using the sandbox:
  1. People get sorted into Category:Uses of Wikidata Infobox with no family name thou they have a surname on WD.
  2. Sur- anf given name cats are getting set thou they are not existing yet. Which ich fine for me, but other people may complain about that.
Please have another look. Thx. --JuTa 23:37, 26 September 2018 (UTC)
@JuTa: The first should be fixed [9] - the code was also adding it where a second spanish name wasn't present. The second is more complicated - with the new code, I removed the ifexist checks. @RexxS: can you think of a good way to add them back - maybe the check could somehow be nested in the prefix parameter, or is that going to be too many layers of WikidataIB? Thanks. Mike Peel (talk) 22:05, 27 September 2018 (UTC)
@Mike Peel: Without an example, it's difficult for me to phrase solutions. However, it seems that you're asking to not add a category to a page if the category page doesn't yet exist, is that right? The checks can be expensive and may end up with spurious "What links here", so I tend to avoid them. If we actually get a complaint, is there any reason why we don't just create the relevant category page? --RexxS (talk) 22:34, 27 September 2018 (UTC)
As I said: I'm happy with that. As long we dont get complaints we can keep is as it is from my point of view. --JuTa 23:07, 27 September 2018 (UTC)
PS: please gimme a ping when you activate the new sandbox. I like to clean up my uses of it. thx. --JuTa 23:09, 27 September 2018 (UTC)
@RexxS: Any of the categories in Category:Uses of Wikidata Infobox missing surname category will probably have the problem - random example, Category:Hamid Amjad. There aren't as many as I expected of those now, though, so maybe it's not a bit issue. I guess adding the tracking category has the same computationally costly as identifying whether to show the category link or not... Thanks. Mike Peel (talk) 23:58, 27 September 2018 (UTC)
@JuTa and Laddo: This is now live. Note that Category:Uses of Wikidata Infobox missing surname category will be deprecated, but the redlinks will show so you can check Special:WantedCategories instead. Thanks. Mike Peel (talk) 21:54, 29 September 2018 (UTC)
Thx, I now removed the sandbox from any peoples cats. --JuTa 00:32, 30 September 2018 (UTC)

Another question: Is there a possibility not to use some WD name statements like on Category:Gustaf Wilhelm af Tibell and D:Q4457034 (family name "af Tibell"? I dont like to start (or continue) an edit war on WD. In this case the other surname is an alternative not a second surname. --JuTa 18:25, 30 September 2018 (UTC)

@JuTa: Set one to 'preferred rank' on Wikidata, and the other one shouldn't be used by the template. Thanks. Mike Peel (talk) 18:32, 30 September 2018 (UTC)
@Mike Peel, thx, but how? When I try to add a qualifier 'preferred rank' or 'rank' it tells me No match was found. --JuTa 18:39, 30 September 2018 (UTC)
@JuTa: See d:Help:Ranking - you use one of the buttons on the left of the value to change this setting. Thanks. Mike Peel (talk) 18:42, 30 September 2018 (UTC)
Ahh, I see. Thats working, thx. We never stop learning :) --JuTa 18:48, 30 September 2018 (UTC)
Moin Moin JuTa, is this part done? Could you then please set {{Section resolved|1=~~~~}} to this part? Thanks --Crazy1880 (talk) 13:10, 28 April 2019 (UTC)
Hi, anybody hanging around who is willing to look into this? It seems strange to find a Peter Candid in the Category:De Witte (surname) without any (direct) reference to the aliases. Thank you for your time. Lotje (talk) 13:20, 28 April 2019 (UTC)
Doesnt it get archived automiactly? But anyhow: :This section was archived on a request by: JuTa 17:19, 28 April 2019 (UTC) --JuTa 17:19, 28 April 2019 (UTC)

procedure - category for awards etc

Latest comment: 5 years ago10 comments3 people in discussion

Moin Moin together, what I need is a doku how categories are automatically set by the infobox, if the object has the corresponding property. In the view from Wikidata. Example: Bishop of Bradwell (Q4917784) as article and Category:Bishops of Bradwell (Q8301689) for the category. The value for the person is set with property position held (P39). So how does it work and where can you read it? Thanks --Crazy1880 (talk) 19:29, 28 January 2019 (UTC)

@Crazy1880: That one's complicated. The award categories work by the sitelinked Wikidata item having a award received (P166) value that points towards an award item that has category for recipients of this award (P2517) set to a Wikimedia category item - then that category can be added automatically. Something similar could be done for position held (P39), but that needs an equivalent property to category for recipients of this award (P2517) creating on Wikidata. Thanks. Mike Peel (talk) 23:17, 28 January 2019 (UTC)
Moin Moin @Mike Peel: , couldn't we do something with topic's main category (P910) there for? So in the end looking for position held (P39) and the objects having topic's main category (P910) to automatically build the category?
Example:
John Wraw (Q3182787) with P39 = Bishop of Bradwell (Q4917784)
Bishop of Bradwell (Q4917784) with P910 = Category:Bishops of Bradwell (Q8301689)
This would have the advantage of allowing us to create categories across different subject areas, wouldn't it?
Thanks for checking --Crazy1880 (talk) 18:34, 12 February 2019 (UTC)
@Crazy1880: We have a function in Module:WikidataIB that does that job:
  • {{#invoke:WikidataIB |getPropOfProp |prop1=P39 |prop2=P910 |fwd=ALL |osd=n |noicon=y |linked=n |qid=Q3182787}} → Category:Bishops of Bradwell
You'll have to check with Mike Peel for how he might implement it. --RexxS (talk) 00:33, 13 February 2019 (UTC)
Moin Moin @RexxS: , looks great. But because it is in categories, we should check it twice and three times to see whether it works the way we want it to. Examples:
  1. Angela Merkel (Q567) with P39 = Q56022 → Q56022 with P910 = Q20653561 (  Not OK, Category:Federal Chancellors of Germany, Category:Members of the Bundestag, Category:Members of the Bundestag, Category:Members of the Bundestag, Category:Members of the Bundestag, Category:Members of the Bundestag, Category:Members of the Bundestag, Category:Government ministers of Germany, Category:Government ministers of Germany, Category:Members of the Bundestag, Category:Secretaries General of the CDU, Category:Members of the Bundestag, Category:Leaders of the CDU, Category:Chairpersons of the CDU, Q17276997)
  2. Donald Trump (Q22686) with P39 = Q11696 → Q11696 with P910 = Q7130129 (  OK, Category:Presidents of the United States, Category:Chairpersons of organizations, Q9137316)
Do we have more examples where we can test that? Regards --Crazy1880 (talk) 17:39, 13 February 2019 (UTC)
addendum: @RexxS: Can I set it so that duplicate entries are shown only once? Angela Merkel (Q567) with P39 = Q1939555 with eight times and P39 = Q248352 two times? --Crazy1880 (talk) 17:59, 13 February 2019 (UTC)
More examples:
  • Steven Jobs (Q19837) (Double categories   Not OK, Category:Chief executive officers, Category:Chief executive officers, Category:Chief executive officers, Category:Chief executive officers)
  • Julius Caesar (Q1048) (  OK, Category:Ancient Roman dictators, Category:Roman quaestors, Category:Ancient Roman senators, Category:Roman consuls, Category:Roman consuls, Category:Roman consuls, Category:Roman consuls, Category:Roman consuls, Category:Pontifexes, Category:Pontifices maximi of the Roman Republic, Category:Ancient Roman governors, Category:Ancient Roman governors, Category:Roman praetors)
  • Adolf Hitler (Q352) (  OK, Category:Reichskanzler, Category:Presidents of Germany 1919–1945, Category:Members of the Reichstag of the Weimar Republic, Category:Members of the Reichstag of Nazi Germany)
  • Pedro Sánchez (Q6070218) (Double categories   Not OK, Category:Madrid city councillors, Category:Members of the Congress of Deputies (Spain), Category:Members of the Congress of Deputies (Spain), Category:Prime Ministers of Spain, Category:Members of the Congress of Deputies (Spain), Category:Members of the Congress of Deputies (Spain), Category:Members of the Congress of Deputies (Spain), Category:Members of the Congress of Deputies (Spain), Category:Members of the Congress of Deputies (Spain))
  • Benedikt XVI. (Q2494) (Double categories   Not OK, Category:Popes, Category:Deans of the College of Cardinals, Category:Cardinal-priests, Category:Roman Catholic archbishops of Munich and Freising, Category:Cardinals (Catholic Church))
  • Pehr Evind Svinhufvud (Q209439) (Double categories   Not OK, Category:Members of the Parliament of Finland, Category:Presidents of Finland, Category:Prime Ministers of Finland, Category:Members of the Parliament of Finland, Category:Members of the Parliament of Finland, Category:Speakers of the Parliament of Finland, Category:Prime Ministers of Finland)
  • Hugo Chávez (Q8440) (  OK, Category:Presidents of Venezuela, Category:Leaders of political parties)
  • Pierre-Simon Laplace (Q44481) (  OK, Category:Members of the Chamber of Peers of the Bourbon Restoration, Category:Members of the Sénat conservateur, Category:French interior ministers, Category:Presidents, Category:Presidents, Category:Presidents)
I think, if you get rid of the double entries of the categories, then we have already won a lot. --Crazy1880 (talk) 19:24, 13 February 2019 (UTC)
@Crazy1880: It doesn't matter how many times we check it, Angela Merkel (Q567) has multiple values for position held (P39). Two of those, Federal Chancellor of Germany (Q4970706) and member of the German Bundestag (Q1939555), are preferred values and each of those has one topic's main category (P910), so we could select them like this:
  • {{#invoke:WikidataIB |getPropOfProp |prop1=P39 |prop2=P910 |rank=best |fwd=ALL |osd=n |noicon=y |linked=n |qid=Q567}} → Category:Federal Chancellors of Germany, Category:Members of the Bundestag, Category:Members of the Bundestag, Category:Members of the Bundestag, Category:Members of the Bundestag, Category:Members of the Bundestag, Category:Members of the Bundestag, Category:Government ministers of Germany, Category:Government ministers of Germany, Category:Members of the Bundestag, Category:Secretaries General of the CDU, Category:Members of the Bundestag, Category:Leaders of the CDU, Category:Chairpersons of the CDU, Q17276997
However, I think we would normally want all values, so the version you used should be the one you want.
{{#invoke:WikidataIB |getPropOfProp |prop1=P39 |prop2=P910 |fwd=ALL |osd=n |noicon=y |linked=n |prefix="["[: |postfix="]"] |sep=" " |qid=Q567}} → Category:Federal Chancellors of Germany Category:Members of the Bundestag Category:Members of the Bundestag Category:Members of the Bundestag Category:Members of the Bundestag Category:Members of the Bundestag Category:Members of the Bundestag Category:Government ministers of Germany Category:Government ministers of Germany Category:Members of the Bundestag Category:Secretaries General of the CDU Category:Members of the Bundestag Category:Leaders of the CDU Category:Chairpersons of the CDU Q17276997
Now when we actually use it to put a page into categories, it doesn't matter how many times we put it into the same category, so the duplicates are irrelevant. You can check that by changing the prefix parameter to |prefix="["[ and previewing – you'll find that this page is in just 5 categories, not 13.
When a property has multiple values, there's no way to programmatically filter the ones we might want by arbitrary criteria. You need a database query language to do that, and there's no implementation of one currently available to run inside Wiki-pages. --RexxS (talk) 20:21, 13 February 2019 (UTC)

→ Not mature yet. --Crazy1880 (talk) 12:57, 28 April 2019 (UTC)

This section was archived on a request by: Crazy1880 (talk) 12:57, 28 April 2019 (UTC)

Issue collapsing award list

Latest comment: 5 years ago4 comments2 people in discussion

For some reason WI only shows a single award in field "Award received" for Category:Elizabeth II of the United Kingdom, while obviously dozens of automatic award categorization do take place successfully. I would have expected the infobox to indicate a collapsed list of awards ("[show]") like in Category:Barack Obama, for example. Laddo (talk) 22:15, 2 May 2019 (UTC)

@Laddo: That looks like a data problem. In Elizabeth II (Q9682), award received (P166)=Order of the Garter (Q215248) has a preferred rank, and none of the other awards have the same rank, so only that one is shown. The best solution is probably to change it to a normal rank on Wikidata, and then all of the normal rank ones will appear in the infobox. Thanks. Mike Peel (talk) 04:03, 3 May 2019 (UTC)
Woah, good guess! Indeed I fixed the issue as you suggested. Thanks! Laddo (talk) 10:39, 3 May 2019 (UTC)
This section was archived on a request by: Laddo (talk) 10:39, 3 May 2019 (UTC)

Some properties for books

Latest comment: 5 years ago24 comments4 people in discussion

Would it be possible to add some of the following:

And, in the external identifiers

Thanks. Jheald (talk) 23:02, 24 April 2019 (UTC)

Jheald my Module:Artwork now supports {{Artwork}}, {{Art photo}} and {{Photograph}}. I am planning to start working an replacing {{Book}} with lua code likely based on Module:Artwork. --Jarekt (talk) 02:37, 26 April 2019 (UTC)
Thanks @Jarekt: . I haven't been using {{Book}}, and it would take up so much space across the top of a category before one got to the images, so that's why (working on these categories: Category:Books with images from the British Library Mechanical Curator collection, but with a lot more to add or create) I was tending towards just the standard Wikidata Infobox template; also then I just need to sort out the information on Wikidata, without having to duplicate it on Commons. But perhaps these uses could later be switched to {{Book}}, once you have it up and running.
One other thing I was wondering (unrelated), do you have automation of {{Map}} on your to-do list any time soon? I've got large numbers of map scans that I'm going to be uploading soon, together with making Wikidata items for them, and it would be nice to reduce the amount of duplication. Compare maps in eg Category:BL Maps K.Top.124 (South America) vs tracking page for Wikidata items for this set at d:User:Jheald/BL18C/tracking; also wider tracking pages for Wikidata items for maps at d:Wikidata:WikiProject Maps/stats. Thanks, Jheald (talk) 07:22, 26 April 2019 (UTC)
Jheald, my comment above is only tangentially related to you request of adding fields to Wikidata Infobox. I am sorry to hijack the discussion, since {{Wikidata Infobox}} is used in category namespace and perhaps should be replacing instances where {{Book}} is uses there. However about the {{Map}} infobox: it has not been used much, as it has now ~40k transclusions, so it was not high on my to-do list. I did not think much about it since I created the original {{Map}} infobox. --Jarekt (talk) 13:30, 26 April 2019 (UTC)
@Jarekt: Thanks for creating the {{Map}} infobox! I have about 10,000 potential usages, that will be backed by Wikidata items, that I hope to be adding over the course of the year, plus up to 50,000 (8000 ready to go in the short term) that won't have Wikidata items; there are also at least two other big map upload projects out there, that may be taking the Wikidata-backed route (one from Harvard map library, another that is one of the SDC GLAM pilots). But maybe still not as many transclusions, even then, as things higher up your to-do list. Jheald (talk) 13:41, 26 April 2019 (UTC)
@Jarekt: Why so many different templates? Once Lua access to the depicts statement is available, I'm hoping that we can move towards having a single information template for file pages in the same way as this template works for all categories. Thanks. Mike Peel (talk) 18:18, 2 May 2019 (UTC)
Mike, so far I am mostly working with legacy templates, created long time ago, often by me, by merging dozens of earlier templates. However I agree with your desire for a single infobox template and it just happen that all the infobox templates I am rewriting in Lua are handled by Module:Artwork and {{{{Artwork}}, {{Photograph}}, {{Art photo}} and soon {{Book}} are more like different skins to the same underlying code. There some differences between them, like date in context of {{Book}} is publication date, but in context of artwork, it is creation date. I might create in a future some generic Infobox template that does not try to be backwards compatible which will be meant to be used for future uploads. --Jarekt (talk) 02:57, 3 May 2019 (UTC)
@Mike Peel: Hi Mike! Any chance of these? Sorry if they're already on your radar. Jheald (talk) 22:26, 30 April 2019 (UTC)
@Jheald: Sorry for the delay. Please give {{Wikidata Infobox/sandbox}} a spin and see how that looks. Thanks. Mike Peel (talk) 18:17, 2 May 2019 (UTC)
Quote: "F*** me that's nice" -- User:Andrew Gray, sitting next to me.
It looks great. One wrinkle: typically the items I'm putting up have two values for British Library system number (P5199) -- one for printed copies of the edition, a different one for the scan. A qualifier indicates which. It might be nice to have both; but failing that, the printed one will normally be the first one in Wikidata and the numerically lower one (so the one you're probably showing by default). Not a big deal if it's not easy -- both have very similar information; but nice for completeness if easy, and to let people order up the copy they want.
But really just fantastic, thank you so much. Jheald (talk) 21:04, 2 May 2019 (UTC)
@Jheald: At the moment the code that provides the authority control links only supports one link for each ID, which is either the first one or the preferred rank one. I might try to figure out how to support multiple ID values at some point, but it's not trivial. If everything else looks OK then I'll update the main infobox code over the weekend. Thanks. Mike Peel (talk) 04:06, 3 May 2019 (UTC)
@Mike Peel: Taking another look at this on eg Category:The County Seats of the Noblemen and Gentlemen of Great Britain and Ireland by Francis Orpen Morris before it goes final, one further mini-request might be to now move "Publisher" to below "Place of Publication" (and also, therefore, after "Author"); but no big deal if it would mean anything substantial. Jheald (talk) 17:47, 3 May 2019 (UTC)
  Comment I might add displaying full full work available at URL (P953) link is a bit awkward. An approach similar to the one already applied with official website (P856) would be nice, IMHO. Strakhov (talk) 17:55, 3 May 2019 (UTC)
@Jheald: I've changed the ordering to author -> publisher -> city, is that OK? That's the order that I'm used to seeing with book publication info in dead tree technology. @Strakhov: That sounds like a sensible improvement, but can you point me towards a test case for this please, so that I can make sure that the change looks OK? Thanks. Mike Peel (talk) 19:01, 3 May 2019 (UTC)
@Mike Peel: Dead tree, I'm slightly more used to seeing London : Smith, Jones & Sons, at least in references, but Strakhov's example below looks really nice, & it makes sense for all the different sorts of responsibility data to be kept together, so I am happy. Jheald (talk) 19:24, 3 May 2019 (UTC)
@Mike Peel: [10]. Thanks! Strakhov (talk) 19:11, 3 May 2019 (UTC)
@Strakhov: Ah. With an official URL, there's only one of them. In this case, though, there could be multiple URLs for the same thing, and ideally it would be available on Wikisource. I'm not sure how to code that... Thanks. Mike Peel (talk) 19:22, 3 May 2019 (UTC)
@Mike Peel: Indeed. [11] for an example with a different URL for each of 5 volumes. Jheald (talk) 19:26, 3 May 2019 (UTC)
@Jheald and Strakhov: I've shortened them so they appear as [12] - how does that look? If that's not OK, then it's probably going to be best to remove this line. Thanks. Mike Peel (talk) 09:00, 4 May 2019 (UTC)
Works well enough for me. Please don't remove them -- it's incredibly valuable to be able to be able to give people links to the full book. Jheald (talk) 12:47, 4 May 2019 (UTC)
Ok enough for me too. By the way, main subject (P921) may be useful for books too. Strakhov (talk) 16:06, 4 May 2019 (UTC)
OK, let's go with that then. main subject (P921) is already included. Thanks. Mike Peel (talk) 16:11, 4 May 2019 (UTC)

@Jheald, Strakhov, and Andrew Gray: This is now live. Thanks. Mike Peel (talk) 17:39, 4 May 2019 (UTC)

This section was archived on a request by: Mike Peel (talk) 17:39, 4 May 2019 (UTC)

Award categorization ignores "autocat=no" parameter

Latest comment: 5 years ago5 comments2 people in discussion

Hi, I just figured that setting |autocat=no prevents generic categorization (birth, people...) but not that of awards... It may become an issue (see here). Could you please add {{#ifeq:{{{autocat | yes}}} | yes | ... }} around 

award auto-cat -->{{#ifeq:{{NAMESPACENUMBER}} | 14 | {{
 #invoke:WikidataIB |getAwardCat |fwd={{{fetchwikidata|ALL}}} |osd={{{onlysourced|no}}} |noicon=y 
 |qid={{#invoke:WikidataIB |getQid |qid={{{qid|}}} }} |sortkey={{#ifeq:{{{defaultsort | y}}} | y | {{{sortkey|}}}}} }}}}

I guess inception auto-cat may require the same handling. Cheers - Laddo (talk) 23:39, 26 April 2019 (UTC)

@Laddo: Thanks for catching that. It should now be fixed in the sandbox, can you give it a go? Thanks. Mike Peel (talk) 18:08, 2 May 2019 (UTC)
@Mike Peel: Works great! Thanks - Laddo (talk) 22:06, 2 May 2019 (UTC)
@Laddo: This is now live. Thanks. Mike Peel (talk) 17:38, 4 May 2019 (UTC)
This section was archived on a request by: Mike Peel (talk) 17:38, 4 May 2019 (UTC)

WoRMS source ID (P6678)

Latest comment: 5 years ago4 comments2 people in discussion

Hello, I added it in the sandbox, but this don't work, it can be tested there. An idea?

Regards, Christian Ferrer (talk) 10:58, 1 May 2019 (UTC)

@Christian Ferrer: {{Wikidata ID}} supports 200 IDs as currently coded, and we went above that number now. Rather than adding more parameters to that template, I've split the list of IDs into two in the infobox call, so it should work OK now in the sandbox. Thanks. Mike Peel (talk) 17:52, 2 May 2019 (UTC)
@Mike Peel: great, thanks you. I moved that change and the property to the infobox. Regards, Christian Ferrer (talk) 18:54, 2 May 2019 (UTC)
This section was archived on a request by: Mike Peel (talk) 17:37, 4 May 2019 (UTC)

Adjust image size for unconventional aspect ratios?

Latest comment: 5 years ago5 comments2 people in discussion
 

Super 16 (Q2713357) uses File:Super 16 mm film.jpg as image (P18). The image is very tall and narrow. Using the infobox Template at Category:Super 16 film results in the image being blown up to the usual width (and past the image's own native width), which results in a ridiculously large image. Is there a way to fix this? --El Grafo (talk) 08:25, 3 May 2019 (UTC)

@El Grafo: I've tweaked the code in {{Wikidata Infobox/sandbox}}, how does that look? (It's live in your example). Thanks. Mike Peel (talk) 09:09, 4 May 2019 (UTC)
@Mike Peel: Not sure if 200px will be good for every potentially problematic image, but for my example it seems to look fine! --El Grafo (talk) 17:25, 4 May 2019 (UTC)
@El Grafo: OK, this is now live, let's see how that goes. Thanks. Mike Peel (talk) 17:36, 4 May 2019 (UTC)
This section was archived on a request by: Mike Peel (talk) 17:36, 4 May 2019 (UTC)

Softwarefehler?

Latest comment: 4 years ago4 comments3 people in discussion

Hallo, Bei Mario Kunasek gibt es beim Feld Bild zwei Bilder. Erstes ist ohne "Beschreibung Medium" und Zweites mit "Beschreibung Medium":[[13]. Bei der Databox auf Commons wird 1. Bild angezeigt, jedoch mit der Beschreibung vom 2. Bild: [14]. -- Bwag (talk) 17:53, 27 January 2019 (UTC)

@Bwag: That's a known bug, sorry. The temporary solution is to remove one of the images from the Wikidata entry, or to add a caption for the first one as well. The full solution will hopefully be to switch to using the Structured Data on Commons captions when they are accessible through Lua, hopefully later this year. Thanks. Mike Peel (talk) 23:24, 28 January 2019 (UTC)
Thx! Bwag (talk) 09:20, 29 January 2019 (UTC)
This section was archived on a request by: Crazy1880 (talk) 18:44, 19 May 2019 (UTC)

Authority control

Latest comment: 4 years ago4 comments3 people in discussion

Hello, in Category:Media from Arango et al. 2019 - 10.3897/zookeys.835.27528 the authority controls DOI (P356) and WoRMS source ID (P6678) seems to be displayed on the same line, and not one above the other. Christian Ferrer (talk) 07:54, 5 May 2019 (UTC)

@Christian Ferrer: fixed. Thanks. Mike Peel (talk) 11:52, 5 May 2019 (UTC)
Great, thanks you! Christian Ferrer (talk) 11:54, 5 May 2019 (UTC)
This section was archived on a request by: Crazy1880 (talk) 18:42, 19 May 2019 (UTC)

Female forms for P106

Latest comment: 4 years ago10 comments4 people in discussion

I'd like to suggest, to put it as briefly as possible, that if P31 is Q5 and P21 is Q6581072 (in other words, in cases of human women), then P106 displayed in the infobox should try to use female forms for all its values, if available. Those forms can be found as P2521 in the WD elements for each job. For example, in the infobox I've just put in Category:Hanka Bielicka all names of Ms Bielicka's professions are displayed in male forms (at least in Polish), which looks quite bad and artificial to me as native speaker. Powerek38 (talk) 23:11, 19 March 2018 (UTC)

@Powerek38: Sorry for not replying quicker, I only just noticed this. I think this needs a modification to Module:WikidataIB. @RexxS: Could you have a look at this, please? Something analogous to 'getShortValue' that uses the value from P2521 might work, as I can then use an if statement to detect when that's what we want, or a parameter for 'female=yes' or similar might also work. Thanks. Mike Peel (talk) 11:16, 25 March 2018 (UTC)
@Mike Peel: That would mean that every time a Wikidata-entity was returned for any property, the code would have to check whether it had a P2521 property (i.e. the entity's label has a female form) in the currently selected language. That requires an expensive arbitrary access for each value of each property in every case. I'm sorry, but that would make the code unusable in my opinion. Perhaps somebody else can figure out how to write code that gets round the problem that Wikidata creates in retrieving female forms of labels by the way it presently stores them; otherwise it needs to change to actor and actress being two different entities, so we can use the associated labels without expensive calls. --RexxS (talk) 12:40, 25 March 2018 (UTC)
@RexxS: Yes, I'd agree that would make the code unusable if applied by default. :-( Is it possible to have it as an option, so it's only triggered for cases where it's needed? I can write some if statements here that would minimise the times it's called to just the cases where it's needed. Thanks. Mike Peel (talk) 11:10, 26 March 2018 (UTC)
@Mike Peel: That would require a significant re-write of the code, and even then I worry about the overhead. Remember the code is generic for every property that is fetched from every page. For example, let's say your infobox script only called the new code for the occupation field. It still means that every page where there is 'occupation' has to have an extra expensive call for each value of the occupation property - and there are often quite a few of them. Then what about when somebody finds other fields where the label has a female form?
Where does this stop? In the Polish Wikipedia, how are they going to fill in the occupation field on the infobox for pl:Hanka Bielicka from Wikidata? If I look at the Wikidata entry for Hanka Bielicka in Polish, I see her occupations are: aktor, piosenkarz, artysta kabaretowy and aktor filmowy - grammatically incorrect. The problem is created by Wikidata not understanding that aktor and aktorka are different things, and need to be separate entities if retrieval of those labels as values in other entities is to be grammatically correct. A good database will store its contents in a way that doesn't put the onus on every single application that uses it to create its own complex code for what should be simple operations, like retrieving Hanka Bielicka's occupations. --RexxS (talk) 17:16, 26 March 2018 (UTC)
OK, I've now raised this for discussion on the Wikidata Project chat. Thanks. Mike Peel (talk) 21:17, 26 March 2018 (UTC)
And I've raised that at the technical table at Polish Wikipedia's bar (here), because our language seems to be among those quite seriously affected by this issue. You can try to read it using a translator, but to summarise it very briefly: most of my collegues seem to think that this should be solved by WMF / WMDE as Wikidata developers and that is technically feasible, if they really want to do it. Another point that was made (and I share this concern) is that an infobox relying so heavily on Wikidata labels and descriptions is quite risky, because of poor anti-vandal patrolling of WD. I mean, I love this box and as you can see I've been spending quite a lot of time lately putting it into various "Polish" categories, but I do hope they come up with some better quality control solutions at WD. Powerek38 (talk) 19:53, 29 March 2018 (UTC)
Thanks for raising it there. It would be useful if you could mention that at the Wikidata project chat discussion as well, please. On the labels/descriptions: those are what enable the multilingual benefits, and it's not feasible to start caching every label in every language. Hopefully anti-vandal patrolling will improve on Wikidata directly, but I also hope that making more use of the labels improves the rate at which vandalism (and data inaccuracy) is fixed. Thanks. Mike Peel (talk) 20:33, 29 March 2018 (UTC)
Yes, I did link both discussions (this one here and the one at WD) and I offered my services as translator if someone would like to have some input into this conversation but prefers to write in Polish. Powerek38 (talk) 20:53, 29 March 2018 (UTC)
This section was archived on a request by: Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 13:51, 7 June 2019 (UTC)

Wrong capital letters

Latest comment: 4 years ago14 comments5 people in discussion

When using the infobox, all items start with capital letters, even when not being named like that. It would be helpful to disable that function, so descriptions and names starting with small letters will also be shown as they should be shown. Thanks! --j.budissin+/- 16:42, 3 April 2018 (UTC)

@J budissin: Can you point out a problem case in action, please? Wikidata systematically uses lower case letters at the start, so mostly we need to convert them to upper case, but if there are places where that shouldn't be happening then I can see if we can avoid that in those cases. Thanks. Mike Peel (talk) 17:06, 3 April 2018 (UTC)
@Mike Peel: When I use Commons with Polish interface, then all descriptions (as understood in WD terms) in the box start with capital letter, even if they start with lower case in WD. That's generally wrong, because usually the descriptions are not sentences in grammatical sense. Powerek38 (talk) 17:25, 3 April 2018 (UTC)
It's simple enough to remove the upper letter from the start of the descriptions unless it's present on Wikidata. @Jarekt: You suggested using ucfirst above, any comments on this? Thanks. Mike Peel (talk) 17:43, 3 April 2018 (UTC)
The names of the fields (in the blue boxes, like "Instance of" or "Location") should be capitalized as we do with any infobox, see {{Information}}. The values of each field, if fetched from Wikidata, I would not change, so it might be capitalized in German and lower case in Polish. --Jarekt (talk) 19:19, 3 April 2018 (UTC)
OK, I've removed ucfirst from the content, it's just used for the labels now. Let me know if there are still problems. Thanks. Mike Peel (talk) 21:49, 3 April 2018 (UTC)
@Mike Peel: It's correct, what Powerek38 says, and that's the case not just for Polish, but also for Sorbian, Czech and other Slavic languages. As an example, see Category:Jurij Brězan in Upper Sorbian (hsb). There you have the labels "Date of birth" (datum narodźenja), "Date of death" (datum zemrěća) and so on starting with capital letters, which is wrong according to Sorbian orthography. Regards, j.budissin+/- 07:21, 4 April 2018 (UTC)
@Jarekt: should be capitalized as we do with any infobox – No, they shouldn't for example in Sorbian and that's also not as we do with infoboxes. --j.budissin+/- 07:22, 4 April 2018 (UTC)
j.budissin, I will be first to admit that I do not know nothing about Upper Sorbian (hsb) orthography, but if you view Template:Information using that language all the names of the fields are capitalized ("Žórło", "Druhe wersije tuteje dataje"). That template is sort of a golden standard for us as it is used on so many millions of pages and viewed in so many languages. {{Creator|Wikidata=Q77196|lang=hsb}} gives
Jurij Brězan  (1916–2006)  
 
 
alternatiwne mjena
Pseudonym: Dušan Šwik
wopisanje němski žurnalist, přełožowar, spisowaćel, basnik a dramatikar
datum narodźenja/smjerće 9. junija 1916   12. měrca 2006  
Městno narodźenja/smjerće Worklecy Kamjenc
Normowe daty
creator QS:P170,Q77196
which also have "Datum narodźenja/smjerće" starting with the capital letter. The capitalization come from https://translatewiki.net/wiki/Special:Translations/MediaWiki:wm-license-creator-date-of-birth Where a native speaker have chosen that capitalization. --Jarekt (talk) 12:32, 4 April 2018 (UTC)
Thanks, I corrected that. The problem while translating those things is, that you don't always know where the word is going to be used, so such things may happen. Which doesn't automatically mean that it's right. --j.budissin+/- 13:38, 4 April 2018 (UTC)
j.budissin, If you want to correct more of them at Template:Information or other infoboxes use this trick to see where the messages are stored. --Jarekt (talk) 15:48, 4 April 2018 (UTC)
Note that this template uses Wikidata labels, and doesn't rely on translatewiki at all. So changing them there won't change them here. I'm leaning towards pulling ucfirst from the rest of the template, any comments? Thanks. Mike Peel (talk) 15:52, 4 April 2018 (UTC)
I would be fine with that. Jarekt just mentioned the templates above as a "role-model" for how to capitalize or not labels here, I guess. --j.budissin+/- 18:06, 4 April 2018 (UTC)
This section was archived on a request by: Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 13:51, 7 June 2019 (UTC)

Displaying of "owned by"

Latest comment: 4 years ago5 comments4 people in discussion

I'm not sure how this could be fixed but the displaying of the "owned by" property qualifiers should probably be improved. As you can see at Category:Kronprinzenvilla the end time is shown first, then the start time. I would suggest the opposite order and to replace the comma by an en dash (–). Thanks--Leit (talk) 12:37, 29 May 2018 (UTC)

@Leit: Try {{Wikidata Infobox/sandbox}} - does that look better? The downside is that it won't show any qualifiers for that field that aren't the start/end dates, do you think that will be an issue? Thanks. Mike Peel (talk) 13:02, 29 May 2018 (UTC)
That looks fine, I don't think other qualifiers than start/end time would be useful.--Leit (talk) 13:36, 29 May 2018 (UTC)

@Mike Peel: displaying proportion qualifiers would be nice, e.g. from items like d:Q2328468. --Te750iv (talk) 15:06, 31 May 2018 (UTC)

This section was archived on a request by: Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 13:51, 7 June 2019 (UTC)

Population

Latest comment: 4 years ago13 comments5 people in discussion

Thanks for adding population (P1082). But I am not sure about "qual=ALL" setting, as in my opinion, not all qualifiers are suitable to display (and undoubtedly they look odd without any explanation, see Category:Prague for example). I think that point in time (P585) is the most important, not sure about determination method (P459) and criterion used (P1013), but female population (P1539) and male population (P1540) seems to be too much detailed to me.

Another population (P1082) related remark is the format of values. For higher numbers, a plain format is not easy to ready, some digit group separator may be useful. As it varies among countries, it is not easy to select one, I prefer spaces per ISO 31-0. This may apply to{ {P|2046}} as well.--Jklamo (talk) 09:35, 31 May 2018 (UTC)

@Jklamo: I've tweaked the sandbox to just display the point in time (P585) qualifiers here, how does that look? Formatting is a tricky question as that needs to be internationalised - so displaying in English might be 1,234.56, but Portuguese 1.234,56 - and then there's the space option, and more. Not sure if @RexxS: wants to look at this, but it might be better to leave this for the future to handle alongside other issues (unit conversions for example). Thanks. Mike Peel (talk) 13:09, 31 May 2018 (UTC)
@Mike Peel and Jklamo: Actually, formatting numbers is already done in the MediaWiki software, so it's fairly simple to use that. I've made a demo/utility function in Module:WikidataIB/sandbox.
  • {{#invoke:WikidataIB/sandbox |formatNumber |1294513 }} → 1,294,513
  • {{#invoke:WikidataIB/sandbox |formatNumber |1294513 |lang=}} → 1,294,513
  • {{#invoke:WikidataIB/sandbox |formatNumber |1294513 |lang=en} → 1,294,513
  • {{#invoke:WikidataIB/sandbox |formatNumber |1294513 |lang=en-gb}} → 1,294,513
  • {{#invoke:WikidataIB/sandbox |formatNumber |1294513 |lang=xyx}} → 1,294,513
  • {{#invoke:WikidataIB/sandbox |formatNumber |1294513 |lang=cs}} → 1 294 513
  • {{#invoke:WikidataIB/sandbox |formatNumber |1294513 |lang=de}} → 1.294.513
  • {{#invoke:WikidataIB/sandbox |formatNumber |1294513 |lang=ar}} → ١٬٢٩٤٬٥١٣
  • {{#invoke:WikidataIB/sandbox |formatNumber |1294513 |lang=hi}} → १२,९४,५१३
You could use that to wrap values for now to try it out.
Optionally: population is data-type quantity, so I could just use a form of the formatting code internally to format quantities by default. That may have side-effects? Or I could add yet another parameter to switch on the formatting of quantities on demand? What are your wishes? (and if the last option, please suggest a name for the new parameter!). --RexxS (talk) 14:15, 31 May 2018 (UTC)
@RexxS: It sounds like it might be best to turn it on by default, then, and we can see if any side-effects show up. Thanks. Mike Peel (talk) 14:20, 31 May 2018 (UTC)
@Mike Peel and Jklamo: Done. It will be simple to switch it on or off with a parameter if you can think of a name (maybe |fnum = true/false?). population (P1082) of Prague (Q1085):
  • {{#invoke:WikidataIB/sandbox |getValue |qid=Q1085 |P1082 |rank=b |fwd=ALL |osd=no}} → 1,357,326  
  • {{#invoke:WikidataIB/sandbox |getValue |qid=Q1085 |P1082 |rank=b |fwd=ALL |osd=no |lang=en}} → 1,357,326  
  • {{#invoke:WikidataIB/sandbox |getValue |qid=Q1085 |P1082 |rank=b |fwd=ALL |osd=no |lang=cs}} → 1 357 326  
  • {{#invoke:WikidataIB/sandbox |getValue |qid=Q1085 |P1082 |rank=b |fwd=ALL |osd=no |lang=de}} → 1.357.326  
Let me know if problems arise. --RexxS (talk) 15:07, 31 May 2018 (UTC)
@RexxS: Testing at Category:Prague and changing language (e.g. [15]), the format doesn't seem to change. Can it auto-detect the language, or does the lang= parameter have to be set? Thanks. Mike Peel (talk) 15:37, 31 May 2018 (UTC)
Hi Mike. Reading mw:Extension talk:Scribunto/Lua reference manual #getContentLanguage() brings up the interesting fact that the content language for Commons is not what the user sets (as we thought), but English. So try changing your language for these:
  • {{#invoke:WikidataIB/sandbox |getLang}} → en
  • {{int:Lang}} → en
I've used the 'hack' which calls {{int:lang}} so the getValue formatting should auto-change with user's preference now. Let me know if problems arise. --RexxS (talk) 16:17, 31 May 2018 (UTC)
@RexxS: Interesting. The hack seems to be working nicely, though. Time to move things out of sandbox? Thanks. Mike Peel (talk) 16:21, 31 May 2018 (UTC)
On commons we had for a long time {{Formatnum}} which was at some point implemented in Lua: Module:Formatnum which uses {{int:Lang}} as default language and mostly follows mw.language:formatNum Lua function. The module handles wider range of numbers, precision and some languages Lua does not (unclear if that last functionality is ever used but it was in the original template). That is what my codes use for number formatting. --Jarekt (talk) 16:35, 31 May 2018 (UTC)
That's interesting, Jarekt. You've obviously put a lot of thought into that. Do you think that setting fnum = require("Module:Formatnum") in Module:WikidataIB and then simply using fnum.formatNum(number) in place of langobj:formatNum(number) would be a "drop-in" replacement? If I've read the code correctly, it looks like it would use {{int:Lang}} by default and would retain the precision of the value supplied. --RexxS (talk) 19:08, 31 May 2018 (UTC)
RexxS, the way most modules are written on Commons is that all external functions which can be called from Lua or wikitext take "lang" parameter. Than the Lua function which is called from wikitext check if "lang" is provided and if not than it calls {{int:Lang}}, but from that point on "lang" is passed to all the functions and there is no need to call {{int:Lang}} again. Code require("Module:Formatnum").formatNum(number, lang) should be "drop-in" replacement of mw.getLanguage(lang):formatNum(number). However if the input string is not in scientific notation and you do not specify precision than I think the only difference between two outputs would be support of several very rarely used languages. --Jarekt (talk) 11:40, 1 June 2018 (UTC)
Thanks, Jarekt. The original en:Module:Wikidata had a 'global' table that kept the current language object. It goes against the grain for me to have the global-level processing needed to check whether a parameter has been passed, then get fallbacks if not. So I didn't implement that in WikidataIB which originally didn't need much language processing for enwiki. Now that it's being used on Commons, I've had to expand the language-handling, but I think I'd prefer to wrap up the code into a function to aid portability. I'm also averse to passing a long string of parameters from one function into another, so I'll keep the language object in the local args table. It's no increase in efficiency to avoid expanding a template more than once if it dramatically complicates the rest of the code. I've tried to strike a balance in the current implementation. Cheers --RexxS (talk) 21:00, 1 June 2018 (UTC)
This section was archived on a request by: Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 13:51, 7 June 2019 (UTC)
Retrieved from "https://commons.wikimedia.org/w/index.php?title=Template_talk:Wikidata_Infobox/Archive_2&oldid=626967320"
Return to "Wikidata Infobox/Archive 2" page.