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

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)

Showing where a function is used

Compositions allows to see the smaller functions/compositions that a specific implementation has used, but what about the other way around? Showing where a certain small function or composition was used in other bigger implementations. This would both show the impact of smaller, essential functions while also being helpful for people trying to build new implementations by following the same logic that has been implemented by someone else already to save time. What do you all think? Omar M. Ghaly (talk) 05:47, 16 August 2026 (UTC)

Special:WhatLinksHere/Special:FunctionUsage YoshiRulz (talk) 05:50, 16 August 2026 (UTC)

August 2026 Wikimedia Café meetups regarding Next 25

Hello! There will be two Wikimedia Café discussion opportunities in August. Both sessions will focus on the Next 25 initiative, including framing the initiative. Participants may attend either or both Café sessions.

1. 29 August 2026 15:00 UTC (timestamp converter), at a time friendly to the Americas, Africa, and Europe
2. 30 August 2026 03:00 UTC (timestamp converter), at a time friendly to Asia and the Pacific

Please see the Café page for more information, including agenda details and how to register!

To subscribe or unsubscribe for Café notices on your talk page please go here.

༄ᨒ𖠰 Pine (✉) 01:37, 17 August 2026 (UTC)

A proposal on number types on the Wikifunctions project

Hi! We'd like to submit our proposal surrounding the status of numbers in the Wikifunctions ecosystem, Wikifunctions:Proposal for built-in number types! We're open to discussion, advice, ideas, and so on. What we propose, while important, is complex and requires proper approval before we begin thinking about implementing it. Virinas-code (talk) 15:10, 17 August 2026 (UTC)

person lead sentence configuration

A newly-solved phabricator task now means that person lead sentence with occupations (Z38757) can work well. I think it's well-defined and has enough arguments to work for most people. The exception is those with Julian dates for birth/death (we still don't have a Julian type, so can't import Julian WD values). Please configure config for person description (Z32826) in your language! Wherever possible, follow the language wiki manual of style for this lead sentence. Please make noise if there's a conceptual/definitional problem for your language. --99of9 (talk) 05:13, 20 August 2026 (UTC)

Wikifunctions & Abstract Wikipedia Newsletter #261: Mayors and the North

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

In this issue, we have an essay from Denny about accidental gaps in languages, 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) 09:41, 21 August 2026 (UTC)

Coincidentally, I just made an abstract article for a different government gato... the initial idea was to write about a racehorse, but maybe I was subconsciously influenced by reading this when Denny posted it on the RfC earlier.
reː translatability of San Francisco is the cultural centre of Northern California, it was always a stupid question. "Northern California" together is the toponym, and "cultural centre" together refer to a concept (not one in WD as far as I can tell, but the concepts of financial and historic centres exist there). So there's no need for "North" as an absolute direction or "centre" as a relative position. YoshiRulz (talk) 13:40, 21 August 2026 (UTC)

"Northern California" is not a stupid question. The preferred way of describing locations varies from culture to culture. For example, a riverine culture might consider the most important aspect of its location to be "at the mouth of the Sacramento River", while an island culture might describe it as "on the coast of North America". "Northern California" is the map-centric description of its location.

Even within map-centric cultures, the borders vary. For example, when preparing a test case for Z26570, I discovered that Spanish places the United Arab Emirates in "Oriente Próximo", and "Oriente Medio" is seen as an Americanism to be avoided. Carnildo (talk) 21:52, 21 August 2026 (UTC)

You've missed the pointː the labels for items, including Northern California (Q1066807), have no restrictions and don't have to be word-for-word translations of the native label (P1705). Beijing (Q956) is not "Northern Capital" and Sotavento Islands (Q500453) is not "Leeward Islands". Describing where a place is in relation to other places is a separate problem (shares border with (P47) + direction relative to location (P654) qual. seems to be how that's modelled, so that might be limiting for some languages). Choosing how to group countries/regions is a separate problem (there's a Near East (Q48214), but United Arab Emirates (Q878):part of (P361)=Middle East (Q7204) only). YoshiRulz (talk) 06:39, 22 August 2026 (UTC)

Japanese is not suggested in the language selector when using uselang=ja

Tracked in Phabricator:
Task T435712

It seems that the language selector does not always suggest Japanese even when the interface language is Japanese (uselang=ja).

For example, when most languages have already been added and the dropdown only shows a couple of suggested languages, Japanese may not be among them. If I type "日本語" manually, it appears and can be selected normally, so the language itself is available; it is only missing from the initial suggestions.

As I understand it, the selector is supposed to prioritize the user's/interface language among the suggested languages. This may be related to phab:T391130.

Is this expected behavior, or should Japanese be suggested when the UI language is Japanese? 鈴音雨 (talk) 14:04, 22 August 2026 (UTC)

Are you referring to the autocomplete on Z60-typed reference selectors, for example on Z31676? It's the 6 UN languages, but including the current UI language is a good idea. YoshiRulz (talk) 14:42, 22 August 2026 (UTC)

Yes, that's correct. Including the current UI language would make the translation work easier. 鈴音雨 (talk) 14:45, 22 August 2026 (UTC)

Implementation edit request

I found a bug in the connected implementation lemma or fallback QID label, comp (Z38773)).

The first Find lexemes for a Wikidata item (Z6830) correctly uses the language argument, but the second one in the non-fallback branch has English hard-coded as its language.

As a result, for example, with the item for “permission” and Japanese as the requested language, the function detects Japanese Lexemes such as "許可", but then fetches an English Lexeme and returns permission tagged as Japanese.

The hard-coded English value in the second Find lexemes for a Wikidata item (Z6830) call should be replaced with the function's language argument.

I tried to make this one-line fix myself, but editing a connected implementation requires additional permissions. Could a Functioneer please fix it?

(Honestly, I'm thinking of applying for the functioneer permission. Is it way too soon, or what?) --鈴音雨 (talk) 14:56, 22 August 2026 (UTC)

Done, thank you.

There’s a 48-hour waiting period for Functioneer, so I’d apply sooner rather than later. GrounderUK (talk) 15:16, 22 August 2026 (UTC)

Language-specific guideline pages

Is it possible to create guideline pages for each language, or do they already exist?

Rather than translating a single English page using the Translate extension, it would be better to have standalone pages (subpages are acceptable). Naming conventions and similar rules in each language are almost always different from English rules. 鈴音雨 (talk) 07:04, 23 August 2026 (UTC)

→ WT:Naming conventions#Per-language pages YoshiRulz (talk) 08:39, 23 August 2026 (UTC)

Thank you (I didn't know that discussion exists). I'll write a draft for naming conventions for Japanese. 鈴音雨 (talk) 08:48, 23 August 2026 (UTC)

Wikifunctions & Abstract Wikipedia Newsletter #262: Wikifunctions Object Reference

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

In this issue, we discuss a new Type implemented after a community request, 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) 12:32, 28 August 2026 (UTC)