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

"language" argument for certain functions

Hello. I am relatively new to Wikifunctions. Recently, I tried to create functions for Chinese translation of State location using entity and class (Z26570) and subject is kind of (Monolingual text) (Z26095) (which became Z32788 and Z32900). During the creation of these functions, I was trying to take defining role sentence in S/T Chinese (Z32212) as reference. And I realized that the defining role sentence function is taking language as an argument (and the test case of the Chinese-language function already contains two varieties of Chinese). This makes it possible to output monolingual text in zh-hant, zh-hans, zh-tw, or any varieties of the language. I think for this reason, it is better to have language as arguments for the implementation of Z26570 and Z26095, and potentially more functions that require Configuration of functions for given languages (Z14294), since it would output the varieties code instead of just saying zh for zh-hant, zh-hans, zh-tw in the output of type Monolingual text (Z11). I am not sure how the fallback mechanism works if one of the language (varieties) do not have a labels/lexemes, but to me, it is reasonable to have a language argument. Sun8908 (talk) 09:38, 31 March 2026 (UTC)

The functions you mention do have a language argument. For Wikifunctions, the Natural language (Z60) can be at a higher or lower level; whether a Monolingual text (Z11) is for a language or a variant is determined by the function that constructs it. Please see [“driving licence”(en-gb), …] ↤ Q205647 (Z26565) for an example and feel free to add test cases in Chinese. GrounderUK (talk) 17:54, 11 April 2026 (UTC)

Hello @GrounderUK, thanks for the answer. I understand that whether Monolingual text (Z11) is for a language or a variant depends on the function. But that is exactly what I am asking for. It is true that Z26570 and Z26095 takes Z60 as argument, but the language-specific functions in config for state location using entity and class (Z29843) and config for article-ful instantiating sentences (Z26096) don't.

Let me give you an example: INPUT to Z26570: entity: Tokyo, class: city, location: Japan, language: zh-cn, the config would select Z33030 (created after my previous comment by elseone) as the implementation, and it would RETURN 东京是日本的一个城市。(zh-hans), which is not zh-cn as requested in the INPUT. It would also be using the term not for the variant (when it is different) because it is hardcoded to use the term in zh-hans. However, if we have the implementation like Z32790 (which was created by me but a natural language argument was added by elseone) or Z32213 (that works in the defining role sentence function because of the extra argument), it could cater for different variant.

If we don't have the language argument in the language-specific function, the desire for article creation on Abstract Wikipedia would be to create a function for every variant. Is it then better to create functions for every variant? Sun8908 (talk) 18:18, 11 April 2026 (UTC)

I forgot to mention that there are some hardcoding in State loc using entity and cls, zh, cmp (Z32790) as well, but I cannot fix it because it is a connected function and I am not a functioneer. Sun8908 (talk) 18:31, 11 April 2026 (UTC)

Okay, I think it’s safe to disconnect this one as the function is not yet configured for use on Abstract Wikipedia. GrounderUK (talk) 19:04, 11 April 2026 (UTC)

Ah, sorry… I misunderstood you. I agree that the called function should be able to accept the original language argument. That is simpler in theory than in practice, because the configured functions all have to have the same argument types, as I understand it. I’m not sure which the best approach is, really, but we probably want to avoid two levels of configuration. That suggests that all language-specific functions would need to accept the additional argument, which is unrewarding work for someone. @99of9, @Jdforrester (WMF), @DVrandecic (WMF) Any thoughts? GrounderUK (talk) 18:57, 11 April 2026 (UTC)

I mean, we would need to modify all the functions in each language, which could take some time. But we are still in an early stage. If we don't fix it now and we want to fix it later, it would be a disaster. Sun8908 (talk) 19:25, 11 April 2026 (UTC)

Agreed. And we probably want them converted to HTML too, with separate language spans for text in different languages. GrounderUK (talk) 19:35, 11 April 2026 (UTC)

@GrounderUK: This sounds like a reasonable change to make. Note that (given these Functions are primarily for use on Abstract Wikipedia), altering/replacing them to return Z89/HTML fragments is already a desired but breaking change, so making a second breaking change at the same time is probably easiest for fixing things swiftly. That said, that's of course a decision for the Abstract Wikipedia and Wikifunctions communities, not me! Jdforrester (WMF) (talk) 19:43, 12 April 2026 (UTC)

@GrounderUK@Sun8908 to make it a non-breaking change, I've created apply three or optionally four argument function (Z34039) which allows a composition state loc ent cla, compose apply3/4 args (Z34043). This way you can make functions which either need the specified variant or don't! --99of9 (talk) 05:52, 24 April 2026 (UTC)

I have now created state loc using entity and cls, compose, 4 args (Z33465), which is an implementation of Z26570. Maybe we can migrate to use that function when more (language-specific) functions for it are ready? Sun8908 (talk) 18:19, 14 April 2026 (UTC)

Actual difference between subject is instance of (string) (Z26039) and subject is kind of (Monolingual text) (Z26095)

What is the actual difference between these two functions? I ask, since it seems to me that the current distinction is more or less that the first one doesn't use an indefinite article in English, while the second does. Which is not a good distinction in a project that should be language neutral. This doubt emerged from my use of the first one in abstract:Q124441, which @Hogü-456 made me notice that is probably wrong. My question is: why is it wrong? How could we clarify the difference? Dv103 (talk) 19:46, 19 April 2026 (UTC)

I think the difference is if there is an indefinite article like a or an before the subject or not. In German there can be cases where a definite article is necessary before the subject. I looked at the functions and before the object both times an article is mentioned. As it depends on the language and the word what is the correct function to use I hope it will be clarified and it is an example of the necessity to have a human with understanding in a specific language check it. I hope there will be longer functions what generate more content about a specific kind of item. Then it is necessary to write one such function per language and it can be then applied to several items. It still requires checks and so maybe it is better to write down what item category needs what kind of introduction sentence function for what language. Hogü-456 (talk) 20:05, 19 April 2026 (UTC)

The point of these two functions (and of the entire Abstract Wikipedia project) is that they should be defined in a purely language-independent way, so that the translation to actual language can be done automatically. This is the reason why these functions have been renamed; I think that this attempt was not succesful, since meaning is still unclear. My proposal to clarify them would be to invoke the concept of specificity: subject is instance of (string) (Z26039) should be named "specific subject is instance of (string)", and should be used only when the QID of the subject uniquely identifies a single thing; subject is kind of (Monolingual text) (Z26095) should instead be renamed in "non-specific subject is kind of (Monolingual text)", and should be used when the QID refers to a multitude of real life items, and we are specifying the class that all these item belong to. This clarification would not still be enough, since it doesn't explain how mass nouns are handled (is water a unique thing? Does bread (Q7802) refer to a single piece of bread or to the entirety of bread, like water?). This problem is very tricky, since mass noun are language-specific and blurry the line between these two functions. Dv103 (talk) 20:58, 19 April 2026 (UTC)

Simply put, one corresponds to P31 and the other to P279. Paris is an instance of (P31) a big city (Q1549591)

whereas a big city (Q1549591) is a subclass of (P279) (alias “kind of”) city (Q515). Whether the Wikidata knowledge representation will be sufficient to resolve into fluent natural language representations in all languages is, of course, a crucial question. Where it is not, the Abstract Wikipedia knowledge representation will need to supplement the Wikidata content with additional details about the relation between the participants or the participants themselves, and these details should be language-neutral, to the extent that this is practicable. The item washing machine (Q124441) has no P31 statements; it has only P279s, including one relating it to home appliance (Q212920), which suggests subject is kind of (Monolingual text) (Z26095) is the appropriate choice here even if the rendering in some languages is the same. GrounderUK (talk) 22:52, 19 April 2026 (UTC)

Thanks for explaining it. I think that I'll change the implementation of subject is kind of (Monolingual text) (Z26095), so that in Italian it produces more or less the same output of subject is instance of (string) (Z26039) (both with the definite article). Dv103 (talk) 11:24, 20 April 2026 (UTC)

Equivalent of Z6830 for lexemes

Is there an equivalent of Find lexemes for a Wikidata item (Z6830) that enables retrieving all lexemes pointing to a particular lexeme using a specific property? Redmin (talk) 21:06, 20 April 2026 (UTC)

There's Find lexemes for a Wikidata lexeme sense (Z6831) but I think that's slightly different again to what you're after. YoshiRulz (talk) 12:31, 21 April 2026 (UTC)

Thanks for sharing that one, I did not know it existed. But you are right, it’s not quite what I am looking for. I want a function that would take a Wikidata property reference (like P5191, which is ‘derived from lexeme’) and a Wikidata lexeme reference, and return a list of lexemes that reference that lexeme using that property. Redmin (talk) 13:23, 21 April 2026 (UTC)

Storing huge datasets

It is not a necessity I suppose, but an idea came to me earlier to write a function that would give the corresponding of an English word written with the Latin alphabet, or perhaps apply that operation to an entire sentence. However, just trying to guess as to what the IPA pronunciation of each word passed into it could be is is both not ideal (pronunciations obviously can and will vary widely between accents) and infeasible (Wikidata lexemes don't really seem to account for pronunciation). It happens, though, that a comprehensive Shavian dictionary exists named the Read Lexicon, which uses pronunciation and spelling similar to that used by the creator of the alphabet himself. This would be a good dataset to use in performing this translation in the function, but it appears that, all in all, the total size of the dictionary is nearly 26MB when formatted as JSON, which would certainly be larger when converted into a typed list.

I am wondering if this will ever be feasible or admissible, or if there is really a way around this if importing such a large set of data is deemed impractical. — rae^5e <talk> 22:30, 20 April 2026 (UTC)

@Theki: "Wikidata lexemes don't really seem to account for pronunciation"" is patently untrue; not only does every Bokmål lexeme form have IPA attached to it (thanks to Jon Harald Søby), but there are lots of languages--including English--that have pronunciation information, whether through IPA or otherwise, indicated on their forms. The big issue of course is that adding this data is not always possible to perform efficiently--for instance, I'd love to have Yiddish pronunciation respellings from Paul Abelson's dictionary on as many English forms as possible, but this dictionary not being previously processed makes this difficult. The data set you have brought up, if a suitable reading of m:Wikilegal/Lexicographical_Data allows it, could be added as pronunciation (P7243) statements on various English forms. Mahir256 (talk) 23:20, 20 April 2026 (UTC)

Well, sorry... I haven't witnessed these pronunciation statements before, I wasn't aware of their existence until you pointed it out. — rae^5e <talk> 15:02, 21 April 2026 (UTC)

I got 1,900,000 characters into Z33875 before the UI gave up on me. I'm not sure what the limit is. Feeglgeef (talk) 15:21, 21 April 2026 (UTC)

Could not serialize input JS object: Number [insert tested number here]

I'm not one to throw my problems at others, but I have no idea how to fix this. Am implementing parse JSON object to map (Z24602) in JavaScript, which requires returning a typed map. It now works for every type of value except numbers. Tried explicitly converting the numbers to float64, but either way it throws the error above. Would appreciate it if anyone could diagnose or fix the problem, as my knowledge of Wikifunctions is amateur at best. Thank you. Some helpful person (talk) 00:32, 23 April 2026 (UTC)

The quick answer is that like some list-related functions, code implementations returning typed maps are not possible unless the type of the objects in the map is specified in the function signature (e.g. if it was a map from Strings to Natural numbers only). So unfortunately, I think you've chosen a function that is not really possible at the moment. There are a few ideas of how we might address this, but for the moment, work on something else. Sorry! --99of9 (talk) 13:21, 23 April 2026 (UTC)

Maybe explicitly using natural numbers would work? I would try using { "Z1K1": "Z13518", "Z13518K1": "[number]" } to represent numbers, perhaps, and seeing if that works. Of course, you would also probably have to adapt this for other types that cannot be serialized, and I'm not sure how easy that would be to generalize (assuming DRYness is desired). — rae^5e <talk> 14:39, 23 April 2026 (UTC)

Help with creating a function for Abstract Wikipedia

Hello! I was inspired by State location using entity and class (Z26570) to create State origin using entity and class (Z33975), however I'm not sure how I add specific language implementations here. Can anybody help me? QuickQuokka (talk) 10:41, 23 April 2026 (UTC)

I think I figured it out, I created a new object with the language config type, added select a function based on language (Z14310) to my implementation, and added a new function for English... At least I think that's how it works... QuickQuokka (talk) 13:16, 23 April 2026 (UTC)

You have the right idea, as far as I know. I went ahead and connected the implementations you created as they appear to work fine for English, and added a test for State origin using entity and class (Z33975) (which passes ). I also corrected an error you made on the config object where you appear to have accidentally connected English to State origin using entity and class (Z33975) instead of State origin using entity and class, English (Z33977). Thank you for contributing! — rae^5e <talk> 13:45, 23 April 2026 (UTC)

@Theki: Thank you so much for you help! Could you please kindly also connect the implementations for Prepend Hebrew clitic (Z33986) which I just made, which is going to be used for the Hebrew implementation of State origin using entity and class (Z33975). QuickQuokka (talk) 14:11, 23 April 2026 (UTC)

You seem to be returning the wrong type in both implementations. Functioneers should not connect implementations that don't work for non-functioneers. Feeglgeef (talk) 14:13, 23 April 2026 (UTC)

@Feeglgeef: Oh thank you for pointing that out! I am still a bit new to this project and confused, so I need to read up some more about this. How do I return a monolingual text object? QuickQuokka (talk) 14:17, 23 April 2026 (UTC)

I'm trying to fix it for you, the construction of ZObjects in code implementations is a bit difficult right now. Since the State origin using entity and class function will (presumably) be composition, perhaps State origin using entity and class (Z33975) can be adjusted to return a string, using monolingual text from language and string (Z26107) and monolingual text from language and string (Z26107)? Feeglgeef (talk) 14:21, 23 April 2026 (UTC)

I did not notice any discrepancies from looking at the functions by themselves, and it seemed to work fine on my end. Is it bad practice for NLG functions to return the monolingual text type? I had assumed it was logical. — rae^5e <talk> 14:24, 23 April 2026 (UTC)

Both implementations are failing all three tests on my end. No consensus has been established as to whether monolingual texts or strings should be used, so it's like the war of the currents but for Wikifunctions. Feeglgeef (talk) 14:27, 23 April 2026 (UTC)

Oh, you were referring to Prepend Hebrew clitic (Z33986). I assumed you were stating that something was wrong in the earlier English functions that I missed; I apologize for the misunderstanding. Has there been any centralized discussion on this string vs. monolingual text issue? — rae^5e <talk> 14:31, 23 April 2026 (UTC)

Not that I'm aware of, I've brought it up on the telegram twice before, though. Feeglgeef (talk) 14:49, 23 April 2026 (UTC)

The centralised discussion is at WT:Abstract Wikipedia/2025 fragment experiments#Proposed recommendation: Fragments should return Z11/monolingual strings. YoshiRulz (talk) 07:19, 24 April 2026 (UTC)

@Theki and Feeglgeef: Can only functioneers test implementations? For me I can't test it at all... QuickQuokka (talk) 14:32, 23 April 2026 (UTC)

AFAIK, test cases are only immediately testable during editing of a function if they are connected. This is one of my personal pain points with Wikifunctions, iterating on functions without exhaustive connected test cases makes debugging practically impossible for non-functioneers working on newly-created functions... I (or Feeglgeef) can quickly connect the tests you need for you if you want, although if they are not well-formed they may need to be disconnected again afterwards. Additionally, I could temporarily connect the implementation you are writing so that you can test it on the sidebar as you work, but I'm not sure if this is advisable. That functionality is also something that unfortunately only works when not disconnected. — rae^5e <talk> 14:43, 23 April 2026 (UTC)

Yup, agree with you on all points, thanks. Feeglgeef (talk) 14:48, 23 April 2026 (UTC)

Please disconnect implementation

I think I've fixed my issue with Prepend Hebrew clitic (Z33986), but I can't edit an actively connected implementations with my rights. I must admit it is an AI-aided fix, I feel very strongly about disclosing that.

Courtesy pinging User:Theki and User:Feeglgeef. QuickQuokka (talk) 18:51, 23 April 2026 (UTC)

Additionally, I think the JS might be working. QuickQuokka (talk) 18:52, 23 April 2026 (UTC)

Just to clarify, I mean disconnect the Python implementation please. QuickQuokka (talk) 18:53, 23 April 2026 (UTC)

Done I've disconnected the Python implementation.

I've also added a couple of tests. The rule is a bit more complicated than adding a maqaf before every character that is not a Hebrew letter. Unfortunately, I don't think I'll have time to fix the implementations any time soon. Amir E. Aharoni (talk) 19:03, 23 April 2026 (UTC)

Thank you!

Also, for some reason I thought you put a maqaf before all gershayim, so thanks for correcting me. QuickQuokka (talk) 19:09, 23 April 2026 (UTC)

No, that's not the rule.

The rest of this reply is an infodump, feel free to ignore it :)

In the Academy's punctuation rules, the rule for adding a maqaf is written kind of badly: שמים מקף ברצף שיש בו שני סוגי גופנים, כגון אותיות ומספרים ("maqaf is added in a sequence in which there are two types of fonts, such as letters and numerals"). These are not different types of "fonts", but different types of characters, and I should email them about it. It gives the examples ה־12 and ב־DNA. It doesn't say anything explicitly about quotation marks, but in other places on the same page, you have stuff like ב"הארץ", and from that I deduce that a maqaf is not needed before double quotes if there are Hebrew letters inside the double quotes.

That said, a few people do think that there must be a maqaf before double quotes. I have a somewhat surprising example of somebody who always does it: translators of Scientology materials into Hebrew. At least that's what they did last time I looked at them, about ten years ago. Those people are certainly prolific, and they get points from me for consistency, but this not the prevalent standard. (And if I recall correctly, they use the minus and not the proper Hebrew maqaf, and they don't get any points from me for that!)

Also, the name of the character is just "double quotes" and not "gershayim". Gershayim are mostly for abbreviations, although most people use the same character for them. I use ״ for gershayim, as do a few other nerds, but we're the minority. Amir E. Aharoni (talk) 19:35, 23 April 2026 (UTC)

@Amire80: Yeah, "font" is a weird choice of wording here by the Academy...
I think I'll follow your guidance and not use a maqaf for quotes beginning with Hebrew letters.
I should also add more tests for different types of quotes, like straight (", '), curly (“, ”, ‘, ’), gershayim (״, ׳), including single quotes.
P.S. gotta deduct points from Scientology for being a cult but that's neither here nor there QuickQuokka (talk) 20:49, 23 April 2026 (UTC)

@Amire80: Courtesy ping because I mistyped your username on the last message. Anyways I'm also gonna do that tomorrow because I'm tired now... QuickQuokka (talk) 20:50, 23 April 2026 (UTC)

Connect implementations

Hello!

I'm done with the implementations of Prepend Hebrew clitic (Z33986) both in JS and Python, and all tests pass.

Pinging @Amire80 to check if all the tests I've added are alright. QuickQuokka (talk) 15:24, 24 April 2026 (UTC)

Connected. It's possible that some more changes will be needed, but it looks OK now.

Another little comment: It should be called "clitic" and not "prefix". Amir E. Aharoni (talk) 15:56, 24 April 2026 (UTC)

@Amire80: Thanks for your comment! Luckily labels are easy to edit, so I'll get to it.

Currently I'm working on Bulgarian във or в? (Bulgarian) (Z34072) and със or с? (Bulgarian) (Z34084), along with other Bulgarian functions. After I'm finished with those I'll take your advice. QuickQuokka (talk) 16:01, 24 April 2026 (UTC)

Please connect my Bulgarian implementations

I recently created the following Bulgarian functions:

• State location using entity and class, Bulgarian (Z34070) (currently broken, I think because another function I built it upon is unimplemented)
• State origin using entity and class, Bulgarian (Z34088)
• Bulgarian article-less instantiating sentence (Z34105)
• във or в? (Bulgarian) (Z34072)
• със or с? (Bulgarian) (Z34084)

Can somebody please connect these functions, and perhaps suggest other functions I could localize? QuickQuokka (talk) 19:03, 24 April 2026 (UTC)

Specifically, Z34070 is based on Z34072 QuickQuokka (talk) 19:05, 24 April 2026 (UTC)

Done for everything that passes, Z34070 still does not work after purging WF's cache, though. For future reference, please request on the community portal instead of the project chat. Thank you for your work! Feeglgeef (talk) 20:03, 24 April 2026 (UTC)

@Feeglgeef: Thank you for your help! I will keep in mind to go to the community portal in future instead for this.

I still don't understand why State location using entity and class, Bulgarian (Z34070) fails... It's implementation is almost completely identical to Z30399 from State location using entity and class, English (Z30397), unless I messed something up... QuickQuokka (talk) 20:11, 24 April 2026 (UTC)

Done No, it was mostly just timing out. It is better to use selective fetches where possible. One case is failing to match the expected results, but at least it is returning something. For all I know, it might even be acceptable! GrounderUK (talk) 20:35, 24 April 2026 (UTC)

@GrounderUK: Thank you so much for your help! The one failed case is with a definite article, so I feel like that might be fixed in the future... QuickQuokka ^{[⁠talk • contribs]} 20:43, 24 April 2026 (UTC)

Editor experience suggestions

I'm a bit frustrated with the editing experience on Wikifunctions, and I have suggestions based on pain points I've had contributing to this project:

• Adding a wizard to create functions, implementations, and tests in one flow, somewhat like Wikimedia Commons' upload wizard
• A sandbox for experimenting without changing mainspace functions, and maybe letting non-functioneers connect implementations (Project: Sandbox doesn't seem to fit this)
• We could have functions for creation based on the sandbox, like how Wikipedia has articles for creation and edit requests,
• Maybe even another test instance of Wikifunctions, like how Wikidata has Test Wikidata

I really like this project and I don't mean to whine, but it certainly has a lot of pain points both for technical and non-technical people. QuickQuokka ^{[⁠talk • contribs]} 20:41, 24 April 2026 (UTC)

It's also really complicated to localize functions, so maybe we should add another wizard for that, where you can choose a language, and then create the new function with the aforementioned function wizard, and it just automatically adds it to the related language configuration object of the related function. QuickQuokka ^{[⁠talk • contribs]} 20:48, 24 April 2026 (UTC)

1. Sounds good to me.
2. A sandbox available is Z10119, though an extension-provided sandbox that allows you to manipulate the types, code, and tests easily without interfering with the mainspace would be nice.
3. This page works to some extent, though it's too messy in my opinion.
4. We used to have a "beta cluster" but it got shut down just over a year ago because it was broken.

Feeglgeef (talk) 21:07, 24 April 2026 (UTC)

Language parameters in language-specific functions

I think that an effort should be made to give the different natural language options corresponding to different English dialects, Chinese scripts, etc. more of a use (I added the test [en-us] a plow is an agricultural tool (Z34119) to subject is kind of (Monolingual text) (Z26095) and unsurprisingly it fails). There are two main problems with this approach that I can identify:

• If you ask the majority of these functions to make a sentence in British English, much of the time it will give you an output with missing words, because it does not fallback to English labels in the case of a British English label for that item missing. The same applies for every other English dialect, British English is just an example here.
• Uninformed editors will probably see the presence of a language parameter on these functions, consider it redundant, and remove it. I have made this mistake before.

In my opinion, in a perfect world, all of these language generation functions would output monolingual text, and if the user asks for American English text, then American English text is what they'll get. If the user asks for Japanese text in hiragana specifically, then that's what they'll get in return. This is not as high-priority as just rendering text in the language plainly in the first place, but it's something that I feel is still worth devoting some effort to.

Right now switching functions to use this paradigm is difficult because, on the one hand, I don't know if consensus tends towards this direction being ideal or advisable, and I don't want to make changes like this without at least notifying the wider community. In addition, all tests break once a parameter is added or removed, and the function editor does not recognize the change in number of parameters and therefore you have to remove the function call, re-add it along with all of its parameters it had previously (which is a tedious cut-and-paste job), and then it will work again. This is something that you can do in five seconds by just adding a few lines of JSON to the test source, but this is not directly editable from the Web browser. This tedium is largely what's preventing me from doing this on a larger scale, besides asking for comments first.

If anyone has any insights or comments on this, then that would be appreciated. If a reference of functions with and without the support for language variants is needed, of course WF:NLG can be perused, but I've also my own list cataloged at User:Theki/functions#language...

Of course, this thread has many similarities to the one above, but this concerns me going out and making this consistent across these NLG functions. — rae^5e <talk> 21:09, 24 April 2026 (UTC)

I've created apply four or optionally five-argument function (Z34122) as an extension to apply three or optionally four argument function (Z34039) for larger functions. — rae^5e <talk> 21:34, 24 April 2026 (UTC)

Just to confirm that I, for one, support a Natural language parameter for all natural-language functions. The concern about getting them all aligned is just that we haven’t finally settled on Monolingual text (Z11) being preferred to HTML fragment (Z89) or some other type that conserves the text’s provenance, so we risk having to change them all again. GrounderUK (talk) 10:07, 25 April 2026 (UTC)

“Key not found ()”?

What am I doing wrong in Unlabelled (Z34137)? Redmin (talk) 00:39, 25 April 2026 (UTC)

You were passing a Z6091 to best values from Wikidata item statements (Z32290), but it takes a Z6001. Fixed. YoshiRulz (talk) 07:10, 26 April 2026 (UTC)

Thank you! Redmin (talk) 14:13, 26 April 2026 (UTC)

Why is my test failing?

Hello! I recently made Bulgarian transliteration (Z34139) based on wikt:Module:bg-translit, and the test case Bǎlgárija (Z34141) is failing on both implementations, despite the expected output and actual output being the same as far as I can tell.

I tried looking at the Unicode codepoints of the output, but those are also identical. QuickQuokka ^{[⁠talk • contribs]} 06:21, 25 April 2026 (UTC)

Yes, it’s a tricky one. I’ve added a normalize step to the result validation in Bǎlgárija (Z34141), which confirms it is a normalization issue. It looks like it is in the code but I don’t know whether simply normalizing the result is the way to go. Logically, you would normalize both the input and the result. The implementations of normalize Unicode (Z10384) show you how to do this. GrounderUK (talk) 09:41, 25 April 2026 (UTC)

Edit request

Hello! I have an edit request for something is a something, compose WD labels (Z23752) and something is a something, compose WD Lexeme labels (Z23414).

Please replace all the "an/a" logic with Z21739(Argument reference), both for readability and for more accuracy ("a university is an institution") QuickQuokka ^{[⁠talk • contribs]} 09:50, 25 April 2026 (UTC)

Done Dv103 (talk) 12:24, 25 April 2026 (UTC)

Wikifunctions & Abstract Wikipedia Newsletter #245 is out: The Foundation's search for the perfect language

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

In this issue, we present an academic paper about Abstract Wikipedia, we discuss our latest Type created, and we take a look at the newest created functions.

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

Enjoy the reading! -- User:Sannita (WMF) (talk) 09:54, 25 April 2026 (UTC)

@Sannita (WMF), @DVrandecic (WMF), technical meta-question: the newsletter quotes the article:

the only way to contest its algorithm is to click 👍 or 👎 (Crawford and Gillespie 2016)

This quotation sounds sensible, but the article's web version, and the PDF that is downloadable from the same page doesn't actually show the emojis. It rather shows text that looks lacking:

the only way to contest its algorithm is to click or (Crawford and Gillespie 2016)

Where did you get the emojis? Is it your (probably correct) guess or is there a version somewhere that actually shows the emojis? Amir E. Aharoni (talk) 15:16, 25 April 2026 (UTC)

Scratch that. I've found a version with correct emojis: https://wikihistories.github.io/wikilambda-the-ultimate/ Amir E. Aharoni (talk) 15:37, 25 April 2026 (UTC)

Requested deletion of test

Please delete Unlabelled (Z34143). this was never valid Bulgarian, I messed up. QuickQuokka ^{[⁠talk • contribs]} 10:19, 25 April 2026 (UTC)

WF:RFD please. Feeglgeef (talk) 16:40, 25 April 2026 (UTC)

Request for comment (global AI policy)

A request for comment is currently being held to decide on a global AI policy. Thank you! MediaWiki message delivery (talk) 00:57, 26 April 2026 (UTC)

Is it OK to connect the implementation?

Hello!

I recently applied for functioneer on WF:RFG, and I was wondering whether I could connect the implementation for Bulgarian article-ful instantiating sentence (Z34165) despite its dependency subjective definite article (Bulgarian) (Z34149) being currently unimplemented. That is if I get accepted.

I am planning on implementing it based on wikt:module:bg-nominal, but am still having trouble figuring it out for now. QuickQuokka ^{[⁠talk • contribs]} 09:04, 26 April 2026 (UTC)

Past tense function

Is there a function like subject is instance of (string) (Z26039), but for the past tense (e.g. "Leo Tolstoy was a writer.")?

If not, I will create it myself, I just want to make sure there's not a duplicate. QuickQuokka ^{[⁠talk • contribs]} 10:10, 26 April 2026 (UTC)

Done with (DO NOT USE!) subject was instance of (Z34224), but I have a few kinks to work out with it. QuickQuokka ^{[⁠talk • contribs]} 10:35, 26 April 2026 (UTC)

I need to create some other similar functions for the past tense, I have some ideas:

• subject is kind of (Monolingual text) (Z26095)
• subject is instance of multiple objects (Z32643)
• defining role sentence (Z28016)
• State location using entity and class (Z26570)
• State origin using entity and class (Z33975)
• Superlative definition (Z27243)
• Classifying a class of nouns (Z26627)
• Ordinal class location fragment (Z27627)
• Describe the class of a class (Z27173)
• describing entity with adjective / class (Z29591)

Are there any I have missed? QuickQuokka ^{[⁠talk • contribs]} 10:57, 26 April 2026 (UTC)

I think that here we are starting to walk on dangerous waters: what does past mean? Is it a recent o a far past? Does it have ripercussions on the present or not? Is it just a thing that happened once, many times or for a continuative period of time?

Consider that various languages distinguish between many different types of past. Dv103 (talk) 12:38, 26 April 2026 (UTC)

@Dv103: That is a fair point...

How do we go about solving this problem though? I don't think having every sentence on Abstract Wikipedia be "X is a Y" is a very good idea.

Maybe we have different functions for all these variations of past you mentioned that just map into "X was a Y." in English? QuickQuokka ^{[⁠talk • contribs]} 13:31, 26 April 2026 (UTC)

To properly solve this problem, we should use a more complete abstract content representation model, like for example the proposal of Semantic units (look at the example to see how times could be handled). For now, since we're still stuck with single fragment generation functions (that I hope will be slowly replaced with the complete represenation model, when available), we could just restrict your function to a very specific meaning, like "subject was an instance of, for most of its existence" (which means for example that it could be used to say "Douglas Adams was a writer", but not "Abraham Lincoln was a president", since he only was a president for 4 years). Probably my definition is still too vague, and this is why we need to go beyond these fragment generating functions. Dv103 (talk) 19:47, 26 April 2026 (UTC)

Nitpick... I don't like that it outputs a string instead of monolingual text. With subject is instance of (string) (Z26039) it's used so much that I think it's unfixable in that case beyond deprecating it if people care that much, but (DO NOT USE!) subject was instance of (Z34224) doesn't even have any connected implementations yet. Consider it, maybe?

Nitpick 2... English past article-less instantiating sentence (Z34227) is missing a language parameter. — rae^5e <talk> 16:08, 26 April 2026 (UTC)

I will consider that!

I just did that because that's what subject is instance of (string) (Z26039) does, so I assumed I should follow suit with it. QuickQuokka ^{[⁠talk • contribs]} 16:48, 26 April 2026 (UTC)

Legacy functions

If and when more robust methods of abstractly representing and generating linguistic content come around, and more efficient ways of creating abstract content are devised and implemented, I suspect that our current methods will require some form of deprecation. This is a significant source of concern for me in relation to WF and AW, questioning how prone our current methods of doing things are and eventually will be prone to obsolescence, and how it will be worked around when it comes. We have over 1 250 articles on AW presently, and these are rather all over the place. I suspect the maintenance burden from keeping these articles up to code will eventually, err, creep up on us, I suppose, and some kind of major refactoring will be necessary. We are definitely in a period of experimentation and whatnot right now but eventually, like with enwiki, some sort of structure and rigor will form and I suspect it will start to become rather boring for me...

I, for one, very much enjoy experimenting with new and better ways to do things here. I don't personally mind changing things to use a new and better paradigm if need be, that sort of thing highly excites me, but of course there will be things that are left behind, and I suspect maybe bots will be employed to deal with this? A lot of Wikipedia sister sites seem to do that, e.g. going and fixing up use of deprecated templates. Considering the nature of Wikifunctions and Abstract Wikipedia I suspect certain maintenance tasks will be made simpler or even trivial by the typical uniformity of our implementations.

I guess I am just concerned if Wikifunctions or Abstract Wikipedia will ever accrue its own kind of "technical debt" with how we are plowing through things presently, and if there is a plan for how we will eventually seek to mitigate that. Maybe too early to ask this question, but I am a notoriously anxious person, so I thought it wouldn't hurt to raise the question regardless... — rae^5e <talk> 21:30, 26 April 2026 (UTC)

I very much agree, thank you for expressing my position so well. @Immanuelle: has been using an AI-generated tool (well, they haven't edited in a week, perhaps it's a break or perhaps they don't wish to contribute to the project any more) to create a bunch of articles en masse, which I have warned them multiple times is a bad idea (on top of evolving functions, all of the articles are one-sentence-per-paragraph, like so). That's why I've been avoiding creating articles recently, I'd say I have a good fourth (no data to support, rough guess) of the comments on the wiki, yet less than a percentage of the article count (only three, including the first article, though, so perhaps I'm the next office.bomis.com). Feeglgeef (talk) 19:41, 27 April 2026 (UTC)

I feel that the overwhelming presence of these low-quality articles (which I admit I myself am guilty/of/creating, usually as testbeds) may incur a large maintenance burden. I do expect them to be easy to detect, however, as searching for the presence of "deprecated" NLG functions is trivial, and it is possible that replacing them with their future even abstracter™ counterparts could be done automatically since they all have the same signatures and can be expected to create the same form of sentence. If it needs to be done manually for a while or for certain delinquent instances, my hope is that it will be fun, at least for a while.

I just hope that these hypothetical future waves of "this new and versatile way of abstractly representing linguistic content" obsoleting previous methods and requiring refactoring across all articles is only a one-time thing. We should strive to be as robust and flexible as possible from the outset as each brand new paradigm of abstraction is also a brand new maintenance burden for updating old articles. At the end of the day, at least some of these articles will still render to many different languages even if their methods of creating those sentences of theirs is completely outdated. Ergo, the time it takes for the switchover to be performed across our articles should not be a persistent inconvenience for users (as, of course, they will always still be able to read the content as it was before since these legacy functions aren't being deleted outright), and the increased availability that the new methods will bring about will likely act as motivation for them to join the effort in refactoring (「You're telling me that if I rewrite this article in this cool Lisp-looking stuff then I can probably read it in Galician?? COOL!」). — rae^5e <talk> 20:26, 27 April 2026 (UTC)

Totally agree. Feeglgeef (talk) 02:54, 28 April 2026 (UTC)

My vague plan is to implement a default function returning an HTML fragment (Z89), for each language-neutral function. A single function would convert any of these to a Monolingual text (Z11), so that a composition of the two can be implemented as the current default until such time as the language-neutral function is ready to return a Z89. We can already convert a Z11 to a Z89 so, although there is more to be done in this space, existing language-specific functions could be adapted to return a Z89 quite mechanistically.

Although we certainly could deliver parallel Z89 functions for each existing Z11 function, I don’t think we should assume that particular outcome. Provided the Z89 captures a lang attribute from the Z11’s language tag, the two representations should be largely interchangeable, although I am expecting a Z89 to carry additional attributes at the span level that would be lost on conversion to a Z11 (along with any higher-level tags and attributes).

When I say there is “more to be done in this space”, I am referring to a new type that would allow HTML fragments to be represented as tractable Wikifunctions objects, but this is currently drafted only in my head! GrounderUK (talk) 11:21, 29 April 2026 (UTC)

Filtering types of objects

Hello!

I have tried to comb through my own edit history several times, but it's really hard to search for specifics because there's no differentiation between different types of objects (functions, implementations, tests, etc.) in the logs as far as I can tell.

Am I missing anything? I want it to work sort of like how filtering by namespace works. QuickQuokka ^{[⁠talk • contribs]} 16:48, 27 April 2026 (UTC)

There is differentiation, it's just rather hard to look through. Since all ZObjects are just JSON data at their core, you can search for instances of { "Z1K1": "Z[type]". I haven't tried this so I'm not sure how well it would work and I know MediaWiki search syntax treats quotation marks as a special character, but I have seen Wikifunctions pages link to searches using this before. There is also Special:ListObjectsByType but it is sitewide rather than specific to your edit history in particular. — rae^5e <talk> 18:59, 27 April 2026 (UTC)

[It doesn’t help directly here, but please see WF:Find for more details of how this works.] GrounderUK (talk) 10:24, 29 April 2026 (UTC)

See the feature requests phab:T399244/phab:T373735. YoshiRulz (talk) 06:06, 28 April 2026 (UTC)

The lack of filtering edits by namespace is exactly the problem that I was trying to solve with the User:Amire80/wikifunctionsanalytics tool.

I even kind of succeeded, but it has two major problems:

1. It doesn't have any real frontend, so you have to know some SQL to use it (or ask other people who know SQL).
2. It doesn't get information from the live site, but from the dump, which appears to be updated once a month.

I've made a sample query for you. Unfortunately, it won't do anything at the moment because of the second problem—your edits started in April 2026, which isn't over yet, so the dump for it hasn't been processed. But I hope that early in May you'll be able to use the same query and see something useful.

(I plan to add support for recent edits, but I haven't done it yet. Now that I more or less figured out how to process Wikifunctions edits, I'm focused on trying to understand Abstract Wikipedia edits. Processing up-to-date edits from both sites will possibly be the next thing I work on, but if you know some Python and want to try doing it yourself, don't wait for me—Patches welcome.) Amir E. Aharoni (talk) 18:51, 28 April 2026 (UTC)

@QuickQuokka, I've just updated the data until the end of April. Now the query to which I linked above gives some results. You can also try running other queries if you know SQL. (Or try asking for other queries if you don't.) Amir E. Aharoni (talk) 03:26, 3 May 2026 (UTC)

Z34213

I'm not quite sure why this implementation is failing. Could someone take a look? JJP_Master (she/they) 02:24, 28 April 2026 (UTC)

I've notified the team that this is still occurring, the issue was marked as resolved. Feeglgeef (talk) 02:52, 28 April 2026 (UTC)

Some useful tips:

• create more testcases: sometimes it is a random error, so try to see how consistent it is between testcases
• your implementation is very inefficient, since it fetches items and lexemes a lot of times. Ideally, each item and each lexeme should be only fetched once in all the execution tree.

Dv103 (talk) 06:06, 28 April 2026 (UTC)

Caching (should?) means that the lexeme and item data are cached, so the call doesn't actually execute multiple times. Feeglgeef (talk) 17:51, 28 April 2026 (UTC)

Are lexemes and items actually cached within the same function execution? Even if they are only partially fetched and/or fetched in bulk? Dv103 (talk) 17:54, 28 April 2026 (UTC)

I don't have any evidence to prove that it works but that's definitely A. what's supposed to happen and B. the ideal behavior. This happens because the Z680X functions can be cached just like any other. Feeglgeef (talk) 18:02, 28 April 2026 (UTC)

It is unclear. In general, I believe identical branches are resolved only once in orchestration, but there is also independent caching of Wikidata fetches.

According to @DMartin (WMF) (on Telegram):

Well, no. We have caching of Wikidata entities that have been retrieved, but not of the results of nested function calls. There is a proposal for doing this in the context of the V2 composition language, when it's a bit more mature, and it's regarded as a relatively high priority.

It’s hard to tell whether fetches in nested calls are, in fact, cached and available for other nested calls in the same call, since it is not generally the actual fetch that consumes the most resources. Rather (I believe), it is construction and transmission of the result object, which is currently repeated afresh in each nested call (unless it is in an identical branch).

I hope that’s clear, and I apologise in advance if it happens to be inaccurate! GrounderUK (talk) 10:16, 29 April 2026 (UTC)

Oh, I should clarify.  There is a lot of caching going on, in several different places.  Lexemes and items are cached by the orchestrator within the same function execution, even if they are only partially fetched and/or fetched in bulk.  When I said that we don't have caching of the results of nested function calls, I meant that's not happening in general, for all nested function calls in compositions.  But fetching of Wikidata entities gets special treatment, so yes, fetched content from Wikidata is cached, regardless if it was fetched by a top-level call or a nested call.

It is also true that the construction of a ZObject from the fetched JSON might happen more than once within the same function execution, depending on how a composition has been structured. However, the construction of the ZObject is actually very fast, compared to the elapsed time of getting the JSON from Wikidata. DMartin (WMF) (talk) 18:04, 1 May 2026 (UTC)

Question about cardinal numbers

I was about to edit config for cardinal from natural number (Z16435) to add my function Bulgarian cardinal with gender (Z34308), but I noticed that none of the other functions have a gender parameter.

Should I create a new wrapper function "Bulgarian cardinal, neuter", or should I just remove the gender parameter and always return neuter? QuickQuokka ^{[⁠talk • contribs]} 10:39, 28 April 2026 (UTC)

The “cardinal” functions should return the words used for “counting” numbers in the abstract.

We should consider converting them to return a Monolingual text (Z11) rather than a String (Z6). It may even be appropriate to return a Multilingual text (Z12) to cater for language variants. Either way, I think that would be the approach to adopt for inflected forms, unless reference to specific lexeme-forms is required. GrounderUK (talk) 12:52, 28 April 2026 (UTC)

This. If a native of your language were to count up, which form would they be most likely to use? Feeglgeef (talk) 13:29, 28 April 2026 (UTC)

@GrounderUK and Feeglgeef: Thanks for both your input!

I relabeled the aforementioned function to Bulgarian cardinal with gender (Z34308), and created a new wrapper function Bulgarian cardinal (Z34457).

Should I specify that my old function is a monolingual text in parentheses? QuickQuokka ^{[⁠talk • contribs]} 16:26, 28 April 2026 (UTC)

You don't have to, unless you think that is something that would require distinction when viewing the function in a list of search results &c. — rae^5e <talk> 16:36, 28 April 2026 (UTC)

Optional/nullable function parameters

Hello!

Recently, I was informed that Wikifunctions has no optional/nullable function parameters as of now.

Are there any future plans to support this, and/or workarounds? Maybe create a union type system like "String (Z6) or Nothing (Z23)". QuickQuokka ^{[⁠talk • contribs]} 17:53, 28 April 2026 (UTC)

What I do for this is use an "is empty" function corresponding to the type of the parameter in an If statement. If it isn't empty, the function works as intended. Otherwise, it does something else. JJP_Master (she/they) 17:58, 28 April 2026 (UTC)

Unions are not a thing (yet) on Wikifunctions, but you can always define an argument of type Object (Z1), which means that all types are allowed (I already did this for first part of Italian instantiating sentence (Z26737); note that it is still a ugly workaround, don't use it for high level functions). Also, note that usually on Wikifunctions we use void (Z24) as the null value. Dv103 (talk) 18:00, 28 April 2026 (UTC)

@JJPMaster and Dv103: Thanks for your help!

@Dv103 told me a function call with a missing parameter is treated as an invalid function call, so how does the "is empty" function work with that?

Also, setting the type to Object (Z1) seems naive, like setting the type as any in TypeScript...

Related question: Are there plans to add default values to parameters (outside of "if empty")? QuickQuokka ^{[⁠talk • contribs]} 18:19, 28 April 2026 (UTC)

Setting the type to Object (Z1) is actually naive, and that's why I advised you to only use it for low-level functions. Currently there is nothing better. Sometimes, type correctness is not actually checked, so it might seem that nullable types are possible. But it is still an hack, and it could broke anytime since it is not intended behavior.

I don't think that there are current plans to add default values (but correct me if I'm wrong). The closest thing that comes to my mind is that, if you incorporate Wikifunctions into Wikitext, you can leave empty some fields (only of some specific types) and Parsoid will replace them to their default value. This is done only depending on the type, and not on the functions. For example, Wikidata item reference (Z6091) and Wikidata item (Z6001) are assigned the QID associated to the page, and Gregorian calendar date (Z20420) is assigned the current date. Dv103 (talk) 18:56, 28 April 2026 (UTC)

@QuickQuokka: At the very least, Z10008 accepts a null input. Maybe that feature is unique to the String type—I am not sure. JJP_Master (she/they) 19:10, 28 April 2026 (UTC)

I think it's just not checked, but it shouldn't be intended. Dv103 (talk) 19:20, 28 April 2026 (UTC)

Strings and typed lists can be “empty” in the sense that their length can be zero. Typed pairs may also be “empty” in a degenerate sense, but such an object will not be returned from a code implementation. A typed map with no entries will also fail to be returned from code, although it is fine in compositions.

For a genuinely optional parameter, I prefer a properly typed list, which at least encourages an argument of the correct type. Is empty list (Z813) is also typically faster than is empty string (Z10008). Quite a good example of this approach is emulate Wikidata statement object (Z23723), where it helps to resolve the type union (using Z1) for both Z6003K1 and Z6003K3. Of course, there’s nothing to prevent more than one element in the list, but additional elements are easily ignored. GrounderUK (talk) 22:55, 28 April 2026 (UTC)

Pinging Jdforrester (WMF), I believe there are no current plans. Feeglgeef (talk) 19:02, 28 April 2026 (UTC)

@QuickQuokka: I'm afraid there are no current plans to build out optional params, indeed; we would be happy to review this if a compelling case was made, but it'd be a lot of work to re-build the function model with that support and ensure we don't break (too many) things. Jdforrester (WMF) (talk) 19:11, 28 April 2026 (UTC)

Z6830 for Chinese

I was trying to use Find lexemes for a Wikidata item (Z6830) for implementation in the Chinese-language. And turns out most of the Lexeme on Wikidata is using d:Q727694 as the language instead of d:Q7850. This makes it impossible to use the mentioned function above, since Standard Chinese is not available (or did I miss something?). Is there a way to fetch lexemes with language=d:Q727694 from item? Sun8908 (talk) 18:20, 30 April 2026 (UTC)

@Sun8908 There is Z1006 for Chinese and it has the language code zh. There is an overview of languages in Module:Wikifunctions label so you can search there for chinese versions and choose the one you need. Hogü-456 (talk) 20:53, 5 May 2026 (UTC)

I know that. The problem is when using the function Z6830, it cannot retrieve lexeme with language d:Q727694 (but it is the "Chinese language" with the most current Wikidata lexemes, see ordia). I think it should be a Wikidata problem, I might fix it (possibly by creating the same lexemes with language code zh) on Wikidata. Thanks anyway. Sun8908 (talk) 05:39, 6 May 2026 (UTC)

Could you provide an example of a Chinese lexeme that has a linked Wikidata item, or a Z6830 function call that fails to find such a lexeme where one exists? GrounderUK (talk) 07:55, 6 May 2026 (UTC)

Here: d:Lexeme:L846083. I think that's a primary reason of me trying to look into this problem, as the label in zh for d:Q6256 (country) is not a single phrase (see its talk page on WD for more information). This makes some Abstract Wikipedia articles very weird in Chinese when State location using entity and class (Z26570) is used, so lexeme could potentially fix that. Sun8908 (talk) 10:33, 6 May 2026 (UTC)

Thank you. It looks as though Find lexemes for a Wikidata item (Z6830) returns that lexeme for language tag "cmn". Perhaps that tag should be added into the helpers for fallback languages (Z24144)? If it is widely used for lexemes, perhaps it should have its own Natural language (Z60)? In any event, improvements might be considered under phab:T390563 (or otherwise), including amending Z6830 to also consider "cmn" (and "zho", "chi"…?) when requests are made for "zh-hans" or "zho-hant" (or others?) @Winston Sung @DMartin (WMF) GrounderUK (talk) 17:22, 6 May 2026 (UTC)

If you go to d:Special:NewLexeme and put in d:Q727694 as the language, it is going to tell you it has an unrecognized language code. So I believe "cmn" should not be a Natural language (Z60) by default? I also started a discussion on WD regarding this. I guess we can still use it as a fallback language though if possible. Sun8908 (talk) 03:43, 7 May 2026 (UTC)

We don't have a separated cmn BCP 47 language subtag in MediaWiki and Wikidata at the moment. zho and chi are ISO 639 language codes but not BCP 47 language subtags.

For Modern Standard Mandarin, please use zh-* language tags for now. -- Winston Sung (talk) 15:26, 8 May 2026 (UTC)

Key not found error

Is there a reason why I am getting key not found error for this function part-of sentence in English, impl (Z34677)? All the underlying functions run and all the test cases work. The debug information does not give more details. Any pointers? Thanks in advance John Samuel 19:24, 1 May 2026 (UTC)

It was passing the Z6091 to item is part of these items (Z34641) when that takes a Z6001. I've fixed that, but there's some other problem with the logic, so I've left it disconnected. YoshiRulz (talk) 19:42, 1 May 2026 (UTC)

@YoshiRulz Thanks a lot. John Samuel 20:21, 1 May 2026 (UTC)

Wikifunctions & Abstract Wikipedia Newsletter #246 is out: Request for input: what should we count for Abstract Wikipedia

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

In this issue, we ask you what would be the relevant metrics for Abstract Wikipedia, we discuss our latest news on Composition Language v2, 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:21, 2 May 2026 (UTC)

Any formal process for deletion of pages

Does a formal process exist for the deletion of functions, implementations, and tests that includes a notification system for creators, analogous to Wikidata’s process, explaining the rationale behind the deletion (or proposal for deletion)? John Samuel 12:36, 3 May 2026 (UTC)

Does Wikifunctions:Requests for deletions work? Amir E. Aharoni (talk) 13:00, 3 May 2026 (UTC)

Please see the discussion at Wikifunctions talk:Requests for deletions#Should we expect Objects' creators to get pinged on deletion proposals?.

As I see it, it is the proposer’s responsibility to consult appropriately before making a request and we expect our administrators to act only when satisfied that appropriate consultation has occurred. In many cases, no consultation is required. Administrators may delete their own contributions without making a request, but this is not a practice I would encourage. GrounderUK (talk) 13:51, 3 May 2026 (UTC)

Implementation of rational number in JS doesn't match in Z19677 (Rational number) and Z28579 (RGBA colour)

In Rational number (Z19677) it's

{
	"K1": sign * numerator,
	"K2": denominator
}

but in RGBA color (Z28579) it's

[ sign * numerator, denominator ]

dringsim 05:15, 4 May 2026 (UTC)

I'm guessing this is why Z34743 fails all the tests. YoshiRulz (talk) 01:00, 18 May 2026 (UTC)

Nested functions in compositions

I wish it will be easier to a add another function about a specific existing function in a function implementation based on a composition. When I write long functions in spreadsheets I usually stat with a small part and then I try to go further and after important steps I test if the output is as expected. I created Z34826 to get the German gender specific occupation lexeme for a specific person based on their gender. I wanted to add a function around the existing one and it was not successful. It is not very easy to implement as it requires the possibily to move a part to another section but I think it can be helpful if it will be implemented. So far I spend more time as expected on the function. Describing it with words what the function needs to do is much easier than implementing it here in Wikifunctions. So I think there needs to be improvement to make Wikifunctions more accessible. Hogü-456 (talk) 21:10, 5 May 2026 (UTC)

Have you tried to use the copy-paste functionality? It is very useful to move parts of composition arounn. Dv103 (talk) 07:12, 6 May 2026 (UTC)

I've also found the composition editor to be wholly unsuitable for any expressions more than a few levels deep. (Even with the localStorage clipboard, because of its overzealous type checks.) Compositions naturally grow out from the "leaves", the immediate operations on the inputs, while the interface really wants you to build from the "root". I mostly use the drag-and-drop block editor which I made to smooth over some of the site's problems, so if you want to try that out and give me some feedback I'd appreciate it. YoshiRulz (talk) 14:36, 6 May 2026 (UTC)

Wikifunctions & Abstract Wikipedia Newsletter #247 is out: References from Wikidata now available

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

In this issue, we announce that is now possible to pass references in Wikidata statements, we introduce the Abstract Data dashboard, we report you on the presentation about Abstract Wikipedia at WikiCon Australia, 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 May 11, at 17:30 UTC (link to the meeting).

Enjoy the reading! -- User:Sannita (WMF) (talk) 11:16, 8 May 2026 (UTC)

RGBA colour, spelling...

Something that has always irked me a little bit is the spelling of RGBA colour (Z28579). I guess this is not unsurprising for me considering my use of US English but I think there is more to it than preference and I want to try to argue for it being changed to use American spelling. I know that this probably has a snowball's chance in hell of actually garnering any support, so I won't really be miffed if the spelling remains as it is, but I thought it wouldn't hurt to raise this regardless.

The main issue I have with it is the spelling of the original proposal. When infernostars raised the type proposal, the spelling was 「RGBA color」. Of the comments that mentioned the word 「colo[u]r」, two used British spelling while six used the American spelling as used in the proposal. The only thing that really pointed to the use of colour was the fact that the catalog page on color functions used that spelling already. For all intents and purposes, the spelling of the original proposal should have been maintained, but it was not; DVrandecic, the eventual creator of the type, used a different spelling.

It should be noted that there was really no reason for this to occur and while it is an undoubtedly minor issue I still believe it should be rolled back and the type should use the spelling of the original proposal and majority of editor comments. In OpenStreetMap, there have been keyvalue proposals that have had the finalized spelling that gets put to use be in British English despite the original proposal being in American English; this has usually occurred with proposals relating to 「X center/centre」 tags. This makes sense on the surface, because OpenStreetMap is maintained by a UK organization, and still has close ties to Europe. The Wikimedia Foundation, however, is an American company. This is often brought up as a fallible argument when debating article spelling on the English Wikipedia, and I don't bring it up to support that 「RGBA color」 should be used for that exact reason, but rather to state that OpenStreetMap's general policy on tag names need not apply here. It appears to me that, at least initially, the majority of 「core contributors」 to Wikifunctions used British English; I can name YoshiRulz, 99of9, GrounderUK, and VIGNERON. I see (or saw) these people everywhere, so it makes sense that British English has prevailed in some sorts on this website, but I don't think that indicates that it should be the preferred spelling across the website, at least not to the point where a proposal should have its name changed to match such a "consensus".

The unnecessary modification of the original spelling is my main argument for changing it back... but of course, I must obligatorily state that on English Wikipedia, it is Color and RGBA color model; on Wikidata, it is color and RGBA color space; in CSS (which typically uses hexadecimal triplets to specify RGBA values), the properties are color, background-color, etc.; bit of a weak jab, but on Schema.org it is color, colorSwatch; et cetera. same RGBA color (Z28580) uses color, so does JS converter from RGBA color (Z28591) and its Python counterpart.

Mr. Vrandečić, I have to ask, I'm rather confused... you created the color type using British English spelling, but you were also responsible for the creation of the equality function which uses the American English spelling. You also seem to be writing in American English for the status updates, judging by your use of -ize over -ise endings and use of program over programme in Wikifunctions:Status updates/2026-04-16. Is there something I'm missing or have you switched your preferred variant somewhere along the way?

Anyways, do consider this if you wish... again, I don't suppose this will garner much support, it is the non-issuest of non-issues, but it has irked me to the point where I want to ask about it to get some answers, if nothing else. I am not arguing for every other color function to have its name changed, just the type itself.

— rae^5e <talk> 14:04, 8 May 2026 (UTC)

This is a multilingual project; the en label is RGBA colour and the en-us label is RGBA color. Though I'm not able to switch to en-us via the language picker so that would need to be fixed.
edit after reading your whole comment: The same is true of color (Q1075), there are labels specified for multiple English variants. (In RGBA color space (Q2325624) it's only an alias.) I agree that other websites' choices aren't binding on us, but from that, I conclude that the more widespread British/Commonwealth spellings should be used for the generic en. As for myself, I'm Aussie and I will continue to use the BrE spellings (+ "routing", TIL) if only by muscle memory.
YoshiRulz (talk) 17:42, 8 May 2026 (UTC)

Your lattermost point would normally be fine in a perfect world. Wikipedia's convert function defaults to "international" English, which I don't personally take issue with because it happens that we here in America are actually outliers for saying and spelling things differently... err, or we were for a while at least, nowadays it seems like an even split (plus you have "yield" vs. "give way" which is effectively the logical opposite of US's use of "meter" over "metre").

However, this is not a perfect world, and I don't think en should correspond to any particular variant. It is too fragmented across all software at this point to impose such a requirement. The inability to switch to en-us on this website foregoes an easy and simple solution to this problem that makes everyone happy, because the yanks (such as myself) can't be happy because we can't see the labels in American English even if we wanted to, and the other folk can't switch either as far as I'm aware (and the en-CA and en-GB languages in the preferences page seems to be deprecated). My point being, en is abused to mean "en-UK" just as often as it is abused to mean en-US; I think a decision shouldn't be made on such an assumption of one "default". — rae^5e <talk> 14:48, 12 May 2026 (UTC)

Hi @rae! I have no opinion nor preference on this, and given my background, I am just entirely confused about my spelling preferences myself, as you can tell from my inconsistent usage. I learned British English in school and used that for maybe two decades or so, but moved to the US and lived there for more than a decade, enough to be naturalized, but now I am back in Europe and I am technically a professor at King's College London, soooo.... honestly, I do not know. I don't remember having put too much thought into it at the moment I created it. The good thing is that in Wikifunctions, just as in Wikidata, it is easy to change, without messing things up too much (unlike in Wikipedia), so my suggestion is, just make the change, see if anyone complains, and if they do, discuss it more. I don't know if there is a guideline already in Wikifunctions about the variants. I am happy either way, and honestly, I keep forgetting which variant is which most of the time. --DVrandecic (WMF) (talk) 18:16, 10 May 2026 (UTC)

I can definitely understand this, although I am unfortunately rather passionate about any minutiae involving preferential minor differences in anything, of which AmE vs. BrE chiefly is. So I dedicate a lot of headspace to it. More than I should. Not that I wish to imply that the comment above that I have wrote is of an irrational nature, or done out of spite or pure emotion and subjectivity; I do genuinely believe that RGBA color is beyond just a personal preference and is just logical. I may boldly go and change it, but for some reason I was expecting that changing the English label of a Type would require elevated permissions, and I also didn't want to do it only to get immediately reverted because it did strike a chord with someone, when I could instead see how apathetic, supportive, or in opposition interested people are beforehand and then act accordingly. I was not meaning to antagonize you over your spelling habits, I did actually use British English for a few years starting in 2020 before I went back to American English, so I'd be a hypocrite for me to decry you for not always sticking to some arbitrary standard of spelling words over the other. — rae^5e <talk> 14:55, 12 May 2026 (UTC)

Although I spell it “colour”, I think it makes more sense to use “color” for the type, since that is almost always the required spelling when the string functions as a keyword.

More generally, though, Wikidata’s lexicographic data happens to favour “colour” over “color” and (quite rightly, in my view) lacks a specific representation for "en". This is unusual, in my experience, as "en" is widely misused in place of "en-US", where there are recorded spelling differences.

(I would also say it is standard British English to use “program” in a programming context and “programme” elsewhere. Use of -ize rather than -ise is a matter of personal preference or house style, but regional autocorrect encourages -ise.) GrounderUK (talk) 11:00, 12 May 2026 (UTC)

Wikidata’s lexicographic data happens to favour “colour” over “color” and (quite rightly, in my view) lacks a specific representation for "en"

Definitely agreeing with you on the latter being a good choice. However, I suspect the favoring of "colour" over "color" may be because, in terms of language codes, when sorted alphabetically en-us actually comes after en-gb. Although, the frontend seems to be sorting en-ca after en-gb, so I don't actually know how correct that is.

I would also say it is standard British English to use “program” in a programming context and “programme” elsewhere

The context of the spelling was "No program for the NLG SIG meeting for next Tuesday has been proposed". In that usage context, I think it makes sense to assume that program is not being used to refer to a computer program, but to a program of events or similar, something that you would spell as a programme in British English. — rae^5e <talk> 15:02, 12 May 2026 (UTC)

 Support this. I'm obviously biased but I believe American English is preferable generally, American dominance on the internet (our Department of Defense invented it!) and rapidly-increasing consumption of American media by international English speakers means that more people use American English's conventions, this is clear through for example search trends (though they aren't particularly reliable). Perhaps this is a bit of a supremacist opinion, but we should have internal consistency, and if we must choose, American English should be our first choice (then Indian and then British English) Feeglgeef (talk) 14:10, 12 May 2026 (UTC)

This is rather flawed reasoning, though. I think probably any given British or Indian person would not agree on using that as the reasoning for this, not that you are necessarily completely wrong, but if this is not a good enough reason for English Wikipedia's (admittedly extremely flawed) ENGVAR policy then I don't think it's likely it will pass here either.

Although of note is that Google ngrams agree with you, but "color" vs. "colour" is an eternal holy war that will not be won by demonstrating that more books use US spelling over Commonwealth spelling. — rae^5e <talk> 14:44, 12 May 2026 (UTC)

You're probably right that it's not very sound. I'm biased in that other varieties of English irk me, and that's probably mutual for people who are used to other varieties of English when they read what I write! Feeglgeef (talk) 14:56, 12 May 2026 (UTC)

I've decided to boldly make the change. Feeglgeef (talk) 15:02, 12 May 2026 (UTC)

Thank you. Considering both you and GrounderUK seem to consider it an okay change, I think this will do for now.

I should note that the matter of whether to move Wikifunctions:Catalogue/Colour functions in response to this (however this discussion will ultimately turn out) is a whole other can of worms, in my view. I can't say I have an opinion on that at the moment, but I'm putting it out there regardless. — rae^5e <talk> 15:06, 12 May 2026 (UTC)

Personally, I'm in favor of moving the page and renaming all of the items on it. Feeglgeef (talk) 15:10, 12 May 2026 (UTC)

I don't like this (exactly because of the American hegemony you cited), but again, it shouldn't matter because the software is meant to be multilingual. Clearly there's a bug preventing you from picking an English variant/dialect as your display language. But the search bar and Function/Type autocompletion do check the English variants for matches. YoshiRulz (talk) 15:15, 12 May 2026 (UTC)

Proposals on the architecture of Abstract Content rendering

Starting from a discussion born on the Telegram chat, I've explained two different proposals on how the NLG on Abstract Wikipedia should be organized in the page abstract:User:Dv103/Abstract articles architectures. Please come to contribute to the discussion, or to propose alternatives. Dv103 (talk) 14:31, 11 May 2026 (UTC)

Thank you for dedicating your time to writing this, it is very informative. I will try to add input once I'm not in over my head with finals. — rae^5e <talk> 16:27, 12 May 2026 (UTC)

Display function for HTML fragment

Currently, any collapsed Z89 literal appears as

<> HTML fragment

If I were to create a new Function which returned something like

<> 123-byte HTML fragment <td><span lang=…

could that be connected to replace the collapsed form, or would it require changes to the Wikilambda software? YoshiRulz (talk) 16:14, 11 May 2026 (UTC)

It might work, but I doubt it. Those angled brackets suggest that the collapsed form is not simply defaulting to the type’s label. Looking at phab:T410509, I’ve concluded that enhancements to the collapsed form were never considered, rather than being actively rejected. GrounderUK (talk) 12:12, 12 May 2026 (UTC)

Phab:T391985 documents the original design. Note the fifth bullet point under “Acceptance criteria”. GrounderUK (talk) 12:21, 12 May 2026 (UTC)

I'm not sure the byte-size is necessary, but the outer tag (or first outer tag, though generally I'd prefer most fragments use a wrapper tag if it needs multiple like JSX does, but that's a whole different topic) would be nice. Feeglgeef (talk) 12:51, 12 May 2026 (UTC)

Wikifunctions & Abstract Wikipedia Newsletter #248 is out: A higher meaning

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

In this issue, we discuss functions creating language fragments, we present our latest news in Types, 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) 14:36, 15 May 2026 (UTC)

Z34510

This function, which determines if a Wikidata item for a human (Q5) has an undeprecated sex or gender (P21) statement of male (Q6581097), returns false for Elliot Page (Q173399), a transgender man. This is because his item assigns his P21 statement to trans man (Q2449503), not male (Q6581097). I'm not sure how to account for this discrepancy. Should Q5 is male? (Z34510):

1. Include trans man (Q2449503) as a value that can lead to a true result,
2. Not include trans man (Q2449503) as a value that can lead to a true result, while another function (e.g., "Q5 is a man?") could return true for either "male" or "trans man",
3. Not include trans man (Q2449503) as a value that can lead to a true result, while another function (e.g., "Q5 is a trans man?") could return true for "trans man",
4. Not exist at all?

JJP_Master (she/they) 16:48, 16 May 2026 (UTC)

I can't think of a single use case where you would need to determine if a person is a cisgender man and nothing else. Functions are good for generalizing across multiple possibilities when they exist, so I think it would be best if trans men were considered a part of the criteria for returning a true value. If asking for specifically male (Q6581097)s and nothing else was desired then the function name would be a misnomer as Elliot Page is inarguably a male (at least in the view of most reasonable and intelligent people). — rae^5e <talk> 19:03, 16 May 2026 (UTC)

You made the function in the first place; what were you planning on using it for? AW? Maybe it should return a Grammatical gender (m/f/n) (Z25501) which can then be passed on to other NLG functions. YoshiRulz (talk) 20:01, 16 May 2026 (UTC)

Lexeme from wikidata label, or "best" lexeme from wikidata item

I was looking into fixing Z28028. I found that I could add "requires grammatical feature: definite article" to "United Kingdom" (L8558). Now I'm stuck on how to get to that lexeme from United Kingdom (Q145). There's Z23471, but that for very good reason gives you multiple lexemes with the same sense, and I just want the best one like how the label is always the best string. Is there a function that can do this?

There's definitely the case of a Wikidata label that isn't a lexeme (most commonly multiple lexemes) but I'm only considering the case where it is one lexeme here. Aaron Liu (talk) 20:02, 16 May 2026 (UTC)

There is best lexeme for Wikidata item (Z27327), that tries to give the best lexeme through various heuristics. Dv103 (talk) 22:22, 16 May 2026 (UTC)

Wonderful! I did stumble upon Z33818 but this is perfect. Aaron Liu (talk) 00:25, 17 May 2026 (UTC)

Z29591 isn't working for me

For instance, trying to manually put in the exact inputs for one of the test cases just returns an empty Monolingual text. See . JJP_Master (she/they) 01:17, 17 May 2026 (UTC)

You used d:Q22006653 rather than d:Q1075. It looks like the explanatory error is suppressed by the final transformation. The returned result is not actually empty; if you expand it, you can see that it is an unresolved function call. GrounderUK (talk) 09:59, 17 May 2026 (UTC)

Z35298

Does anyone know what the problem with this implementation is? JJP_Master (she/they) 21:14, 18 May 2026 (UTC)

There is a bug that doesn't allow Python implementation to return nested lists. Dv103 (talk) 05:31, 19 May 2026 (UTC)