Wikifunctions:Project chat/Archive/2023/10

From Wikifunctions

Wikifunctions & Abstract Wikipedia Newsletter #129 is out: Arguments made easier

There is a new update for Abstract Wikipedia and Wikifunctions. Please, come and read it!

In this issue, we discuss the recent improvements that made it easy to reference arguments in functions.

Want to catch up with the previous updates? Check our archive!

Enjoy the reading! -- User:Sannita (WMF) (talk) 13:58, 5 October 2023 (UTC)

This section was archived on a request by: Sannita (WMF) (talk) 16:35, 22 October 2023 (UTC)

Mainpage rtl not displaying?

I am just wondering if the main page is not showing content in right-to-left for anyone else (Main page in he) compared with Template:Main_page/he. Is this a known thing or is this a me thing? Terasail[✉️] 19:21, 16 October 2023 (UTC)

Confirmed, and well-spotted. It looks like the same issue exists at's Main Page, too, but not at Wikidata. I believe copying the root-page's #switch method that is used at Wikidata might resolve it, but I'm uncertain what other elements from d:Wikidata:Main Page/Content would also need to be added/updated to our Template:Main page (and potentially also at mw:Template:Main page!). Are these links/notes enough to help you/someone determine the fixes, or should I try to experiment? Quiddity (WMF) (talk) 18:33, 18 October 2023 (UTC)
I am happy to look into it, I haven't looked at anything since I posted this. I was planning on updating the main page with the change discussed on the talk and can have a look through the links you have provided (Possibly monday). I had some ideas @Quiddity (WMF) would it be possible to get admin and TA access on beta wf so I can try some things without testing here since it is probably best that anything that could break the mainpage is done elsewhere (my account). Terasail[✉️] 14:11, 21 October 2023 (UTC)
Done. :) Quiddity (WMF) (talk) 22:19, 23 October 2023 (UTC)
@Quiddity (WMF) Thanks, I couldn't get translations to work correctly in beta however I figured out what the problem was and have now fixed it so that language versions using rtl will now appear rtl when on the main page and not just the template. Basically the same problem exists on mediawiki, I will make a sandbox mainpage over there with the change and that should fix the issue, when implemented. Terasail[✉️] 16:42, 24 October 2023 (UTC)
This section was archived on a request by: Terasail[✉️] 17:04, 24 October 2023 (UTC)

A request for adminship is currently open!

A request for adminship by Ameisenigel is currently open. The request is open until 08:26, 28 October 2023 (UTC).

The request is posted at Wikifunctions:Requests for user groups#Ameisenigel. Any discussion regarding the request can be made there. Terasail[✉️] 14:24, 21 October 2023 (UTC)

This section was archived on a request by: Terasail[✉️] 10:12, 28 October 2023 (UTC)

Silly question

What language are the functions written in? If it's in Python, then it won't be useful for Perl coders, etc. Are there versions of each function in multiple languages, requiring "translation"? Edward-Woodrow (talk) 23:30, 1 October 2023 (UTC)

I think I just answered my own question, but if someone with experience could explain the system to me, that would be great. Cheers, Edward-Woodrow (talk) 23:32, 1 October 2023 (UTC)
not particularly experienced but each Function [let's say Compact JSON string (Z10357)] has Implementations [e.g. Compact JSON string JavaScript (Z10358) and Compact JSON string Python (Z10362)] which are per-language implementations of the function Infernostars (talk) 16:04, 3 October 2023 (UTC)
Yeah, that makes sense. Thanks. Edward-Woodrow (talk) 19:34, 3 October 2023 (UTC)

More questions

  1. Do implementations have to be in python or javascript, or are other languages accepted?
  2. How is the user input represented in code? I mean, in Perl, the user's input on the command line is represented by <STDIN>, and the user submits a string, etc. to the code with control-D. I hope I can use <STDIN> to represent the user's input into the little box, and clicking "run function" is the same as control-D, but is there something else I should use? Thanks. Edward-Woodrow (talk) 19:56, 3 October 2023 (UTC)
    At the moment only JavaScript, Python or creating functions as a composition are supported. Other languages may be added in future™ (the third one is likely to be Lua). There's no concept of stdin now, actually. You're only able to define functions that take specifies number of arguments and that's all you can read from (no console input, files, URL fetching – at least that's what's expected by the developers and escaping the sandbox is discouraged). Msz2001 (talk) 16:44, 4 October 2023 (UTC)
    Thanks for the quick response, Msz2001. Oh well. I guess I'll have to learn Python. Edward-Woodrow (talk) 19:30, 4 October 2023 (UTC)
    Since you seem to know what you're doing, I'll ask you an inane question that's been bugging me: where is the source code? I mean, the actual programs behind the functions. It must be hiding somewhere, but I sure as heck can't find it. Take Language code to language (Z860) as an example. Edward-Woodrow (talk) 19:40, 4 October 2023 (UTC)
    Okay, I messed around in the sandbox and I think I mostly get it now. Edward-Woodrow (talk) 20:12, 4 October 2023 (UTC)
    Functions with low numbers are likely to have their implementations hidden as they are part of the Wikilambda system. join two strings (Z10000) and above are created by the community. Msz2001 (talk) 20:34, 5 October 2023 (UTC)
    Okay, thanks. Edward-Woodrow (talk) 20:35, 5 October 2023 (UTC)

markAdmins available

Hello. If anyone is interested: I have set up a local version of the gadget markAdmins that is already used in many other projects. If you want to use it, just add the following line to Special:MyPage/common.js:

mw.loader.load( '//' ); // [[User:Ameisenigel/Gadget-markAdmins.js]]

Feel free to suggest improvements! --Ameisenigel (talk) 09:00, 7 October 2023 (UTC)

Thanks, adding it right now! -- Sannita (WMF) (talk) 10:46, 7 October 2023 (UTC)

Wikifunctions & Abstract Wikipedia Newsletter #130 is out: Running on WebAssembly

There is a new update for Abstract Wikipedia and Wikifunctions. Please, come and read it!

In this issue, we discuss our decision of rewriting the evaluator encapsulation service, in order to make it run on WebAssembly.

Want to catch up with the previous updates? Check our archive!

Enjoy the reading! -- User:Sannita (WMF) (talk) 13:31, 27 October 2023 (UTC)

This section was archived on a request by: Sannita (WMF) (talk) 14:54, 7 November 2023 (UTC)

Task centre

I've created Wikifunctions:Task centre; if you're interested, feel free to add requests or expand the "perennial tasks" section. Edward-Woodrow (talk) 13:24, 8 October 2023 (UTC)

Thank you very much, we'll keep an eye on that as staff too. :) Sannita (WMF) (talk) 08:39, 9 October 2023 (UTC)
That's great. I wonder if perhaps it could be merged directly into the Community Portal in the future? See also related notes at Wikifunctions talk:Community portal. Cheers, Quiddity (WMF) (talk) 21:46, 11 October 2023 (UTC)

unexpected error message

I don't understand why I got this message: "Z504K1":"Builtin validator \"Z112\" not found for \"Z12\" in the evaluation of composition of regex replacements testing position relative to spaces (or start/end of strings) (Z11493) with test apostrophe replacement: 'What's going on here?' (Z11495) (and others?). It's a bit of a complex composition, but I thought I got it right. --99of9 (talk) 03:54, 16 October 2023 (UTC)

Unable to create new Z61/programming language

At Special:CreateObject I wanted to create an item for w:Brainfuck but I couldn't, trying to save the item resulted in an error message "User does not have permission to edit". I tried using qqx to see the underlying message key and track down the responsible code but with qqx I couldn't search for a type of the object to create. I think I have the ability to edit objects? DannyS712 (talk) 03:47, 8 October 2023 (UTC)

To create an item for a programming language you need the user right wikilambda-create-programming. This is currently only available for functionmaintainers and staff. --Ameisenigel (talk) 06:50, 8 October 2023 (UTC)
Oh, thanks. Based on the current list of functionmaintainers I assume that this isn't open to the community yet? DannyS712 (talk) 17:44, 8 October 2023 (UTC)
WF staff are currently handling both functioneer and maintainer roles, no one that I am aware of has even requested the maintainer role yet so I have no idea what is happening with it, and there is no real place to request this that I am aware of. Pinging @DVrandecic (WMF) @Quiddity (WMF) as they might have more input on this. Terasail[✉️] 18:07, 8 October 2023 (UTC)
Re: maintainer role, there should be more info about that in two weeks (still confirming some details).
Re: adding new Z61 items, I've asked for the team to explain details on when & how that should be done. (We currently just have a handful at Special:ListObjectsByType/Z61, primarily the entries for the working languages, Python and JavaScript, and a placeholder (IIUC) for the potential/likely future support of Lua).
Re: the Brainfuck language itself, I kind of hope we don't ever support functions written in that! It's technically fascinating, and is amusing (even better IMO is Ook!!), but I think it conflicts with the (draft) Wikifunctions:Valuable / Wikifunctions:Notability and Wikifunctions:What Wikifunctions is not?
I hope that helps! Quiddity (WMF) (talk) 22:15, 11 October 2023 (UTC)
@Quiddity (WMF) thanks for the notes about the maintainer role, I'll keep an eye out for the details. As for the BF language itself, I would actually suggest that it is *far easier* to add support for BF than it would be for any other language, since it has no standard library, no predefined/primitive classes, no file io, and otherwise has (as far as I can tell) 0 possible ways to exploit the underlying implementation system the same way that other languages could. BF is identical to Ook! and I think implementing it would be a good demonstration of how languages are added to Wikilambda without the demonstration needing to have a whole bunch of standard libraries or calling of existing compilers/interpreters/engines.
On the other hand, if it doesn't get added it already exists as a function (Brainfuck Interpreter (Z10441)) so it can still be used. --DannyS712 (talk) 22:47, 11 October 2023 (UTC)
Not as easy at it seems ! How would the type converter work ? If I’m not wrong there are not types at all in BF … So you would like to come up on a specification on how to code types and values in BF. Not an easy ride, and a nightmare to use. TomT0m (talk) 14:13, 17 October 2023 (UTC)

Easy way to document/verify inverses

For example, I just created previous character (Z11564) to match next character (Z11538). Ideally, it would be possible to compose these in a test that is run for both - if we call previous and then next and compare it to the original, it should remain equal. Is there a way to have tests that cover *multiple* functions? DannyS712 (talk) 21:32, 21 October 2023 (UTC)

I thought I'd done this before, so I tried it here previous(next(😄)) = 😄 (Z11572), but alas, my attempt isn't currently working. --99of9 (talk) 06:35, 22 October 2023 (UTC)
@99of9 my point was that this test case can only be attached to Z11564 but it would be helpful to also attached to Z11538 DannyS712 (talk) 13:12, 22 October 2023 (UTC)
OK, I see. I know it doesn't satisfy your goal completely, but I've now also added the reverse test to that function: next(previous(😄)) = 😄 (Z11582) --99of9 (talk) 22:52, 23 October 2023 (UTC)
@99of9: I fixed it (see here the json diff). Sometimes there are mysterious glitches with the interface and then it helps to re-enter everything and make sure to click on the function names at each step. (· מקף Hyphen · 21:05, 23 October 2023 (UTC))
Thanks! --99of9 (talk) 22:52, 23 October 2023 (UTC)
@DannyS712: I think the idea is great. I wonder how such a thing can be carry out. Maybe it is possible, like including a template or page like {{user:example/myTemplates/exTmpl}}, to include the page {{:Z11572}}? redirect? Or maybe we should just ask for the change in fabricator? · מקף Hyphen · 21:05, 23 October 2023 (UTC)

Helper templates

So, I figure this infrastructure will be welcome even in early going, so I've created a few helper templates:

And I could create 200 more, but I figure it's fine to stop and take the temperature after a representative batch. :) Remsense (talk) 10:08, 25 October 2023 (UTC)

Just a small kind reminder that other languages exist. --Base (talk) 21:36, 27 October 2023 (UTC)
Oh, yes, of course. What's the best way to fully internationalize these things, do you think? Remsense (talk) 21:43, 27 October 2023 (UTC)

Generating lexeme forms using Wikifunctions

This is an announcement that the Wikidata Lexeme Forms tool now has experimental support for using Wikifunctions to generate lexeme forms (which are then saved on Wikidata as regular forms). See § Wikifunctions support for how to opt in, and please let me know how it works :)

I also created Wikifunctions:Projects using Wikifunctions to track this and other projects that use Wikifunctions “in the wild”, so if you know of any others, feel free to add them there. Lucas Werkmeister (talk) 16:29, 29 October 2023 (UTC)

Wikifunctions on multilingual main pages

Where can I translate the "Free function library" text from et. al? I do not find the text on Translatewiki: [1], [2]. --NGC 54 (talkcontribs) 12:24, 29 October 2023 (UTC)

@NGC 54: Hi there. It should appear on but indeed it does not, as they're not in the system. I have filed T350041 to fix this. Thanks for the alert! Jdforrester (WMF) (talk) 14:40, 30 October 2023 (UTC)

Your input needed: Functioneer role definition & policies

Hi folks, as you know, currently the ability to hand out the powerful "Functioneer" user group is being handled by Wikifunctions staff, as part of our early support and guidance for the community. We want to transfer the granting (and removal) of this right from us to the community in the coming months, and to help with that we were hoping that we all could agree on a set of policies and expectations that we would all look to Functioneers to uphold and encourage.

For example, there are several draft policies around what content on Wikifunctions is meant to do, who it's meant to support, and how it's meant to be used, and the Wikimedia-wide Universal Code of Conduct implicitly means that, for example, you must not write functions to hack around the system's limits and controls.

None of these local pages are yet agreed as official policies, and they generally lack an enforcement/consequences section. Given that the Functioneer right will allow users to make code go live instantly for anyone online to call it, and therefore potentially imperil the availability of Wikipedias (and other Wikimedia projects, in perspective), we want to make sure that people feel confident and supported in what the expectations of Functioneers are.

Other wikis have similar roles, though often less-powerful, like Wikidata with their "Property creator" group, or Meta with the "global interface editors". You can see how the Wikidata community decided on a set of requirements there in Wikidata:Property creators and have a process for granting it at Wikidata:Requests for permissions/Other rights#Property creator. For global interface editors, the stewards grant the right sparingly, and there is a less clear enforcement mechanism, as can be seen at Meta:Interface editors.

The staff team encourages you to consider these points for inclusion in what will be the official policy for Functioneers:

  • Functioneers are expected to exercise good judgement, especially when making changes that could, in later phases of Wikifunctions, ultimately affect many pages on dozens or hundreds of other wikis. They should have a bias for consensus and working for helping communities, rather than rapid action.
  • Users serving as Functioneers should demonstrate a feeling of responsibility for their actions and responsiveness to concerns. Functioneers are not expected to always be perfect, especially as Wikifunctions itself and its concepts are new, but they should learn from their mistakes and those of others, and work to build processes and policies to help the community avoid making the same mistakes multiple times.
  • As the role of Functioneer is novel and unique, it's difficult to assess someone's ability to do well based on their technical aptitude, and it might make more sense to grow the pool slowly.
  • In general, the Wikifunctions community should be careful not to come up with selection criteria that skew the eligible pool of applicants to only very technical people, or only to people who speak particular languages, or come from particular countries or situations. A range of experiences would be valuable to ensure that different needs are understood and supported.
  • Functioneers, like other sensitive roles, are required to use two-factor authentication.
  • There should be a process to remove the right in case of misuse or breaking of trust (see for example Meta:Interface administrators#Involuntary removal).
  • Functioneers are generally trusted members of the community, preferably with at least some history in working with functions or programming-related activities.
  • Functioneers have shown a satisfactory understanding of how Wikifunctions works, especially regarding Functions, Testers, and Implementations.

We hope you will help us in defining a new policy in the coming weeks, so that we'll have a working policy soon.

-- Quiddity (WMF) and Sannita (WMF), on behalf of the developer team, 16:50, 24 October 2023 (UTC)

Question: @Sannita (WMF) @Quiddity (WMF) When the change is made, will this also include the change for non-functioneers to be able to create / edit functions but not implement them as layed out at Wikifunctions:Functioneers#Technical abilities or will this still be limited to functioneers for the foreseeable future? The abilities of a group compared with editors without a group should be taken into account when defining policies such as this in order to not over/under prescribe restrictions. This is a significant way for users to gain edits and administrators to monitor contributions to wikifunctions so clarity on this may be helpful in designing appropirate policies / guidelines. Terasail[✉️] 17:23, 24 October 2023 (UTC)
That's a great question! We expect the community created policy to get into effect once we have allowed every logged in user to create and edit most objects. The functioneer rights would be mainly about connecting and disconnecting implementations and testers to functions. We have written a full list of rights, and we are talking about the situation after General Availability. --DVrandecic (WMF) (talk) 20:21, 24 October 2023 (UTC)
Before reading the post, I thought the functioneer role is going to be like editor on many Wikipedias – i.e. a user who has demonstrated knowledge of policies and customs in a level that no one has to clean after him. But such level is nowhere to be compared with a very powerful interface editor group, which confused me a bit.
I'm aware that it's very easy to miss some details that lead to an infinite loop, massive memory usage etc., that could affect other wikis. But I'm also afraid that such errors, except for the most evident ones are hard to catch without a thorough look at the code – an activity that takes much time and is not tempting at all.
I feel like setting the requirement too high will lead to Wikifunctions being a dead project where you can in fact write code, but you will have to wait ages for someone to look at it and accept it (which would be more of a nighmare when composing functions).
I suppose that careless functioneers may pose a less threat to the project overall than hidden bugs in the on-wiki code – bugs that may be hidden few layers below the function that was just written and that happen to be untested edge cases.
Side note: interface administrators and interface editors are much more powerful groups and (if abused) may even take over an account or perform massive DDoS against Wikimedia. This has to be considered when comparing the requirements and revoke rules. Msz2001 (talk) 19:46, 24 October 2023 (UTC)
That's a great point, and we are indeed still struggling and figuring out the right levels and how to phrase all of this. The problem is indeed less about endless loops and massive memory consumption. Our infrastructure should be robust with regards to them. But we don't want to have this tested in production. The issue is more about, for example, running an eval function on user input, or code that is intentionally aiming to stress test the infrastructure, if it was run often. We also wouldn't want them to connect intentionally obscure code.
It is also, and in particular, about the following scenario (which is not possible yet):
  1. assume we have a function that is being called in a frequently used Wikipedia infobox
  2. assume someone connects an implementation that adds the poop emoji to the output, and disconnects the other implementations and tests
  3. suddenly, we have all those articles in Wikipedia sporting poop emojis
The main defence against that are the functioneers, who would hopefully prevent Step 2.
Yes, they are also a defence against implementations overloading our resources, but as you say, these can be easy to miss. That's OK. We have a few other layers of defence against that. Functioneers are an important ingredient in this mix.
Also, I expect that how exactly these rights work will change over time, as we see how the community works and the project develops.
Thanks for the great point! --DVrandecic (WMF) (talk) 23:22, 31 October 2023 (UTC)
The scenario you outlined resembles a similar threat that could be introduced through Wikidata. In order to prevent vandalisms from spreading to other Wikimedia wikis, highly used items are semi-protected. Maybe it would make sense to protect such functions so that only function maintainers can attach/detach implementations and edit attached implementations (and perhaps the same for test cases)?
Regarding eval etc., I agree that there's no a perfect way of preventing from those but I suppose that it's possible to assess whether user is likely to know the policies and good practices after a few hundred edits to implementations that eventually got attached. Yeah, it's possible to turn evil after that but I believe the amount of work required to perform the required number of edits is so high that only few vandals could become functioneers and mess with wikis (and, besides, they would have done bunch of good things as well :)). Msz2001 (talk) 11:40, 1 November 2023 (UTC)
Good point about semi-protection.
Regarding the point regarding eval, I am not sure I understood it, sorry. Care to rephrase? -- DVrandecic (WMF) (talk) 15:40, 1 November 2023 (UTC)
Okay. So I imagine two kinds of vandals:
  1. those who make few edits
  2. persistent ones
The first group is unlikely to break the wiki because their code won't get connected to a function. The other group can, however, mimick novice good-faith users, like on other wikis. Requiring some minimal amount of contributions (say 200 function edits) can provide a base for asessing the user's experience and behavior. And yes - it's still possible that someone starts doing something bad just after being given rights. But getting them will take longer than a while and would require some skills and work.
The question is who will be the one who asesses the candidate's edits: admins (like for lower permissions or community (like for advanced rights). Personally, I'm leaning towards the former option.
And besides, can't eval-like threats be introduced by running an unpublished evil implementation (eg. for testing; third column on WF:User groups)? Msz2001 (talk) 22:02, 2 November 2023 (UTC)
I think this is an interesting topic. Currently the impact of actions of functioneers is limited but we also have to think about the future when functions might be used in other Wikimedia projects. It might be hard to determine who is suitable for this role, especially since we do not have such a role in other wikis. My first idea would be that a similar approach like for property creators on Wikidata could make sense here. --Ameisenigel (talk) 09:44, 25 October 2023 (UTC)
@Sannita (WMF) @Quiddity (WMF) I realize that the instinct would be to say no per w:WP:BEANS, but would you mind explaining just what a malicious functioneer can do that a normal editor cannot? Eg on Wikidata with property creators, my understanding is that the worse that would happen is a property gets created that shouldn't be, and then you can just delete it. On the other hand, I'm an interface admin on a few sites, and if that role is used maliciously the effects would be catastrophic. But what exactly will a malicious functioneer be able to do? Is this about performance concerns if a bad implementation is approved (in which case w:WP:PERF is either applicable, or we should have a local version saying the opposite)? --DannyS712 (talk) 14:56, 25 October 2023 (UTC)
A malicious functioneer might allow for a much larger attack surface than what we would have otherwise. Part of our multi-layered defence system is that we only have people who are trusted by the community to make code-based functions available to everyone. But if, for example, someone write's a function that takes an arbitrary string, and evaluates it, well, suddenly everyone can run any code they write on our system. And while we do have further layers of protection in that case, one important such layer was removed. That is probably the most important scenario we want to avoid. --DVrandecic (WMF) (talk) 15:44, 1 November 2023 (UTC)
My thoughts on this at the moment are that we are working in a a sea of hypotheticals. With WF still in limited release, neither functioneers or users in general have the abilities that they will, making it difficult to gauge anything, in terms of editing behaviour or otherwise. Comparisons with IA at this time are somewhat unhelpful, since this is a comparison which may only become valid in the long term, and crafting any policy around that now will probably end up missing the mark and have to be reworked when / if the group ever reaches those heights. With this in mind d:Wikidata:Property creators#Requesting this right is a good starting point to copy from with all these unknowns still in place, edit and account age requirements are best avoided for the time being. I would maybe suggest adding a criteria for revocation for functioneers who do not use the functioneer tools in a 1 year (Similar to template editors on enwp). A way for community consensus to remove the group after an AN/PC discussion sounds like a good idea. And possibly have a 24hr hold period on any request to allow for any urgent concerns with an application to be brought up? Giving functioneers 2FA access would probably be good but I think requiring it will become problematic, at least at this stage. Terasail[✉️] 18:16, 25 October 2023 (UTC)
I made an example of what I am trying to say here: User:Terasail/Page. Terasail[✉️] 18:37, 25 October 2023 (UTC)
I am a big fan of inactivity rules and would support your proposal. I also agree that there should be a specific waiting time before processing requests. --Ameisenigel (talk) 21:37, 25 October 2023 (UTC)
This section was archived on a request by: Sannita (WMF) (talk) 17:35, 30 November 2023 (UTC)

Looking for research participants

Hi everyone,

This is Amin, one of the designers behind Wikifunctions.

We are currently seeking 6 research participants to test the latest iteration of our proposed design for the Function Editor. For this study, participants will be asked to:

  1. create a function on Wikifunctions Beta Cluster, and
  2. create a function while navigating a Figma prototype.

The study is hosted on, our user testing platform, where we will record their screen as participants complete a series of tasks. This will help us understand the user experience of the proposed design.

If you wish to participate, please sign up below to receive detailed instructions via email (keep in mind that Special:EmailUser must be active to participate because we need to send you the release form). (Pinging people who've volunteered in the past: @Waldyrious, Kristbaum, Chess, Aishik Rehman, Egezort, Musindi250, and Tidjani Saleh:). AAlhazwani (WMF) (talk) 10:21, 30 October 2023 (UTC)

  1. Dolphyb (talk) 11:30, 30 October 2023 (UTC)
  2. Aishik Rehman (talk) 14:01, 30 October 2023 (UTC)
  3. —‍Mdaniels5757 (talk • contribs) 17:40, 30 October 2023 (UTC)
  4. VIGNERON (talk) 18:49, 30 October 2023 (UTC)
  5. Egezort (talk) 22:27, 30 October 2023 (UTC)
  6. Msz2001 (talk) 13:16, 31 October 2023 (UTC)
  7. (extra spot in case of dropouts) Gufo46 (talk) 17:57, 31 October 2023 (UTC)

AAlhazwani (WMF) (talk) 10:21, 30 October 2023 (UTC)

Hello, I haven't had the time to participate yet (after 5 days), however I will have time either tonight or tomorrow. I hope it's okay. Egezort (talk) 12:27, 5 November 2023 (UTC)
Absolutely okay, much appreciated @Egezort! AAlhazwani (WMF) (talk) 16:29, 7 November 2023 (UTC)
This section was archived on a request by: Sannita (WMF) (talk) 17:35, 30 November 2023 (UTC)

recursive composition times out

I wrote a recursive composition recursive composition with remove all and next character (Z11545), but alas it times out. --99of9 (talk) 07:03, 18 October 2023 (UTC)

Just noting that its not timing out now, though it might again in the future DannyS712 (talk) 22:05, 3 November 2023 (UTC)
This section was archived on a request by: DannyS712 (talk) 09:53, 1 December 2023 (UTC)

Once we get new types, which ones will be coming out first?

I'm assuming that a List type would be one of the first ones and hopefully an integer type (I am most knowledgable about mathematical functions so this would be where I could be of the most use) but I'm wondering which specific ones are going to be first or if it will be like 5 types come out at once or if there isn't a clear plan yet or what. Obviously this is probably not going to come out for some time now and there is a lot to be added with just booleans and strings (and I haven't yet been approved to be a functioneer anyway :)) but I would love to have a better sense of all of this. Thank you! Cool314 (talk) 19:22, 19 October 2023 (UTC)

@Cool314 Thank you for the extremely timely question! I will be picking up this question for this week's update. We indeed plan to open up the list type very soon, and I think that whole numbers are a good next type, but just like you I am curious to hear more from the community and what they would like to see next. --DVrandecic (WMF) (talk) 00:18, 15 November 2023 (UTC)
Here is the promised update. --DVrandecic (WMF) (talk) 21:50, 16 November 2023 (UTC)
Thanks for this update. It's not clear to me how hard each new type is/will be to create. This might determine how we answer some of your questions. So for example, if it's easy to make new types, then maybe we should eventually make all options of short natural numbers, long natural numbers, and unlimited natural numbers. But if every new type will continue to require developer work, then maybe we need to have a very rigorous discussion first so we get it right first time. --99of9 (talk) 23:46, 16 November 2023 (UTC)
Initially we will need minor development work for each new Type, but that is planned to change, and in the medium term there won't be any developer interaction required to create new types. It would all be hosted on-wiki and be doable by the community, similar to properties on Wikidata.
Nevertheless it would be good to get the types right, because once they are started being used, it will be difficult to change them. Again, you might compare it to properties in Wikidata, where changing a property is quite a hassle, and might need changes in third party apps etc. But not because of any involvement with the Wikidata development team.
I hope the answer helps, and thanks for your patience, I have been traveling. --DVrandecic (WMF) (talk) 03:55, 2 December 2023 (UTC)
PS. We have a csv workaround for lists of strings, so simpler compositions for the examples given are is vowel from CSV options, composition (Z11941) and test for Breton mutation, CSV composition (Z11942). It will be good to get proper lists though! --99of9 (talk) 23:46, 16 November 2023 (UTC)
yes, lists is a very good one! -- DVrandecic (WMF) (talk) 23:28, 7 December 2023 (UTC)