This is an archive of past discussions. Do not edit the contents of this page. If you wish to start a new discussion or revive an old one, please do so on the current talk page.
@Mike Peel: There's a rather intractable problem with languages and monolingual text. Take the example of birth name (P1477) for Bebe Rexha (Q16185856), which is specified in Wikidata as "en". The current implementation looks for the user language if not specified and returns the value that matches the language of the monolingual text. That would allow a birth name to have a transcription into Cyrillic script or Arabic, Hindi, etc. and the user would then see the birth name in their language. The problem then is that when we don't have a birth name version in German or French, we won't get anything.
It would be a lot of complication to implement fallbacks in the code, so maybe it would be better to switch monolingual text to look for the content language (i.e. "en" on Commons), which cuts out the chance of displaying Cyrillic script or Arabic, Hindi, etc. where they exist. Optionally, you could specify |lang=en in the infobox design for certain fields that you expect to only have an English version of something like birth name. I'm not sure what the best line would be. The latter one would improve the compatibility of the module with other language wikis, but requires special considerations for infoboxes on Commons. What do you think? --RexxS (talk) 21:39, 1 June 2018 (UTC)
@RexxS: Hmm, I don't like the idea of just using English here, as that won't work in cases where there isn't an English birth name. Maybe it could fall back to showing the first (and/or only) entry in that case? Or Wikidata has the concept of 'fall-back languages' (although I can't find the documentation for that beyond d:Help:Navigating_Wikidata/User_Options#Language_fallback_chain), maybe those could be used in these cases? Pinging @Lydia Pintscher (WMDE): for help/pointers here. Thanks. Mike Peel (talk) 21:48, 1 June 2018 (UTC)
@Mike Peel: I know how to get the list of fallback languages for a given language, but the code works by looping through each of the values available and adding it to the list of items to return or not - it's a big complication to say "only take this one if some other one isn't there" because the values are kept in random order on Wikidata. I mean when the code encounter an English value, it doesn't know that there might be a German or Arabic one later. That's not easy to work around but I'll try. It wouldn't help when the only monolingual test is in Russian, say, because we can either display that or nothing. What do we do when there are two monolingual texts available, but they are in Russian and Chinese? What algorithm do we use to choose? --RexxS (talk) 22:08, 1 June 2018 (UTC)
@Mike Peel: Well, it was a pain, but I think I have a solution. Here's the algorithm:
If there's only one value, return that;
Otherwise, make a table of languages from the user's default and all its fallback languages, then see if each one in turn matches one of the languages in the property - if so use that;
Otherwise, WTF? - might as well just return the first one.
Seems to work - see the table above now - but I have very few test cases to try out. Do you know of any for me? --RexxS (talk) 00:01, 2 June 2018 (UTC)
Side note for interested users: If this is following the MediaWiki fallback pattern, then the list of fallback languages will always include English. (I'm now curious how many items would actually reach that last step.) Whatamidoing (WMF) (talk) 19:05, 30 May 2019 (UTC)
Disable map option?
Routes (such as Interstate 696) defined by OSM relations doesn't appear to be displayed on the Infobox map. In those cases creating a "custom" mapframe (width, height, zoom + extra POI's) often appears to make sense though, so to save space & clutter I'd like an option to disable the Infobox map.— Preceding unsigned comment added by Hjart (talk • contribs)
@Hjart: We could, but I'd like to see if there's a way of doing what you're thinking of automatically, as we could then use that across all routes. Can you set up a demo (or point to where one already exists) that I could have a look at? Thanks. Mike Peel (talk) 00:05, 7 June 2018 (UTC)
I don't know if this has been addressed before, but I don't think it is ok to display Q-IDs to the end user even if there isn't a localized label, even worse if the Q-ID isn't clickable to at least lead to the Wikidata item that might tell more. Example is the last spouse here. Please make it clickable and replace the Q-ID with for example an italic name missing or one of the foreign language names with a dotted underline (if no fallback exists, than try to fallback to same script, if still no label matches and there is more than one label, more complex heuristics could be used, e.g. here reading of country of citizenship (P27) could indicate that Russian is the most relevant language, but all that is not necessary), but anything will still be better than a Q-ID. Thanks in advance, --Marsupium (talk) 13:29, 13 June 2018 (UTC)
@RexxS: Curious to know what you think might be possible here. (It connects to Francis's comments on enwp, but I'm not going to comment there!) Personally I like showing the Q-number as it's a call-to-action to add the English label on Wikidata (since that's the base fall-back language that all other languages end up at where their labels are missing), but a number of suggestions here would still do that while making things more user-friendly. Thanks. Mike Peel (talk) 11:56, 17 June 2018 (UTC)
Anything is possible. It just depends on how much effort we want to put into it. It would be trivial to replace the entity-id ("Q-ID") that is returned when there is no sitelink or label available in the user's language. We could have an error message like "name missing in your language", but how would that be better for the reader than the entity-id?
Other options are not so easy. Unfortunately, there is no convenient mechanism exposed to Lua by the Extension:Wikibase Client (that I am aware of) to return the collection of available labels for a given entity-id. That means that we would need to have a list of all available languages and try each of them in turn to see if each one returned a label, which would be an expensive search. Let's say there were labels in Belorussian (old style), Japanese, Hebrew and Hindi: how would we algorithmically determine which one to return for a given user/reader/topic? What if there is no country of citizenship (P27)?
As for the link, the option is already there for each field to have an "edit on Wikidata" link (a pen-icon with tooltip on hover). But if we turn that on, we get some editors complaining that it adds "clutter" to the infobox. In Category:Sergei_Yesenin, the infobox has a pen-icon linking the Wikidata entry at the bottom of the infobox. Why wouldn't we use that to see more? If we turn a piece of text into a clickable link to the Wikidata entry, we have editors complaining that it comes as a surprise to the reader who doesn't expect to be taken to "a different site". Now we have complaints that we need clickable linked text potentially in each field. I have to ask, shouldn't we be establishing a consensus for which option is wanted, rather than trying to guess which option is most desirable? --RexxS (talk) 18:29, 17 June 2018 (UTC)
Yes, Francis, we all know what you don't want. But as usual, you're not capable of saying what you do want. Do you really want what the OP suggests? clickable links to the Wikidata item, or an italic "name missing", or the foreign language name with a dotted underline, or what? --RexxS (talk) 21:18, 18 June 2018 (UTC)
My view is that it makes sense where the sitelinks aren't available and where we don't have this infobox, but where either of those are true then it's just unnecessary clutter presenting a duplicate link, so should be removed. The template can't be completely deleted (yet), though, since it is still useful where we don't have the sitelinks/infobox. Thanks. Mike Peel (talk) 18:19, 18 June 2018 (UTC)
@RexxS: This seems to be an odd one. They display the correct way around on Wikidata, but not in the infobox. Switching to 'qual=DATES' would probably solve this, but that will hide the other qualifiers. Any ideas? Thanks. Mike Peel (talk) 23:43, 20 June 2018 (UTC)
@Mike Peel: When Lua traverses a table, it does it in a non-specific order. So as far as the Lua code is concerned, there is no "correct way around". I could re-write the code to specifically use the same order as in this dump of the property, but we have no guarantee that all qualifiers are the "correct way around" in other entities. I'll have to make use of the ["qualifiers-order"] to fix order of the qualifiers - which I can see how to implement. However, that will need a pretty big revision (as I need to ensure that all qualifiers have a qualifier-order and provide a fall-back if they don't), so you may have to bear with me for a while. Here's what we have to work with:
@RexxS: Ah, OK. So even though they appear in the right order in the source, the Lua parsing changes the order? Would ordering by the property number be easier, as that would solve things in this case? Thanks. Mike Peel (talk) 11:51, 21 June 2018 (UTC)
No, Mike. The order that Lua transverses a table of key-value pairs is not specified, so no amount of jiggling around with what you see on Wikidata will guarantee a particular order. What you see in Wikidata, or in that printout above, is not the source. That's merely a human-readable representation of what's in the database in RDF-format. I could traverse the table by using numerical indices, but that's less efficient and still leaves us vulnerable to changes that look innocuous, but which actually alter the order. --RexxS (talk) 17:26, 21 June 2018 (UTC)
@DarwIn and Mike Peel: Okay, Mike, it wasn't as straightforward as I thought. I now have the code in place to ensure the qualifiers are presented in the order dictated by the ["qualifiers-order"] table (see the printout above). Unfortunately, I don't have any way of writing to that table directly to change the order if it's wrong. We still have to remove qualifiers and replace them in what looks like the right order in the Wikidata interface to affect that table. That's really hacky, but it's the only way I can see of setting the qualifier order definitively.
@Mike Peel: I don't see how it could be, as I've just edited Richard Burton (Q151973) to "massage" the start/end times of his spouse (P26) so that they are in the "right order", which changed the ["qualifiers-order"] table. It seems that the last qualifier property edited goes to the end of that table. --RexxS (talk) 22:50, 21 June 2018 (UTC)
Note - markup fix: I removed the template {{Wdib}} and copied, exactly, the text generated by it (including the link edit this on Wikidata). The problem was that {{Wdib}} categorized this page into the categories Elizabeth Taylor, Navy of Portugal and Politicians. As you can see, my solution reproduces exactly the same text generated using wdib (exept for the Wikidata link icon, a sort of pencil). Regards. --Dэя-Бøяg10:57, 27 June 2018 (UTC)
Thanks, DerBorg, for spotting my omission. On Commons, making the link adds the current page to the category, rather than displaying the item linked to the category. The usual solution is to set |linkprefix=":", which adds a colon before the link text thus allowing the display instead of adding the page to the category:
@Leit: It's in the sandbox, try {{Wikidata Infobox/sandbox}}. However, that doesn't support "point in time", so the dates are no longer shown for e.g. the opening ceremony on that page. So perhaps it's best to leave this as it currently is? Thanks. Mike Peel (talk) 22:29, 21 June 2018 (UTC)
(Edit conflict) If you're quite certain that no qualifiers other than start and end times will be wanted, then it's just a matter of replacing |qual=ALL with |qual=DATES in the 'significant event' section of Template:Wikidata Infobox. Here is a comparison for Langer Eugen (Q884122):
For many event-related qualifiers, I expect that start time (P580) and end time (P582) are going to be the only ones. Perhaps using qual=DATES is a better bet in general? Optionally, I could check the qualifiers available when qual=ALL is specified, and if P580/P582 are there, then I could treat those two as if DATES were specified. That would be a bit more work. --RexxS (talk) 22:43, 21 June 2018 (UTC)
It might be good to always format P580/P582 as a range since they are so heavily used on Wikidata to show a date range. Or have point in time (P585) in DATES, which would resolve this, but probably not other cases (particularly preceeded/follows). Thanks. Mike Peel (talk) 10:51, 24 June 2018 (UTC)
The reason seems |object = Logitech ScanMan Color-Musée Bolo there.
Now Logitech ScanMan Color-Musée Bolo is exactly the name of Category:Logitech ScanMan Color-Musée Bolo, from which the infobox part is then included into the image description. But it does not use the info from d:Q30020217, but the filename and NO WIKIDATA ID FOUND! instead.
This infobox is not compatible at all with object photo. My view is that the latter needs to be deprecated in favour of using Wikidata directly in the file pages, but I haven't looked into this enough yet to propose a solution. For now it's best to avoid adding the infobox to categories that are used by object photo. Thanks. Mike Peel (talk) 13:25, 26 June 2018 (UTC)
@Rama: Because templates that are used in main space (and yours seems to be used on 7451 pages..) should never ever be in user space. - Alexis Jazzping plz15:07, 26 June 2018 (UTC)
@Salgo60: It seems that this is an issue with the configuration of MediaWiki here - mw:Extension:PageImages doesn't seem to be enabled for categories, so there is no image provided to twitter/facebook/etc. when someone links to a commons category. This needs WMF dev input, so I've raised that on phabricator, see phab:T198716. Thanks. Mike Peel (talk) 14:47, 3 July 2018 (UTC)
@Salgo60: Sorry for not replying quicker to this. I don't think that extension is available here? As per my comment on phabricator, I think PageImages uses the more general approach rather than something that's twitter-specific, but I might be wrong. Thanks. Mike Peel (talk) 08:54, 16 July 2018 (UTC)
I have old books who are using some name or another that has a different name now. "American Ornithological Union" vs the current "American Ornithological Society" now. [[:Category:Current name|Stated as]] Category:The Auk --RaboKarbakian (talk) 22:16, 7 July 2018 (UTC)
At source, it is probably going to be the Union, here it is going to be the Society. I don't know when the Society started and the Union ended, but it is still a Union in 1920, I think.... I just want to be able to wrap the old name (red letters) around the new name (blue letters). It is easier for linking the publications. Thanks for answering. @Mike Peel: --RaboKarbakian (talk) 20:56, 10 July 2018 (UTC)
"stated as" takes a string value rather than a link value, so one might expect modern name as a blue link, stated name as black text. That might be a clearer representation of what is at the wikidata item. Or do you specifically want both to be linked as blue links to the category for the modern entity? Jheald (talk) 21:07, 10 July 2018 (UTC)
I should add that I've been working quite a lot on some of these journal items recently, where there are scanned copies in the Biodiversity History Library, so do talk to me if you think there is anything not right or that could be systematically improved with their Wikidata items. Jheald (talk) 21:10, 10 July 2018 (UTC)
I would also tend to be wary about this because I have been using object named as (P1932) to record how names (eg of book authors) have been stated in the source I am citing, which (at least for the BHL index) tends not to what is written on the title-page, and probably is also not how we would want to primarily state them in the infobox.
There is going to be a problem similar to this when source starts doing taxonomy. Stated as is the best way to point to which taxon name and if known system being used. Plants, birds, reptiles, amphibians, probably more. Same problem, really.--RaboKarbakian (talk) 20:00, 11 July 2018 (UTC)
"Stated as" should be used differently per thing (or item). It is safe and good to use author, and publisher stated as this way. Taxonomic names also.--RaboKarbakian (talk) 20:05, 11 July 2018 (UTC)
While trying to fix a similar error reported below, I realised that we're better off not trying to link string values by default, and specifically link them only in rare cases, so I've suppressed the links. --RexxS (talk) 17:15, 24 July 2018 (UTC)
Hello @Mike Peel: . now the feels a bit lonely.
Why not moving it to the sitelinks section (looking like "Wikidata"?) ?
Perhaps first of them as it is the source.
It will allow you to suppress all the first "if" part (because there would always be a wikidata link).
Cheers Liné1 (talk) 15:45, 14 July 2018 (UTC)
The reason why the value of burial plot reference (P965) is linked is because the template sets |qlinkprefix=":" in the call for "place of burial". That triggers linking for qualifiers that are of type 'string', such as burial plot reference (P965). As the qualifiers for place of burial (P119) are unlikely to be linkable wikibase items, it's probably best not to set the qlinkprefix – unless anybody knows of any examples of wikibase-items that are categories being used as qualifiers for place of burial (P119)? If so, I could always create yet another parameter like qlinked to control linking of qualifier values, although I'd rather not unless there's a demonstrable need. --RexxS (talk) 14:26, 24 July 2018 (UTC)
[Update:] It seems we rarely need qualifiers which are strings to be linked, so I've suppressed linking of qualifiers when the linkprefix is just ":" (i.e. used to suppress categorisation when category links are made). The template seems to be behaving better when there are qualifiers with datatype string now. Let me know if there are any consequential problems arising. --RexxS (talk) 17:19, 24 July 2018 (UTC)
We should never use small letters in any element that's already reduced in size. Any text that less than about 85% of the normal font size for the page is going to be unreadable by most folks with visual impairments, including older readers like me. --RexxS (talk) 18:37, 13 August 2018 (UTC)
@Jklamo and Jérémy-Günther-Heinz Jähnick: The current options available here are to show one qualifier (e.g., P462); the date properties; or all qualifiers. It doesn't seem to be possible to select 4 qualifiers ([1] doesn't work, unless @RexxS: can help). So, which should we do? Thanks. Mike Peel (talk) 13:11, 30 August 2018 (UTC)
@Mike Peel and Jérémy-Günther-Heinz Jähnick: I can see how to do what's required, but it will take a bit of a re-write of the code that handles qualifiers. Essentially, we could use something like |qual=P580, P582, P642, P768 and I could then detect the list and arrange for the code to loop through the supplied qualifiers, checking if each one existed in turn, and processing each one found. How would you envisage that the display should handle multiple values for each qualifier? --RexxS (talk) 15:14, 30 August 2018 (UTC)
Improvement to "location" field with hierarchical information
Hello,
I have had a thought about the "location field", which I will illustrate with an example.
In cases such as Category:Near Eastern Antiquities in the Louvre - Room B, we see things like "Located in: Sully Wing, France". The field takes information directly from the item, in properties "located in" (P276) and "country" (P17). This has obviously been designed with large locations in mind such as cities or regions ("London, UK" or "Kantō, Japan" make sense), but as precision increases the outcome becomes absurd: if you know that the Sully Wing is one of the main subdivisions of the Louvre, you do not need to be told that it is in France; and if you do not know what it is, "France" is too vague.
In the case of Category:Near Eastern Antiquities in the Louvre - Room A, we see a more reasonable hierarchy of locations, generated by a similar list in the Wikidata item for Room A. This sounds sub-optimal as the Wikidata item then contains several locations, more and more precise, instead of the most precise of these.
Would it be possible to perform hierarchical queries to parent items, as to obtain "Sully Wing, Louvre Palace, 1st arrondissement of Paris, France" (with the rule: Room 300 (Q30083572) located in (P276) Sully Wing (Q17309954); Sully Wing (Q17309954) located in (P276) Louvre Palace (Q1075988); Louvre Palace (Q1075988) is in the administrative unit (P131) 1st arrondissement of Paris (Q161741); 1st arrondissement of Paris (Q161741) country (P17) France (Q142)" ?
That sort of thing is easy to do in database query but is hard to do by a code traversing multiple items. Each loaded item is another expense in time and memory. A while ago I wrote phabricator:T167521 proposing a solution, but without changes to the software I do not think it is feasible. --Jarekt (talk) 16:56, 28 August 2018 (UTC)
It would be a big help if folks had a chance to test it out on a number of test cases and let me know if any problems arise. Cheers --RexxS (talk) 23:16, 28 August 2018 (UTC)
[Update] I figured that we could also terminate the chain when the item is an instance of (P31) of country (Q6256), so I've re-instated P706 and implemented that termination condition. A side-effect is that we can find higher-level chains now:
A huge thank you to all for your attention, your swift answer, your impressive efforts and for the splendid solution! Rama (talk) 06:26, 29 August 2018 (UTC)
Ok, I understand. I added it here because the smallest administrative area here is quite a bit a larger than the town this example is in, so for a lot of cases in Denmark I'd really like to have both though. --Hjart (talk) 13:36, 4 September 2018 (UTC)
@Mike Peel: It looks perfect, thanks, and in fact a bot job to go through them would be fantastic! By the way, I really appreciate the infobox and I know you've put a lot of work into it, so, thank you! Josh (talk) 06:51, 6 September 2018 (UTC)
@Joshbaumgartner: I've run the bot through the ones that are linked to from Wikidata (and added the sitelinks for the others that I could). There are still a few that the bot couldn't migrate as their wikidata entries are already linked to another item, perhaps you could have a look through those manually? Thanks. Mike Peel (talk) 22:25, 6 September 2018 (UTC)
@Mike Peel: No problem, I can take care of the sticky ones. There are some aircraft which have multiple categories on Commons but one entry on Wikidata. Thanks! Josh (talk) 22:28, 6 September 2018 (UTC)
@Mike Peel: Mass implementation of Wikidata Infobox cause graphical disruption of category pages because the infobox pushes other templates, description and content of the category out of the screen. Some solution should be developed:
wrap text, all other templates and section titles around the infobox
a bot task which would manage pernamently an optimal order of templates and boxes to minimalize unwanted effects. --ŠJů (talk) 12:44, 8 September 2018 (UTC)
@ŠJů: Pi bot has been adding the templates below the last }} for this reason. I'm not aware of anything that can be done with the infobox code to fix this - the other templates' codes need to be fixed so that they no longer insist on 100% of the screen width (which is why browsers then display them below the infobox). Or hopefully the functionality of those templates is now in the infobox, and the other templates can simply be removed. Thanks. Mike Peel (talk) 19:32, 9 September 2018 (UTC)
Only several templates are fully replaced by Wikidata infobox. Some other (as "cat see also", "do not confuse", naviboxes, warning and maintenance templates etc.) should remain in the head of the page. --ŠJů (talk) 19:45, 9 September 2018 (UTC)
Most of those should work OK (e.g., {{Categorise}} can be put after the infobox and it displays fine). Others need to be fixed. If they use mbox, then I think the trick is to use auto width, e.g., see {{Categorise/layout}} (I don't know why that's not the default). Thanks. Mike Peel (talk) 19:57, 9 September 2018 (UTC)
@Mike Peel: As I noticed now, it is a problem with [Mark this page as patrolled] link. It displays below the infobox and pushes all content below. However, this problem affects "patrollers" only. --ŠJů (talk) 19:50, 12 September 2018 (UTC)
@ŠJů: I have patrol rights, and I see that link, but it appears to the left of the infobox for me, and doesn't push the content down... Can you link to a case where it does push it down for you? Maybe there's something else that's also going on there. Thanks. Mike Peel (talk) 20:27, 12 September 2018 (UTC)
@ŠJů: Ah, you're using Monobook still. If I add "?useskin=monobook" onto the end of the URL, then I can reproduce the problem. If you want to try "?useskin=vector", then it should look OK. It seems to track back to a div.patrollink {clear: both;} *somewhere* in the CSS for Monobook - if that can be removed then the problem should go away. Thanks. Mike Peel (talk) 23:09, 12 September 2018 (UTC)
Found it - it's in the 'skins.monobook.responsive' module, see [2] (search for 'patrollink'). I have no idea what Mediawiki namespace page that corresponds to, though, so I don't know how to fix it. Thanks. Mike Peel (talk) 23:23, 12 September 2018 (UTC)
@Liné1: I'm trying to embed {{VN}} into the infobox, but have run into a couple of problems. For the implementation, see [3]. However, at Hymenaster the VN module gives the error "Error: Incorrect parameter(s) "qid"" - can that be fixed? Also, for cases where there are many VNs, can you implement show/hide, like is done at Category:Iron Man (film) for "Cast member"? Also pinging @Christian Ferrer to be aware of this discussion. Thanks. Mike Peel (talk) 22:53, 24 September 2018 (UTC)
Thanks! If possible, suppressing the "No common name has yet been provided in this user nor in wikidata 'Dytaster'" text would be good (that way the row just doesn't show in the infobox). Thanks. Mike Peel (talk) 20:55, 25 September 2018 (UTC)
@Liné1 and RexxS: There is still an issue here that when VN returns nothing, the line still shows in the infobox. Live example is at Hymenaster, where {{Wikidata Infobox/sandbox/line {{!}} Q502895 |2={{VNNoDisplay|useWikidata=Q3463442}}| showhide=y}} returns
Aah, that actually returns values ... so something else is wrong here, potentially the inclusion of the template in the line template... More investigation needed. Thanks. Mike Peel (talk) 14:00, 19 October 2018 (UTC)
That could be it ... it doesn't look like the 'nocat' parameter does much, sadly. I suspect the Lua code needs some work... Thanks. Mike Peel (talk) 17:21, 19 October 2018 (UTC)
Hi! When showing data from a "category item"... would it be possible borrowing a locator map image (P242) value from another item, linked in category combines topics (P971) (and displaying the map in the infobox, of course)?
Hi, if I understand correctly, current located on street (P669) implementation is fetching label of the street only. I think it would be nice to have also link to a street category in a case of presence of located on street (P669) only, but even in a case of presence of both located on street (P669) and P969 (P969). I am not sure about how to implement the second case, maybe real splitting "located at street address" row to "located at street address" and "located on street" can be the solution.--Jklamo (talk) 09:19, 17 October 2018 (UTC)
Have a look at Category:Stemmen (Landkreis Rotenburg). There's a picture in the infobox that is from a different place called "Stemmen". The image is not in the Commons category and also not on Wikidata, so the error must be in the template, I guess!? --Slomox (talk) 11:28, 7 June 2019 (UTC)
Moin Slomox, nee, mit Wikidata ist alles richtig in die Box gekommen. Wenn du dir das verknüpfte Wikidata-Objekt aufruft und dann auf "Thema der Kategorie" schaust, ist Stemmen hinterlegt. Das ist das Thema. Wenn dann müsste da etwas anderes verbunden werden. --Crazy1880 (talk) 12:29, 7 June 2019 (UTC)
Danke! Ich habe die beiden Wikidata-Objekte von Kategorie und Ort verwechselt und deswegen den Fehler nicht erkannt... Ich habe es korrigiert. --Slomox (talk) 12:36, 7 June 2019 (UTC)
Hi, just wondering how I can fix the sorting for Category:Berenice Abbott in Category:Abbott (surname) (for example). I come across these at times, and I thought maybe it has to do with the fact that she did not have a given name property, which 1) existed and 2) I added, but that didn't fix it? Thanks, -- Deadstar (msg) 15:34, 12 June 2019 (UTC)
@Deadstar: You fixed it correctly, but the cache was stale. I've made a null edit to the category (click 'edit', then save without making any changes), and that's refreshed the cache, and the sort order in the category. Thanks. Mike Peel (talk) 16:21, 12 June 2019 (UTC)
This section is resolved and can be archived. If you disagree, replace this template with your comment. Crazy1880 (talk) 08:03, 23 June 2019 (UTC)
Hard to distinguish multiple values
Eastern European Time
Central Africa Time
Israel time zone
South African Standard Time
I noticed this problem at Category:UTC+02:00, where the "Said to be the same as" items are hard to distinguish from each other (see right for how I see it in my browser), but it applies to other properties, as well. When there are multiple items listed under one property, there is no visual indication of where one item ends and the next begins. This is particularly problematic when (as here) the items are getting wrapped across muliple lines and capitalization cannot be used to visually separate the items. This needs improving. - dcljr (talk) 03:47, 5 June 2019 (UTC)
Sure, but what if the items themselves contain commas? (I can't provide an example at the moment). Perhaps a parameter could be added to specify a separator (or an override to a default separator). Hmm… What if different separators are necessary on different properties? This could get very complicated! (But, yeah, I do prefer the commas in this particular case.) - dcljr (talk) 08:38, 5 June 2019 (UTC)
@Dcljr: It's even more complicated than that. What separators make sense when the infobox is displaying Chinese or Japanese characters, for example? A new line is the simplest option, maybe a comma is the next simplest. Thanks. Mike Peel (talk) 20:24, 5 June 2019 (UTC)
Eastern European Time
Central Africa Time
Israel time zone
South African Standard Time
There's already a "newline" at the end of each item (I assume, since they are "<li>" elements). Do you mean a blank line (i.e., additional vertical whitespace)? As for non-Latin based languages, as you know, each has it's own convention(s) for separating items in a list (for example, there is a Japanese comma: 、). Anyway… other comparatively "language agnostic" options include middots [•] and horizontal rules of some sort (see left for a simple example). - dcljr (talk) 00:42, 6 June 2019 (UTC)
Personally, I tend to use ";" or " // ". Maybe some "different from" don't need to be displayed in the infobox, e.g. the statement pointing to an item for disambiguation pages at Category:John (given name) (same on every other category for given names). Besides that, personally I wouldn't mind smaller print for some of the infobox content. Jura1 (talk) 12:03, 6 June 2019 (UTC)
This section is resolved and can be archived. If you disagree, replace this template with your comment. - dcljr (talk) 00:42, 25 June 2019 (UTC)
Moin Moin Strakhov, on witch position you want to show this? Do you habe an example article, where I can look for the right position? Thanks --Crazy1880 (talk) 17:36, 8 June 2019 (UTC)
Something is strange on Category:Grand Rond (jardin) the coordinates are correct on Wikidata (and precision is also correct apprently, I put a greater precision and purge but it doesn't change anything) but for some reason the coordinates seems incorrect when reused on Commons... @Mike Peel:
Well, to be honest I was a bit lost and there seems to be indeed some caching issue on top of it. The correct coordinate is "43° 35′ 44.88″ N, 1° 27′ 9″ E" but there was something wrong with the precision on the Wikidata side (original walue was 43.5958 1.4525 0.01 which is incorrect, I changed it to 0.0001 but it changed the lat and long too for some reason and because of the cache I didn't saw it). It seems to be ok now. Cdlt, VIGNERON (talk) 12:14, 21 July 2019 (UTC)
This section is resolved and can be archived. If you disagree, replace this template with your comment. VIGNERON (talk) 12:14, 21 July 2019 (UTC)
Coexistence with another templates
Hi everyone,
I am adding Wikidata infoboxes, but doing this task I have noticed that the infobox already has many data that it is in another templates (e.g., {{Object location}}). So my question is, what we have to do if the Wikidata infobox already has the data that it is in another template (like the one mentioned)? This can be observed in this category.
And, another case of coexistence. Should be the multilingual descriptions templates (e.g., {{Es}} or {{En}}) being removed from the category if it doesn't contribute considerably to explain the category?
I did a fast reading of the FAQ but I didn't find the answers to my questions. If someone might help me to clarify this, I would be very thankful.
@Ivanhercaz: My view is that it's best to remove those templates where they duplicate what's now provided through the infobox. Others probably disagree, though. Thanks. Mike Peel (talk) 16:04, 23 June 2019 (UTC)
@Mike Peel: Thank you for your comment! I have your point of view: if those templates have the same data than the ones shown in the infobox, the additional templates should be removed. But I wanted to be sure that more users are making this. I am going to remove those kind of templates.
This section is resolved and can be archived. If you disagree, replace this template with your comment. Mike Peel (talk) 08:43, 28 July 2019 (UTC)
Lines in map
I noticed that sometimes there are white lines in the dynamic map of the infobox. This is due to the templatestyle:
#wdinfoboximg{max-height:250px;width:auto;}
The tiles of the map are larger than 250px. The css should be made more specific, so that it doesn't accidently match the map tiles. —TheDJ (talk • contribs) 10:54, 25 July 2019 (UTC)
This section is resolved and can be archived. If you disagree, replace this template with your comment. Mike Peel (talk) 08:40, 28 July 2019 (UTC)
Customizing displays of contents of Wikidata infoboxes used in the Commons
Hi, guys!
At Ottoman Empire I want to customize the display of infobox contents from Wikidata based on language.
In Turkish I want "Edirne" to display as only such, but in other languages to display as "Adrianople (Edirne)". This is because the city was known as Edirne in Turkish but Adrianople in French. Is it possible to customize displays of contents by language in this way?
WhisperToMe (talk) 15:09, 25 July 2019 (UTC)
This section is resolved and can be archived. If you disagree, replace this template with your comment. Mike Peel (talk) 08:38, 28 July 2019 (UTC)
Award received field
See Category:Rickie Lee Jones: "Award received Grammy Award for Best New Artist (Christopher Cross, A Taste of Honey, 1980)". That's three consecutive Grammies crammed together - A Taste of Honey (1979), Rickie Lee Jones (1980), Christopher Cross (1981). The wikidata record seems correct; it has follows and followed by qualifiers, and these are displayed here as part of Rickie Lee's award. Retired electrician (talk) 23:27, 15 January 2019 (UTC)
Sometimes I think the Wikidata infobox is trying to become a mini Wikipedia article unto itself. There are a lot of fields that have no use in helping people find media on Commons (e.g. factoids with no links). The data-obsessed overlords continue to pad it, and we're stuck with it. --Animalparty (talk) 00:40, 16 January 2019 (UTC)
This section is resolved and can be archived. If you disagree, replace this template with your comment. Laddo (talk) 04:01, 4 August 2019 (UTC)
Removal of interwiki links
Hi everyone, there are several categories with WD-Infobox and interwiki links.[4]. Is it ok to remove them with a bot, if the same link comes from WD? --Arnd (talk) 07:27, 16 December 2018 (UTC)
@Aschroet: They should no longer be needed (and will only rot over time as pages elsewhere get moved around) so I'd say go for it. I know @Gabrielchihonglee: and @Zhuyifei1999: were working on this with Gabrielchihonglee-Bot, but I'm not sure if that's running at the moment. I guess if you can bot-work through the ones that you can, we can start working through the remaining ones manually using that search query. Thanks. Mike Peel (talk) 16:51, 16 December 2018 (UTC)
Hmm... Looking at the current situation, am I correct that this template {{Wikidata Infobox}}no longer calls {{Interwiki from Wikidata}}? The bot only works on pages that transcludes the latter, and with the current scheme, invocation of Module:Wikidata alone is not sufficient evidence that Module:Wikidata.interwiki is called, and very complex logic might have to be added to figure out the parameters that are used to invoke the Lua module. I can notify Gabriel to extend the bot, but I don't understand why this separation is done. CC @Mike Peel: --Zhuyifei1999 (talk) 18:06, 17 December 2018 (UTC)
Ok I'll notify Gabriel. We are in different timezones so it'll probably be a few hours / tomorrow before I get a chance to catch him. --Zhuyifei1999 (talk) 19:09, 17 December 2018 (UTC)
Gabrielchihonglee, seems to work fine. Thank you. However, can it be that your bot only considers interwiki links of languages with two letter codes. I ask because of the remaining links as for example here: [5]. --Arnd (talk) 15:09, 18 December 2018 (UTC)
@Aschroet: This is an old bug relating to some leftover inconsistent state in wikimedia configuration / database from the be-x-old -> be-tarask move. So as far as pywikibot is concerned, neither be-x-old nor be-tarask is an interlanguage prefix. --Zhuyifei1999 (talk) 18:14, 18 December 2018 (UTC)
A lot of the remaining langlinks are on those categories that link directly to an article item on Wikidata. Gabriel's bot won't remove them since they aren't expanded by Module:Interwiki, and my bot won't remove them because they are cross-namespace. They need some help on Wikidata side (probably Pi bot?). --Zhuyifei1999 (talk) 15:30, 4 January 2019 (UTC)
so {{#invoke:Interwiki|interwiki}} on that page expands into (make sure to enter the context title)... nothing. Gabrielchihonglee-Bot ignores the category page.
and the text langlink is to en:Lower South Falls, in another namespace, YiFeiBot will not operate on these links.
oh and to clarify, neither of the two bots edit Wikidata. They rely on Wikidata being in a good state before they are 'confident enough' to perform its tasks. We have bots like Pi bot that I link is fixing these category <-> article linking on wikidata, but since I haven't really looked at how that bot (or pretty much any other wikidata bot) works, @Mike Peel: --Zhuyifei1999 (talk) 02:39, 5 January 2019 (UTC)
@Zhuyifei1999: Can you drop the cross-namespace exclusion from your bot (or at least the category -> article part)? That doesn't really make sense, since category items here correspond with articles on Wikipedias, and there's no plan to mass-create category items just for a commons sitelink that currently sits well in the topic item (pi bot just makes use of category items that already exist). Thanks. Mike Peel (talk) 07:45, 5 January 2019 (UTC)
@Mike Peel: I'm thinking of this scenario: say if my bot removes such link on a category page, but the page does not call Module:Interwiki; later, someone moves the sitelink on wikidata from the topic item to a category item, then the category page would no longer have langlinks to wikipedia articles... which would be bad. How about this: I'll make it drop this requirement iff the page calls Module:Interwiki? --Zhuyifei1999 (talk) 07:55, 5 January 2019 (UTC)
@Zhuyifei1999: The infobox should automatically deal with that scenario by including Module:Interwiki if it becomes necessary (providing P301 is present, as there's an if statement that then invokes the module), so I don't think that situation's something we need to worry about. Thanks. Mike Peel (talk) 08:04, 5 January 2019 (UTC)
@Zhuyifei1999: We're at the point where nearly every category linked to wikidata has an infobox, so that shouldn't be a frequent issue. But how about removing them iff the category calls the infobox? Thanks. Mike Peel (talk) 08:34, 5 January 2019 (UTC)
Gabrielchihonglee-Bot seems to have logged out (we are investigating). YiFeiBot... I just fixed a bug in it a few days ago and it is now doing much more --Zhuyifei1999 (talk) 19:59, 28 January 2019 (UTC)
This section is resolved and can be archived. If you disagree, replace this template with your comment. Laddo (talk) 23:37, 5 August 2019 (UTC)
UK locations
This displays place, district, local government county and ceremonial county so some of the names are there twice - "Lancaster, Lancaster, Lancashire, Lancashire". For the first repetition it would be better to display the name used in the category for the district if possible; for the second there is one with no category which is unnecessary. Another problem is that North Yorkshire (ceremonial county) is in two regions - Wikidata uses "applies to" for this but it looks like the infobox displays North East England for all, when it only applies to the part formerly in Cleveland. Peter James (talk) 20:10, 4 January 2019 (UTC)
When you try to change the located in the administrative territorial entity (P131) value on Wikidata to skip the inaccurate ones, you get reverted because apparently it's more important to be able to find places in the city or ceremonial area than it is to accurately portray what an administrative territorial entity is.
@RexxS: Perhaps a way to simplify the string a little might be to check if the next string is the same as the previous string, and to not display it if it is (or, if one has a link but the other doesn't, to display the one with the link? That would avoid things like "Staffordshire, Staffordshire". Thanks. Mike Peel (talk) 17:06, 5 January 2019 (UTC)
@Mike: I considered that, but then had reservations about displaying the ceremonial county Staffordshire (Q23105), which is linked, rather than the administrative entity Staffordshire (Q21694786), which isn't. But if you think it's okay, I'll implement the logic of testing whether a location is the same as the previous location in the chain, then displaying the one that is linked if there's only one linked, or picking one location if both are either linked or unlinked. Let's see how that goes. --RexxS (talk) 17:43, 5 January 2019 (UTC)
Yes that's an improvement, but there's one thing I'm not sure about. There was another Sefton there, the civil parish which is called Sefton Village in Commons but "village" was missing as it isn't in Wikidata (or officially in the name). Should the district be changed to "Metropolitan Borough of Sefton" in Wikidata (and similar for Knowsley)? If not, could it be specified in Wikidata to use an alternative name here? Peter James (talk) 20:08, 5 January 2019 (UTC)
Feel free to edit Wikidata and change the labels to whatever you think best. Everybody else does. I don't think Wikidata will want to have an alternate name just for use on Commons. I'm not inclined to create a substitution lookup table in the code to change "Sefton" to "Sefton Village". How many villages would I have to have in the table to catch every one? --RexxS (talk) 20:42, 5 January 2019 (UTC)
The logic has greatly complicated the algorithm in WikidataIB/sandbox|location, so it will need checking and monitoring when implemented. Cheers --RexxS (talk) 18:05, 12 March 2019 (UTC)
This section is resolved and can be archived. If you disagree, replace this template with your comment. Laddo (talk) 23:39, 5 August 2019 (UTC)
Media legend for images
In case there is no "media legend" in English for images in Wikidata, why media legend for other language is shown on this template? For example in Category:Sus scrofa domesticus media legend is shown in Catalan language (Truja amb porcells), because it's the only language for this image in wikidata, but i would prefer to see media legend in English if there is one, or no legend at all. --Smooth O (talk) 13:10, 16 January 2019 (UTC)
I disagree that captions should be removed. When used properly it establishes context and gives information about the subject. For instance, the age or location of the subject are information that should be display when the information is available. For certain countries like Norway, it's also mandatory by law and the practice of the language project to display attribution (photographers' moral rights). Toresetre (talk) 15:52, 31 January 2019 (UTC)
It's an incredibly annoying feature to have. More unfiltered data clutter. It should be self-evident that a portrait in a person's infobox is that person, and true-but-trivial info like the year or setting is just extraneous for the purpose of Commons. I'm sure some OCD, data-loving folks would want to add the photographer, historical context, and every minor thing in the image, which doesn't realistically aid users on Commons. It's even more useless when there are red-links inserted into the caption. If we MUST have this crud shoved in our faces, it should at least be hidden unless it's in the language specified by users. I don't want to see English captions, and I definitely don't want to see Swedish, Korean, or German captions. User:Mike Peel any thoughts? --Animalparty (talk) 20:23, 4 February 2019 (UTC)
I am hoping that the media legend can be replaced with the structured data on commons caption when that is accessible through Lua (hopefully later this year). Until then, the work-around is to add the media legend in your preferred language and/or English. Thanks. Mike Peel (talk) 20:43, 4 February 2019 (UTC)
Ah yes, Wikidata, the ever-hungry beast whose demands to be fed grow stronger every week. Caption me! Make categories! One day humans won't even need to write articles, or curate photographs, we'll just feed raw data into Wikidata, who will recreate the world in Its image. Everything in the universe controlled from a single point. Because individuality is inefficient. --Animalparty (talk) 02:28, 5 February 2019 (UTC)
@Pigsonthewing: I think that should be relatively straightforward using {{#invoke:WikidataIB|checkvalue}}, but it's going to have to be a lookup table saying "if this QID is in P31, then add this category". Do you have a list of the QIDs for the items like common year starting and ending on Sunday (Q235670), and their corresponding categories? You would then need to make sure that the P31 value is set on Wikidata for all months/years, but that's a problems that someone else might be able to solve on Wikidata. Thanks. Mike Peel (talk) 09:38, 3 February 2019 (UTC)
It’s way easier without involving Wikidata: {{#time:l|1 February 2019}} → Friday. The category name can be tested using a regexp to decide whether it’s a month/year, or Wikidata can be used at this tiny part (searching for appropriate P31 values; I’d advise in this case wrapping the whole #time call in an {{#iferror:…}} guard, just in case the category name is not a valid date for some reason). I don’t see, however, why this categorization is useful at all, so I’d like to see some use cases before implementataion. —Tacsipacsi (talk) 19:35, 3 February 2019 (UTC)
This section is resolved and can be archived. If you disagree, replace this template with your comment. Mike Peel (talk) 14:16, 14 August 2019 (UTC)
Small request
Can you make the title of the Wikidata Infobox appear in bold type? I think that's more consistent with other infoboxes. - PKM (talk) 23:19, 21 April 2019 (UTC)
So what was wrong with the old coordinates and their precision? I guess that Wikidata and your code used different approaches to rounding it up, and if you change precision from +-1 mile to +-3 meters there will be less discrepancy in rounding approaches. Most cities, countries, and other large regions should not use precision measured in meters. I do not know if the issue was with your map or with Wikidata map but they should look similar even if you have less precise location. --Jarekt (talk) 14:47, 19 May 2019 (UTC)
@RexxS: can you comment here? I'm guessing it's something along the lines of one rounding down, and another using the central value? Thanks. Mike Peel (talk) 06:55, 20 May 2019 (UTC)
@Jarekt and Mike Peel: Before Mike's edit, the coordinates given had a precision of 0.014930716856725. Wikidata stores its coordinates and precisions as decimal degrees, so that old value represents a distance of up to 1.6 kilometres. When WikidataIB retrieves a latitude or longitude, it rounds the value to a decimal number in line with the precision (see lines 240 to 260). The algorithm used is to round the precision to the nearest power of 10; then to divide the lat or long by that precision; then round the value to the nearest integer; then multiply that integer by the precision. That gives a decimal value truncated with no more significant figures than the precision suggests. This avoids spurious decimal places that are not warranted by the given precision. The effect can be visualised by imagining the area in question broken up into a grid of a size given by the precision. An object can then effectively only have a location at the intersection of these grid lines. Of course if you give a precision of more than a kilometre, it's not surprising that the point on the map shown could be a considerable distance away from the real location. Mike's edit reduced the size of the grid squares to around 3 metres, so you will get a building pretty much where you expect it to be. It would, however, be ridiculous to give that much precision to, say, the location of a mountain.
The other option would be to completely ignore the precision setting when retrieving coordinates, which would lead to New Town (Q11793603) displaying a longitude of 18.611639722222 deg W (an implied precision of around 70 nanometres). I think I prefer the current system of fixing nonsensical precisions on Wikidata by making them something sensible (which benefits everyone), rather than the alternative of displaying coordinates with ludicrous precisions. YMMV --RexxS (talk) 17:22, 20 May 2019 (UTC)
@RexxS and Mike Peel: , I was contacted by a a user who likes to set town location coordinates right in the central square (if one exist) so they look nice on Wikidata, and he did not like that his handcrafted coordinates were in a incorrect spot on identical looking maps on Commons. I am quite familiar with rounding based on precision as I do exactly the same in my Module:Coordinates. I think the little pin should be exactly in the same place as on map on Wikidata where the coordinates coming from however numbers displaying this location can (and should be) rounded to the correct precision so that we do not give impression of 1 m accuracy when we display location of a continent. Would that be acceptable? --Jarekt (talk) 20:05, 20 May 2019 (UTC)
@Jarekt: That all depends on what editors choose to consider "correct precision". If they decide to enter the location of a town's small central square with a precision of 300 metres (10 arcseconds), they shouldn't be too surprised if the pin shows up 200 metres away from the centre. I don't think it's our job to try to compensate for that sort of error. --RexxS (talk) 20:41, 20 May 2019 (UTC)
@RexxS: Users are surprised if map on Commons has a little tag at different location then almost identical looking map on Wikidata. As long as position on both maps is the same we should be fine. --Jarekt (talk) 02:17, 22 May 2019 (UTC)
@Jarekt: You can have the the little tag in the same place on any map if you ignore the precision. Retrieving the coordinates from Wikidata is not only used for maps but also for display as numeric values. Users are entitled to complain if we imply that the location of a building is known to less than a micron. --RexxS (talk) 03:10, 22 May 2019 (UTC)
This section is resolved and can be archived. If you disagree, replace this template with your comment. Mike Peel (talk) 14:30, 14 August 2019 (UTC)
Inappropriate passing of categories
Hello! I'm not sure where would be best to post this if not here, but I've found an odd instance of the infobox inappropriately passing categories. In this specific case, for Category:Apollo 9 and Category:Apollo 12, their Wikidata pages include the Callsign parameter. For whatever reason, this is causing the Callsign's components (in this case, "Gumdrop *applies to part* Apollo Command/Service Module" and "Spider *applies to part* Apollo Lunar Module" for Apollo 9) to pass the Commons categories for Apollo Command/Service Module and Apollo Lunar Module on to the mission category. I know this is the *reason* these categories are showing up, but I don't begin to understand why Wikidata:Property:P2317 would be causing this. Any help would be appreciated, as this is obviously not a desirable behaviour. — Huntster (t@c)01:59, 22 June 2019 (UTC)
From the empty parentheses, it’s pretty obvious that some code doesn’t prefix links intended to link to category pages with a colon. The only question is what code is this, but that will be answered by someone who knows this template more in detail than me. —Tacsipacsi (talk) 20:14, 22 June 2019 (UTC)
Mike Peel, yes, the sandbox fixes it. Thank you! I don't understand how that happened on the Wikidata side, but at least it won't impact things here. — Huntster (t@c)08:10, 23 June 2019 (UTC)
@Huntster: OK, it's now live. The difference is in the coding here, while [[:Category:Blah]] displays a link, if it's [[Category:Blah]] then it's included in the category. If you still see this happening in other categories, try a null save (click edit then save without making changes) to see if that fixes it - if not, let me know. Thanks. Mike Peel (talk) 08:38, 23 June 2019 (UTC)
Sure, I know how the wikicode works; I just thought something weird was happening on the Wikidata side that caused our code to display in this manner. Sorry for the questions, I like to try and understand the whole of the problem in case I see it happening elsewhere and can avoid punting it to someone else. — Huntster (t@c)13:57, 23 June 2019 (UTC)
This section is resolved and can be archived. If you disagree, replace this template with your comment. Mike Peel (talk) 14:27, 14 August 2019 (UTC)
One more qualifier for "position held"
Hi, I believe it is worth improving the "position" field to fix occurrences such as position held (P39)=mayor (Q30185) with dates... and nothing else. See this case that shows:
It would be worth adding info from qualifier "of (P642)", to indicate for which entity the statement applies; I suggest changing the template code as follows:
This section is resolved and can be archived. If you disagree, replace this template with your comment. Mike Peel (talk) 14:23, 14 August 2019 (UTC)
value = unknown, with qualifier "stated as"
There was a thread somewhere about showing qualifiers when value is somevalue ("unknown"), but I have lost it.
Anyway, in the special case that there is a object named as (P1932) qualifier on a somevalue, it would be nice to show the P1932 qualifier text, rather than "unknown". This pattern is used a used as a fairly standard mechanism when there is no wikidata item for the value (and for notability reasons, probably won't be), but we know the name.
@Kaganer: This is #1 in the #Wishlist - can you suggest how we could do this? As it's text rather than Wikidata items, it's rather more difficult to translate this than the infobox content! Thanks. Mike Peel (talk) 18:23, 17 July 2019 (UTC)
@Mike Peel: . See diff. This is some magic - translation items in the translatable page was named directly (instead default numbering - see code). Naming pattern is optionally, "msg-" prefix may be cleaned if desired.--Kaganer (talk) 19:33, 17 July 2019 (UTC)
I can see all the items (11 and 8 respectively), so I think it's a caching error. I've made a null edit to the categories to see if that helps. If you still can't see all the items, can you try adding "?action=purge" to the category URL to clear the cache in your language? Thanks. Mike Peel (talk) 17:11, 2 August 2019 (UTC)
This section is resolved and can be archived. If you disagree, replace this template with your comment. Mike Peel (talk) 13:37, 14 August 2019 (UTC)
preferred status for population
Somebody is removing the preferred status on poulation entries. Thats the effect: Category:Heilbronn. Is there a ule on WD how to record population information? We have the same problem on WV. -- DerFussi18:34, 8 August 2019 (UTC)
I'm not sure that's a good idea, as there might be cases where several different values might want to be displayed with different qualifier clarifications. So I'm going to leave this as it is for now, if that's OK. Thanks. Mike Peel (talk) 13:37, 14 August 2019 (UTC)
This section is resolved and can be archived. If you disagree, replace this template with your comment. Mike Peel (talk) 13:37, 14 August 2019 (UTC)
Wikipedia link
While there are already Wikipedia links in the Wikipedia sidebar, this template could have a link to the corresponding Wikipedia article in the current displayed language. This would advantageously replace the hard links currently seen in some categories. The RedBurn (talk) 09:39, 17 August 2019 (UTC)
@The RedBurn: It should already do so - there should be a link to Wikipedia and the other sister projects just below the image when there is a relevant sitelink. Is it not working in some cases? Thanks. Mike Peel (talk) 16:16, 21 August 2019 (UTC)
@Jarekt and RexxS: The thing they have in common is that they use a lot of country items - e.g. "France (Q142) Other (Statements), Some labels, Title" - and those are typically big Wikidata items. Is there any Lua optimisation that could be done to reduce the amount of information fetched for each country? Otherwise I can try setting maxval to a lower number, and removing some of the qualifiers. Thanks. Mike Peel (talk) 13:47, 23 August 2019 (UTC)
@Jarekt and Mike Peel: The problem is simply the time it takes to retrieve information from each country just to display a link when there are lots of countries. I checked Category:Teenage Mutant Ninja Turtles (2014 film) and found that an edit-preview took as much as 9 seconds out of the 10 seconds allowed before time-out. The cached view naturally didn't have the same problem. So I added |linked=no to the WikidataIB call in the line that does the publication date (line 476) in the sandbox. Using the sandbox version in Category:Teenage Mutant Ninja Turtles (2014 film) reduced the preview time to under 2 seconds at the cost of unlinking all of the countries in that huge list.
21 August 2014 (Czech Republic, Netherlands, Slovakia, Thailand)
22 August 2014 (Bulgaria, Finland, Romania)
26 August 2014 (Seoul)
28 August 2014 (Costa Rica, Hungary, South Korea, Lebanon, North Macedonia)
29 August 2014 (Cyprus, Honduras, India, Lithuania, Nepal, Panama)
3 September 2014 (Egypt, Kuwait)
4 September 2014 (United Arab Emirates, Denmark, Croatia, Iraq, Jordan)
5 September 2014 (Bangladesh, Turkey)
11 September 2014 (Australia, Papua New Guinea)
12 September 2014 (Venezuela)
18 September 2014 (Switzerland, Italy, New Zealand)
11 October 2014 (Scotland)
15 October 2014 (Belgium, France, Luxembourg)
16 October 2014 (Austria, Germany)
17 October 2014 (Spain, United Kingdom, Republic of Ireland, Kenya, South Africa)
22 October 2014 (Malta)
23 October 2014 (Greece)
30 October 2014 (Portugal)
31 October 2014 (People's Republic of China)
2 February 2015 (ward area of Tokyo)
7 February 2015 (Japan)
You can see the difference in the above call by changing to |linked=yes. I couldn't do a permanent fix in the sandbox because it's presently unsynchronised. I suggest, though, that any field where you are likely to get more than about 50 linked items ought to compromise by unlinking those items. TMNT has about 80 countries in its publication date field.
I could make the code run faster by skipping the parts where it looks for a short name and where it uses the sitelink when available, etc. so that it just gets a label, but I'd need yet another parameter to turn on the skipping because folks asked for the present functionality. --RexxS (talk) 14:51, 23 August 2019 (UTC)
@Jarekt and RexxS: OK, I've updated the current version of the sandbox to unlink those items, and also collapse the list when it gets very long. I'll probably deploy the new version tomorrow after a bit more work, so please test it to make sure it looks OK! Thanks. Mike Peel (talk) 17:34, 24 August 2019 (UTC)
@Sadads: Great tool! Thanks for sharing! Do you know why it is so slow? Or is it just me? I just ran a set and it took me forever... Is there anything we can do about it? --Joalpe (talk) 20:20, 20 September 2019 (UTC)
@Joalpe: its quicker than Help:Gadget-ACDC -- but I think it has the same kind of challenge/opportunity that Quickstatements and other tools have in the Wikidata/Wikibase ecosystem: each edit is done through an API and probably throttled. @Magnus Manske: might be able to speak to that. Sadads (talk) 20:24, 20 September 2019 (UTC)
@Sadads, Magnus Manske, and Joalpe: "Depicts" statements cannot be used by templates, so I can't see the point in adding them right now. That will hopefully change when we can access the information via Lua, but I don't know when that might become available. Thanks. Mike Peel (talk) 21:02, 20 September 2019 (UTC)
Hi Mike: its less about the current utility and more getting a set of data that is useful once we have access to the SPARQL endpoint and tooling like Lua as you mention (both of which are on the SDC roadmap now). Just because we can't exploit it right now, doesn't mean that its useless. Sadads (talk) 21:24, 20 September 2019 (UTC)
This section is resolved and can be archived. If you disagree, replace this template with your comment. Mike Peel (talk) 13:32, 28 September 2019 (UTC)
Error: Lua error in Module:Wikidata_label at line 24: attempt to call method 'getSitelink' (a nil value).
This section is resolved and can be archived. If you disagree, replace this template with your comment. Mike Peel (talk) 14:23, 1 January 2020 (UTC)
Add Petscan link?
What would be great from an editing perspective would be a small link to the petscan query for the category page when the template is on the category (maybe near the upload button). This would make it a lot easier to edit via quickstatements, evaluate the files for other charachterisitcs (I.e. template usage or missing properties) and generate lists of files. Sadads (talk) 09:48, 2 November 2019 (UTC)
Hey @Mike Peel: ! Sure :) Category:Ryan Lavarnway, which can be generated with generate this link. Note the variables that need to be in place are ns =1 (which indicates the namespace for files), project = wikimedia (which gives us the initial project prefix), and language = commons. The categories field gives you the category. All the other url fields that get generated in other spaces are optional, and something you would have to tweak per the application you have for the list. Sadads (talk) 19:59, 4 November 2019 (UTC)
Appears to work :) Thanks! If you could push that into the live template, I am going to be teaching at WikiConference North America this weekend and want to show it to folks :) Sadads (talk) 20:10, 4 November 2019 (UTC)
@Sadads: Sorry for the delay, I was hoping to do one update to the infobox that included the new image code, but that got stalled. I've now done a partial update that adds the petscan link. Thanks. Mike Peel (talk) 15:46, 9 November 2019 (UTC)
How does this relate to Infoboxes particularly? AIUI your boilerplate Petscan query, that would apply to any Category on Commons – no relation to Infoboxes or Wikidata. In which case, wouldn't that be a gadget for the LHS sidebar? Andy Dingley (talk) 17:30, 9 November 2019 (UTC)
You're right, it doesn't depend on Wikidata, but perhaps it makes sense to have it grouped with the other tools in the infobox? Either way, you could do a gadget for the left-hand toolbar. Thanks. Mike Peel (talk) 15:53, 10 November 2019 (UTC)
This section is resolved and can be archived. If you disagree, replace this template with your comment. Mike Peel (talk) 14:22, 1 January 2020 (UTC)
Graphics of chemical compounds
For chemical compounds the most important illustration is usually P117 not P18. Maybe it's possible to add P117 to be displayed if it exists in WD, and P18 if there is no P117? Wostr (talk) 18:42, 27 November 2019 (UTC)
@Wostr: I've implemented it in {{Wikidata Infobox/sandbox}} - P18 will still show by default, but P117 should now also show if it's present. Can you confirm that it shows, or point to an example if there are issues? There's a new image switcher coming soon, so the visual look will change - turn on the infobox gadget in your preferences to see the future version. Thanks. Mike Peel (talk) 19:45, 14 December 2019 (UTC)
Thanks, the structure shows correctly in several categories I've tested. If it's not possible to prioritise P117 over P18, then the current situation P18>P117 is better than not showing P117 at all. There is, however, one issue: if there's P2096 qualifier (image description), both image description and property description are shown (e.g. in Category:Proline that would end with the following description: "structure of proline without indicated stereochemistry /next line/ chemical structure". Wostr (talk) 09:14, 21 December 2019 (UTC)
@Wostr: I've tweaked the logic so that the "chemical structure" label only shows up when image (P18) is also present - it should at least then have a radio button in front of it to mark it separate from the text. Does that look better? Thanks. Mike Peel (talk) 13:31, 21 December 2019 (UTC)
@Aschroet: This one was vandalism, see [12]. It should clear up itself. (I've seen the ones above, but haven't had time to investigate them yet - thanks for reporting them!) Thanks. Mike Peel (talk) 18:07, 9 December 2019 (UTC)
This section is resolved and can be archived. If you disagree, replace this template with your comment. Mike Peel (talk) 14:21, 1 January 2020 (UTC)
Link to search "depicts"
A link to a search with depicts (P180) with the item could be useful.
@Jura1: It's in the sandbox for testing. One issue is what text to display - at the moment it just says "Search depicted" in English, is there a QID that we could use the translated labels from? Also, @Keegan (WMF): , this might be of interest to you. Thanks. Mike Peel (talk) 19:05, 14 December 2019 (UTC)
Useful, except when it's not. When eager editors pile on numerous trivial elements (and let's face it, Wikidata like all Wikimedia projects, tends to often attract people more concerned with intricate details and trivia than common sense), we get unfiltered data vomit as can be seen at Miss Dorothy Quincy Roosevelt by John White Alexander. More famous painting like Washington Crossing the Delaware have somewhat more useful depictions, but an open-ended field will eventually attract more unwanted cruft. I think we should eliminate the data-regurgitation of depicts (P180), and let COM:DEPICTS handle that. Wikicommons is NOT Wikidata. Let's not forget that. --Animalparty (talk) 05:35, 29 December 2019 (UTC)
@Animalparty: I worry about this issue as well - it's an issue on Wikidata, but it could be a lot worse through depicts statements here. On Wikidata, there is one entry for the painting, and you can describe what it depicts once in that entry. Here, however, we might have 10 images of that painting. So for each of those, you can either say "this is that painting", pointing to Wikidata for the information, or you can set 10 copies of the same depicts information locally. Then if you disagrees with the existing depicts statements, you have to do 10x the number of edits to change them. Thanks. Mike Peel (talk) 07:26, 29 December 2019 (UTC)
@Ghouston: thanks, I see you increased the Wikidata rank for this year's value. Would that mean having to modify ranks every year to maintain the currently fixed situation? --HyperGaruda (talk) 17:36, 27 December 2019 (UTC)
I think there's a bot that makes sure that the latest value is set as preferred as well, but I'm not sure why it didn't catch this case... Thanks. Mike Peel (talk) 09:02, 28 December 2019 (UTC)
This section is resolved and can be archived. If you disagree, replace this template with your comment. Mike Peel (talk) 11:02, 19 January 2020 (UTC)
film poster images
Two suggestions here, the first is purely mechanical, the second involves opinions of aesthetics and pertinence. Currently, it appears that infoboxes for films fail to display film poster (P3383), in favor of image (P18). Compare Category:Ace of Cactus Range to Category:North by Northwest (1959 film). I think that in the event a wikidata item has an image for "film poster" but not for "image" (or logo image (P154)) the film poster should be displayed. Secondly, in the event that both "image" and "film poster" have values (see below), I think it would be preferable to display only the poster image, as "image" is often occupied by arbitrary screen grabs, lobby cards, and less exemplary imagery. In this case, "image" would be suppressed if there is a value in film poster (P3383) (especially important when items have the same image for both values, as in House on Haunted Hill (Q263583)). I'm no fan of infobox clutter creep (i.e. increasingly cramming in as many images/values as possible just because they're 'true'), and I certainly don't think we need two or three images displayed per film. One is plenty. --Animalparty (talk) 21:18, 3 January 2020 (UTC)
@Deadstar: This seems to be phab:T244529 - a major cross-wiki issue with labels from Wikidata. Pinging @RexxS: in case there's any debugging that can be done on this side, but I think this is something the devs have to fix (and urgently!). Thanks. Mike Peel (talk) 10:26, 7 February 2020 (UTC)
@Deadstar: It seems to be working again now (see the ticket), but you might need to add "?action=purge" onto the URL to see the correct version. Thanks. Mike Peel (talk) 17:33, 7 February 2020 (UTC)
@Mike Peel and Deadstar: Yeah, it was the label bug. Normally the code looks for a local sitelink (an article on a wikipedia) and uses that (stripping out dab qualifiers, etc.), rather than using the label. It's only for entities that have no Wikipedia article that it falls back to the label, and then the Q-value if there's no label. That's why most values remained unaffected. Cheers --RexxS (talk) 18:21, 7 February 2020 (UTC)
@Mike Peel: Nice, now it keeps the text inside the box. Only thing that annoys me a little is the strict width of the infobox. This cut words last letter to a new line (like Coronavirida-e). Last but not least line-wrapping should be done with hyphenation (-). - Premeditated (talk) 10:42, 19 April 2020 (UTC)
@Premeditated: I'm using css "word-wrap: break-word;", I don't think that supports hyphenation, and I can't change how browsers work. I am tempted to widen the infobox a little, as this does seem to make a good case for that, but it's a balancing act keeping it small enough on the page that it doesn't distract from the media files, while still clearly displaying the most useful info. Thanks. Mike Peel (talk) 11:55, 19 April 2020 (UTC)
This section is resolved and can be archived. If you disagree, replace this template with your comment. Mike Peel (talk) 14:48, 19 April 2020 (UTC)
Category:2019–20 coronavirus outbreak
The infobox template in this category gives a lot of "The time allocated for running scripts has expired" error messages, see this version before the template was removed. Behanzane (talk) 12:47, 9 March 2020 (UTC)
@Behanzane: Thanks for the heads up. It was because there are so many different countries in the item, which take a long time to load. I've added a new limit of up to 10 countries being displayed, and that seems to have resolved this issue. Thanks. Mike Peel (talk) 15:04, 9 March 2020 (UTC)
This section is resolved and can be archived. If you disagree, replace this template with your comment. Mike Peel (talk) 09:55, 19 April 2020 (UTC)
The extra figure disappeared when a warning issue was solved in Wikidata. (Someone had entered a web address as unit, which was an illegal unit.) So perhaps this behaviour of the template was expected. Tomastvivlaren (talk) 20:30, 6 April 2020 (UTC)
This section is resolved and can be archived. If you disagree, replace this template with your comment. Mike Peel (talk) 09:29, 19 April 2020 (UTC)
Imperial unit abbreviations
I noticed on BP-1101A that the abbreviations given for pounds and inches were displayed in the somewhat non-standard characters # and ″, respectively. I don't think this is something being passed by Wikidata, as both of these are marked deprecated. If possible, can these be changed back to "lb" and "in" when displayed here? — Huntster (t@c)17:55, 20 March 2020 (UTC)
@Huntster: @RexxS: I think this needs a tweak in Module:WikidataIB. pound (Q100995) has two values of unit symbol (P5061), one 'preferred' the other 'deprecated', but WikidataIB is somehow using the deprecated one. inch (Q218593) is similar - there are more properties, but the deprecated value is being returned. Minimal code to reproduce: {{wdib|ps=1|P2067|qid=Q88093310 | unitabbr=yes}} -> 10,000 lb, 4,536 kg (should return "10,000 lb, 4,536 kg"), and {{wdib|ps=1|P2048|qid=Q88093310 | unitabbr=yes}} -> 127 in, 322.58 cm (should return "127 in, 322.58 cm") - other languages will differ. Thanks. Mike Peel (talk) 09:52, 19 April 2020 (UTC)
@Huntster and Mike Peel: Good catch, although why on Earth anybody feels those symbols are useful is beyond me. I should have fetched the table of best statements instead of all statements. That's fixed now in Module:WikidataIB/sandbox:
{{wdib/sandbox|ps=1|P2067|qid=Q88093310 | unitabbr=y}} -> 10,000 lb, 4,536 kg
{{wdib/sandbox|ps=1|P2048|qid=Q88093310 | unitabbr=y}} -> 127 in, 322.58 cm
This section is resolved and can be archived. If you disagree, replace this template with your comment. Mike Peel (talk) 16:55, 22 April 2020 (UTC)
Taxon author is buggy
If a taxon in Wikidata has either the taxon author or year of taxon publication specified, Wikidata Infobox outputs "Taxon author: " and whatever data was found, often leading to output such as "Taxon author: 1928". See Category:Phintelloides brunne for example. The template code should make sure that taxon author (P405) is actually specified before creating a "Taxon author:" row in the output. The relevant code can be found in Template:Wikidata Infobox/core around line 769. Kaldari (talk) 18:16, 31 March 2020 (UTC)
A smart solution would be to not display the year if no author is given. An even smarter solution would be to only display surnames (regardless of year), to more accurately reflect common usage: the complete formal scientific name of the spider above is Phintelloides brunne Kanesharatnam & Benjamin, 2019, and pedantry like "Nilani Kanesharatnam, Suresh P. Benjamin 2019" is needlessly precise data cruft. Similarly, if a taxon has three or more authors, the standard form of "Surname et al XXXX" would be preferable to listing lots of names. --Animalparty (talk) 20:02, 31 March 2020 (UTC)
This section is resolved and can be archived. If you disagree, replace this template with your comment. Mike Peel (talk) 16:54, 22 April 2020 (UTC)
Country of registry
For ship categories it would be helpful to display "Country of registry" (P8047) since "Port of registry" can already be shown. Using the "Country" property will render as "Location" in the infobox, which I think is not appropriate as ships can move between countries. So, would it be possible to add P8047 to the list of properties for the box? De728631 (talk) 21:26, 12 April 2020 (UTC)
This section is resolved and can be archived. If you disagree, replace this template with your comment. Mike Peel (talk) 15:02, 10 May 2020 (UTC)
punctuation for aliases
On top each page, below the heading, there is a display of the applicable Wikidata item with its label, description and aliases. Currently, in English, the aliases are separated by a comma (","). This works fine when the aliases doesn't include a comma, but for those with, its somewhat suboptimal. I wonder if another punctuation mark wouldn't work better, e.g. a semi-colon (";").
@Jura1: It’s your common.js subpage that adds it (so most people don’t have this at all); more specifically its third line. You can propose changes on the tool’s talk page. (And if you’re already there, I think you should change importScriptURI to mw.loader.load, as the former is deprecated, and will most probably cease to work at some point.) —Tacsipacsi (talk) 21:14, 23 April 2020 (UTC)
Thanks, I had forgotten about that. I had looked at my gadgets ;) . In that case I can fix it myself. Jura1 (talk) 10:44, 26 April 2020 (UTC)
This section is resolved and can be archived. If you disagree, replace this template with your comment. Mike Peel (talk) 15:01, 10 May 2020 (UTC)
Template shows strange text on category pages
Since today this template shows strange text on category pages, i.e. on Category:Real-time clocks: "Realtimeklok
ساعت بلادرنگ Realtidsklocka 실시간 시계 Echtzeituhr リアルタイムクロック Gerçek zamanlı saat Real-time clock 實時時鐘 Rellotge de temps real Reaalajakell Нақты уақыт сағаты Horloge temps réel Часы реального времени Reloj en tiempo real Zegar czasu rzeczywistego Годинник реального часу Hodiny reálného času Hodiny reálneho času Đồng hồ thời gian thực Jam Waktu Nyata Relógio de tempo real Real-time clock "
Either related to a change to this template/Lua modules or the the last deployment of MediaWiki today to release 1.35.0-wmf.30? Raymond18:54, 29 April 2020 (UTC)
This section is resolved and can be archived. If you disagree, replace this template with your comment. Mike Peel (talk) 15:01, 10 May 2020 (UTC)
Only label shown
I'm not sure if this is the right place for the issue. Currently I'll see sometimes only the Q-Label in the infobox and not the acronym of the something behind. Have a look here. It shows Q10454 and not as expected "Landkreis Ansbach". thx for checking. --Derzno (talk) 05:36, 7 May 2020 (UTC)
@Derzno and VIGNERON: phab:T252079, it should be fixed now but caching will take a time to refresh. If there are any cases that urgently need refreshing, let me know and I'll run through them making null edits. Thanks. Mike Peel (talk)
The coordinates on Wikidata are correct (and with the correct precision AFAIK) but the display on Commons of the *same* coordinates is wrong somehow (around 100 meters too far south).
@VIGNERON: It seems to be a precision issue - it's manually set to 0.1° on Wikidata. Trying to manually change that to 1 arcsecond, the map on Wikidata matches the one shown here. I've re-imported the coordinates from frwp to Wikidata, and they should display correctly now. [15]. Thanks. Mike Peel (talk) 07:25, 7 May 2020 (UTC)
This section is resolved and can be archived. If you disagree, replace this template with your comment. Mike Peel (talk) 14:58, 10 May 2020 (UTC)
Severe problems with Infoboxes and Wikidata queries
Since the introduction of recursive infoboxes, there are massive amounts of Lua script errors (time exhauted), and TONS of false autocategorization everywhere.
I repeat what I said to the author of this change : DO NOT RECURSE DOWN into related topics to generate ANY recursive infobox, IF the related topics (lsited at top of the main infobox) ALREADY have a link where they point to the relevant page with the SAME infos.
This change made this wiki incredibly slow foor every update, and is now causing severe degradation of performance and generate a huge load on servers.
Such recursive infoboxes are just duplicating info that is available ON REQUEST of visitors by just following the links displayed in the related topics. We don't need such repetition.
As well almost all these recursive infoboxes are now autocategorizing pages (but with wrong sort keys) and frequently the scripts terminate by an error causing a test for membership not being performed correctly. Tests for existences (which are very costly on the server) for example will be wrong and will cause a page to be categorized even with the scripting error (which is not detected at all).
This change now makes many categories to have random contents collected everywhere. Many become overpopulated with these false categorization.
PLEASE REMOVE these unnecessary recursive infoboxes. And in all cases (if a recursive infobox is still used, because the related topics have no links to a relevant page showing thir own infobox), the autotocategorization of subinfoboxes should ALWAYS be disabled).
This is now dramatic on this site: If the author does not want to do that to remove the subinfoboxes, I will once again disable this change for all subinfoboxes (unconditionnally).
Note that there's also a dramatic slowdown in Lua scripting, and another major issue where {{Label}} now uses more than 7MB of memory (a severe new bug in Module:Wikidata) plus about 3-5 MB for each other label added, so many pages now have other errors (because the Lua memory usage is limited to 50MB for redering each page). The maintainers of Module:Wikiata should really monitor their memory usage.
@Verdy p: If you want to be constructive here, please stage your edits in the sandbox so that they can be tested before they go live. I try to keep the number of edits to the template to a minimum, as invalidating the cache of ~3 million categories probably shouldn't be done too often for performance reasons (ironically here!). Issues are being fixed as they are raised, if you can point out more examples then I can look into them. Better if you can help investigate and make things more efficient (in the sandbox again!), as that would be really useful. However, saying things like "I will once again disable this change for all subinfoboxes (unconditionnally)" is not useful nor welcome. Thanks. Mike Peel (talk) 18:02, 11 May 2020 (UTC)
You are not using the sandbox yourself to make tests for your changes. It's a fact that you've severaly degraded this site with tons of errors and severe degradation of performance
This is visible for everyone. You are not constructive because you insist in doing these recursive infoboxes when they are in fact almost never needed (this is jsut duplicating info by copying again and again to tons of unrelated pages, including importing all their categories (that should have never occured), breaking many categories and causing lot of server damages on millions of unrelated categories. Your edits with recursive infoboxes have created this huge maintenance cost everywhere (with millions pages affected and invalidated in the cache).
So apply all what you ordered me here to yourself. I've not made edits that caused these millions pages being invalidated (and then never refreshed later even after errors that this "feature" introduced). You have invalidated millions of pages, many of them broken now.
So I repeat what I said: DO NOT RECURSE DOWN ANY sub-infobox for related topics are already **linked** at top of the box (that link is enough)! This is absolutely never useful, always undesirable pollution, it generated considerable maintenance cost, and this basic rule is simple to apply and will dramatically reduce the damages. verdy_p (talk) 00:29, 12 May 2020 (UTC)
@Verdy p: Every change I make goes in the sandbox first, just look at the histories and the number of times it says 'sync from sandbox'. I'm handling errors as they are pointed out - if you are aware of currently live ones, please point them out and I'll investigate them. You clearly have a strong opinion here, but I think that the recursion is useful in quite a few categories, as a random example, see Category:Milwaukee Clipper (ship, 1905) and Category:IMO 5235375, or Category:Buildings by Elissa Aalto. It definitely needs improvements, though, which we can make incrementally. Thanks. Mike Peel (talk) 07:01, 12 May 2020 (UTC)
No I disagree, for example: the link to Elissa Aalto is self-sufficient, it shows all the details in its own infobox (which is alsu available on hovering if you have enabled this option) without needing to be repeated (and importing false categories about herself and not about some creations she made, which should neve rinherit things, like the place of birth/schools/death or her related family members or other creations she got: there are lot of information about people, there's no need to reimport them each time a person is named).
The same is true for the ship. There are lot of cases where categories are imported incorrectly, and in fact this is unncessary and very costly (as you've seen with all the details about countries, or major sports events, and even about famous people, or large topics with lot of details like vehicles). We don't need that in articles: for details we just lik to the related articles (when they exist) and want to keep things short and simple to read (and there's no risk of ambiguity as the link is there to disambiguate everything).
So again I ask you remove these subinfoboxes for related topics (notably here because there can be several ones, each with their own details) if and only if these topics have a relevant link to their own category (which has its own infoboxes for details) already listed at near the top of the infobox. verdy_p (talk) 07:43, 12 May 2020 (UTC)
Performance questions
The extra information can be nice, but there can also be too high a cost, which I think it is at the moment. A few comments:
The Category:Milwaukee Clipper (ship, 1905) page, when I go to edit it, is taking roughly 4.9 to 5.0 *seconds* of *CPU time*, and over five seconds real time, to render. That number is down from 7ish seconds due to a change made per an earlier discussion here, which is great, but not nearly enough. If I disable the infobox template by deleting the first brace character, leaving everything else there, it now takes 0.06-0.07 seconds of CPU time, and 0.1 - 0.14 seconds real time to load. That is fast, and most categories are a bit faster than that (under 0.05 seconds CPU, under 0.1 real).
A website's loading time is pretty critical. Once you get above a second to render a page, you can start losing users, more after two seconds, and it's very bad after three. Just doing a google search there is this document, which has several quotes giving various opinions of exactly where it becomes a problem. And it is apparently a factor in Google's site ranking.
For the Wikidata Infobox template to take 5 seconds all to itself is singlehandedly taking Commons from a very fast website to an egregiously slow one, at least on pages where the template appears. I would guess image pages are the most common and are unaffected, but browsing category pages has become much worse anywhere this template exists. If cached it's OK, but any time the template is changed, or any time files or categories are added or removed from a given category, it will need to be re-rendered. And those pages are now painful if not recently cached.
For people donating their time to categorizing stuff and managing categories, the penalty is now on every "preview" click as well. It's either taking away their time, or reducing the amount of work they can get done in a given time.
I do like a lot of the extra information provided, but if the cost is this high, it's not worth it. I would imagine you will get some arguments against particular data being shown, when the real frustration is the performance. If that can be made acceptable, then the information shown becomes a function of screen space really, and more information if not losing significant performance) is usually better.
Frankly, a full second of CPU time is an *enormous* amount of processing. Even for a complex template, it seems to me it shouldn't be anywhere near there -- I can't remember other templates anywhere near that performance cost. Something seems really wrong, either some pathological template or Lua code doing way more work than is being realized, or a database index is broken, or something. I really don't know the architecture at all or where the performance problem could be. It's possible there is a quick solution, but I have no real idea.
If you get the CPU time down to 0.1 seconds, which would be a tripling of the CPU time for pages without the template, that should be fine. Somewhere between there and 0.5 seconds is probably the point where it's not worth it, and it's time to cut functionality out until the performance can be improved. The current five seconds is far, far beyond that -- I'm finding I have to disable the template if I want to use the "preview" button like I'm used to. And sometimes I may forget to re-enable it. I don't know if the excessive CPU usage is causing server problems or not, but it's definitely causing editing and viewing problems.
The template has been around for quite a while, and is very cool -- it's only recently (maybe the last month or two) that something changed and it started taking far, far longer to render than it used to. I have no idea what changes were made to potentially cause that. I definitely like the template and would prefer for the performance to be fixed rather than losing information, but the extra info is certainly not 100x more valuable than the actual category contents which I'm trying to see, and is not worth 100x the rendering time it's currently taking.
In short, would definitely like to know what options there are -- if this recursion is the problem, and disabling it gets the template to at least under a second and preferably closer to a tenth of a second, maybe that would work for now until a way can be devised to make the recursive feature performant. Or maybe the problem is elsewhere, but could experiments be made to see how to drastically reduce the render time? Carl Lindberg (talk) 12:17, 12 May 2020 (UTC)
@Mike Peel: I was just debugging the reason why Category:Pages with script errors takes so long to respond and come to the same conclusion Carl Lindberg just made: It takes 6.9 s to load with {{Wikidata Infobox}} and 0.07 seconds without. 6.9 seconds is way too long, and people will begin to remove those templates. We had issues like this in the past where some people were manually adding creator templates to files while others were removing them with bots because they had some categorization issue. It was very unpleasant. I think we can give up some functionality to speed this template up. --Jarekt (talk) 18:26, 12 May 2020 (UTC)
OK, I'm really busy this week (literally going up and down a mountain each day for work), but I can look into this in more detail over the weekend. If you're interested in helping, then please try things out in the sandbox. @RexxS: One thing in particular might help, in Module:WikidataIB around line 650, Commons category (P373) is always fetched, could that logic be changed so that if the commons sitelink is available then that is used, and only if it's not available is Commons category (P373) checked? Or better, just remove Commons category (P373) support now that we're over the critical mass of sitelinks. Thanks. Mike Peel (talk) 06:31, 13 May 2020 (UTC)
I tried disabling the SEO, the checks and the categories, which made only a small improvement. I tried disabling the location field, which again did very little.
I restored all of those and tried moving the getQid call to the main template from the core. Removing 586 redundant calls sped things up a bit, but it is still not enough. You can see the changed coding for that in the two template sandboxes. I'll have another look tomorrow if I can. --RexxS (talk) 14:22, 13 May 2020 (UTC)
@RexxS: As a thought, is there a cheap way to retrieve a list of all properties that are set in a Wikidata item? If so, a function that retrieves those, and returns a list of them ("P18,P31,P276,...") that could be passed into the infobox core as a variable, along the same lines as suppressfields (but as a whitelist rather than a blacklist) might reduce the number of checks that need to be made while the infobox is being assembled. Thanks. Mike Peel (talk) 17:14, 15 May 2020 (UTC)
@Mike Peel: No. That would simply call getEntity() as we used to do before getBestStatements() was implemented. Loading the entire entity and then scanning through it for properties that exist completely defeats the savings of using getBestStatements(). If you really want to go down the path of removing the overhead of multiple module calls, then you need to write the entire infobox in Lua. That's perfectly possible, but begs the question of what order you would use for the fields in the infobox? Also how many maintainers would we have for an all-Lua version? --RexxS (talk) 18:45, 15 May 2020 (UTC)
@RexxS: Perhaps we could ask the developers for a Lua call that returns the list of properties without having to resort to getEntity? But perhaps the best approach is to switch to Lua completely - since your Lua course at Wikimania Stockholm I've been picking up various bits of Lua while writing Module:Wikidata Infobox, but switching completely would still be complex. The main issue I think I'd have is the passing of frames to WikidataIB - see the 'formatLine' function in Module:Wikidata_Infobox/sandbox - is there a simpler way to do that? Thanks. Mike Peel (talk) 18:57, 15 May 2020 (UTC)
Yes, Mike. The new infobox would be based on the code in Module:Infobox and Module:WikidataIB, but at the top level, it would simply load the entire entity once, and then loop through all of its statements to generate each html row of the infobox, presumably using the property label as the field name (although you could have a table of substitutions if required); each row's value would then be the call to Wikidata. You'd have to fix some exception cases like the image and caption, and statements that we don't use like instance of (P31), but essentially it would only require a single call to generate the infobox. The only thing in that frame would be the qid (and perhaps fwd and spf if they were to be implemented). The question of sourcing and osd is something to think about. --RexxS (talk) 19:13, 15 May 2020 (UTC)
There are known causes for this lack of speed:
the major reason in the Wikibase interface in PHP which lacks functionality to efficiently filter just the properties we want (all properties are retrieved), just the qualifiers we want (all qualifiers are loaded), as well as filter for labels/descriptions we want (too many languages, and we don't care at all about retrieving aliases, only useful in Wikidata), as well as sitelinks (too many site codes for unneeded languages, note that sitecodes for lovalized projects group languages differently, they use interwiki codes and group several distinct languages not using the same BCP47 code as for labels/descriptions/aliases and monolingualtexts). And the JSON returned is MUCH too verbose with lot of redundancy. Wikibase should have a much more efficient way to be quiries instead of using "mw.wikibase.getEntity()" which is very costly, has very badly tuned caches (15 entities are fully cached even if we don't need them completely, but this is still not enough for infoboxes showing more than 15 entities: there are repeated queries to Wikidata for the same entities, which takes a long time; additionally there's a cache for only 50 properties which are also kept entirely with all their own entity data, so we end up with up to 65 entities in memory, using lot of memory, up to 7MB, sometimes even more).
Wikibase does not properly intern many Lua strings (this is a limitation of Lua) and many Lua tables have overlong collision lists (also a bug of Lua, with inefficient hashing)
Wikibase returns a lot of unnecessary metadata; the entities in caches are not kept with weak references (so we get "out of memory" errors): memory is incorrectly managed in Wikibase.
Really we need better and faster way to retrieve more selectively the data we want (probably using by queries by RDF triples, using SPARQL, but without any internal cache in this interface, and with a JSON output that is much better filtered).
Several algorithms in Wikibase and in the Module:Wikidata are very inefficient, using slow lookups. There are ways to improve it, but the current Module:Wikibase is wrong, and Module:WikibaseIB is not really much better because it also keeps too much data in memory (then there's also a huge activity of the garbage collector because it uses really too many intermediate objects for various string operations or conversions, plus a very inefficient sort algorithm, which can also reload entities being compared but that are no longer in the Wikibase cache: the big JSON from aech query is reparsed again and again for the same entities).
The topologic sort algorithm (for tree-like data, even if they contain loops that can be detected) is also very inefficient (there's absolutely no need to "mark" items with additional tables, in fact this sort can be made in a single visit pass in sequential order without even having to madify the traversed nodes in trees). I've rewritten this algo in a much faster way, using much less memory (only an map of entity ids to entity is sufficient; there's no need to add data for rank in the tree, no recursion, all visits can be made in a single loop: it can be implemented as a simple forward iterator, so no second pass is even needed to format the topologically ordered items; it's even possible to use the iterators in Lua and return to the wiki parser that can recall Lua later with the iterator keeping its progress state: most formatting should be done outside Lua, because the wiki parser is more efficient and has better memory management for processsing templates and non-costly parser functions: a Lua call can be costly and notably Lua calls that use mw.wikibase queries).
May be the alternative would be to not use Lua for Infoboxes, but use a custom parser function written directly in "native" PHP (PHP is compiled, unlike Lua which uses a VM for interpreting bytecode and which has numerous memory management issues, very inefficient hash tables, inefficient string hashing functions, very poor garbage collection, inefficient management of the pool of unmutable strings) and that would build a single selective SPARQL query not requiring any cache of full entities. verdy_p (talk) 02:19, 22 May 2020 (UTC)
Note: as long as getEntity() can only load full entities, we'll have a problem. We should be able to first build the query we need for all the useful properties/qualifiers/labels/languages, and retrieve only those, then a pass to eliminate conditional properties, before even starting to format everything. verdy_p (talk) 02:25, 22 May 2020 (UTC)
But presumably those issues have been there all along -- I don't recall this extreme slowness with earlier versions of the template. Would it be possible to try out older versions of the template (maybe in a sandbox with a test page), to try and narrow down which edits caused the performance to drop? I.e. see if the template as of mid-January is much faster, then keep iterating halfway between the earliest known slow version and the latest known fast version to see when the problematic edits are. If identified, perhaps those edits could be reverted until a much (*much*) faster way of obtaining that functionality can be found (which may indeed involve solving some of the issues that Verdy p is discussing). Carl Lindberg (talk) 18:58, 29 May 2020 (UTC)
@Clindberg: Feel free to experiment with the sandbox. RexxS and I have been trying various things, and it is now faster, but not as fast as you'd like. If you can point to specific things that are slowing things down in general (aside from the subinfoboxes), that would be useful to know. Thanks. Mike Peel (talk) 20:19, 29 May 2020 (UTC)
Removing categories
@Mike Peel: : the categories that I removed from the core are fake almost always, never needed. They are only for specific categories (year numbers) that are categorized directly by their own template, separately from the infobox, without even performing any Wikidata query: they are resolved algorithmically and locally). These additional entries in Infobox just create lot of unneeded overhead, and frequent errorsn with fake entries added in these autocategories by year type or by month.
I did not need any sandbox to remove them directly, there was absolutely no degradation of functionality. And their cost is too expensive for all other unrelated pages (infobox/core needs serious optimization, it takes really too much time now, and lot of ressources on server, increased now by multiple subinfoboxes which were also added, multiplying the cost by several factors). Did you even notice any problem with this removal ? Did you ever look at pages with script errors (almost always by categories incorrectly listed as if they were years). We never need such autocategorization for years, all Gregorian years (and months) are categorized dirctly by their own template, with much lower cost. No need to add this for all other categories or pages that have an infobox. Additionally the names of the target categories are clearly wrong and are about to change.
@Verdy p: @Pigsonthewing: requested their addition, and they shouldn't take up much processing power. What you did was remove a symptom, not a cause. My plan was to move those higher up in the template code if necessary. In general, the way the development of this template works is that things are discussed here, sandboxed, then deployed in a batch to avoid invalidating cache too often. I've upped the page protection to admin-only edits to enforce that for now, although it hasn't been a problem until now... Thanks. Mike Peel (talk) 16:39, 15 May 2020 (UTC)
So what we need now to fix:
Lua needs to have its hash tables fixed (notably for all string keys): they don't work as intended (as a "fast hashed" access), and we've reached a point where the worst case is reached with most lookups for keys used in Wikidata JSON queries are only found by long scans over many nodes (the access time is then proportional to the total number of items in the table! This is no longer a fast hashed table access! Be careful with Lua tables using string keys, and notably any global "hashtable" used for string interning, supposed to save memory but which is very slow with all these scans caused by overlong collision chains, and a very inefficient internal representation of collision chains using additional storage for chaining "next" pointer in every table node!).
We need a better more compact representation of JSON query data: there's lot of unnecessary duplication of language codes associated to translated labels/aliases/descriptions, requiring the creation of an additional subtable for only these two items, even if these subtables are values for a specific language (the same) or values in an integer-indexed ordered table used as value for the same language. This is a defect of the current JSON query format (and JSON deserialization in Lua uses way too much memory, especially when loading the full data for a full item). For that we need a new query format (not the current JSON model which is very inefficient and really too much verbose, with overlong desrialization using lot of memory in Lua).
We need probably new more selective queries supported by Wikibase/Wikidata to load specific properties, and not the full set of properties with all their qualifiers (using an internal case in Modulewikidata will not solve the problem, everything is still loaded, in inefficient tables indexed by strings with lot of collisions and very slow lookup using scans of long chains).
Seriously, did I make something damageable ???? Consider removing these unnecessary lines in Infoxbox/core given they are never needed, produce lot of fake categorizations (caused by internal memory limits in Lua script), and removing it saves CPU time everywhere (in the wiki parser for templates). Infobox/core template is dramatically too complex and performs really tooo many Wikidata queries (and Module:Wikidata itself has severe performance problems as it is not selecvtive enough about the data it loads from the server). verdy_p (talk) 16:45, 15 May 2020 (UTC)
It's not a question of "performance" (though it is still true) but memory usage. And definitely this template is too huge. Adding these categories also counts on the number of Wikidata queries performed on ALL pages using infoboxes, and there are still many that experience memorey exhaustion. We can save many unneeded queries and template expansion time on tons of pages that never need these categorizations: these subcategories are jsut for specific categories pages which are ALREADY categorized by their dedicated navbox, without performing any query and not depending at all with Wikidata.
In addition this blocks the renming of these categories (which are named only for their starting day ignoring the fact they are also categorizing the ending days and in fact every date in these years (or months). They are clearly not needed, we don't need the infobox to properly categorize these years and months.
Any way to reduce the cost of infobox by being more selective is a win (and clearly the infobox core is now really slow, and its cost on everypage must absolutely be reduced): 6-7 seconds per page is much too high, the server is now extrmely busy and cannot even refresh the pages correctly: it's busy 100% of the CPU, everyday, at all hours, only because of it (and notably since the introduction of subinfoboxes that were not even needed but added without any form of discussion, causing lot of errors and false categorizations everywhere).
You've not properly used the sandbox, and not thought at all if they were really needed (they are absolutely not needed in ANY of the relevant categories to which they would apply: this is duplicate work, and these also don't properly set the correct sort key, which is correct in the dedicated year and month navboxes).
So you reject my edit which is perfectly safe and goes in the right direction. But really harmful additions that were added without prior talk or any evaluation on a limited set of pages (using a sandbox version only for a subset of categories instead of being applied unconditionally everywhere) have been kept, causing major damages: the sandbox is not used as it should be: it's not intended to test a single page or preview, its effect mist be analyzed on a significant **subset** of real pages and NOT all pages using it (just to see some days laters tons of errors spread everywhere). verdy_p (talk) 06:01, 16 May 2020 (UTC)
verdy_p, It is not OK to be "improving" templates and modules actively maintained by other users, without discussing the proposed changes first and arranging best time to release the changes. You have made twice, without prior discussion, seemingly unnecessary changes to Module:Wikidata label altering 14M pages for unknown reasons. Now you are "fixing" this template against the wishes of its maintainers. I see you just got template editor rights (given to you by User:Magog the Ogre) allowing you to edit highly used templates and modules. That right is usually given to individuals trusted by the community to know and follow rules and traditions of this project. Please follow those rules and traditions or you will loose the template editor right. --Jarekt (talk) 04:17, 18 May 2020 (UTC)
Why the quotes around "improving". I explained above what I did. These were real needs (and related to other talks elsewhere). These were tested first and also after.
This huge template has lot of performance problems and what I did could certainly not hurt except going to the correct direction by a small step. verdy_p (talk) 07:23, 18 May 2020 (UTC)
The "wishes of maintainers " is not a policy. Everyone modifies what other are doing in any wiki, and improves what he thinks appropriate. Only when there are diagreement, there can be discussions. Thanks all Wikimedia wikis are not the property of the initial creator of any page. And Many things I've done have been later modified by others (including templates I create here). Ther is no express "wishes" from authors except the general consensus that these should not break the work of all others (like this Infobox/core now does to everyone, with its huge performance and resource usage problem that affects EVERYONE (and that I modestly wanted to fix as I explained you).
But visibly you continue ignoring all explications and want to keep the bad performances experiences by everyone, and continue to steal massive server ressources by repetedly adding more and more complication and more costs instead of fixing what is now a major problem. You have made repeated edits that have affected millions of pages on this wiki many times (and the server still cannot follow the speed of these additions, most pages are now outdated, and this site has never been as slow as it is today, and this continues to be worse and worse other time).
Can't you make a pause and start profiling this template and cleanup what is not even needed (like these lines that modestly remove things that are not even not needed but that also block other corrections discussed elsewhere). The problem of false cvategorization continues constantly, jut like the number of pages tracked with script errors.
The addition of subinfobox was not discussed and tested, still it has been applied massively (even if it is broken and made the situation very bad for everyone). I do not trust the initial maintainers that constantly want to add more and more compelxity and cost at huge price for servers and for all visitors).
So even if optimizations and removal of unneeded parts are modest, they are a step for a solution that must be progressively made: this goes with small things that you consider minor, but give nthe current costs, winning a bit somewhere is still benificial as there remains little or no ressources for any progress. Initial maintainers don't always have the best solution, they propose something, that can be improved, because they've not seen everything. And I've NOT broken anything in terms of functionality by removing only something that was completely unneeded but just adding more problems. verdy_p (talk) 09:57, 20 May 2020 (UTC)
@Jeff G.: Which browser are you using, please? In Firefox on a Mac, I see it at 206px × 250px pixels, which is the same aspect ratio (82%) as the original. Thanks. Mike Peel (talk) 16:40, 24 July 2020 (UTC)
@Mike Peel: Ok, sorry, I didn't realize you had changed something. It looks the same on both browsers on my iPad, but looks fine in Chrome 83.0.4103.116 (Official Build) (64-bit) (cohort: Stable) on my Windows 10 laptop. — Jeff G. ツ please ping or talk to me17:46, 24 July 2020 (UTC)
Thanks. @Verdy p: The changes I undid in the sandbox were your edits to the stylesheet, would you be able to have a look and see what's happening here please? Thanks. Mike Peel (talk) 17:52, 24 July 2020 (UTC)
Oops, it seems I missed that whole discussion. I'll try to look at this again tomorrow (I have other things I want to get on with this evening) to see if I can figure it out. Thanks. Mike Peel (talk) 18:42, 24 July 2020 (UTC)
I think it would be helpful to start adding the category Built in country (P17) in inception (P571) automatically if the value is supplied in Wikidata and at least contains a year value (without any uncertainty qualifiers). Would save a lot of work adding information to Commons that is readily available on Wikidata (with the option to also properly reference the year of construction, which is not the case on Commons right now). Cheers, Braveheart (talk) 22:50, 30 June 2021 (UTC)
inception (P571) is not only for things that are built. For example, an institution/company or a settlement can well have this property, but New York City (Q60) was not built in the US in 1624/1626 (and not only because the US hasn’t existed yet back then); Samsung (Q20716) was not built in South Korea in 1938 etc. —Tacsipacsi (talk) 22:58, 30 June 2021 (UTC)
Don't think this makes sense outside of buildings anyway, sorry if that wasn't clear. The commons categories "built in xyz in 123" should relate to current day countries, otherwise you get into a real muddle. Braveheart (talk) 11:27, 1 July 2021 (UTC)
@Mike Peel: I tested it for Category:Charles Bridge and Category:Bridge in Lékařova Lhota and the output is not visible in the output of the infobox. Btw., this property is not an unique identifier linked to any register but rather a supplement or substitute for the bridge name, i.e. it should be rather in the head of the infobox beside (below) the bridge name and label, than in the foot among "authorities". --ŠJů (talk) 13:37, 24 July 2021 (UTC)
@ŠJů: Sorry, it was displaying the wrong label, now fixed. I put it just below location, I can move it to elsewhere in the infobox if you'd prefer. Thanks. Mike Peel (talk) 13:47, 24 July 2021 (UTC)
OK, I'll leave this in the sandbox for now, after I've implemented a few other changes I'll deploy them as a batch. Thanks. Mike Peel (talk) 14:41, 24 July 2021 (UTC)
I would like to see Mapy.cz ID (P8988) link in the infobox. This POI identifier is widely used especially for Czech localizable items and it is useful to see at a glance whether this entry is filled out in Wikidata (and it enables also direct leap to that on-line map). If some other notable online maps have similar POIs as properties in Wikidata, their links could be in the infobox as well (is OpenStreetMap relation ID (P402) implemented already?). If Mapy.cz ID (P8988) string (value) starts with "osm&", than OpenStreetMap relation ID (P402) is derrivable from that value. (Google Map probably has not linkable POIs).
This seemed to come from the sandbox version of the template which was used in the category. I removed the infobox template there so the category should work again. De728631 (talk) 12:31, 20 August 2021 (UTC)
The template presents a link to wikipedia about the subject, but no link to other projects (wikibooks, wikiversity, wikisource, ...).
Why only wikipedia ?
@DavidL and Crazy1880: Sorry for the delay. I think the code you suggest is good, except it copies existing checks a bit too much. I've implemented this (copy-pasting the existing code and then tweaking it, so it might not exactly match your code) at [16], please double-check it, I'll deploy it soon. Thanks. Mike Peel (talk) 19:39, 26 December 2021 (UTC)
Moin Mike Peel, no problem for the delay. Could it be, that I see in your Diff that you added wikibooks two times? And what will we do with wikinews and wikiversity? Regards --Crazy1880 (talk) 19:44, 26 December 2021 (UTC)
feels a bit lonely.
Comment Nah. I "semi"withdraw the proposal, since category contains (P4224) is apparently the way-to-go with regard to describing categories in Wikidata. Strakhov (talk) 13:16, 11 October 2018 (UTC)
This section is resolved and can be archived. If you disagree, replace this template with your comment. Crazy1880 (talk) 08:03, 23 June 2019 (UTC) 
Done and re-submitted the job. Let's see how it goes --Zhuyifei1999 (talk) 09:11, 5 January 2019 (UTC)
Should film infoboxes display this?
or this?
.jpg)
