Jump to content

Wikifunctions:Wikimania 2026 survey

From Wikifunctions
Latest comment: 5 days ago by Jdforrester (WMF) in topic Individual fragment editing

Thank you to so many of you who came in-person and online to the workshop at Wikimania last week around creating Abstract Wikipedia articles.


Based on your comments there and things you ran into or mentioned, we've pulled together a quick ideas list of possible improvements (alongside our work on faster and better NLG support, working with communities to consider piloting Abstract Wikipedia on their wiki, and other major parts of the annual plan).

Please indicate which items you think we should work on soonest by signing your name (~~~~) below them. We'll probably work on many of these, but the count of "votes" and arguments will help guide us in which ones we prioritise.

Individual fragment editing

Latest comment: 5 days ago15 comments9 people in discussion

These are some ideas about how we might make adding and editing individual fragments easier.

Done Only auto-match the Wikidata item to the subject of the article on the first item in a Function call, not all of them

Tracked in Phabricator:
Task T435657
This should avoid the confusing step of suggested items saying "Cairo is the Cairo of Cairo", but instead would need you to specify the item references for the others. The heuristic of only matching the first item might be enough as a starting point for many calls. We probably still want to match all dates and languages, though.

Please take note of phab:T435657#12335577.

Note: This was implemented slightly differently, with items rather than arguments, so it's easier to edit. Jdforrester (WMF) (talk) 16:10, 5 October 2026 (UTC)Reply

Split out some of the '…' menu on each item so you can quickly switch to a manual item reference

A big stumbling block for folks was switching from an auto-matched (argument key) item or a function call to a specific item reference. This would allow you to quickly switch to that, without having to notice and go through the menu of all the other options.

Done Re-word the labels for the abstract argument keys to be more clear about what they are

We label the keys as 'wikidata item reference', 'language', and 'date'; we should make it clearer that these are 'this article's subject', 'view language', and 'view date' respectively. This would help avoid confusion about what these keys are for, and when you don't want to use them.

Add short description fields to Functions' arguments, to help people can understand what the inputs mean when they use them

For Functions, we have labels, aliases, and short descriptions, but Functions' inputs just have a single label each, which can make it hard for people to know what to put where, especially if they have unusual or unfamiliar words. Add a short description field, maybe shown via a secondary accessor like a "" rather than all the time.
  • Better documentation of existing functions may also help. The existing one seem outdated or too complicated. We could have pages like "useful functions for towns". Descriptions should also help searching and finding the right function. Jeanne Noiraud (talk) 18:04, 11 August 2026 (UTC)Reply

Example: Thing to fix (copy me!)

What it would involve, and why it would be valuable.
  • Sign here

New/better kinds of fragment

Latest comment: 1 month ago7 comments5 people in discussion

Here are some ideas for different kinds of fragments that you could use in abstract articles.

Add support for pulling structured data from Commons files e.g. captions

Right now you can put in image files themselves, but you can't fetch any data about them. This is particularly unhelpful as the Wikidata items still use the File: name rather than the MID; we'd need to add the ability to fetch meta-data from Commons to the back-end services, like we do from Wikidata.
  • Neutral Comment The suggestion of accepting Commons filenames as well as MIDs would mean that media values and their qualifiers could be pulled from a Wikidata Item, but most of the metadata isn't there, it's on Commons. I'm not sure which parts from Commons would be useful, maybe the author/licence, maybe the structured data ('depicts' etc.). Does anyone know of a Scribunto module on a sister project which uses metadata from Commons? YoshiRulz (talk) 20:45, 9 August 2026 (UTC)Reply
  • It would be simpler to have a function to generate the caption ? Jeanne Noiraud (talk) 17:51, 11 August 2026 (UTC)Reply
  • Sign here

Add support for video/audio file inclusions

You can only specify image files, not audio or video files which are more complex. If demand is high we could add this sooner rather than later, though it may be complex to align with the existing workflows.
  • Sign here

Add support for galleries of media file inclusions

You can create multiple media file transclusions, but it's limited to a small number and you have to do all the work of creating the styles around it. We could give a first-level media file output, if this is strongly wanted.
  • Sign here

Add support for map inclusions

We don't yet support maps, which might be wanted if folks are making articles about places a lot. Full support would be quite complicated.

Add support for chart inclusions

We don't yet support charts, which might be wanted if folks are making articles about numerical things a lot. Full support would be very complicated.
  • Sign here

Abstract source mock-ups and multilingual reviews

We are approaching Abstract Wikipedia from the bottom up, with very simple examples. This may be the "Wiki Way", but for software it is very unconventional, and I think it is uncertain whether it can eventually work for more advanced text. The project will have failed unless natural text similar in complexity to current Wikipedia articles can be generated. I think nobody (except possibly Mahir Morshed) understands what the abstract source for more complicated sentences would look like.
Mahir Morshed has created a multilingual text generation system called Ninai/Udiron at toolforge:elemthala (see his introduction at https://www.wikifunctions.org/wiki/Wikifunctions:Status_updates/2024-10-17 and his session at Wikimania). This is linked to Abstract Wikipedia, and extremely relevant to it (since it is the only real current proposal for the abstract souce that I know), but it should be noted that Ninai is only a proposal, not Abstract Wikipedia policy. The list of constructors defines the abstract source as it is at present. Also more information on how this abstract content can be constructed can be found at https://www.wikidata.org/wiki/User:Mahir256/language-generation, with various links and references.
It is not clear to me whether the abstract source, consisting of functions of Wikidata items backed up by lexemes, can even work at all for a wide variety of languages. Rendering a text needs much information which is special to the target language, for instance there can be genders, grammatical cases, polite forms of address, etc. Example: The Eiffel Tower (Q243) usually needs a definite article when used in English, whereas Blackpool Tower (Q880905) does not. Where should this information for the English renderer be held? It cannot be in the abstract source, since the answer is special for English; some editors of the abstract source will speak languages which do not use articles. Well, I think that this type of item needs an English lexeme with a flag to indicate the article usage, and that would be a solution. Another example relates to the grammatical tenses, voices and moods of verbs. How will that be managed? I suppose that a verb tense indication must be given as a parameter in the abstract source, but how will the values of this parameter be related to all the possible tense/voice/mood verb forms in all the languages? There are an enormous number of such diverse features; how can we be sure that there is enough information in the abstract source to do the rendering in all cases?
I think that there is an urgent need to create examples of complex text (such as real Wikipedia articles) in the proposed abstract source. Then testers who comprehend the abstract source format and also know a relevant language should interpret the source text and confirm whether they understand it and whether they have enough information to reconstruct the text in their own language (not by software but with their own mental processes). If so, that would give much-needed confidence that the Abstract Wikipedia scheme can actually work, and I think it would advance the project by making clearer the next needed steps.
  • Strobilomyces (talk) 20:41, 5 August 2026 (UTC)Reply
  • I do not know if this is a priority but would clearly be interesting to test. I am curious to know if abstract Wikipedia can express something more subtle or complex than a wikidata statements. But it is a strategic question: is the goal to put wikidata statements into sentences (with relatively poor language) to build automatic placeholders articles and call for additional human contribution, or is the goal to generate a full "Wikipedia article" with a rich language ? Jeanne Noiraud (talk) 17:51, 11 August 2026 (UTC)Reply
  • Sign here

More showcase/example items

More articles to give an idea of what's possible or good practice. The impressive Australia article is great, but I'm thinking about something-like the query for cats in the Wikidata query service. Ideally with an option to copy everything as the foundation for a new article on a similar topic.


Example: Thing to fix (copy me!)

What it would involve, and why it would be valuable.
  • Sign here

Article editing

Latest comment: 16 days ago25 comments11 people in discussion

Here are some quick ideas about overall article editing, not specific to a given

Drag-and-drop moving of fragments, instead of having to click on the menu and the "move up/down" multiple times

Drag-and-drop is a relatively familiar UX feature, and we could add an affordance for it to make it more discoverable at the same time as more usable.

Done Fix the long article dual-column scroll problem where you can't see what you're editing

This is particularly an issue on longer articles and smaller screens, but was mentioned as very irritating by some of you!

Support multiple sections, rather than just the lede

Right now (despite some functions outputting <h2>s and the like), all articles are limited to just editing the lede section. We have mostly-built support for thematic sections, but this needs some polish. This would let you 'chunk up' articles, potentially editing only a section at a time for ease of use and / or collapsing those sections away to focus. We could also use this to allow external links limited to only the "external links" section (and references).

Prompt editors with function calls based on statements in the Wikidata item

Add a feature that checks the subject's Wikidata item for statements of the kind it knows about (e.g. "born 1850-01-20 in France") and match them to fragments, prompting you to add this. We'd need to work out how to link between fragment functions and Wikidata claims, and how to know whether the claims were already in the article, so this is quite complex to design and build, but would probably help a great deal.

Prompt editors with media used on Wikipedia articles for the subject

A more specialised option compared to fetching media suggestions alongside everything else from the Wikidata item would be to check for the main/first image on any existing Wikipedia articles and suggesting that if it's not already set.
  • Sign here

Fill in the parameters at copy/paste

Fill in the parameters at copy/paste if the number and types of parameters match. That is especialy usefull when copying a new function from one language to an other. Currenltly every parameter has to be filled manually.

Example: Thing to fix (copy me!)

What it would involve, and why it would be valuable.

Any other ideas you might have

Latest comment: 16 days ago58 comments14 people in discussion

The sections above aren't everything. What else is something you'd like fixed?

Done Make it more obvious in the search whether there's an existing abstract article or not

Right now we just add "– AW" to the end of search results when there's an existing article; if we make it clearer whether the link is a "read this" or "create this" link, folks won't be surprised when they click it.

Auto-linking new Abstract Wikipedia articles to their Wikidata counterparts

Right now people need to manually say that e.g. Q90 is the same as Q90, which takes time and isn't obvious. If we did this automatically as articles were created, the workflow would be easier to understand.

Show labels of talk pages

Show labels of Zid's talk pages on recent changes, watchlist and also on Categories like this one. Idem for Qid's talk pages on Abstract Wikipedia

Enlarge the field for labels

Currently the field for labels can hold a maximum of 50 characters. See for example German instantiating sentence no article, Comp (Z32398). Frequently this is not enough and abbreviation have to be made. That makes the function names confusing and not consistent.

Support wikitext in functions output

Wikifunctions don't support wikitext. They can only output unparseable plain text or HTML. I know that the page f:Wikifunctions:Embedded function calls says very clearly that wikitext will never be supported. But this is the number one thing that causes me not to be motivated to use functions, and I suspect that I'm not alone. So perhaps you could reconsider it.
  • Amir E. Aharoni (talk) 16:01, 5 August 2026 (UTC)Reply
    • @Amire80, @HenkvD: What would you do with the produced Wikitext? Copy it into an existing page on one of the sister projects? YoshiRulz (talk) 01:01, 7 August 2026 (UTC)Reply
      The same things that everyone does with templates and modules. Amir E. Aharoni (talk) 02:50, 7 August 2026 (UTC)Reply
      We should write functions as Wikitext like '''[[Q1]]''' and table and templates and modules etcetera. that should be rendered into HTML or so, the same as string to HTML functions. HenkvD (talk) 05:45, 7 August 2026 (UTC)Reply
      Coming back to expand on this. I believe "support for Wikitext" can be divided into 2 independent featuresː use as output, that is, a new Type like HTML fragment (Z89) or String (Z6) which has first-class support as a return type in WF:embedded function calls; and use as input, that is, the ability to implement a Function as a concatenation of Wikitext strings instead of HTML—so closer to how templates/modules are written.
      Accepting Wikitext as input could be a good way to bring in editors from sister projects, but unfortunately as explained below, using Parsoid for that is a non-starter, and writing a bespoke Zwww→Z89 translator would be a lot of effort for not much benefit. After all, a lot of valid Wikitext is already valid HTML, the main differences are links/images, shorthand for bold/italic, and shorthand for headings (the HTML syntax for bold/italic and headings can also be used in Wikitext), plus in Wikitext you would use template/module calls whereas in compositions it would be Function calls. This is a good time to mention the plans for Wikitext as second-class in a future HTML-centric MediaWiki.
      Allowing Wikitext as output would have no advantage over HTML for readers, and I dispute the claims here and in the RfC that it would be useful for editors. Because when you do something like {{langx|fr|links=yes|{{#property:P1705}}}} in the world of templates, the expectation is that each parameter is either an option whose contents are scrutinised, or a block of rich text whose contents cannot be introspected. If embedded calls produced Wikitext, it would still fall into this latter category. There's precedent for this with e.g. frame:callParserFunction("#tag", { "ref", "footnote contents" }) in modulesː it returns weird-looking sentinels like '"`UNIQ--ref-00000000-QINU`"' which you can concat with Wikitext strings but not introspect. YoshiRulz (talk) 11:23, 23 August 2026 (UTC)Reply
      After all, a lot of valid Wikitext is already valid HTML, the main differences are links/images, shorthand for bold/italic, and shorthand for headings (the HTML syntax for bold/italic and headings can also be used in Wikitext) - This is a tempting thought, but as I wrote in another comment here, wikitext is far beyond "shorthand" for formatting. Wikitext is a lot of functionality, not just formatting. It is categories; magic words like DEFAULTSORT, DISPLAYTITLE, PAGELANGUAGE, and many others; special content like formulas, musical score, poem, and hieroglyphics; and much more. Each of them can theoretically be reimplemented to be supported in Wikifunctions, but it would take a lot of time: it has just taken at least a couple of months to add image support to Wikifunctions, and it's still too rudimentary (e.g., you cannot see on which pages an image is used, which is very basic in usual wiki pages). And the engineers would have to do it for every one of those features, even though the rest of the Wikimedia world already supports them. Ironically, some of these things, like math formulas, would not need translation, and they could be easily shared across languages in abstract articles, but currently, it's simply impossible to insert them into abstract articles at all.
      This is a good time to mention the plans for Wikitext as second-class in a future HTML-centric MediaWiki. - I'm quite sure that "a future HTML-centric MediaWiki" is not a "plan". It's a bunch of ideas thrown around eleven years ago by some people who have a lot more relevant knowledge about this topic than I do, but who have lots of other things to work on. If there is indeed such a plan, I, and many other Wikimedians, would love to read it. Amir E. Aharoni (talk) 12:43, 23 August 2026 (UTC)Reply
      Most magic words are "escape hatches" to allow for limited computation without modules, which isn't a limitation WF compositions have.
      • The big ones you didn't mention, {{param|default}}, {{#exprː}}, and {{#ifː}} et al., are all handled by functions specific to one task, IMO a better system. You also didn't mention <ref/>, but that's been reimplemented already.
      • Categorisation/{{DEFAULTSORT:}}ː see phab:T433157
      • {{DISPLAYTITLE:}}ː N/A to AW
      • {{PAGELANGUAGE}}ː was in AW from day 1, also in embedded function calls
      • <math/>ː I never understood why this isn't done with MathML
      • <score/>ː no idea
      • <poem/>ː just <pre/>
      • <hiero/>ː also no idea; last I checked the Unicode proposal for hieroglyph layout/composition was still stalled?
      • Tracking all of them here
      it has just taken at least a couple of months to add image support to Wikifunctions, and it's still too rudimentary (e.g., you cannot see on which pages an image is used, which is very basic in usual wiki pages) It's not clear that allowing Wikitext for implementations would have made that faster, and they would still have to wire up backlinks either way.
      If there is indeed such a plan, I, and many other Wikimedians, would love to read it. I learned of the move to HTML from this talk at last year's Wikimania. It was a long-term goal 10 years ago, and since then Parsoid was built with that idea and we're in the middle of mw:Parsoid/Parser Unification. Moving the Wikitext editor to an optional component might still be planned for after that, but I couldn't find a definitive statement on it. YoshiRulz (talk) 13:56, 23 August 2026 (UTC)Reply
      The big ones you didn't mention, {{param|default}}, {{#exprː}}, and {{#ifː}} et al., are all handled by functions specific to one task, IMO a better system. - yes, that's why I didn't mention them :) Wikifunctions are indeed better for this (in Python and JS, not so much in Composition). But so are Lua modules, which are already nicely integrated into wikitext.
      Categorisation/{{DEFAULTSORT:}}ː see phab:T433157 It's good that categorization is tracked in a Phab task, but that Phab task also has a revealing comment from @Jdforrester (WMF), which says exactly what I want to say: "Categories are fundamentally part of wikitext, not a general thing in MediaWiki that we can plug Abstract articles (or Wikidata items or Wikifunctions functions) into". If Abstract Wikipedia is supposed to be an encyclopedia, it needs categories of some sort. If Wikifunctions supported wikitext, AW would get them for free. Since Wikifunctions don't, AW has to do without categories until it's implemented somehow. (Wikifunctions itself needs categories, too. So does Wikidata, as James says in the same comment, but for Wikidata this is solved with Wikidata's own taxonomy with properties. Come to think of it, perhaps that taxonomy could be reused for Abstract Wikipedia, but I can also think of some difficulties that it would create.)
      {{DISPLAYTITLE:}}ː N/A to AW</nowiki>: I can easily think of cases where it is applicable, e.g. abstract:Q169226 (w:en:Sgt. Pepper's Lonely Hearts Club Band). Maybe now AW doesn't have a manual of style that requires italic titles for album articles, but it may want it in the future. As with categories, if Wikifunctions supported wikitext, AW would get it for free, and now it's limited and has to wait for it to be implemented separately.
      And it's the same for everything else. Poem is not just <pre>; it's not much more complicated, but it's still something separate that will require non-zero engineering effort. You say "no idea" about <score>, but what it actually means is that Wikipedia articles can have score and abstract articles cannot. Math formulas could perhaps be better done with MathML, but the fact is that they weren't, and now we have lots of formulas that Wikipedia can use and AW cannot (I vaguely recall that MathML and other solutions for formulas were discussed extensively by relevant experts, and they decided that the best solution is what we have now).
      And so on, and so forth. You have to reimplement everything, and it looks a lot like Second-system effect.
      I learned of the move to HTML from this talk at last year's Wikimania. - I'm pretty sure that it's not "move to HTML", but an idea by @Cscott, who also participated in the discussion eleven years. As far as I can tell, it's still not a project, but @Cscott or anyone else who knows better is welcome to correct me if I'm wrong. If it ever becomes a project, it will run into all the same issues that I'm describing in this discussion. I'm not saying that it's a bad idea; it may be a very good idea. But it has to be discussed widely and present an actual transition plan that takes all the current content into account. Amir E. Aharoni (talk) 14:48, 23 August 2026 (UTC)Reply
      ... To clarify, while I agree with the dry fact that "Categories are fundamentally part of wikitext, not a general thing in MediaWiki that we can plug Abstract articles", I disagree with the weight that James gives it. This is such a critical part of wikitext, and essentially of the whole Wikipedia editing and reading experience, that you cannot just dismiss it. There's a reason that it was added to MediaWiki (or to wikitext, I don't care how you call it) more than twenty years ago: Wikipedia editors really, really needed it. In this regard, it's far more important than <poem>. However, if Wikifunctions simply supported wikitext, Abstract Wikipedia would get both things, and lots of others, for free. If Abstract Wikipedia doesn't have categories, I don't understand how can it even call it itself "a Wikipedia". (By "simply", I don't mean that it's simple to add this support, but that having it would give Abstract Wikipedia all the features of Wikipedia without having to discuss each feature separately.) Amir E. Aharoni (talk) 18:56, 23 August 2026 (UTC)Reply
    @Amire80: As you may recall from the repeated times this has been discussed, this isn't in our gift to offer, regardless of how much you ask for it, sorry. Jdforrester (WMF) (talk) 15:34, 7 August 2026 (UTC)Reply
    Look, it's not just me; more than a year has passed since enabling the embedding of Wikifunctions into Wikipedia and Wiktionary articles, and practically no one uses it. I'm just trying to explain the likely reason.
    If you are going to respond that this survey is not about embedding Wikifunctions into other wikis, but about Abstract Wikipedia, it doesn't change much: this makes Abstract Wikipedia so different from other Wikipedias that contributing to it is unreasonably hard for almost everyone.
    It's your call if you want to fix it. Amir E. Aharoni (talk) 11:24, 8 August 2026 (UTC)Reply
    @Amire80:

    It's your call if you want to fix it.

    No. It is not, and never has been, in the Abstract Wikipedia team's power to "give" this feature to you. You and I have directly discussed this before, repeatedly. Wikifunctions producing wikitext that would be woven into existing pages was precisely and directly vetoed for us in 2020.
    You stating that it's actually possible, or starting votes about this, or complaining at me, Denny, or whomever in the team hasn't changed this fact. At some point even I will run out of good faith assumptions, when you repeatedly make statements that have been refuted. If you think the lack of wikitext is the red line over which you won't work with the project, that's understandable if sad, but I don't understand your comments. Jdforrester (WMF) (talk) 19:10, 11 August 2026 (UTC)Reply
    Thank you for the clarification, James. I think the “woven into existing pages” qualification deserves closer scrutiny. It seems plausible (to me) that an entire Abstract Wikipedia article could be delivered as HTML, wikitext, rich text, plain text or any other format, so long as it is not actually delivered into the unparsed wikitext of a page. Is that a misinterpretation of the “veto” (which I haven’t actually seen)?
    The focus today is on whole articles, but that has never been my priority. As far as functions are concerned, wikitext is just plain text, so I don’t see any issues with individual functions returning wikitext, apart from the “why doesn’t it parse” confusion. Should we consider a new type for “unparsable” wikitext that, unlike strings, would require a display function before functions returning that type could be embedded? GrounderUK (talk) 20:21, 11 August 2026 (UTC)Reply
    @GrounderUK: I don't understand your suggestion. Any Function can today return a Z6/String with wikitext-like characters in it, but the veto is that results will never be parsed as such into pages. Your proposed new non-parsed wikitext Type would need a display Function, as you say. Writing a display Function to turn wikitext into HTML would be extremely challenging to write, and an unbelievable expense of time. Parsoid, which this would mimic without being able to be called or share anything, is after ~15 years of work and millions of dollars of staff time now ~100k lines of pretty densely-written PHP (plus more than that again of test cases). Even if this were built, it would still never work for the things people are actually asking for when they say "wikitext" — templates, references, categories, etc. — as they are page-level integration concerns. Jdforrester (WMF) (talk) 18:27, 12 August 2026 (UTC)Reply
    Although you have discussed it with Amir, I would also appreciate an explainer somewhere of who, where, why, and exactly what was vetoed. Without that it's impossible for me to know what is "actually possible". I was not around for discussions in 2020 - if it's public, I'd be interested in a link. My first function on WF was to make Wikitext, as I assumed that was how we would eventually deliver Wikipedia content. Wikifunctions:Embedded function calls does give me some understanding of why this direction was chosen, and I'm broadly okay with contributing under whatever restrictions are current. But this whole page is about improvement. So let's allow space for Amir to raise this, especially if it sheds light for others of us, and possibly leads to improvement. Possibly even without further development from the AW dev team. Along with @GrounderUK's suggestions above, I think we have under-explored making functions that output string-wikitext. For example, the grammatical tables for Wiktionary could be written like this. Rather than "embedding" (~transclude), we could copy-paste (~subst) into pages (on any Wiki, not just Parsoid etc). This would have the advantage that it could be further edited by the receiving community. It would have the disadvantage that it would not be live-updated, so it might work better for grammar tables than for live population lists. But even live updating data could be incorporated by putting smaller #function calls inside the tables (depending whether you plan to implement the 5-10 call hard cap you mentioned at T431175). I don't know if any of this would improve the uptake of WF content being used directly in non-AW wikis. It might. For now it's not my focus, but I think some of these options are in the WF contributors hands, and may only require little support from the AW team. --99of9 (talk) 02:03, 12 August 2026 (UTC)Reply
    @99of9: The veto was made in the very early system design conversations in 2020 by SRE and Security, and what we would now call the MediaWiki group.
    My concern is that this page was meant to be about actionable ideas, and diverting a huge amount of effort into this conversation when Amir was part of those conversations then is disrespectful of your time. I'd of course be happy to discuss, at length, but it feels like this is a detailed enough area that it should be its own page/set of conversations that can be discussed, agreed/concluded, and summarised at length? Jdforrester (WMF) (talk) 18:31, 12 August 2026 (UTC)Reply
    I think that’s fair. The problem in this specific context is that “Support wikitext in functions output” can have multiple interpretations. I’m happy to expand on my previous comments here or elsewhere, but I did attempt to keep them as brief as possible.
    Just to clarify one point: a new wikitext type would need not to have a display function, so that wikitext functions would be unavailable as embedded functions, unlike a current string function whose string is intended to be wikitext. Or it might be formatted as a copyable text block… whatever the community concludes, and subject to the current “staff” discretion, when it comes to connecting an eventual display function. GrounderUK (talk) 19:09, 12 August 2026 (UTC)Reply
    @Jdforrester (WMF),
    It is possible that my memory of the last six years is horribly broken, which is not totally inconceivable because I am diagnosed with a few neuropsychological conditions, at least some of which are lifelong. However, if it's not horribly broken then:
    • I didn't know about the 2020 SRE "veto" until you mentioned it on this page on August 11.
    • Amir was part of those conversations then - I was not part of those conversations. Like, at all. If I was, then my memory of them has been damaged somehow. For that matter, I don't recall being part of any conversations about Wikifunctions in 2020, except a very informal 1:1 chat with Denny very early in the project, and my public and mostly supportive responses on Meta.
    • I first learned about the fact that Wikifunctions output will not be parsed as wikitext in the middle of 2024. If I knew about it in 2020, I wouldn't express any support for this project back then, as I did on the page m:Abstract Wikipedia/Archive 1, and I'd probably say that it shouldn't be done at all because no support for parsed wikitext means that not a lot of people will want to use it.
    • You and I have directly discussed this before, repeatedly - the only two times I can recall in which I spoke to you directly about this in any way are both public: here and here. In neither of those cases I learned from you about the "veto", or about why is wikitext parsing prohibited, or what is this prohibition good for, etc. (I am still really curious about the answers to these questions.)
    • You stating that it's actually possible - I'm pretty sure that I never said that adding wikitext parsing support to Wikifunctions is "actually possible". I don't know enough about parsing to claim if it's possible or not. If you think that I did claim this anywhere, please show me where, and I'll try to understand why did I say it then. What I did speak about is that it is desirable.
    • I cannot recall repeatedly making statements that have been refuted. If you have examples of this, please give them before throwing accusations of bad faith around. If you don't have them, then please do not do this, it is very rude.
    The only thing that I should clarify is that when I said "It's your call if you want to fix it", I didn't necessarily mean you personally. I meant anyone who wants Wikifunctions to have some users and has the power to do it. You say: If you think the lack of wikitext is the red line over which you won't work with the project, that's understandable if sad - well, I think that it's not just my red line, but that it's almost everyone's red line. Again: It is a cold hard fact that sixteen months after the deployment of that feature, practically no one embeds Wikifunctions into wiki articles. The likely root cause of this is the lack of support for wikitext parsing, although I'd love to hear other theories.
    If you cannot do it, then don't do it, but it likely means that the number of people who actually use Wikifunctions will remain negligible for the foreseeable future, and probably forever. I'll be happy to be proven wrong about this someday. Amir E. Aharoni (talk) 00:08, 13 August 2026 (UTC)Reply
  • HenkvD (talk) 22:11, 5 August 2026 (UTC) Without wikitext the Abstract Wikipedia is not a real Wikipedia. Using wikitext code for bold, italic etc. Maybe also for Wikilinks.Reply
    It should be for everything, not just bold, italic, and links. Wikitext is much more than that: magic words, article structure, etc. I'm not saying that it's good; there are lots of problems with wikitext, but it doesn't matter, because wikitext is the way in which practically all the content in all the wikis is stored, so you are right when you say that without wikitext the Abstract Wikipedia is not a real Wikipedia. Theoretically, the format shouldn't matter, because sharing knowledge shouldn't depend on the markup language, but practically, it matters a lot. Amir E. Aharoni (talk) 15:05, 7 August 2026 (UTC)Reply
  • Kambai Akau (talk) 17:05, 7 August 2026 (UTC)Reply
  • —UndueMarmot (talk) 13:10, 11 August 2026 (UTC)Reply
  • Sign here

Completely change the UI of compositions

I don't get compositions. A few people get them, but a lot of people don't. I mostly don't. When I try to read existing compositions, their deeply-nested hierarchy immediately confuses me, and I'm almost always afraid of editing anything. And I barely know how to start a new composition. The "clipboard" feature, which was added a few months ago, makes it a little bit less frustrating. But only a little bit; it doesn't solve the big issue. Creating and editing compositions is the only way to edit abstract articles, and it's very commonly needed on Wikifunctions, too, so if a lot of people have a hard time understanding how to do it, neither project will acquire a lot of editors. If you ask me, I'd do away with them completely and just use Python or JavaScript (or Lua!) code.

Allow choice of implementation to be forced

Where a function has multiple implementations, it would be helpful to be able to force the orchestrator to select a particular implementation for a particular run (or a particular session or a particular user). This would often be very helpful for debugging, or when an implementation appears to have a bug. I am not too sure how that could work - I propose that each user should be able to mark any implementation as always to be selected in their case (or perhaps as never to be selected). Perhaps only in the current session.
It would even be useful to have a mode in a given session where the orchestrator always selects the first (or last) implementation for all functions - then one would at least know which implementation was going to be called!
  • Sign here

Done Allow Wikifunctions functions to be called from Python and Javascript

As indicated in an earlier suggestion, it is not convenient to write complicated code in the form of compositions. I think far more code would be contributed if it could be done in Python or Javascript.

Done Allow clearing cache in WF/AW

Add a way to clear the cache for a function given a certain input(s). For example, if a function takes a QID and a language, I might want to clear the cache for all outputs that take the French language or Q90 in.
Some current short descriptions are written like Z1/Object. It would be better if these could be linked by writing [[Z1]] and displayed as when using {{Z}}.

Example: Thing to fix (copy me!)

What it would involve, and why it would be valuable.
  • Sign here

Thank you!

It was great to speak to and hear from so many of you.

Retrieved from "https://www.wikifunctions.org/w/index.php?title=Wikifunctions:Wikimania_2026_survey&oldid=323781"