[03:13:24] @Sannita I assume that the team are aware that AW is not currently a pleasant experience to either edit or read? (re @u99of9: T430898) [11:08:35] Al you were asking for a documentation of the integration plan. Between this weeks' update and the one linked from January, does it make it clearer? [11:10:29] It doesn't really have a way of dealing with articles which change. (re @vrandecic: Al you were asking for a documentation of the integration plan. Between this weeks' update and the one linked from January, does...) [11:11:28] that's true. the assumption is that changes just gets propagated. a system where each edit is reviewed for every language wouldn't scale. [11:12:28] This is also worth considering. (re @Al: I think my fifth point is particularly important. There are other solution options in this space, no doubt, but it should always...) [11:14:37] blocking parts of an article is very fine-grained and increases the work load for a community considerably. what are the cases where this would be desired? (sorry if the motivation is higher up in the thread) [11:17:31] When you wrote about talking with the pilot communities, I think you need to emphasise preliminary work for them to do on WF. Otherwise they will see nothing useful when they try to add articles. [11:19:27] I'll let Al GrounderUK make the case for that. My concern is that many languages will see a whole lot of errors if their WF linguists don't keep up with global AW editors. (re @vrandecic: blocking parts of an article is very fine-grained and increases the work load for a community considerably. what are the cases w...) [11:19:57] i see your point [11:23:36] Yes, we're working on that (re @u99of9: @Sannita I assume that the team are aware that AW is not currently a pleasant experience to edit or read?) [11:26:22] Another way of saying it is that a successful AW transmission has work at both the sending and the receiving end. The sender, the AW writer, needs to encode their local knowledge in abstract. The receivers, the readers, need representative linguists to configure every function the senders make use of. Without both, they see nothing/garble/errors. (re @u99of9: When you [11:26:22] wrote about [11:26:23] talking with the pilot communities, I think you need to emphasise preliminary work for them to do on WF. Ot...) [11:28:10] that is correct. and the assumption is that the work for each receiver is considerably smaller than the work for the sender. [11:29:53] Has anyone made an Abstract Wikipedia / Wikifunctions authoring tool focused on local evaluation (ideally with fine control over caching)? That seems to me like something that'd be really useful, from my very limited attempts so far to edit Abstract Wikipedia. [11:33:45] I get that it'd place a bit more load on Wikidata, but Wikidata should be able to take the load just fine if only a small number of editors are using the tool, it'd guaranteed avoid putting excess load on server-side runners, and editors could avoid transient runner errors and flush relevant parts of the cache more agressively if they're editing Wikidata while working [11:33:45] on an article. [11:37:17] i would love that. I tried a vibe-coded version of that, and I got somewhere, but it is mostly broken. the load on wikidata is rather small, and i was able to keep the load on wikifunctions low too, with a lot of caching. but it is vibe coded, mostly broken, that's why i am rather non-confident about putting it out. It was really just a prototype. [11:38:40] I'm considering sketching something using Engraft (https://engraft.dev/) [11:41:07] Yes, thank you, Denny. I expect to comment on-wiki in the next few days and include my thinking on fine-grained control. (re @vrandecic: Al you were asking for a documentation of the integration plan. Between this weeks' update and the one linked from January, does...) [11:41:51] YoshiRulz (https://www.wikifunctions.org/wiki/User:YoshiRulz)'s WikiLambdaBlockly (https://gitlab.com/YoshiRulz/WikiLambdaBlockly) caught my eye but i don't think Blockly is flexible enough to be a good fit, from my experimentation (re @bb010g: I'm considering sketching something using Engraft) [11:44:20] I'm not sure I agree, but I'm also not sure exactly what you're comparing. If you mean the receiver-representative-linguists, I think they have quite a hard job (and are currently frustratingly slow), but maybe the volume of configurations is much less than the volume of AW articles. (re @vrandecic: that is correct. and the assumption is that the work for each [11:44:20] receiver is conside [11:44:21] rably smaller than the work for the sender.) [11:47:59] There is also https://ragesoss.github.io/zblocks/ (re @bb010g: YoshiRulz's WikiLambdaBlockly caught my eye but i don't think Blockly is flexible enough to be a good fit, from my experimentati...) [11:50:31] Can't we just get rid of the transient runner errors and find a way to clear/bypass caches? Or at least not cache errors so faithfully! (re @bb010g: I get that it'd place a bit more load on Wikidata, but Wikidata should be able to take the load just fine if only a small number...) [11:55:08] Is @Henkvd in here? Nice work on templating the configurations lists. It loses the chance to annotate specific configs, so maybe once it's settled the older chunks should be subst'ed? [11:55:45] You can invite him (re @u99of9: Is @Henkvd in here? Nice work on templating the configurations lists. It loses the chance to annotate specific configs, so maybe...) [11:56:34] i was figuring for initial cache control UI you could get away with [11:56:35] 1. a “cache” inspector presenting a [11:56:36] 1.1. list of cached entities from Wikifunctions, Wikidata, & Abstract Wikipedia [11:56:38] 1.1.1. that's fuzzy filterable via a text input [11:56:39] 1.1.2. that can filter down to the dependencies of a selected function (invocation) [11:56:41] 1.2. and a button to evict cached wikifunction evaluation results [11:56:42] 2. and tracking dependencies for wikifunction evaluations so they can automatically rerun if their relevant cache is purged and the refetched data differs. (re @vrandecic: i would love that. I tried a vibe-coded version of that, and I got somewhere, but it is mostly broken. the load on wikidata is r...) [11:56:44] So far I've just pressed "Thank".... (re @cvictorovich: You can invite him) [11:57:17] As far as you know his username here [11:57:39] Are you sure the user you point to on telegram is himself (re @cvictorovich: As far as you know his username here) [11:57:55] I do think that would also be good. (re @u99of9: Can't we just get rid of the transient runner errors and find a way to clear/bypass caches? Or at least not cache errors so fait...) [11:58:13] No, I just copied the username and it wasn't recognised. (re @cvictorovich: Are you sure the user you point to on telegram is himself) [11:58:50] It’s recognized (re @u99of9: Is @Henkvd in here? Nice work on templating the configurations lists. It loses the chance to annotate specific configs, so maybe...) [11:59:17] Pointing to “Henk Rossum” (re @cvictorovich: It’s recognized) [11:59:29] Most editors will not want to install anything as a barrier to start editing. (re @bb010g: I do think that would also be good.) [11:59:44] Click on the username (re @u99of9: No, I just copied the username and it wasn't recognised.) [12:02:12] From here or on-wiki? (re @cvictorovich: You can invite him) [12:05:20] Engraft has refunc (https://github.com/engraftdev/engraft/tree/6196ae17a3487f7e42acc9862d3aa3479bf3f59f/packages/refunc) for incremental computation but i don't know if that's flexible enough for what i've described here and i also wonder if alien-signals (https://github.com/stackblitz/alien-signals) could now be used instead. in particular filtering the cached [12:05:20] responses to an ar [12:05:21] bitrary evaluation wants some automatic association from a computed signal to a subset of its transitive dependency signals. (re @bb010g: i was figuring for initial cache control UI you could get away with [12:05:23] 1. a “cache” inspector presenting a [12:05:24] 1.1. list of cached enti...) [12:12:15] Here (re @u99of9: From here or on-wiki?) [15:10:02] minor comment: the channel description here says “Mirrored to and from IRC”; would anyone mind if we add *where* it’s mirrored? [15:10:24] I just had to go through the bridgebot config to discover that it’s #wikipedia-abstract (on libera chat ofc) ^^ [17:19:58] Done (re @lucaswerkmeister: I just had to go through the bridgebot config to discover that it’s #wikipedia-abstract (on libera chat ofc) ^^) [17:25:16] thanks!