[00:50:01] This call will retrieve the labels in 4 specific languages for the item for Chicago: (re @u99of9: Can you please send an example of an API call for multiple specific language labels on a single item? I briefly looked at the RE...) [00:54:38] The relevant Wikidata API documentation is at https://www.wikidata.org/w/api.php?action=help&modules=wbgetentities, [00:54:39] specifically the "languages" and "props" parameters. [01:08:53] Thanks. Here's an example where the order requested is not the order returned. Would it be worth asking to consider fixing this at the API level? https://www.wikidata.org/w/api.php?action=wbgetentities&format=json&ids=Q30&props=labels&languages=it|en (re @David: This call will retrieve the labels in 4 specific languages for the item for Chicago: [01:08:54] https://www.wikidata.org/w/api.php?action=w...) [01:14:57] IMHO no. I’m not sure about the context of T411865, but in the context of this API request, the order should be irrelevant (re @u99of9: Thanks. Here's an example where the order requested is not the order returned. Would it be worth asking to consider fixing this ...) [01:16:09] (the task seems to be suggesting that Z12 is inherently ordered? I don’t think I would agree with that either tbh) [01:16:53] When you say "should be", do you mean because that's the current spec, or because that's the most efficient? (re @lucaswerkmeister: IMHO no. I’m not sure about the context of T411865, but in the context of this API request, the order should be irrelevant) [01:18:38] Yes, by feeding in an ordered list of fallback languages, we get a Z12 that has some different order. It would be more efficient not to have to re-sort. (re @lucaswerkmeister: (the task seems to be suggesting that Z12 is inherently ordered? I don’t think I would agree with that either tbh)) [01:19:14] I don’t think hiding the re-sorting somewhere else in the call makes it more efficient ;) [01:21:25] Okay, done. Thanks for the test! (re @Al: It would be nice if someone could connect Z30244 to Z6820, David) [01:22:01] I can’t think of any Action API module where the order of keys in a returned object is significant – if it was, I think it would be a problem because some languages don’t even let you observe the order of the keys (it may be reordered by whichever hash table implementation is used) (re @u99of9: When you say "should be", do you mean because that's the current [01:22:01] spec, or becaus [01:22:01] e that's the most efficient?) [01:22:03] I'm not familiar enough with how the API gets its results in the first place. I can imagine possibilities where it would be. (re @lucaswerkmeister: I don’t think hiding the re-sorting somewhere else in the call makes it more efficient ;)) [01:22:22] see also the `"index"` property in the response for this API request for search results (https://en.wikipedia.org/w/api.php?action=query&generator=search&gsrsearch=Test&gsrlimit=5) [01:33:35] Returning the index would be almost as good, especially when we're only interested in the best fallback label. But it is hard to see that coming through the fetch function in a digestible way. (re @lucaswerkmeister: see also the "index" property in the response for this API request for search results) [01:36:50] if you're interested in fallbacks then I should mention the `languagefallback` parameter – it's much better to ask Wikibase for one label and let it evaluate the fallback chain itself than ask it for several labels and try to do it on your own, e.g. [01:36:50] https://www.wikidata.org/w/api.php?action=wbgetentities&format=json&ids=Q1297&props=labels&languages=simple&languagefallback=1 [01:37:07] (not sure if this applies in this case but it should be generally useful) [01:37:42] Another alternative would be to send a flag indicating whether it was required to do the extra work of order-preserving or not (re @David: Thanks for raising this and for making the ticket. It was not intended that the result would preserve the requested order of la...) [01:40:43] Yes that would be another useful flag in David's selective fetch. (re @lucaswerkmeister: if you're interested in fallbacks then I should mention the languagefallback parameter – it's much better to ask Wikibase for on...) [09:28:06] what do you all think of the idea on the project chat: https://www.wikifunctions.org/wiki/Wikifunctions:Project_chat#Wikifunctions_and_the_Abstract_Language_/_functions_helping ? [10:41:23] do we have an equivalent rest api endpoint? (re @David: This call will retrieve the labels in 4 specific languages for the item for Chicago: [10:41:24] https://www.wikidata.org/w/api.php?action=w...) [11:49:03] I note T411947 and will comment there in due course. The problem with testing Wikidata functions is that we are generally prevented from directly constructing an object for comparison. Statements are an exception, but with partial entities now being available via Z6820, we really ought to be able to construct an object representing the precise expectation. We can create [11:49:03] emulator [11:49:04] functions, and that may well be the best way forward. For background, though, Z23723 was originally created to provide constraints over Z6003K1, building on Z23694. One feature that would help here is the ability to specify a (degenerate) function call to a specific function within a function specification. In this case, a required call to Z23694 (with no arguments [11:49:05] provided) as t [11:49:06] he first argument to Z23723 (instead of the first two argument “lists”, which currently provide rudimentary support for mutual exclusivity). (re @David: So AIUI these 2 issues have turned up when comparing statements: [11:49:07] (1) Sometimes enum instances are represented with type + identi...) [14:09:47] Thanks for connecting! I’ve also added Z30315 confirming full-item equivalence. [14:36:05] Pop up to Uncle George, why don’t you. I was heading there after lunch, before Sherilyn hour. [14:36:45] Wrong chat? (re @Al: Pop up to Uncle George, why don’t you. I was heading there after lunch, before Sherilyn hour.) [15:00:08] Meant for someone else? (re @Al: Pop up to Uncle George, why don’t you. I was heading there after lunch, before Sherilyn hour.) [15:01:13] Yes, indeed. Sorry! (re @u99of9: Meant for someone else?) [19:24:19] I'm not that familiar with language-fallback capabilities. (For one thing, I'm wondering if Wikidata's notion of language-fallback is the same as Wikifunctions' notion.) Would this additional flag solve the problem that motivates the desire for preserving the order of languages in the result of Z6820? (re @u99of9: Yes that would be another useful flag in David's [19:24:19] selective fetch [19:24:19] . But without that we have already had to set up ways to do it o...) [23:33:26] Once challenge for us is that we recognize more languages and variants than Wikidata does. So, for example Australian-English en-au is not dealt with in the API as well as we are able to directly: https://www.wikidata.org/w/api.php?action=wbgetentities&format=json&ids=Q1297&props=labels&languages=en-au&languagefallback=1 (re @lucaswerkmeister: if you're interested in [23:33:26] fallbacks th [23:33:27] en I should mention the languagefallback parameter – it's much better to ask Wikibase for on...)