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

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)

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)

Moved to Talk:Z28579 so this doesn't get lost, and made a request on the Administrators' noticeboard. YoshiRulz (talk) 17:39, 5 June 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)

Is there a Phabricator task for this? Searching through them is hell. — rae^5e <talk> 03:22, 20 May 2026 (UTC)

A bit of time ago I opened phab:T392750, which is very similar to this issue. Dv103 (talk) 05:26, 20 May 2026 (UTC)

May 2026 Wikimedia Café meetups regarding the Wikimedia Foundation Annual Plan

Hello! There will be two Wikimedia Café discussion opportunities during the last weekend of May. Both sessions will focus on the the 2026-2027 Wikimedia Foundation Annual Plan. Participants may attend either or both sessions.

1. Saturday, 30 May 2026 at 15:00 UTC (timestamp converter), at a time friendly to the Americas, Africa, and Europe
2. Sunday, 31 May 2026 at 05:00 UTC (timestamp converter), at a time friendly to Asia and the Pacific

Café participants are highly encouraged to read in advance at least this summary of the plan. Optionally, Café participants are encouraged to read portions of the plan that interest them and ask questions or provide feedback on the Annual Plan talk page.

Please see the Café page for more information, including tables of timestamp conversions for both sessions, the agenda, and how to register!

↠Pine (✉) 19:56, 21 May 2026 (UTC)

How to handle items without lexemes

NLG functions relay heavily on the presence of lexemes associated to items on Wikidata. But we know that not all the Wikidata items have an associated lexeme. There are multiple reasons why an item does not have an associated lexeme, like:

1. The lexeme has not been created yet
2. The item represents a place
3. The item represents a person
4. The item represents a specific concept that can only be expressed by a specific combination of words that cannot be notable (like Star Trek episode (Q61220733)).

My doubt is: what should we do with this fourth category? For many languages, just using the Wikidata item label is not possible, since it is necessary to conjugate the words or to retrieve grammatical information like the gender. What should we do? Dv103 (talk) 16:09, 23 May 2026 (UTC)

In that particular example, I think the thing to do is read its subclass of (P279): television series episode (Q21191270), then have some kind of heuristic based on that which says to take its media franchise (P8345) and attach that Item's label to a Form of the word for "episode". In general, synthesising Lexemes for proper nouns is one of the problems that proposals in your list here will have to address. YoshiRulz (talk) 22:59, 23 May 2026 (UTC)

Content of Wikidata by type

@Dv103: very good point.

For your point 2, it depends of the place but I think that quite often a lexeme can be created (most "Administrative territorial entity", most geographical entity, etc.). And with 3, your can add a lot of types (see pie chart) : Scholarly article, Human (with a very few exception), Wikimedia Category, Disambig, etc. which is (rough estimation) 2/3 of Wikidata items.

A common rule (in dictionaries since forever and in Lexemes) is to not create an entry which is the "sum of its part". In this case, "Star Trek episode" is just episode + Star Trek, nothing more than its part. So logically, as YoshiRulz said, when no corresponding lexeme is found, the item should be decomposed the same way, the hard part is to know how to decompose it as the property will vary ; P31 and P279 are an obvious start but beyond that, I'm not sure we could find a general solution.

PS: it's beyond you question but there is also the reverse problem, how to select one lexeme when multiple are linked to the same item...

Cheers, VIGNERON (talk) 10:43, 24 May 2026 (UTC)

For the point 2, I think humans will be used way more than scholarly articles and disambiguations in NLG functions (outside references), that's why humans concern me more (still a cool pie chart, though).

For the reverse problem, there is already best lexeme for Wikidata item (Z27327): it's far from perfect, but usually makes a decent choice. Obviously it is not "complete", and probably it will never be complete, but it will have to be progressively improved by the community. And probably in the future we will need to create similar functions to select the best lexeme in more specific cases.

For my fourth point, I didn't think about the decomposition, but it is something that could be done with another never-complete community-mantained function, that progressively keeps being improved. If semantic units will be implemented, through them it could actually be possible to do this operation in a laguage-independent way. Dv103 (talk) 12:10, 24 May 2026 (UTC)

@YoshiRulz: Proper noun synthesis, along with other fallbacks for realizing the names of concepts that don't have lexemes, is merely a step within the overall abstract content rendering process and is not inherently tied to the process itself; having the ability to run any number of fallback mechanisms, instead of a raw call to (the equivalent of) Z27327, should be possible with any of the methods listed on the architectures page. Mahir256 (talk) 16:41, 24 May 2026 (UTC)

Wikifunctions & Abstract Wikipedia Newsletter #249 is out: Annual plan 2026-2027

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

In this issue, we present you the current draft of objectives for Wikifunctions and Abstract Wikipedia in the WMF Annual Plan 2026-2027, 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:48, 25 May 2026 (UTC)

The new return_type param to Special:ListObjectsByType will show Functions returning e.g. Chemical element (Z27951) and Typed pair (Z882) if those are typed in manually, but the dropdown menu doesn't offer them, probably because it's a copy of the dropdown above (and there are no Persistent objects of those Types). YoshiRulz (talk) 10:12, 26 May 2026 (UTC)

@YoshiRulz: Correct, it's filtering for Types, which includes "real" enums like Day of Roman year (Z20342); light-weight enums have downsides as well as upsides, of which this is one. :-( Jdforrester (WMF) (talk) 14:39, 1 June 2026 (UTC)

I assume you mean Day of the week (Z17402), since Day of Roman year (Z20342) is not an enumeration type? But I never mentioned enums: My hypothesis is that a Type appears in the dropdown iff there is a Persistent object of that type (Z2K2.Z1K1). Whereas I would expect a Type to appear in the dropdown iff there are any Functions which return objects of that type (Z2K2.Z8K2). Or just show every Type in the return type dropdown, since you already have a "no results" message. YoshiRulz (talk) 16:53, 1 June 2026 (UTC)

@YoshiRulz: Yes, you are correct, the concept of a Type here means "there is a Persistent object of that type". Other things (in practice, light-weight enums like Z27951) aren't Types. Jdforrester (WMF) (talk) 16:57, 1 June 2026 (UTC)

Type documentation template

Over the past couple of weeks, I've been developing and rolling out {{Type documentation}}: a standardised layout for Type metadata, de/constructors, conversions, etc. on each Type's talk page. (The layout is loosely based on Wikidata's.) See Integer for an example that uses most of its features, and Quote for one that doesn't.
At this point I can't think of anything more to add besides filling out a couple more tables. But if any of you have ideas or feedback, please click through to the relevant talk page and leave me a message. YoshiRulz (talk) 12:29, 26 May 2026 (UTC)

I really like what you're doing here. Thank you. --99of9 (talk) 13:26, 26 May 2026 (UTC)

Yeah, nice work! I don’t think “Function declarations” is the best header for the collapsed table of searches by function signature, however. Now that it’s finally landed, we should probably include https://www.wikifunctions.org/wiki/Special:ListObjectsByType?type=Z8&return_type=Z16683 as well (outside the table). GrounderUK (talk) 16:23, 26 May 2026 (UTC)

Apparent error in implementations of grammatical genders from Wikidata lexeme (Z20616)

Please can I request help in how to understand a bug? Sorry if this is not the best place to ask.

I created lexemes langue morte L1566135 in French and lengua muerta L1566139 in Spanish, with property grammatical gender (P5185) set to feminine (Q1775415) in each case. grammatical genders from Wikidata lexeme (Z20616) should return a list of the grammatical genders of a given lexeme. It has two implementations, map filter get claims (Z20641) and gender list from Wikidata lexeme, Python (Z21127), each of which works perfectly in the French case, returning a list containing Q1775415. But in the Spanish case, each of the two implementations wrongly returns an empty list. I cannot understand what is going wrong. How can I find out what is happening here? I would be grateful for any help or advice. Strobilomyces (talk) 13:56, 26 May 2026 (UTC)

Both implementations return the same result. As you added the gender only yesterday, I suppose it must have still been looking at a cached version of the lexeme from before that edit. GrounderUK (talk) 16:06, 26 May 2026 (UTC)

Thank you for answering. Yes, it works now. I thought it might have been something like that, but I waited more than 12 hours before testing it again today. I think that whenever SPARQL is in use, there will be caching issues, and it is a very bad problem. Is there any way of clearing the cache, or knowing when the cache will next be cleared, or how long it is necessary to wait before the changes come through? Strobilomyces (talk) 18:59, 26 May 2026 (UTC)

Well, it depends on the cache. “Wikidata entities in the orchestrator cache timeout after 24 hours” according to @DMartin (WMF). There is currently no way to clear that. I don’t think we have a handy guide to the different caches in operation, but the “general” function-call cache should be reset for a particular function when that function is edited. GrounderUK (talk) 22:05, 26 May 2026 (UTC)

I think this is very unfortunate for anyone doing tests in Wikifunctions. So there is a 24-hour delay even applying to changes in Wikidata due to the Wikifunctions orchestrator cache, apart from any other caches such as the SPARQL one. I notice that an intermediate-level call using the lengua muerta L1566139 lexeme change, subject is instance of, with needed args (Z33725), now works on "latín es una lengua muerta.", but the top-level call subject is instance of (string) (Z26039) still does not find the correct gender. If I test the function every 12 hours, does that mean that the erroneous result will be produced for ever, because it will always take the bad value less than 24 hours old from the cache? Strobilomyces (talk) 13:45, 27 May 2026 (UTC)

I can only sympathize.

It seems to me that this has been correct for a couple of days. But in the general case, no, repeated use of cached results does not re-start the clock. That would indeed be most unfortunate! GrounderUK (talk) 13:59, 27 May 2026 (UTC)

It still doesn't work for me, it says "latín es un lengua muerta." But the test on the top-level implementation page, subject is instance of, with needed args (Z33725), does work now. By the way, really it should say "el latín es una lengua muerta.", but that is another issue. Anyway, thanks a lot for your help. Strobilomyces (talk) 14:06, 27 May 2026 (UTC)

Ah, yes… my mistake, sorry.

It should be consistent now. The “couple of days” is the clue here; we were getting a result from the function-call cache and this has now been refreshed by my edit. GrounderUK (talk) 14:25, 27 May 2026 (UTC)

Yes, it all works now. Thanks. Strobilomyces (talk) 14:54, 27 May 2026 (UTC)

Vote now in the 2026 U4C election

Eligible voters are asked to participate in the 2026 Universal Code of Conduct Coordinating Committee election. More information–including an eligibility check, voting process information, candidate information, and a link to the vote–are available on Meta at the 2026 Election information page. The vote closes on 2 June 2026 at 00:00 UTC.

Please vote if your account is eligible. Results will be available by 14 June 2026. -- In cooperation with the U4C,

Keegan (WMF) (talk) 17:14, 27 May 2026 (UTC)

Z35880

The code of this implementation is adapted directly from . I'm not sure why this function only works for "null" and "sort". Every other input causes the function to return Z577. Does anyone know what could be going on here? JJP_Master (she/they) 21:47, 30 May 2026 (UTC)

Could you creade testcases showing this? Dv103 (talk) 21:55, 30 May 2026 (UTC)

I determined that this problem was due to a problem with UTF encoding, and it has since been resolved. JJP_Master (she/they) 18:11, 31 May 2026 (UTC)

Continued WASI runner problems

I've continued to experience Could not acquire WASI runner within time limit (Z576) on convert symbols in SWU string to FSW (Z35904), despite the purported fix. See 𝠀񀀒񀀚񋚥񋛩𝠃𝤟𝤩񋛩𝣵𝤐񀀒𝤇𝣤񋚥𝤐𝤆񀀚𝣮𝣭 (Z35945). JJP_Master (she/they) 18:29, 31 May 2026 (UTC)

A possibly related issue while trying to add more rows in these articles :

1. https://abstract.wikipedia.org/view/en/Q16038495

2. https://abstract.wikipedia.org/view/en/Q13581178

So, I stopped at 2 rows. John Samuel 20:40, 31 May 2026 (UTC)

Wikifunctions & Abstract Wikipedia Newsletter #250 is out: Looking back and forward

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

In this issue, we present you a recollection of our work so far, now that we celebrate our 250th newsletter, we share with you a summary of our latest outreach activities, 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) 10:04, 1 June 2026 (UTC)

Wikifunctions & Abstract Wikipedia Newsletter #251 is out: The illustrated encyclopaedia

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

In this issue, we introduce our first function to import images on Abstract Wikipedia, we present our Functions of the Week, 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 June 8, at 17:30 UTC (link to the meeting).

Enjoy the reading! -- User:Sannita (WMF) (talk) 14:14, 5 June 2026 (UTC)

Questions on a simple fragment example "The Eiffel Tower is a monument"

Hello. I would like to be able to use the function subject is instance of (string) (Z26039) to generate sentences like "the Eiffel Tower is a monument" or "la torre Eiffel es un monumento" in Spanish. It already raises a lot of questions.

Question 1: I should be able to set the first input "entity" to Eiffel Tower (Q243) and the second input "class" to monument (Q4989906) and get the correct sentence, shouldn't I? Just checking.

Question 2: subject is instance of (string) (Z26039) calls a language-specific function like "Spanish article-less instantiating sentence" Spanish article-less instantiating sentence (Z26337), which uses the label of the Wikidata item to get the text for "Eiffel Tower", which is similar to the lemma of the lexeme. But this would not be acceptable in production, would it? The item label "belongs" to all Wikidata users, not to Abstract Wikipedia users, and there is no guarantee what it might contain, such as a parenthesis for disambiguation. Or am I wrong?

Question 3a: We need to have a lexeme for the combination "Eiffel Tower" in each language, don't we? For instance in languages with gender, the lexeme is the only place to find the gender. It is true that if we know that the equivalent of "Tower" is the head word, syntactical information can be found under the lexeme for "tower", and it would be good to use a system like that. But the only place that the syntactic dependency information could be located is under the lexeme.

Question 3b: At present for subject is instance of (string) (Z26039) etc. to work, we have to add any forms or syntax information to the lexeme of the whole phrase, such as "Eiffel Tower". But property combines lexemes (P5238) with attributes syntactic dependency head relationship (P9763) and syntactic dependency head position (P9764) can be used to define the structure and avoid duplicating the syntax information. What lexeme would be used for "Eiffel" in this case? Would it be the same as a lexeme for Gustave Eiffel (Q20882)? That makes no sense to me. I propose that there should be a dummy lexeme in each language which could be added to combines lexemes (P5238) instead of a real lexeme to mean "invariant element".

Question 4: As has already been pointed out elsewhere, the fragment functions do not work well with the initial definite article in languages like English, Spanish and German. Examples:

• "The Eiffel Tower is a monument." The item label "Eiffel Tower" omits the article and so the result omits the initial "The" in English. French, Spanish and German are similar.
• "The Sun is a star." Similarly the article is wrongly omitted, also in French, Spanish and German.
• "Westminster Abbey is a monument." This is OK in English and German as no article is needed, but not in French or Spanish where it is, for instance "La Abadía de Westminster es un monumento".
• "Latin is a dead language." Also this is OK in English and German but not in French or Spanish, where an article is needed.
• "Jupiter is a planet.". This does not need an article and is OK in all the languages; I include this to show that you cannot assume that there is an article in all cases in French and Spanish.

How should the language functions find out whether an article is needed? In some cases, where the lemma is a phrase like "Abadía de Westminster" in Spanish, I think that it could be deduced, but in general there is no rule to give the answer. Using different rendering functions according to the case is not a solution, although it might work for a few specific languages like these four. It would not be acceptable because there will be many, many other cases of syntactical choices to be made for all the different languages, and we cannot expect the person writing the abstract code to take them all into account. So I suppose that a declaration in the lexeme is needed to solve this problem. I suppose that there must already be linguistic terminology for this problem, but I don't know it.

I would be grateful for any comments on any of these questions. Strobilomyces (talk) 15:02, 5 June 2026 (UTC)