[13:24:03] Hello all, I have opened a poll for next Volunteer's Corner, since some people said during last call that it would be too early. You have time until Sunday to cast your preference! [13:24:10] (re @Sannita: ) [13:34:09] I've suggested an amendment to the copyright footer for accuracy on AW's project chat, only global admins and stewards will be able to implement it. [15:58:23] thank you, done! (re @Ameisenigel: I have added two tests for Z832. Could someone with required user rights connect them?) [15:59:58] https://abstract.wikipedia.org/wiki/MediaWiki:Abstractwiki-suggested-functions.json iirc (re @Feeglgeef: Is there any way that the community can change the suggested fragment types? I thought there was but I forgot it.) [16:07:02] I've made a proposal on the AW PC to modify that page [16:20:40] The list is at https://abstract.wikipedia.org/wiki/Special:CommunityConfiguration/AbstractWikiSuggestedWikifunctions not the old JSON page Denny mentions, which is no longer used. [16:30:54] Thank you James! [17:56:23] Returning to this subject, the team is interested in knowing more about the potential impact of this proposed "lightweight enum with ZObjects capability". The enumeration of formatting functions is an excellent use case, but we're interested to know more about other potential use cases. If anyone has felt a need for this capability for some use case, please let me [17:56:23] know. One ar [17:56:24] ea that comes to mind: for NLG purposes, will it be useful to have various lightweight enums of natural languages (instances of Z60). For example, will there be NLG functions that are appropriate for a certain family of languages, and then we'll want to specify the members of that family of languages as possible inputs to those functions? (Note: there is a ticket for [17:56:24] providing [17:56:26] this feature: T405810) (re @u99of9: Al I was pondering your comment in Phabricator about choosing output formats, and realised that we should ask for something simi...) [18:23:31] Could you do the same for Z862? (re @vrandecic: thank you, done!) [23:25:47] Yes, we already have functions like Z29968 which only work for a particular subset of languages, and where it would be nice to have a way of telling the user which variants to choose from. I'll brainstorm some other scenarios. (re @David: Returning to this subject, the team is interested in knowing more about the potential impact of this proposed "lightweight enum [23:25:47] ...) [23:38:26] A sentence generating function could let the user choose an aspect of its behaviour by having a list of allowed subroutines as an input. E.g choosing between functions that make wikilinks to AW or the language wiki. Or choosing whether/how to display unit conversions. Pretty much any authoring choice that is not dictated by your language and is not described by a [23:38:26] Wikidata item. [23:38:27] (re @David: Returning to this subject, the team is interested in knowing more about the potential impact of this proposed "lightweight enum ...) [23:43:05] It would be nice if these were so featherweight that they were transparent. For example in your language example it would be nice for the functioneers to just specify the list of allowed language variants, and the receive the Z60 object rather than having to extract the Z60 from the enum type as we do for QIDs. (re @David: Returning to this subject, the team is [23:43:05] interested in know [23:43:06] ing more about the potential impact of this proposed "lightweight enum ...) [23:45:28] So I guess I'm pitching for constrained selectable inputs of existing types. Maybe that's a slightly different feature? (re @u99of9: It would be nice if these were so featherweight that they were transparent. For example in your language example it would be nic...)