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 2026/08

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 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)

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)

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)

Draft policy for language fallback strategies

Help:Language fallback
I'd appreciate any comments, but I'm particularly seeking approval for this planned mass edit:

• 'limited' in all Category:Display functions
• 'none' in all Category:Reading functions
• 'limited' in all Category:Abstract description functions
• NEW STRATEGY 'insistent' in all Category:Semantic fragment functions (including the ones I haven't categorised yet)
• 'insistent' in all Category:Hatnote functions
• 'insistent' in all Category:Multilingual captioned image functions
• 'none' in all Category:Conjugation tables
• 'none' in all (experimental) Syntactic table (Z36462)-producing functions? @Denny
• 'limited' in everything else: punctuation helpers, lexeme and inflection helpers, partial sentence functions...

YoshiRulz (talk) 15:42, 30 August 2026 (UTC)

I am happy that see that you want to structure the language fallback strategies. I can't oversee the consequences, but I trust you in this plan. HenkvD (talk) 11:46, 30 August 2026 (UTC)

At first read, the policy looks great (even if a person speaking fr-CA will probably be angry with that example, despite being largely true). I also approve the planned mass edit so far, it's good to test that. Thanks for the work! Ornithorynque liminaire (she/they) (talk) 16:20, 30 August 2026 (UTC)

It would also be very great to have a schema and more examples so the policy could be more understandable for newcomers. Ornithorynque liminaire (she/they) (talk) 16:22, 30 August 2026 (UTC)

None for the Syntactic tables is a good idea, I think that one will go from experimental right to deprecated anyway. I am not sure yet about the Semantic fragment functions, and would like to see the effect once we have a few more. --Denny (talk) 11:48, 3 September 2026 (UTC)

Can you provide some examples of things that will change? --99of9 (talk) 04:52, 11 September 2026 (UTC)

'None' → 'Limited': display Gregorian calendar date (Z20780) will use the Dutch implementation when Afrikaans is requested, instead of the ISO 8601 fallback.
'None' → 'Insistent': main articles (Z36083) will use the English implementation when German is requested, instead of the fallback that's just an arrow.
Improvements are very much dependent on how the fallback language lists are configured. And the Z14294s themselves—yesterday I went through and replaced hardcoded [ en, en-GB ] with English variants (Z33034), but in a world where I hadn't, the 'Limited' strategy would be helpful in routing the dialects to en. YoshiRulz (talk) 17:13, 11 September 2026 (UTC)

New visualisation templates to help editors navigate Configuration of functions for given languages (Z14294)

I've got summary table with examples for Configuration (Z40885) mostly working and I hacked together a version of a tree view that's usable: take a look at Talk:Z25091 and Talk:Z39262. YoshiRulz (talk) 02:35, 3 September 2026 (UTC)

Native implementations reading Z12 labels broken after recent deploy

Tracked in Phabricator:
Task T436918

Native (JS/Python) implementations that read labels from their argument now get an empty Z12K1, so they return 0 items. Composition implementations are unaffected.

Example: label-list from item for languages, JavaScript (Z24116) (JS impl of label strings from Wikidata item for language-list (Z24114)) with Q1 + [en, mul] returns 0 items, while composition label texts from selected labels, composition (Z26569) returns ["universe"].

Cause: orchestrator commit "Strip Z12 labels when resolving WFObjects" (Aug 26), deployed in the 2026-09-02 services deploy. fullyRealize() now strips Z12K1, and native implementation arguments go through it (WFImplementation.js).

I've temporarily disconnected Z24116/Z24770 from Z24114 so the working composition Z26569 is used.

Question: Is stripping labels from native arguments intentional? How should native code access labels going forward?

(FYI: Z24114 tester large list of labels and late element (Z36529) is separately failing; Q30 has no no label; it's under nb/nn now.) 鈴音雨 (talk) 08:49, 3 September 2026 (UTC)

label of item in language, javascript (Z23769) is also broken. 鈴音雨 (talk) 09:46, 3 September 2026 (UTC)

It was intentional to remove some, but not intentional to remove all (or at least we didn't understand the effect). The development team are aware. --99of9 (talk) 09:58, 3 September 2026 (UTC)

Should now be fixed. GrounderUK (talk) 11:20, 4 September 2026 (UTC)

Wikifunctions & Abstract Wikipedia Newsletter #263: 5,000 Functions, passing Z40000

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

In this issue, we mark the 5,000th function on Wikifunction, we explore a new Type for functions, and we take a look at the latest software developments.

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

Also, we remind you that if you have questions or ideas to discuss, the next Volunteers' Corner will be held on September 7, at 17:30 UTC (link to the meeting).

Enjoy the reading! -- User:Sannita (WMF) (talk) 11:00, 4 September 2026 (UTC)

i can create my own function?

i need enable my implementation for my function Z38065 Spider077 (talk) 05:40, 6 September 2026 (UTC)

Please request connections at Wikifunctions:Requests for connection and disconnection.

I do not think this particular implementation should be connected.

1. The function has no test cases, so its intended purpose is not entirely clear.
2. The function appears to be a duplicate of string identity (Z11602).
3. The implementation will return an error because Text is undefined.
4. In any event, print() returns the value None, so the implementation would end up returning void (Z24).

Please feel free to reply here if you need any help. GrounderUK (talk) 10:24, 6 September 2026 (UTC)

Help for optimizing functions

I developed infobox for smartphone, composition (Z41075), but in many cases, Reached rate limit in evaluator (Z571) or Reached time limit in orchestrator (Z574) occurs. I understand that this function is trying to do a lot, but I am trying to find a way to make it lighter. Any advice would be appreciated. 鈴音雨 (talk) 06:47, 8 September 2026 (UTC)

I made a few changes, of which I think making all the fetch calls identical would have the most impact. YoshiRulz (talk) 17:55, 8 September 2026 (UTC)

Incorrect number formatting with uselang on Main Page

{{formatnum:{{NUMBEROFFUNCTIONS}}}} on Wikifunctions:Main_Page (or to be precise, on Template:Main page) evaluates using PAGELANGUAGE (en) by default, not USERLANGUAGE. Setting Polish as the interface language and/or appending ?uselang=pl leaves English digit grouping (5,634, not Polish grouping: 5634). Is there a way to fix this? Because right now in Polish, technically speaking, it says there are "5.634 functions" (five and six hundred thirty-four thousandths), since a comma is used as a decimal separator in Polish. Wcalenieja (talk) 19:45, 9 September 2026 (UTC)

This problem has been repeatedly raised on the talk page and ignored every time. YoshiRulz (talk) 21:32, 9 September 2026 (UTC)

Oh, yeah, you're right :/ Wcalenieja (talk) 22:32, 9 September 2026 (UTC)

Will admin rights help with this? Or where should the change be? I take it we can't use an embedded call: 5634?--99of9 (talk) 00:44, 10 September 2026 (UTC)

Yep, admin rights are needed to edit Template:Main page, since it's edit-protected. Hardcoding a static string defeats the purpose of using {{NUMBEROFFUNCTIONS}}, which automatically updates as new functions are added. AFAIK users should be navigated to language subpages (e.g., Wikifunctions:Main_Page/pl). On subpages, PAGELANGUAGE is explicitly pl, so standard {{formatnum:...}} works correctly. But to be honest I'm not that technical, so I may be wrong. Wcalenieja (talk) 10:45, 10 September 2026 (UTC)

I guess I didn't mean hardcoding, I was more asking about using our own functional formatting by calling display natural number (Z14280) with an embedded function call. It might look more like ⏳ Function is being called… --99of9 (talk) 10:53, 10 September 2026 (UTC)

That makes sense. Apologies, I misread your comment as suggesting a hardcoded string rather than a function call. But we should use {{#function:Z14280|{{NUMBEROFFUNCTIONS}}|{{int:lang}}}} instead of hardcoding pl :) Wcalenieja (talk) 11:03, 10 September 2026 (UTC)

Indeed. I think it is now working. This does risk the first visitor in each language seeing "function is being called"... So let's see if we get lots of complaints.--99of9 (talk) 11:20, 10 September 2026 (UTC)

Wikifunctions & Abstract Wikipedia Newsletter #264: Your code can now call back to the Wikidata fetch functions

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

In this issue, we introduce the possibility of calling Wikidata fetch functions, we present a new Type, we celebrate more than 200 new functions this week, 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) 13:13, 11 September 2026 (UTC)

module:citation and templates

template:cite encyclopedia requires it Arlo Barnes (talk) 02:28, 13 September 2026 (UTC)

WF:AN to request imports from another wiki. YoshiRulz (talk) 02:59, 13 September 2026 (UTC)

Thanks, moved to WF:administrators' noticeboard#importing module:citation and associated templates. Arlo Barnes (talk) 19:55, 13 September 2026 (UTC)

Calculadora de Obras de Artista por Periodo

Hola, necesito una función que calcule a partir de dadas

• Una fecha de inicio (dd/mm/aaaa)
• Una fecha de final (dd/mm/aaaa)
• Un artista o grupo de artistas

La cantidad de obras hechas en ese periodo de tiempo por ese artista o grupo de artistas. Jackie SMG (talk) 05:40, 13 September 2026 (UTC)

Something like (Q41264, 1650-01-01, 1659-12-31) → 7? That's not currently possible, because it needs to jump from the artist's Item to the works' Items (backlinks), which SPARQL can do but Wikifunctions cannot.
Something that is currently possible would be to take a list of works as arguments and filter them by date: example. YoshiRulz (talk) 19:06, 13 September 2026 (UTC)

Más o menos algo así quiero, que se haga mediante Wikidata. Aunque igualmente, ustedes son los que saben programar, por algo estoy aquí solicitando. Muchas gracias de igual forma.

Esto es para un proyecto que tengo llamado m:Wikimuseum ~ Art, entonces necesito funciones para ese proyecto para no tener que calcular todo a mano. Les voy a dar actualizaciones si algo pasa.

Atte: Jackie SMG (talk) 19:14, 13 September 2026 (UTC)