[00:28:12] 6118 [14:21:07] We didn't announce that because we don't consider the support for using functions as arguments as fully ready yet, so we didn't list reduce in the announcement (re @Toby: Thanks. I missed that because it preceded so wasn't included in the announcement of list objects and associated inbuilt function...) [14:30:53] Yes, a code point is supposed to have a single code point / roughly character in it. But validators were not fully supported yet, and validators would ensure this, which is why code points are not considered fully supported yet. Right now they behave pretty much like strings, but that's not the intention. A string is like a sequence of code points. (re @Toby: I assume a Code poin [14:30:54] t is supposed to just have a single character in it? Otherwise I can't see how it's different from a string...) [14:35:16] That's weird. I thought the value would be key label for Z14K2, Z14K3 and Z14K4. I think that might be a bug. (re @Al: A French example: the second bullet point.) [14:35:48] I was traveling this week and trying to catch up on open threads here. If I missed something please let me know! [15:02:13] Even if it shows correct labels, it should be at least documented in the message's qqq. (re @vrandecic: That's weird. I thought the value would be key label for Z14K2, Z14K3 and Z14K4. I think that might be a bug.) [15:03:22] And a much bigger problem is that Wikifunctions appears to go in the same direction that Wikidata went: a lot of things are translated as labels within the site without any planning or clear organization or progress. [15:04:04] Oh, why do you think there's no progress, [15:05:39] By "progress", I mean "progress indication". In translatewiki, one can clearly see that the WikiLambda extension, for example, is X% translated. If it's 100%, you know that your job is done. [15:07:05] Ah, yeah, that's right, we're missing a progress dashboard. I sure can see progress being done, but yeah, a dashboard would be nice. [15:08:07] In Wikidata, there are millions of items and thousands of properties, and I cannot see anywhere how many of them are not yet translated into my language. I just randomly translate things when I see that something is missing. [15:09:51] And there's no grouping. Like, a progress bar for _millions_ of items wouldn't be very helpful. A progress bar for several _thousands_ of items that are related somehow (e.g. French sociologists) would be very useful. [15:10:04] And it looks like Wikifunctions has the same problem. [15:10:49] The translatewiki workflow wouldn't really scale to 100M items, I think [15:10:53] So even if I translate 100% of the WikiLambda extension, there are X labels on wikifunctions.org that have to be translated for a full experience in my language, and the X is unknown. [15:11:13] Of course not. That's why I suggest grouping. (re @vrandecic: The translatewiki workflow wouldn't really scale to 100M items, I think) [15:11:15] Yeah, it would be good to make that more visible, agreed [15:11:42] I do that too, that's one of the easiest ways to contribute (re @amire80: In Wikidata, there are millions of items and thousands of properties, and I cannot see anywhere how many of them are not yet tra...) [15:12:28] It is, but there is no end in sight. (re @Egezort: I do that too, that's one of the easiest ways to contribute) [15:15:05] There is a task for it for Wikidata: https://phabricator.wikimedia.org/T64695 . Unfortunately, it's unprioritized. [15:30:28] I think we should include this in https://phabricator.wikimedia.org/T301712: the option to show objects of a particular type without a label in a selected language, as a start 🤔 [15:34:44] And before that, https://www.wikifunctions.org/wiki/Special:ListObjectsByType/Z4?uselang=he [16:18:57] In addition to considering that alongside https://phabricator.wikimedia.org/T301712, Special:ListObjectsByType/Z4 should have an obvious way of distinguishing between custom types and core types (included in the plan for rolling out custom types, perhaps). (re @vrandecic: Ah, yeah, that's right, we're missing a progress dashboard. I sure can see progress being done, but yeah, a d [16:18:58] ashboard would be n...) [17:34:10] Oh, I never thought about that distinction. Why? (re @Al: In addition to considering that alongside https://phabricator.wikimedia.org/T301712, Special:ListObjectsByType/Z4 should have an...) [18:25:05] Just so that the core types attract the attention of translators, whereas custom types are better translated in conjunction with functions that make use of them. (re @vrandecic: Oh, I never thought about that distinction. Why?) [19:33:41] Actually, it’s probably more about degrees of stability, with core types being the most stable and newly created custom types being the least stable (or least trusted to be stable). I think we really need “What links here” (or an equivalent) to be working for custom types. I’d also suggest a two-stage type selector for keys: the first would have just the core types (as cu [19:33:42] rrently) plus a single additional option for selecting a custom type. The type search would only include custom types after the custom type option had been selected 🤷‍♂️ (Nice to have: a custom type selected for one of a function’s keys would be available in the type selector for all of its keys without first selecting the custom type option). (re @vrandecic: Oh, I nev [19:33:44] er thought about that distinction. Why?)