Wikifunctions:Project chat

Welcome to the Project chat, a place to discuss any and all aspects of Wikifunctions: the project itself, policy and proposals, individual data items, technical issues, etc.

Other places to find help:

• Wikifunctions:Administrators' noticeboard
• Wikifunctions:Report a technical problem
• Wikifunctions:FAQ

SpBot archives all sections tagged with {{Section resolved|1=~~~~}} after 1 day and sections whose most recent comment is older than 30 days.

edit
Archives
2023/08 2023/09 2023/10 2023/11 2023/12 2024/01 2024/02 2024/03 2024/04 2024/05 2024/06 2024/07 2024/08 2024/09 2024/10 2024/11 2024/12 2025/01 2025/02 2025/03 2025/04 2025/05 2025/06 2025/07 2025/08 2025/09 2025/10 2025/11 2025/12 2026/01 2026/02 2026/03 2026/04 2026/05 2026/06 2026/07

Discussion at Meta Requests for comment: The future of Abstract Wikipedia

 You are invited to join the discussion at Meta Requests for comment: The future of Abstract Wikipedia. Qcne (talk) 11:35, 14 July 2026 (UTC)

Isn't it too early for this RFC? The project was released for public preview in March-only four months ago—and it has already demonstrated its technical feasibility. Furthermore, some of the examples cited in the RFC depend entirely on specific function choices. Since this is a community-built project, contributors should remain free to use the functions they prefer. Personally, I feel the repetition of words in every sentence simply shows that active contributors currently view this issue as a low priority. After all, fixing it would require rewriting sentences to use pronouns, or correcting them with a comma-separated list of occupations. John Samuel 13:37, 14 July 2026 (UTC)

Thanks John. The project was approved in 2020 and WMF expected the first articles in 2023 so it is not four months old. Integration into language Wikipedias is planned for Q1 of the current annual plan. If it is too early to evaluate, it is too early to ship. I'd welcome your thoughts on the Meta RfC itself. Qcne (talk) 13:40, 14 July 2026 (UTC)

Speaking of "too early", abstract:Project:Response to English Wikipedia criticism has ~3 days left, so I'll hold off on commenting until then. But on a first reading, I can see some of the same misunderstandings repeated. You could delete most of the text above your three proposals and get the same effect.
edit: Yep, misunderstandings all the way down (the page). I've left a brief comment since all my points had already been made by others. YoshiRulz (talk) 20:56, 16 July 2026 (UTC)

Wikifunctions & Abstract Wikipedia Newsletter #257: Beyond syntactic tables

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

In this issue, we discuss syntactic tables and news in Types, we show some community blogposts and tools, we remind you of the Wikifunctions and Abstract Wikipedia events at Wikimania 2026, and we take a look at the latest software developments.

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

We also remind you that in the next weeks these newsletter reminders will be paused, and that they will resume in mid-August.

Enjoy the reading! -- User:Sannita (WMF) (talk) 10:55, 17 July 2026 (UTC)

Update on Blockly editor

In case anyone is actually using my external editor based on Blockly (there's no analytics so I have no idea): I cleared out my "papercut" backlog yesterday, fixing bugs, making exporting smoother, and adding more blocks necessary for NLG functions. YoshiRulz (talk) 15:35, 20 July 2026 (UTC)

Great! I'll try it out now. So9q (talk) 18:15, 21 July 2026 (UTC)

Building reproducible, computable phenotypes on WikiFunctions

Hello all! Very new to WikiFunctions, more involved in the Wikidata side of things, but I was thinking that WikiFunctions may be a great space for computable phenotypes. These are structures (lists of rules) used in medicine to determine if a person has or doesn't have a particular condition (type 2 diabetes, asthma, etc.). There is a constant issue in my field of recreating the wheel for these phenotypes and very few resources where they are openly available (there was PheKB but it isn't updated often and only contains natural language descriptions of the phenotypes and often no code or other information to reproduce). My thought process was that an algorithm for a computable phenotype would essentially be a list of synthetic (fake) patients with certain characteristics, and then the computable phenotype would be run, and it would return a list of patients who have that condition. The major use case would be allowing individuals to download these code snippets to increase general reproducibility in medical care and studies overall. Would it be possible to utilize WikiFunctions for this? Superraptor123 (talk) 08:25, 23 July 2026 (UTC)

(phenotype (Q25203551))
What system(s) are currently in use for doing such computations? Python scripts?
Wikifunctions currently does not cater to offline execution, so I imagine it wouldn't be suitable for medical practice where there are strict data protections. YoshiRulz (talk) 11:35, 23 July 2026 (UTC)

Currently this involves something along the lines of a structured series of descriptors that make up the computable phenotype (ICD codes, RxNorm codes, lab test levels, age ranges, etc.), a fake "patient" (or list of "fake" patients) as input, and the patients that fit the computable phenotype criteria as output. In terms of systems currently in use, they are kind of-- everything. SQL, Java, SPARQL, Python, Perl, Ruby, etc. Currently I develop mostly using Python, so I would likely use that for implementation. And of course, yes, they would not be suitable for practice due to protections! For an example of an algorithm that I think could be useful to adapt, see: https://phekb.org/phenotype/type-2-diabetes-mellitus. Superraptor123 (talk) 12:02, 23 July 2026 (UTC)

So your reference is a decision tree, and are each of the "questions" evaluated by looking up a property/element in the input? That could be translated into a Function relatively easily. Most examples I can think of are NLG-related, like Z36580, but there are some simpler Functions which extract parts of a given Wikidata Item, and Z34840 works with the representations of numbers. What is the structure of the input EMR? YoshiRulz (talk) 13:54, 23 July 2026 (UTC)

Precisely-- I think most of these would be simple implementations, but good to generally have archived as most of them become lost media(-ish). Best-case, the input EMR would be a set of synthetic patients using the OMOP CDM (https://ohdsi.github.io/CommonDataModel/), the most common open data model in the space. It does mean it wouldn't be completely system agnostic, but it would most in the majority of situations. Superraptor123 (talk) 14:07, 23 July 2026 (UTC)

If you decide to go ahead with this, you should propose a new type since it looks like a simple list or dict won't cover it. YoshiRulz (talk) 15:31, 23 July 2026 (UTC)

Did you look much into the possibility of encoding these in Wikidata somehow? Have d:WD:WikiProject Medicine / meta:Wiki Project Med investigated it before? YoshiRulz (talk) 15:31, 23 July 2026 (UTC)

I don't think so-- it could potentially be somewhat encoded in Wikidata-- main issue is that it uses a list of codes which Wikidata sometimes attaches to the same entity in ways that don't match up 1-to-1. And there may be drift in those codes over time, so the list of codes would have to be hard-coded. But there should generally be a way to link from the WikiFunction to Wikidata right? Superraptor123 (talk) 22:06, 23 July 2026 (UTC)

Linking to WF from an Item on Wikidata is an open question, beyond sitelinks of course. YoshiRulz (talk) 12:02, 24 July 2026 (UTC)

So maybe creating functions here makes the most sense for the time being? I want to make sure I'm following the rules as intended but would that be okay for now? (Creating one or two and then presenting to the community to see if things look acceptable?) Superraptor123 (talk) 06:46, 25 July 2026 (UTC)

Yes, you're welcome to try! --99of9 (talk) 06:53, 25 July 2026 (UTC)

Thanks! I've been thinking about this a little bit-- in terms of objects, it may make sense to have an object that is an OMOP CDM database (which is allowed by their licensing, as the database schema is open source). But I'm wondering if it should instead be an extension of a more generic database object? Superraptor123 (talk) 11:06, 28 July 2026 (UTC)

OWID's replacement for Extension:Graph

meta:OWID Gadget / c:Module:Owidslider
I'm currently watching the Wikimania talk "Bringing Interactive Graphs from Our World in Data to Wikipedia" going through the latest iteration of their interactive graphs, and they seem to be in a good position now, including i18n. I think it would be nice to use them in Abstract Wikipedia articles as well, but it's implemented as a Lua module + JS gadget. YoshiRulz (talk) 13:00, 23 July 2026 (UTC)

Friday's talks at Wikimania

Mahir256 just finished his talk/workshop "From Abstract Content to Concrete Text with Wikidata Lexemes" on Elemthala (Q136813071). You can watch it on YouTube here (though there were audio problems, volume warning).
The workshop immediately before that was "Making indigenous languages ready for Wikifunctions". Hello to anyone who came from there! YoshiRulz (talk) 15:58, 24 July 2026 (UTC)

@YoshiRulz: Thanks for highlighting these! There's also today's workshop on YouTube about 90 minutes after the start of the stream, though that might not be as interesting to watch. Jdforrester (WMF) (talk) 13:28, 25 July 2026 (UTC)

Testing an unconnected implementation

Hi everyone!

A few hours ago, I created my first function together with an unfinished Python implementation. When I wanted to test my implementation using the "Try this implementation" box in the bottom-right corner, I noticed that the button "Run function" was grayed out and there was a warning saying "This function has no connected implementations."

As it seems, you can only run an implementation if its corresponding function has at least one connected implementation. The implementation you want to run doesn't even have to be connected itself, as I can run the unconnected implementation Z12949 without any problems, even when I modify its code in the editor.

Is this behavior intentional? And is there any way I can test my implementation? Tc14Hd (talk) 19:28, 28 July 2026 (UTC)

Yeah, it's a pointless limitation. I've connected the test for you. YoshiRulz (talk) 23:56, 28 July 2026 (UTC)

Thanks! I knew I couldn't be the only one who noticed this problem... Tc14Hd (talk) 13:00, 29 July 2026 (UTC)

Help:Categorization

Hi! Just wanted to let everyone know that I recently created Help:Categorization as a draft help page explaining how categories work. I'm new to Wikifunctions, but I used my knowledge of MediaWiki in general combined with some research to write it. If anyone would like to improve it, feel free to. Axolitl (talk) 04:32, 30 July 2026 (UTC)

It's just a general MediaWiki categories guide. It doesn't have anything special for Wikifunctions, which doesn't really have categories in the main namespace. Amir E. Aharoni (talk) 16:42, 30 July 2026 (UTC)

Wikifunctions & Abstract Wikipedia Newsletter #258: Abstract Wikipedia at Wikimania

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

In this issue, we discuss the presentations and workshops at Wikimania, including a features feedback request based on what we heard there, and highlight new features shipped this week including diffs for Wikifunctions.

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

Enjoy the reading! Quiddity (WMF) 19:05, 30 July 2026 (UTC)

Impact of labels translation

A lot of the edits on Wikifunctions are additions and changes of labels, descriptions, and aliases of functions, inputs, tests, and implementations. (I will subsequently call this "labels" for simplicity.)

At Wikimania 2026, I heard from editors in several languages that they were encouraged to translate Wikifunctions' labels, and it made me wonder: Are there reasons to think that editing those labels has impact on the usage of Wikifunctions and Abstract Wikipedia by people who speak these languages? In general, I am quite famous as a major supporter of translating everything imaginable, but there should also be priorities, so if editing those labels doesn't have impact, then perhaps editors should be encouraged to translate something more visible.

After English, the most common languages for editing labels are German, French, Igbo, Italian, Indonesian, Bengali, Dutch, Japanese, Hindi, and Hebrew (information about this data).

Looking a bit more deeply into some of those:

• Hebrew labels were mostly contributed by @מקף (pronounced Maqaf), and a few were contributed by myself. I edit them mostly because I love seeing the UI translated as completely as possible, and since some object labels are integrated into the site's UI, they should be translated. Does this complete translation raise the usage of Wikifunctions by Hebrew speakers, though? I doubt it. Maqaf probably edits them because he creates some functions related to the Hebrew language, but that's just a guess, and I'd love to hear more about his motivation.
• The top editor of German labels is @Ameisenigel, who is generally a major contributor to translations across many Wikimedia projects, so perhaps his motivation is similar to mine, but he does it much more than I do. He also edits the content of actual functions, implementations, and tests. Some of the other German label editors do almost nothing but editing labels, although some, like @Lucas Werkmeister and of course @Denny also contribute to actual functions and implementations. But back to the main question: German is the top language for label translations thanks to Ameisenigel's huge work, but does it, for example, impact the creation of abstract content that works in German? When I try to select German on most abstract articles, I usually don't see a fully translated article. But maybe I'm not searching well?
• The situation is a bit similar with French. @Jérémy-Günther-Heinz Jähnick is the top French label editor, but he makes almost no contributions to functions and implementations. The second top label editor is @VIGNERON, who does contribute quite a lot to functions and implementations. There are several other prolific French label editors, but most of them contribute little or nothing at all to functions and implementations. And as with German, I almost never see abstract articles fully translated into French.
• Igbo has shown disproportionate label editing activity. I don't know why exactly, but I guess that there was some event that encouraged people to write labels (if anyone knows more, please tell me). All the top 10 Igbo label editors only wrote labels and didn't do anything else with functions or implementations. There are quite a lot of Igbo language functions, all of which were made by @Dolphyb, who contributed very little to translations. This, by itself, is not a problem at all: it's very common that programmers mostly write code and translators mostly translate. There is still the same question, though: do those language functions and massive label translations contribute to achieving Abstract Wikipedia's goal of generating Igbo content? I haven't seen evidence to support that, but I'd love to see it if anyone can present it.
• The situation with Indonesian is similar to the situation with Igbo, but there are much fewer language functions for Indonesian.

So that's what I can glean. If I'm incorrect about anything or if you can add some more info, please speak up. Because of my interest in localization, I'll be very grateful to learn more. Amir E. Aharoni (talk) 19:50, 30 July 2026 (UTC)

Adding labels in other languages has several advantages for the project. To name a few

• It is an easy introduction to Wikifunctions
• it is good for the image of Wikifunctions and Abstract Wikipedia as not being English centric
• Contributors of Wikifunctions should be able to add texts in their own languages, so translations main functions is vital for that. That includes labels, descriptions and inputs.

Not many labels are translated yet and not many functions work yet for other languages than English at the moment. The community is still very small, but I hope both will grow over time. They can mutually benefit each other. HenkvD (talk) 21:19, 30 July 2026 (UTC)

@HenkvD, I heard similar claims before, but it's to scrutinize them.

It is an easy introduction to Wikifunctions - and what does this introduction lead to? I haven't seen clear evidence that translating labels leads to other contributions or to using functions.

it is good for the image of Wikifunctions and Abstract Wikipedia as not being English centric - is it actually good? Evidently, many people in recent critical discussions about Wikifunctions and Abstract Wikipedia still think that it's English-centric.

Contributors of Wikifunctions should be able to add texts in their own languages, so translations main functions is vital for that. That includes labels, descriptions and inputs - it sounds vital; as I said, I support localization of everything in principle, and this is the main reason for thinking like that. However, this doesn't answer my question: what is the actual impact? Wikifunctions has been online for three years, so we should have seen something by now, and we aren't seeing anything.

Not many labels are translated yet - how do you define "many"? Thousands of labels were translated, and I think that it is "many". But, as you say, not many functions work yet for other languages than English at the moment - so evidently, translating labels didn't lead to writing those functions, at least yet. Amir E. Aharoni (talk) 21:43, 30 July 2026 (UTC)

Wikifunctions might be live for 3 years, but Abstract Wikipedia is only lie a few months. As it is early days for Language functions, and the first are made in English it still is English centric. THAT NEEDS TO CHANGE. Translations should help with that. HenkvD (talk) 22:08, 30 July 2026 (UTC)

See also Help:Multilingual. YoshiRulz (talk) 21:25, 30 July 2026 (UTC)

Does it say anything about the impact of translating labels? I don't see it. Amir E. Aharoni (talk) 21:44, 30 July 2026 (UTC)

No, I bring it up only as a possible explanation of translators' motives, and to point out where the documentation is should you want to improve it. YoshiRulz (talk) 22:00, 30 July 2026 (UTC)

@Amire80: I've seen folks at Wikimania use Abstract Wikipedia in their language and start and edit articles in Tyap, Japanese, and French. Having labels for those functions unlocks the Abstract Wikipedia to be used entirely in their language. --Denny (talk) 06:07, 31 July 2026 (UTC)

I understand the general idea of what this is supposed to be. I wonder whether there is actual measurable impact.

You give Tyap as a successful example, but it's in fact the example of the opposite. I found zero functions whose name is translated into this language. I found one implementation whose name is translated into Tyap, Z29740, and also a few translated language names and type names. My intuition is that type names are actually among the most important things to translate here, but very few of them are translated at the moment, and I'm trying to talk about measurable impact here and not about intuition. And as you say in the newsletter, the Tyap contributor was able to do something, even though almost nothing is translated into his language.

The label translation statistics for Japanese and French are very good, but seeing something at Wikimania is anecdotal; it's not measurable impact.

So again: I understand the general idea of why localization is desirable. I've dedicated more than sixteen years of my life to promoting this idea, I keep doing it now, and I plan to keep doing for as long as my health allows me to do it. But here, I'm asking not about the idea, but about the impact. Amir E. Aharoni (talk) 09:57, 31 July 2026 (UTC)

Hi @Amire80:. I’m not skilled at programming, but I manage to handle the translation work—even if it isn’t perfect. I’m doing my bit to help out. Jérémy-Günther-Heinz Jähnick (talk) 22:29, 1 August 2026 (UTC)

Thank you! It's fine, not everyone has to know programming. I'm just wondering how much is it actually helping out. I'm not necessarily saying that it doesn't, but I do wonder how to measure that it does. Amir E. Aharoni (talk) 05:50, 2 August 2026 (UTC)

@Amire80: I don't even understand what you are asking for. Measuring what impact, and how? The Tyap editor was able to use it because he also spoke English. If he wouldn't have, he would have an even harder time to use the interface. --Denny (talk) 07:30, 2 August 2026 (UTC)

Does the translation of function labels into a language have a measurable impact on the usage of Wikifunctions and Abstract Wikipedia in that language?

For example, a lot of function labels are translated into Igbo. Does it mean that a lot of abstract articles are fully readable in Igbo?

Same question about German, French, Italian, etc. Amir E. Aharoni (talk) 11:44, 2 August 2026 (UTC)

Translation of labels makes it easier to understand the function side of Abstract Wikipedia, and easier to add and change the lemma. It does NOT have affect on the final text in the language. It may help in writing functions for that language. As Abstract Wikipedia is a fairly new project with few contributors the impact cannot be measured. How would you measure that anyway? HenkvD (talk) 12:02, 2 August 2026 (UTC)

They can make it easier to understand the function, but do they make it easier?

For example, there was obviously some organized activity to translate labels into Igbo. Look at this query: You can see that there was a lot of label editing activity in Igbo in February, March, April, May, June, and September 2024, and very little activity in other times. It was probably related to this event: m:Event:Translation of catalogue of available functions on wikifunctions igbo.

There was also a similar event for Indonesian, and you can see in the statistics for Indonesian that there was a peak of edits in December 2025, as described in the blog post.

I don't know if these events were funded with money, but they were definitely organized. Organization requires effort. And of course, effort was also invested into the actual translation. Effort should be invested if it has some impact, and if it has no impact, then it should be invested elsewhere.

How would I measure it? Some examples:

1. Are there abstract articles that can actually be fully viewable in Igbo and Indonesian? As far as I can see, there aren't, but correct me if I'm wrong.
2. Are there many language functions that can generate text in Igbo and Indonesian, and are those functions actually used? The answer to the first question is "not many" (Igbo, Indonesian); the answer to the second and more important question is "they are probably not used". But again, correct me if I'm wrong.

Amir E. Aharoni (talk) 21:14, 4 August 2026 (UTC)

I think you're right. To help translation to make more impact, we could document which of our 39,000 objects are most important to translate. For example, the list of types, the list of the fragment functions most used on AW, and the list of functions most used in compositions on WF. Your query tool may be able to help make the third of these? --99of9 (talk) 00:58, 5 August 2026 (UTC)

I'll try, thanks for the tip! Amir E. Aharoni (talk) 02:09, 5 August 2026 (UTC)

Perhaps the more useful question is not the impact of contributing labels, but the impact of not contributing them. At present, a user who cannot search for a function using their own language is effectively required to use English (or another well-supported language). Such users do not create a visible failure case.

It may therefore be difficult to measure the benefit of translated labels from usage statistics alone because the absence of translations creates a barrier before usage even begins.

There may also be a feedback loop. English currently has the greatest discoverability, which means English-speaking contributors are more likely to notice when a function cannot be found, and to add aliases or improve labels accordingly. This may mean that English has a higher proportion of functions with aliases, and typically more aliases for any such function. Languages with less discoverability have fewer opportunities for this kind of positive feedback. GrounderUK (talk) 10:09, 5 August 2026 (UTC)

The questions to ask about this are: which languages are the most successful ones in terms of abstract articles translation? What made them successful? Can it be replicated?

But that would be a topic for a separate thread.

Here, I'm wondering about the impact of what people do invest their effort in. Amir E. Aharoni (talk) 11:04, 5 August 2026 (UTC)

Contributing to language functions 1: Language Fragments

At Wikimania, @Dnshitobu recommended cloning a page like User:Dnshitobu/Dagbani Fragments and filling it with my own language. If I understand correctly, it's supposed to help to create functions for handling my language.

I created User:Amire80/Hebrew Fragments and started filling it. There are a bunch of problems with it, but let's say that I can complete it. Is it actually useful? Once it's complete, what do I do with it?

More broadly, if it is useful, is there a written guideline anywhere that recommends doing it? If I didn't visit Wikimania, I wouldn't know about it. Amir E. Aharoni (talk) 22:10, 30 July 2026 (UTC)

From this week's newsletter: [Dnshitobu's] main proposal is that editors can create simple wikitext tables of example fragments in their language so that others could later do the technical work of setting up the lexemes and NLG functions. The next step is to correlate your example sentences to the top-level NLG functions, then add 1 or 2 test cases to each function from your table.
I don't believe Dnshitobu wrote up the process anywhere on-wiki, but that would be worth doing. YoshiRulz (talk) 22:30, 30 July 2026 (UTC)

OK, I can try to do it.

However, I should mention that the examples work kind of well in English, and perhaps they work in Dagbani, but they don't translate easily into Hebrew. Different nouns need different prepositions some letters require morphology transformations and some don't, etc. It cannot really be solved with a few basic concatenations as it was probably done in English.

The same is true for probably most other languages. Amir E. Aharoni (talk) 23:49, 30 July 2026 (UTC)

Also, who do I notify when it's ready? Amir E. Aharoni (talk) 00:58, 31 July 2026 (UTC)

WF:Requests for connection and disconnection YoshiRulz (talk) 01:15, 31 July 2026 (UTC)

But these are not functions or implementations. These are just example strings. Amir E. Aharoni (talk) 09:58, 31 July 2026 (UTC)

Right, you have to create test cases from them. For example, the "part of" sentences #7 and #8 correspond to Z34637, so start by adding a test there. Then create a new function with the same shape as Z34867 and add all your sentences to it as tests. YoshiRulz (talk) 17:49, 31 July 2026 (UTC)

I think people should get help also if they can just write down how a fragment looks like for a specific language. So it should be not required to create a test case. So far I am not good in implementing functions in Wikifunctions. In the last days I have thinked about how to find a good way to define the fragments if the inputs are modified. This is difficult and I am not sure what is the best way. In the past I proposed decision tables for it. From my point of view more ideas and ways how to implement functions are needed as I expected more content in more languages in Abstract Wikipedia so far. It seems to me like it is too complicated to contribute to Wikifunctions at the moment. Hogü-456 (talk) 21:31, 11 August 2026 (UTC)

Contributing to language functions 2: Natural language operations

At this comment, @YoshiRulz recommended using pages like Wikifunctions:Catalogue/Natural language operations/Hebrew to see what functions are missing.

What can I actually do with that table? Is there a guide for writing such functions and fitting them into the NLG system?

Is this much better than something like User:Dnshitobu/Dagbani Fragments, which I've mentioned in another comment on this talk page? Or can both be used? Amir E. Aharoni (talk) 22:17, 30 July 2026 (UTC)

The guide is at User:DSantamaria-WMF/Guide: Working with Z14294 (@DSantamaria-WMF: why is this not in Helpspace?), and mirrored in toolforge:abstract-data IIRC.
You can use whatever organisational method you find easiest. (Or if you're lucky enough to have someone to collaborate with, find consensus.) Starting with a Wikitext table means you're not forced to learn about Configuration of functions for given languages (Z14294) and function creation before you can start working. YoshiRulz (talk) 22:34, 30 July 2026 (UTC)

About the guide, I just end that guide one week ago and I was asking for some feedback on its correctness, once I have some feedback on that I will move it to the proper space.

And definitely the tool is meant to be used for those purposes (finding all the Z14294 that needs coverage in a specific language for example). Let me know if I can help with that. DSantamaria-WMF (talk) 05:36, 31 July 2026 (UTC)

On Abstract:User:HenkvD/Tasks per language I drafted a list of tasks per languages and per language fragment. Feel free to comment on this draft. HenkvD (talk) 10:17, 31 July 2026 (UTC)

Linking to the topic two above, one extra thing for Tasks per Language could be a link to a (sectioned) list of ZIDs that are most important to translate. --99of9 (talk) 13:22, 5 August 2026 (UTC)

On a set type

In WF:TP, sets were refused as an independent type (and we are redirected towards using Typed lists). After adding many functions relative to hereditary sets and von Neumann ordinals, I believe a proper hereditary set type could be welcome on Wikifunctions. Here is the rationale behind this:

• In its current state the Wikifunctions composition language lacks basic arithmetic operations. It is interesting to provide a set-based "fallback" for those, even if its performance makes it rarely used. One of Wikifunction's goals is to "Imagine a programming system that allows us to make the next big leap in knowledge representation", having a proper representation of natural numbers is a good start.
• Set operations are the basis of mathematics. Mathematically, natural numbers are typically defined with sets. Note that these mathematical sets are well defined hereditary sets: sets that only contain other hereditary sets or are the empty set.
• Currently Typed list(Object) is the best available representation of hereditary sets. They are however unclear (Object could be anything, while hereditary sets can't contain anything), and a pain to document: every function performing arithmetic using set representation needs to write "von Neumann ordinals represented as hereditary sets"; simply making the input type "Hereditary set" is a much cleaner and clear solution.
• Hereditary sets can easily be defined as Typed list(Hereditary set). I am however unsure wether this kind of recursive type is possible in Wikifunctions.
• Hereditary sets have all the characteristics of a normal type (a validator, an equality function, and even type converters). Making a proper type for them avoids repetitive work and allow for better integration in the Wikisource ecosystem. Note that all these functions are different from their Typed list equivalents (equality ignores duplicates, type converters return set objects and not list objects).

I would love to see a proper hereditary set type being discussed. If this isn't the right place, please tell me, I'm quite new to the type proposal process :) Virinas-code (talk) 20:30, 8 August 2026 (UTC)

Another use is to avoid confusion, such as between Equality of sets (Z34270) and Equality of hereditary sets (Z34273), which has already caused issues before. Virinas-code (talk) 20:32, 8 August 2026 (UTC)

IMO being "reliant" on code Implementations for arithmetic isn't a problem. Von Neumann ordinals are useful as a mathematical foundation but not as a computational one. YoshiRulz (talk) 05:18, 9 August 2026 (UTC)

After further work on von Neumann ordinals related functions, it appears Wikifunctions' builtin type converter from a Python list to a Typed list really struggles with deeply nested lists. I believe having a strong type converter for hereditary sets can really help with fast computations. Virinas-code (talk) 00:06, 13 August 2026 (UTC)

I don't have the whole answer, but here's some information to start.

> Hereditary sets can easily be defined as Typed list(Hereditary set). I am however unsure wether this kind of recursive type is possible in Wikifunctions.

This is possible! All of the needed features exist in Wikifunctions. If you try to define this type and find it's not possible, then that should be filed as a bug in Wikifunctions (and one we will triage fix through the normal channels).

I also want to set some expectations. While Wikifunctions can (barring bugs?) absolutely represent a hereditary set type, operations on that type will not necessarily have the expected asymptotic performance characteristics. Generally, the ZObject language specification doesn't allow for an object to have an arbitrary number of members, so any container type will end up relying on some kind of recursively-defined structure like WF's own List type. Practically, this means that the composition language could never do something like an O(1) set lookup.

That said, I also want to point you to code converters, which would allow the hereditary set type to be converted to a more efficient representation inside of the JS and Python code executors. That's a secondary concern for after the type exists.

Happy to discuss further! CMassaro (WMF) (talk) 16:02, 13 August 2026 (UTC)

Hi! I'm guessing the proper way to discuss this would be to make a draft type proposal? I still have some free time left on my holiday and I would love to develop that idea further :)

I'm aware of performance limitations; my goal is to rely on composition only as some kind of theoretical fallback while all performance intensive computation is done with code implementations. That way what I make can be "well-defined" and fast at the same time (ideally...). Virinas-code (talk) 21:38, 13 August 2026 (UTC)

Yes, that makes sense. Are you on IRC? #wikipedia-abstract is a very friendly and helpful group; if you're looking to make a new type, that would be a good place to get pointers. CMassaro (WMF) (talk) 09:36, 14 August 2026 (UTC)

Wikifunctions & Abstract Wikipedia Newsletter #259: Congratulations Jules*. An apple is a fruit

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

In this issue, we congratulate Wikimedian of the Year and we discuss his favourite article in relation to Abstract Wikipedia, we introduce a new Type of function on Wikifunctions, and we take a look at the latest software developments.

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

We also remind you that in the next weeks these newsletter reminders will be paused, and that they will resume in mid-August.

Enjoy the reading! -- User:Sannita (WMF) (talk) 13:19, 10 August 2026 (UTC)

Given that they are stored as persistent objects, their anonymity is kinda defeated, but it may be useful for testing and documentation purposes. Not exactly sure what the point is, then, since we'd still need the same amount of documentation in the description to say which function this is a nonce for. Aaron Liu (talk) 17:55, 10 August 2026 (UTC)

You can use them without creating a persistent object, example. YoshiRulz (talk) 21:54, 10 August 2026 (UTC)

Ooh, that's neat. Aaron Liu (talk) 00:17, 11 August 2026 (UTC)

Wikifunctions as a programming system

With lambda and half-of-an-eval, the runtime environment of Wikifunctions now resembles a somewhat less poor LISP. Whereas the runtime, as it stands now, is somewhat reminiscent of Smalltalk, Self and others, an object-oriented programming system. I wonder: how far/well the theory (in the sense of programming language theory, semantics and such) behind Wikifunctions have been developed, whether that has been documented somewhere (beyond Function model) or it still resides in the minds of the implementors for now, which direction you wish to develop this system and so on; where such discussions can take place.

Among the secondary goals is: Faster development of new programming languages due to accessing a wider standard library (or repository) of functions in a new dedicated wiki. For which we should have categorized and isolated the portion of functions (and objects), to be made available seperately as self-contained/sufficient collections, that are most relevant to implementing programming languages/systems. Has (if so, how much) there already been any work in this direction?

Since Wikifunctions aims to be natural-language- as well as programming-language-agnostic, it should be agnostic of any particular representation as well. Thus it should work with different representations (whether it's the underlying (JSON) representation of the objects, the specific choice of numberings, type system or even ontology) and be convertible among equivalence classes of representations (and conceptualizations?). It's this level of generality I'm quite interested about, and wish to have some in-depth discussion (here, insofar relevant to this project and elsewhere).

---

Smlckz (talk) 11:31, 12 August 2026 (UTC)

Hi @Smlckz! I am really interested in the viability of Wikifunctions as a programming system too, but I don't think you're in a for a great experience... While my experience here is quite limited, I worked a lot on a major issue that still bothers me: the composition language is incapable of basic arithmetic. If you look into Wikifunctions:Reserved ZIDs, you'll notice that there isn't any built in implementation for addition, subtraction, and there isn't even a builtin type for Natural numbers. This leads to quite a few fundamental issues, like the fact that the built-in Byte (Z80) depends on the non-built-in Natural number (Z13518)...

Strings aren't much better: the only core functions to manipulate them, [deprecated] -> Z22693 (Z886) and [deprecated] -> Z22683 (Z888) have been deprecated.

And while Wikifunctions:Function model is a great start it is out of date and is nowhere complete enough to be considered a proper specification. If you want any information as to how evaluation and the object model actually work you have to look into the Gitlab repos for the current implementation.

Last thing, the Get envelope from function call (Z823) function is a total breach of purity, and allows functions to get information about there own implementation, the environment they run in, etc. This can even be used, I believe, as a source of randomness.

I have great hopes that Wikifunctions will become a strong programming system one day, but as of now, it's far behind any other functional programming languages. Virinas-code (talk) 00:15, 13 August 2026 (UTC)

I hope that folks who are interested, like you two, can help with moving in that direction.

The development team is not focusing on that secondary goal currently. That shouldn't preclude anyone else from doing so.

How does Z823 break purity?

Honest question: do we need closure for anonymous functions, or is alpha conversion sufficient? --DVrandecic (WMF) (talk) 12:25, 13 August 2026 (UTC)

Sorry for the use of the maybe unclear term purity, I stole it from the Nix language :)

Purity would be the principle that the same inputs always return the same outputs, independently from the running environement. Get envelope from function call (Z823) does the exact opposite by literally giving you information about the outside environment. This constitues a source of randomness that I really do not appreciate from a theoretical standpoint, as it potentially introduces painful runtime errors (race conditions even, albeit only in extreme cases) which no one likes to debug.

I personally think that it is quite an useless function (4 uses in mainspace), but if people really want to keep it, I propose to restrict its usage to tests or make any function using it be marked as "impure" too.

To answer your last question, I don't really understand it --- I'm sorry for showing my lack of computer science basics here :') If you wish to explain it further, I'd be happy to give you my opinion. Virinas-code (talk) 21:44, 13 August 2026 (UTC)

Honest question: do we need closure for anonymous functions, or is alpha conversion sufficient? If we want to evolve towards a proper rewriting system, conversion and reduction rules from lambda calculus might suffice. But, for now, if I have understood the current system correctly, we'd need to have closures, if only for reasons of efficiency. Imagine big, non-persistent, runtime objects, being referenced multiple times in anonymous functions, after beta reduction, to get represented with that many copies in their bodies.. (The evaluator might not be affected, but once these anonymous functions need to persist or even just pass through programming language boundaries, forcing normalization/serialization..) So, if we want to support anonymous functions as first-class objects of the kind of system we currently have, closures are essential. Smlckz (talk) 03:09, 14 August 2026 (UTC)

I worked a lot on a major issue that still bothers me: the composition language is incapable of basic arithmetic. When anonymous functions work better, we should be able to implement Church numerals using them. Similarly, when we'll have support for sum types, we could use that to implement Peano arithmetic (as linked list of unit type). While these are interesting for theoretical purposes, we can't rely on them in practice, due to the kind of runtime we have here; it'd be too inefficient for any non-trivial use. Like functions can have multiple implementations, types could do the same, giving rise to typeclasses.. The aspiration towards purity gives rise to expectations of realization of program-proof equivalence, in having proofs of theorems hosted alongside ordinary functions (and perhaps proofs of correctness of such ordinary functions), but that's too far in the future for us to consider. We can then have performant implementations of types alongside theoretically interesting ones. This leads to quite a few fundamental issues, like the fact that the built-in Byte (Z80) depends on the non-built-in Natural number (Z13518)... Which does sound quite backwards. I'd've expected to see a built-in natural number type, with byte defined as a derived type out of it. (For comparison, here's what Common Lisp came up with: ) Last thing, the Get envelope from function call (Z823) function is a total breach of purity, and allows functions to get information about there own implementation, the environment they run in, etc. This information can also be used to choose more performant (or, for a particular environment, a better-suited) implementation amongst available. I don't expect this system to be able uphold the level of purity expected from a purely functional programming language, but only up to a certain degree: that most functions won't directly need to rely on such escape hatches. (Compare Rust's unsafe. Similarly, consider the caveats of Hask.) Smlckz (talk) 17:41, 13 August 2026 (UTC)

Church numerals are an idea I love, and Peano arithmetic too! My initial attempt with von Neumann ordinals quickly stopped because of speed concerns :') Typeclasses is an idea I had a while ago (although I phrased it as Single Type, Multiple Representations) and could further improve Wikifunctions' abstractness and maybe even performance. I agree the lack of a number type is a major flaw in the system. Last point, I think implementation choice should mostly be done by the system automatically; what you call unsafe is similar to the concept of impurity in Nix, where calling an impure function makes the function calling it impure too. I believe an automatic explicit visible marking of such impure functions could help prevent their abusive use.

Given that some people seem interested in the ideas we discussed but it isn't a main focus at the moment, would you like us to discuss further ideas such as the writing of a formal Wikifunctions specification, some new type proposals for an integer type, and maybe even develop the idea of typeclasses?

If you'd like a more dynamic discussion I have Discord if needed (hope it's not illegal to say that!) Virinas-code (talk) 21:52, 13 August 2026 (UTC)

I'd like to discuss, along with participation from implementors, such that we don't build castle in the air. With how things are in flux, designing a specification now might not be a good idea. At least, we'd need multiple competing full-featured implementations such that the need for specification can naturally arise. We can certainly discuss existing implementations of various programming systems: what to pick, what to discard and what to innovate in our circumstances.. I don't use Discord. You can talk with me on IRC: find me in the Libera.chat channel #wikipedia-abstract. If you don't have an IRC client set up, you can use Libera's web clients. Mention the time (with timezone) you'll be available. We can discuss which (better or worse) protocol/platform to use for further communication there. Smlckz (talk) 04:16, 14 August 2026 (UTC)

I do have IRC! virinas-code, I use the Konversation client. You do seem to have a lot more experience than me with functional programming so I'll be happy to discuss ideas with you :)

I'm typically available from 2PM to 8PM and from 11PM to 2AM-4AM in the Europe/Paris timezone. I think one of the first thing we should do is fix the built-in lack of a number type. A specification can come much later, but we do need to reinforce existing documentation (e.g. by completing Wikifunctions:Function model). Virinas-code (talk) 12:48, 14 August 2026 (UTC)

Wikifunctions & Abstract Wikipedia Newsletter #260: Shoutout to User:99of9

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

In this issue, we congratulate our own User:99of9 for his extensive work with the Wikifunctions & Abstract Wikipedia communities, we discuss what happened at Wikimania, we introduce a document for interested communities to join Abstract Wikipedia, and we take a look at the latest software developments.

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

Enjoy the reading! -- User:Sannita (WMF) (talk) 15:55, 13 August 2026 (UTC)