[00:42:01] How about: [00:42:01] If a function specifies an output list type (other than Z1), mismatched elements cause an error. [00:42:03] If all elements in an output list share a type, the list takes that type instead of being Z1. [00:42:04] If an implementation does not need converted values, you can use _untype a list_ (Z17895) to convert a properly typed list to untyped (Z1). [00:42:06] If an implementation requires type conversion (via _Type converter to code_), any list input must be properly typed, or its elements won’t be converted. Similarly, any list output must be properly typed, or conversion into a Wikifunctions object will fail. (re @Al: I’ve understood what I meant, and I think it’s correct. It will become clearer! 😱) [01:22:22] We have this functionality in some utility code; would it be useful for this to be exposed as a built-in function? (Al: If all elements in an output list share a type, the list takes that type instead of being Z1.) [01:23:19] What functionality exactly? (re @wmtelegram_bot: We have this functionality in some utility code; would it be useful for this to be exposed as a built-in function? (Al: ...) [01:38:30] Heuristic typing? Sure. But Z18475 is not widespread https://www.wikifunctions.org/w/index.php?fulltext=1&ns0=1&ns4=1&profile=advanced&search=%3A+%22Z7K1+Z18475%22&title=Special%3ASearch (re @wmtelegram_bot: We have this functionality in some utility code; would it be useful for this to be exposed as a built-in function? (Al: ...) [01:54:26] Z17895 would be a higher priority because the performance hit is material. This was requested in T370028#9988099 [01:54:27] https://www.wikifunctions.org/w/index.php?limit=50&ns0=1&ns4=1&offset=0&search=%3A+%22Z7K1+Z17895%22&title=Special:Search (re @wmtelegram_bot: We have this functionality in some utility code; would it be useful for this to be exposed as a built-in function? (Al: ...) [03:04:31] Has something changed??? Why is Z22179 working now? [03:06:38] Oh, nevermind, I see you did this: https://www.wikifunctions.org/w/index.php?title=Z22181&diff=162826&oldid=162724 (re @u99of9: Has something changed??? Why is Z22179 working now?) [03:14:00] If I were WikipediaNeko, I would have trouble knowing where to go from your text. I would: Ignore case 1, since the function specified object-typed lists. Case 2 is true, so I assume my lists "take that type" (but when do they change to it??). Case 3 is false for JS, so is skipped. Case 4 is true for JS, so what do you mean "properly". Why isn't (N)[1,2,3] in the test [03:14:01] "proper"? O [03:14:01] r if you mean the function specification should demand (N)[list], then didn't Case 2 tell me that (*)[list] would be "take the type" (isn't that "proper"??) (re @Al: How about: [03:14:03] If a function specifies an output list type (other than Z1), mismatched elements cause an error. [03:14:04] If all elements in...) [04:04:33] Well, this was re-writing the preamble for list functions, not addressing WikipediaNeko. Case 2 explains how we get typed lists back when the function specifies Z1. It doesn’t say it changes. In case 4, yeah, “properly typed” just means it’s not Z1 in the function specification (for inputs or outputs, and not case 1). Case 2 is for when it is Z1 for outputs. 😵‍💫 ( [04:04:33] [04:04:34] re @u99of9: If I were WikipediaNeko, I would have trouble knowing where to go from your text. I would: Ignore case 1, since the function spe...) [04:22:51] WikipediaNeko is writing a list function! I really find this preamble is the right place to add and retrieve our advice about this kind of issue. But sure, I take your point that your answer is not tailored to their specific function. [04:25:05] Yes, I think with these clarifications it's all useful info for that preamble. Certainly I'd read it again when I start work on lists again! [04:26:55] Okay. Thanks. I’ll wikify it in the morning. 😎 (re @u99of9: Yes, I think with these clarifications it's all useful info for that preamble. Certainly I'd read it again when I start work on ...) [11:08:34] I’ve done it, but it looks like the Catalogue subpages are not translated 🤔 (re @u99of9: Yes, I think with these clarifications it's all useful info for that preamble. Certainly I'd read it again when I start work on ...) [11:10:29] Let's road test it in English anyway. Hopefully there might even be systems changes that simplify it. (re @Al: I’ve done it, but it looks like the Catalogue subpages are not translated 🤔) [11:12:38] Yeah, I’m done with it for at least an hour! (re @u99of9: Let's road test it in English anyway. Hopefully there might even be systems changes that simplify it.) [11:30:17] Ah, sorry, yes: heuristic typing is what I meant. We can generally deduce if a list of types is homogeneous, and create an appropriate type annotation for it. (re @Feeglgeef, @Al) [11:50:12] Do you think it would fix Z18690? This relates to *T370399*. (re @wmtelegram_bot: Ah, sorry, yes: heuristic typing is what I meant. We can generally deduce if a list of types is homogeneous, and create ...) [11:59:19] I'm'a go look! It might. (re @Al: Do you think it would fix Z18690? This relates to *T370399*.) [12:01:48] Ah, no, I don't think it will address either of those cases. For that to work, we'd need to use the type inference logic internally, farther forward in the stack than it currently exists. Probably possible, but I'm not an expert in that part of the stack. I'll ask. [12:20:48] Thanks. Z18770 and Z18729 are workarounds only to a limited extent, given the performance overheads. (re @wmtelegram_bot: Ah, no, I don't think it will address either of those cases. For that to work, we'd need to use the type inference logic...) [13:14:30] quick gut check: how do folks here generally feel about truncating the description for wikidata properties? while testing, we noticed that at times wikidata property descriptions can be quite long (image on the left). would it be okay to truncate the description after the 2nd line (mock-up on the right)? thank you as always! : [13:14:30] https://tools-static.wmflabs.org/bridgebot/83781528/file_68424.jpg [13:15:43] yes, truncation is much needed here! [13:15:43] (and I've been saying for years to keep description short on Wikidata exactly for this kind of case) (re @internetam1n: quick gut check: how do folks here generally feel about truncating the description for wikidata properties? while testing, we no...) [13:17:04] Perhaps expand on hover? Otherwise looks good (re @internetam1n: quick gut check: how do folks here generally feel about truncating the description for wikidata properties? while testing, we no...) [13:17:29] That probably won't be smooth though [13:20:42] not sure expansion is useful here [13:20:43] in 90 % of the case, the label itself is enough [13:20:45] for 9 % the rest, the beginning of the description should be enough [13:20:46] for the 1 % of weirdest case, even the full description is not enough and you'll need to go to Wikidata to see the statements [13:24:02] also, I just had a look, there is never two Wikidata properties with the same label (unlike items where this is pretty common) [13:26:33] Shouldn’t it show the search term’s context when that is in the description but not the label? I don’t know about “Object named as”. Is that a case of an alias? Statement? Consistency with Search could be considered. (re @internetam1n: quick gut check: how do folks here generally feel about truncating the description for wikidata properties? while testing, we no...) [13:29:13] agreed! this is something that we'd like to solve for other selectors too, where the matched query is currently not displayed by the label nor the description in the UI/menu (re @Al: Shouldn’t it show the search term’s context when that is in the description but not the label? I don’t know about “Object named ...) [13:34:11] I don't have a strong opinion on whether it should or should not be truncated, but whatever is eventually done should be as consistent as possible with other places where properties are listed, on wikidata.org and elsewhere. Coördinate it with Wikidata's designers. (re @internetam1n: quick gut check: how do folks here generally feel about truncating the description [13:34:11] for wikidata [13:34:12] properties? while testing, we no...) [13:34:22] https://tools-static.wmflabs.org/bridgebot/c91d349b/file_68426.jpg