This RfC is about the future of Abstract Wikipedia (main page). It is not about Wikifunctions, which I've discussed only as the technical infrastructure on which Abstract Wikipedia depends.
Six years after Board approval and three years after the Foundation expected its first new articles to be published, Abstract Wikipedia is live and producing broken nonsense at worst, and single sentence definitions masquerading as articles at best. The Foundation plans to make integration into other language Wikipedias available within months. The 2022 Google Fellows evaluation predicted these failures and the Abstract team rejected its recommendations; and so here we are.
Abstract Wikipedia fails technically, the content fails editorially, the contributor workflow fails practically, and the Annual Plan could declare success without measuring whether the output is accurate or useful.
Abstract Wikipedia was approved by the WMF Board in May 2020. Its stated goal is to generate encyclopaedic content in a language-agnostic way, using Wikifunctions and Wikidata as the building blocks, to allow smaller language projects access to translated articles.
Making more articles available in more languages is a good goal and no one disputes that. What I dispute is this method to achieve it, and six years after approval no one (including the Abstract team) has shown evidence that this method will achieve it either.
I examined a random sample of Abstract articles on 13 July 2026 using Special:Random.
Of thirteen randomly selected pages, four produced only internal error messages. A fifth generated two sentences before failing, and a sixth displayed raw HTML rather than prose. None produced an acceptable encyclopaedia article.
February: Wikifunctions returned a failed response: Invalid key
California:Wikifunctions returned a failed response: ZID not found
oxygen:Reached concurrent evaluator call limit in orchestrator
Hilariously the function that generates the bronze article is literally named (DO NOT USE) SPO sentence (singulars in present) and is used across a bunch of Abstract articles. It triggers the following error:
Bronze is a material.A bronze is a copper-based alloy.
Wikifunctions returned a failed response: no connected implementation yet.
Nice haiku though.
The pages that did render were not articles:
Brussels consists of, in full Brussels is the capital city of Belgium. which is a grammatically correct sentence, but just a Wikidata statement read aloud, not an article about Brussels.
bird is A bird is an avian dinosaur. which... okay, I guess?
animal manages An animal is an organism.An animal is a heterotroph., without bothering to put a space between the sentences.
fire offers Fire is a physical phenomenon. Flame is the part of of fire. which is both ungrammatical and wrong because not all fire has a flame.
Some of it is worse. The Nanjing article generated the following factual errors:
Nanjing is a big city in Jiangsu.Nanjing is a big city in the People's Republic of China.Xuanwu District is the capital city of Nanjing.Lan Shaomin is the head of government of Nanjing.Capital city is the namesake of Nanjing.Nanjing is a big city in Asia.Nanjing is the capital city of Republic of China.
Xuanwu District is not the capital of Nanjing; Lan Shaomin is not the current head of its government; "Capital city is the namesake of Nanjing" is nonsense; and Nanjing's historical status as capital of the Republic of China appears as unqualified present-tense fact because the system cannot yet express the past tense.
This flattens the river, its tributaries, its headwaters, drainage basin, and watershed into a single relation. This is not useful.
The homosexuality article, which I will present without comment:
A homosexuality is a sexual orientation. Gays enter same-sex relationships. Homosexuality exists in 1500 species. Societies persecute gays.
Paul Cézanne contained no text at all, just a heading followed by three HTML links displayed as source markup.
All of the above is the English output, the language the system handles best. There have been documented cases on the Wikipedia:Village pump (WMF) thread of translated language outputs being far worse. Being a mono-lingual speaker, I am only focusing on the English output.
The intended recipients of this content are the smaller language Wikipedias; those with the fewest active editors available to spot and repair systematic grammatical, semantic, factual errors that Abstract generates. Sending terrible generated text to a small project does not actually help them, and terrible generated text carrying the Foundation's name is a serious reputational risk.
Integration into language Wikipedias is being planned before the feasibility of the basic model has been established. I suggest it has failed. Six years in, it is still a research project testing its own premises and has produced no useful output.
The fundamental principle of Abstract Wikipedia rests on the idea that encyclopaedic content can be broken into language-agnostic units and then rendered into any language. But languages do not carve meaning into the same interchangeable pieces.
The project’s own status update admits that even deciding when to use the definite article "the" can become a word-by-word problem across languages; the founder of Grammatical Framework (programming language) Aarne Ranta called it one of the hardest puzzles they had to solve. And the project is trying to do this across the vocabulary and grammar of every language the project hopes to support.
Linguist Mark Dingemanse set the problem out way back in May 2020 in his post Concrete reasons to be skeptical about an ‘Abstract Wikipedia’If even a seemingly innocuous term like “mayor” is subject to this kind of warping of semantic spaces (if it’s available at all), that doesn’t bode well for many other concepts. Six years of development has not produced an answer to him, but instead has produced the article HomerHomer is the part of of Greek mythology which is what happens when a structured relationship is passed through an unsuitable generic English sentence frame without enough semantic information to render it correctly.
Falk's best example is taken directly from Abstract's own architecture example page: San Francisco is the cultural centre of Northern California, as exactly the sort of neutral fact Abstract will one day deliver in every language on Earth. Two of those words are metaphors: "Northern" and "centre" both assume the world is a map, but Jaminjung speakers orient themselves by the flow of the Victoria River, so is Northern California upstream or downstream? Supposedly language-agnostic proposition is already framed through English linguistic and cultural assumptions.
Suppose the rendering worked perfectly; the output would still not be an encyclopaedia. A human editor who does the (difficult!) job of writing an article has to decide which facts matter, what a reader needs to know first, what requires context and attribution, how events relate in time, space, and cause, and what to leave out. Screw is a simple machine. does describe a screw, but it is no one's idea of the right opening sentence of a Wikipedia article about screws.
What Abstract Wikipedia has demonstrated is that some database relationships can be turned into grammatical sentences (infoboxes, census records, some limited structural descriptions etc).
What it has not demonstrated (anywhere, in any language, in six years) is that those sentences can be organised into a useful article. Verbalising structured data has been confused with writing an encyclopaedia.
What contributing to Abstract Wikipedia actually looks like
The team's response to criticism repeatedly frames the current state of the project as a matter of the contributor community that is still developing. I think it is worth showing what "contributing" actually looks like.
Fellow editor User:Chaotic Enby spent about thirty five minutes constructing an Abstract article for Tujiaaspis. This is the best output they were able to produce after thirty five minutes of effort:
Tujiaaspis is a genus in Eugaleaspidiformes. Tujiaaspis is an extinct taxon. Tujiaaspis is a Silurian. Xiushan Tujia and Miao Autonomous County contains Tujiaaspis. Baojing County contains Tujiaaspis.
Tujiaaspises contain fins. Fins contain lengths. Fins make lifts. Fossils make evidences. Galeaspidas contain fins.
Tujia people makes name.
Abstract has no concept of geological period as a temporal qualifier, so it treats "Silurian" as a taxonomic class.
Abstract doesn't know that "evidence" and "name" are mass nouns in English, so it pluralises them. This is the same failure that produced "A homosexuality is a sexual orientation" earlier.
"Tujiaaspises" mechanically applies a regular English plural to a genus name ending in "-is".
With their permission, Chaotic Enby's own observations:
I love how for example, we have separate functions for "Xs verb Ys", and for "X verbs Y", but not for "Xs verb Y". Also how I've only found two verbs ("make" and "contain") that were actually coded in. So we can't even say "fins are elongated", the only options are "fin is an elongation" or "fins contain lengths".
The same thirty five minutes spent writing prose in English or any other language the contributor speaks would have produced a short, useful, correct stub. Instead we've got Tujia people makes name.
Nobody looks at Abstract's composition interface, such as blue's
paragraph (join text-like objects into HTML fragment (Typed list (Object, subject is instance of (string) (wikidata item reference, primary color, language), sentence separator (language), subject is instance of (string) (wikidata item reference, HTML4 named color, language), sentence separator (language), subject is instance of (string) (wikidata item reference, spectral color, language), sentence separator (language), subject is instance of (string) (wikidata item reference, web color, language), sentence separator (language), subject is kind of (Monolingual text) (wikidata item reference, light, language), sentence separator (language), subject is kind of (Monolingual text) (wikidata item reference, cyan, language), sentence separator (language), (DO NOT USE) SPO sentence (singulars in present) (part of, wikidata item reference, seven prismatic colors, language), sentence separator (language), (DO NOT USE) SPO sentence (singulars in present) (part of, wikidata item reference, RGB color space, language), sentence separator (language), (DO NOT USE) SPO sentence (singulars in present) (part of, wikidata item reference, color, language))))}}
and thinks "yes, small-language Wikipedians will happily produce thousands of these". We're facing an editor retention crisis as it is. We cannot afford the energy, time, and money being spent on Abstract Wikipedia.
The WMF Annual Plan for 2026–2027 has Objectives and key results for Abstract Wikipedia. They mostly measure if Abstract Wikipedia can be deployed but not whether it produces actual useful encyclopaedic content.
The stated objective is to Demonstrate Abstract Wikipedia's viability as a scalable, human-centered way to create multilingual encyclopedic content. but the Key Results don't test that claim.
The Q1 Key Result commits to expanding deployment from the first demonstration into the initial target language Wikipedias and scaling to our envisioned 5–10 additional early adopter Wikipedias.
The Q2 Key Result then defines measures that indicate that contributor communities will be able to to create and maintain Abstract Wikipedia articles, Wikifunctions language functions, relevant Wikidata Lexemes, and/or integration into Wikipedia at a rate that can meet the threshold for scalable content viability.
Q1 expands deployment and builds the integration to support five to ten early-adopter Wikipedias. Q2 defines measures intended to indicate whether the content and contributor model are viable. The threshold for scalable content viability isn't published anywhere I can find, and it's due to be defined a quarter after the thing has already shipped. It also doesn't state what result would count as failure or cause the project to stop.
By the end of Q1, increase the number of sentences and core elements in Abstract Wikipedia articles is a measurement of quantity but not quality. It is absolutely not useful to have the 18th longest page on Abstract by bytes Leo Tolstoy return as:
Leo Tolstoy is a writer from Russian Empire.
Leo Tolstoy is a playwright.
Leo Tolstoy is a philosopher.
Leo Tolstoy is a novelist.
Leo Tolstoy is a pedagogue.
Leo Tolstoy is an essayist.
Leo Tolstoy is a children's writer.
Leo Tolstoy is a diarist.
Leo Tolstoy is a prose writer.
Leo Tolstoy is an opinion journalist.
Leo Tolstoy is an Esperantist.
Leo Tolstoy is a pacifist.
Leo Tolstoy is a poet.
Leo Tolstoy is a short story writer.
This just rewards nonsensical listicles and is Goodhart's law in practice. Counting follow-up edits is ambiguous because it's either more engagement or just endless cleanup work from volunteers for nonsensical generated text.
The plan sells Abstract Wikipedia against LLMs on the grounds that it is human-centered, in contrast to an internet increasingly shaped by automatically produced text that is often opaque and unverifiable. Strong agree on the sentiment. But look at what Abstract Wikipedia is like in real life. Human-centred, at current quality, means thirty five minutes, two working verbs, and Fins contain lengths. The Foundation is proposing to scale that to various small-language Wikipedias in Q1.
None of the Key Results measures:
factual accuracy;
grammatical quality;
if qualifiers, dates and sources survive generation;
review by native speakers;
if the output is useful to readers;
if editors find it easier than writing or translating an article directly;
how much maintenance and cleanup is imposed on local communities;
if communities actually even want the generated output.
The Foundation should not enable integration of Abstract Wikipedia content into any language Wikipedia until the following conditions are met:
Quality criteria for generated articles are published, developed with and reviewed by native speakers;
An independent review confirms those criteria are being met;
Each project has specifically opted in through its local process;
This opt-in is based on the system's actual capabilities.
Added 15 July 2026, in response to DVrandecic (WMF), HenkvD and others: I accept the project team's correction that integration was planned to be locally opt-in and article by article. This proposal asks that production integration not be enabled at all until the criteria above are met. qcne(talk)10:19, 15 July 2026 (UTC)Reply
The Foundation should close Abstract Wikipedia and retain it as a read-only archive unless, within a period defined by the community, not the project team, an independent review establishes that it can meet published technical, linguistic and quality criteria.
Latest comment: 3 hours ago175 comments69 people in discussion
This RfC is open for !voting and discussion. There are three separate proposals: 1. Pause the rollout / 2. Transparency / 3. Closure.
Editors may support or oppose each independently.
We are in a difficult period for Wikipedia, with readership funneled through AI models who tend to hallucinate. This is a period to be bold, try new things. The core to having strong innovation is to bet on multiple ideas at the same time, but ruthlessly drop those ideas that do not work out. How much of our readership will still go to small language Wikipedias if machine translation is integrated into all major browsers? Why are we imposing such incredibly technical hurdles on those small communities, making it nigh impossible to fix errors in articles they have? We need money to go into the work that attract new readers, that promote Wikipedia and that support communities in being more effective with less time. —Femke 🐦 (talk) 12:09, 14 July 2026 (UTC)Reply
Just to clarify, I support closure. Ruthlessly dropping this should likely have happened a few years ago. We're at newsletter 250 now, which implies a massive amount of investment just on the communication side, while communication with other communities can feel so minimal. Can you imagine if that money was invested into Commons and Commons integration, how much more we could have listened to reader feedback about images? Or into Community Tech, and its work to create cross-language templates to actually help small communities? In these times, we cannot divert volunteer effort and WMF resources into a project that cannot work in theory and does not work in practice. —Femke 🐦 (talk) 16:12, 14 July 2026 (UTC)Reply
I believe AI models and machine translation does not achieve the goal of Abstract Wikipedia: (1) AI models is non-deterministic, and we have no way to correct its error; (2) machine translation result can not be corrected either if it is wrong. By comparison content of Abstract Wikipedia can at least be controled by human GZWDer (talk) 15:40, 15 July 2026 (UTC)Reply
I support closure, along with a full technical and linguistic post-mortem as suggested, and preceded by a freeze in any planned deployment. Abstract Wikipedia is a conceptually flawed project, based on disproven linguistics and reliant on massive community time and effort to barely function at all, all the while being near impossible to contribute to. When reading the newsletters about Wikifunctions/Abstract progress, it feels like a parralel reality to what everyone can see with their own eyes. As Femke said above, bold ideas are good, but they are only worth exploring while remaining clear-eyed about their chances. Abstract Wikipedia is dead in the water and it is time to acknowledge the reality of the situation, not blindly move forward as is currently the plan. What our communities need is efficient and accessible translation tools, so that small Wikipedias can benefit from the good quality general content on the big ones, while big Wikipedias can take in all the unique knowledge contributed to the small ones. This should be an absolute priority if we are to preserve the linguistic diversity that brings so much value to the Wikimedia ecosystem, and I wish the Foundation was laser-focused on helping editors of all languages and editing proficiency build on what we have to make it better, instead of pursuing endeavors such as Abstract. Choucas 🐦⬛12:50, 14 July 2026 (UTC)Reply
In my opinion Wikifunctions and Abstract Wikipedia is extremely flexable. So even the current way to building article in Abstract Wikipedia does not work, we still have other ways (see my comment at #c-GZWDer-20260715160600-Amire80-20260715131200). I believe no way can be used to build a featured article, but in my proposed way one can translate ~6 million cebwiki article to own language by translating ~100 reusable "messages". GZWDer (talk) 16:13, 15 July 2026 (UTC)Reply
If I understand you correctly, to do this, you probably don't need Wikifunctions and Abstract Wikipedia. You can do most or even all of it using MediaWiki's current messages, templates, and modules. This is also similar to what was proposed in Abstract Wikipedia/Google.org Fellows evaluation in 2022. (Please correct me if I'm wrong.) Amir E. Aharoni (talk) 17:39, 15 July 2026 (UTC)Reply
The output of Z32213 is superior as it is labeled as multilingual text. Problems with editing should be solved by making funtions easier to edit, not downgrading output. Aaron Liu (talk) 19:22, 15 July 2026 (UTC)Reply
It is trivial to convert the output to monolingual text. Also, in my opinion articles should use a very specific builder (via builder fallback mechanism). Z28016 is too general to be used directly; it should be wrapped inside a more specific builder.--GZWDer (talk) 19:26, 15 July 2026 (UTC)Reply
If you convert to monolingual text, you will see the exact same toughness appearing as the "builder" scales to more languages; for example, supporting traditional Chinese as well. My point is that the "builder" approach is exactly what AW is using but with better architecture. The goal is to make more functions like Z28016 to express more numerous and more specific things. I'm sure @DVrandecic (WMF) or AW editors could confirm. Aaron Liu (talk) 19:33, 15 July 2026 (UTC)Reply
Oppose anything I'm not convinced this is necessary. I strongly oppose closure, but we don't need to proactively tell the WMF what to do unless something goes wrong. Feeglgeef (talk) 13:24, 14 July 2026 (UTC)Reply
Thanks @Feeglgeef. Your input on the WP:VPW thread was valuable. You yourself have saidAbstract Wikipedia is a viable project. It just needs more time, and, ideally, better technical support. I do agree with those above that Dr. Vrandečić is overstating our progress.
This RfC exists because something has gone extensively wrong, and the WMF is planning to ship it to language Wikipedias anyway. That's the "something" this RfC is responding to. qcne(talk)13:54, 14 July 2026 (UTC)Reply
Support closure, it is very clear at this point, as so eloquently put by qcne, that this project has unfortunately failed. It is vitally important that we do not get caught in a sunk-cost fallacy and are able to close this now rather than after it costs any more time, money, and editor goodwill. CoconutOctopustalk13:29, 14 July 2026 (UTC)Reply
Oppose all the above Isn't it too early for this RFC? The project was released for public preview in March—only four months ago—and it has already demonstrated its technical feasibility. Furthermore, some of the examples cited in the RFC depend entirely on specific function choices. Since this is a community-built project, contributors should remain free to use the functions they prefer. Personally, I feel the repetition of words in every sentence simply shows that active contributors currently view this issue as a low priority. After all, fixing it would require rewriting sentences to use pronouns, or correcting them with a comma-separated list of occupations. John Samuel13:39, 14 July 2026 (UTC)Reply
The project was approved in 2020 and the Foundation expected the first articles in 2023, it is not four months old. Integration into some language Wikipedias is planned for Q1 of the current annual plan. If it is too early to evaluate, it is too early to ship.
Being able to execute functions and display generated sentences does not demonstrate that Abstract Wikipedia can produce encyclopaedic content. If grammatical and factual quality depends entirely on contributors choosing the correct functions, that is not an answer to the concern: it is the concern. qcne(talk)13:47, 14 July 2026 (UTC)Reply
Support pause and added transparency, weak support closure. I shared some of my thoughts with qcne above, and will elaborate further. All in all, I second Femke's approach: innovate, but prune any dead-end branches – which Abstract Wikipedia might just be – before we become subject to the sunk-cost fallacy. Chaotic Enby (talk) 13:58, 14 July 2026 (UTC)Reply
My observations from half an hour of trying to write an article, which should tell you enough about why I feel that way:Verb search is horribly broken. You don't have a catalogue of verbs, or of words, but of Wikidata identifiers, the vast majority of which don't map to any verbs. Want to search make? You have to guess that the relevant Wikidata item is creation (Q11398090). In practice, that means you'll have to search through every lexeme, select one, wait five seconds for the paragraph to load, and pray that it has a verb form. It won't.This also means that context-dependent synonyms will be flattened into a single lexeme. Want to say that fins generate lift? Sorry, they make lifts. Enjoy your galeaspid-owned elevator business.Function search is even more hopelessly broken. The project is strongly typed, with types such as monolingual text (Z11) or string (Z6), but this is very limited in practice: searching for language-agnostic functions will get you swarmed by language-specific implementations.[a]More subjectively, even just basic editing is so annoying. You can't just wade and add sentence-generating functions right away, you have to know how to chain three separate helper functions just to reach the point where you can actually do that. Once you're there, you can't copy-paste blocks easily, you have to click on the menu button, click copy, create a new block, click on the menu button, click paste, and it opens a window to select from everything you copied before. You'll also run into seemingly random errors, such as Reached concurrent evaluator call limit in orchestrator when writing a paragraph with more than six sentences.The function inventory is also very hit-or-miss. There are two "useful functions" lists, Abstract Wikipedia:Useful functions for article composition and Wikifunctions:Catalogue/Natural language operations/Global language functions. The latter has two whole functions for album short descriptions, but none for "X is Y". You have very little flexibility in existing functions: "X verbs Y" and "Xs verb Ys" are separate functions, but there is no "Xs verb Y" or "X verbs Ys" equivalents as far as I know.This transitions neatly into my next point, which is functions are very rigid, and offload a big part of article writing on function developers, while requiring article writers to be intimately familiar with the existing set of functions. Abstract Wikipedia basically relies on functions for everything, with little regards about how natural languages are structured. Abstract articles only superficially resemble a linguistic parse tree, doing away with the very high-level "noun phrase"/"verb phrase"/etc. nodes and replacing them with hyperspecific "X exists in N Ys" functions that remove all the flexibility. I could foresee a different set of much more high-level functions doing better, with tools to parse them from natural languages, but this is far from what we're seeing today on Abstract.Even in that best-case scenario, there is also the issue that semantics can't be neatly separated from syntax when parsing natural language, or when producing it – for a very concrete example, collective nouns take singular or plural agreement in British English[b] depending on the semantic context.This gets multiplied when looking at cross-linguistic variance: let's say you want to make this basic "X is Y" copula function that could work for plural and singular X and Y. Simple enough, right? Well, several languages have multiple copulas (ser and estar in Spanish), and you'll need fine-grained enough distinctions between the various kinds of copulas[c] to make something cross-linguistically robust, while still being intuitive enough for writers unfamiliar with these distinctions. Chaotic Enby (talk) 14:31, 14 July 2026 (UTC)Reply
AW editors have partially or completely rewritten your Tujiaaspis article (but the English view is currently all timed out -_-), removing Fins make lift. and some other calls to f:Z32531 which is known to be unlocalisable. I suspect lift would need to be marked as a mass noun, and then functions changed to respect that, but the en modelling page doesn't mention how that should be done. Abstract articles only superficially resemble a linguistic parse tree, doing away with the very high-level "noun phrase"/"verb phrase"/etc. nodes and replacing them with hyperspecific "X exists in N Ys" functions that remove all the flexibility. It's not possible to use syntax trees for this as they're obviously not cross-lingual. The template-like constructions you're complaining about are the 80/20 solution for generating the same sentence in many, diverse languages, which is why the first NLG functions have used that paradigm. YoshiRulz (talk) 14:49, 17 July 2026 (UTC)Reply
Not the most specialized forms of syntax trees, obviously, but there must be higher-level functions (like genitive constructions) that can have equivalents in various languages. To take a more concrete example: the order of the branches in a tree won't be the same in an SOV language and in an SVO language, but the underlying structure at a more abstract level remains, and that is what we'd like to capture here.Problem with these template-like constructions is that we end up creating hyperspecific functions and putting even more burden to translate each of them into each target language. Chaotic Enby (talk) 15:19, 17 July 2026 (UTC)Reply
References
↑I am here using "implementation" as a shortcut – each of these language-specific functions is really a function prototype, which itself has a set of Wikifunctions implementations, either as borderline obfuscated Python/JS code or unreadable function composition.
↑But not in American English, where they are always grammatically singular
Support pause and added transparency, weak support closure. My opinion is that this project will not be viable unless there is machine assistance that helps translate natural language to the Abstract Wikipedia syntax. Perhaps that'd involve machine learning (I realize in the AI-hating zeitgeist this is unpopular to say), but I don't really see any other way for this project to work without machine help. Writing in this syntax is ludicrously difficult even for patient, smart, and dedicated users; I've watched them struggle in real time on video calls and text chats. This is just not a useful project. As Femke said, we should be focusing our efforts elsewhere. Grapesurgeon (talk) 14:03, 14 July 2026 (UTC)Reply
Having machine tools transforming natural language inputs into an abstract parse tree form is probably the best way this project could go, instead of requiring contributors to basically be familiar with a whole new programming language before writing articles. This is the only reason I weakly support closure instead of strongly supporting it – there might just be some way such a project could be achieved, but this is infinitely far from it. Chaotic Enby (talk) 14:08, 14 July 2026 (UTC)Reply
Frankly, I think the best use of the Abstract team's time for the coming financial year is to write honest, exhaustive postmortems on why this whole thing didn't work. Let's at least convert this utter failure into something that researchers and developers of the future can learn from. asilvering (talk) 14:06, 14 July 2026 (UTC)Reply
Support rollout pause, since the current model of representation of abstract content has fundamental issues, and is not scalable to represent more elaborate content in more languages. Currently new models of representing abstract content are being proposed and discussed; many of the concerns expressed in this page are not applicable to Abstract Wikipedia as a whole project, but only to the current state. This is why I think that currently Abstract Wikipedia articles are in no way ready to be integrated into any Wikipedia, but more time is needed to solve these issues.Dv103 (talk) 14:20, 14 July 2026 (UTC)Reply
The way to build article in Abstract Wikipedia needs to be reconsidered (you can see a more proper way by viewing ceb:Special:Random and think how to translate it to your language) but even we consider the current way to build article in Abstract Wikipedia infeasible it does not mean we have no other way. GZWDer (talk) 16:17, 15 July 2026 (UTC)Reply
I'm not sure whether referencing Cebuano Wikipedia is a bad example, or a great example of how good intentions plus automation results in a bad outcome. Arlo Barnes (talk) 20:22, 15 July 2026 (UTC)Reply
Support closure, along with post mortem analysis per User:Choucas. This is a huge waste of the limited resource of the WMF and especially of the editor community. It also threatens to poison smaller wikis with wrong or misleading information, making them unreliable and ultimately useless --Ita140188 (talk) 14:34, 14 July 2026 (UTC)Reply
Oppose closure. At the absolute worst, if someone wants to waste his time, let him waste his time. Abstract Wikipedia and Wikifunctions has a long way to go, but it can literally never get there without a live experiment in trying to make it happen. ―Justin (koavf)❤T☮C☺M☯14:41, 14 July 2026 (UTC)Reply
We're seeing the live experiment right now, and it isn't just Abstract contributor time that is being wasted, but also funding, as well as time and energy from small language communities having to deal with the potential rollout. Chaotic Enby (talk) 14:43, 14 July 2026 (UTC)Reply
This argument only works for the editors of Wikifunctions and Abstract Wikipedia who would not use their editing time there to do anything else. It does not take into account the time the rest of the community is spending to monitor the project or even understand what is going on with it (no small ask), the time (and therefore money) of WMF employees working on it, and above all the potential catastrophic time-sink for small communities at risk of being overwhelmed by the generated "articles". Choucas 🐦⬛14:45, 14 July 2026 (UTC)Reply
support closure. abstract wikipedia is a giant waste of time, and for a movement whose most precious resource is the time of editors, it is potentially a threat to all, especially the editors of small wikis. ltbdl (talk) 14:54, 14 July 2026 (UTC)Reply
Support closure. *Responding to Jsamwrites, dealing with repetitive words is already something the LLMs can handle. Earlier today, I noticed I had used the verb "to contrast" three times in one paragraph and wasn't happy about that. My fix was en:Special:Diff/1364077153. Since you brought up that exact example, I just asked Claude to work on the same issue. He came back with a rewrite which I think is just as good as mine, perhaps even better (and I'm not even counting the typo he pointed out).
As Femke said above (and I also said recently on enwiki), I'm all for investing in speculative projects to solve big problems. I don't begrudge the money spent or the volunteer effort invested. Risk is the nature of speculative projects; the fact that any particular one does not make it to production is neither a condemnation of the project nor of the people who worked on it. But for a project to make sense, there needs to be some plausible expectation that it might work as well as a potential payoff if it does (i.e. solves a problem that needs solving). I'll address each of these in turn.
Can this work? I'm sorry, but I don't think so. I've just read through the project evaluation. To be brutally frank, it seems pretty damning. I see major concerns expressed about both the theoretical aspects (i.e. how to architect a natural language translation system) and practical aspects (how to implement a large-scale software project). The only thing that stood out to me as silly was the gratuitous and parochial swipe at the choice of JSON vs protobufs for data transport. But that was four years ago. Lots of dire predictions of the future have been proven false, so we really need to look at what progress has been made since then. Sadly, I'm not seeing that what has been demonstrated in July 2026 (and again, my apologies to the team for my blunt language here) even meets the standard of a good technology demo, let alone an MVP. And I'm speaking here as somebody who has spent a lifetime in software development and more than once endured the pain of projects that got shut down.
So that brings us to the other big question, does this solve a problem that needs solving? In 2022 when the project started, the answer certainly would have been a resounding "yes". Just like the proliferation of choices for data formats (for example, JSON vs protobuf as mentioned above) and programming languages (Python, JavaScript, or Lua, as discussed in the report) impede technical progress, so does the plethora of human language impede human progress. The need for automated ways to make information written in one language available to people who cannot read that language is obvious. In 2022, machine translation technology was in its infancy, and projects like this offered hope of a way forward. But that was before LLMs burst on the scene. I wouldn't go so far as to say it's an entirely solved problem, but it's a "mostly good enough" solved problem, and still clearly on an upward trajectory. So, even if the Abstract project were to surprise us all and start to work as well as has been promised, all it would be doing is competing with another already proven technology.
In summary, I'm seeing lots of risk with little upside potential. It's time to thank the people who have invested six years of their lives in this (and make sure that their career advancement doesn't suffer simply because they had the bad fortune to be assigned to a project that never shipped) and pull the plug. There are so many other big projects that need working on and not enough resources to work on them all. RoySmith (talk) 15:01, 14 July 2026 (UTC)Reply
I'm thinking you might be discounting the benefits for marginalized communities and languages here.
Big tech AIs to my knowledge does not support small and relatively rare languages well.
This system is being built not to generate English stub articles but to give people access to a way to generate content in very marginalized languages primarily.
Evaluation based on a comparison with the current state of AI should take that into account IMO.
Unfortunately I don't speak a marginalized language or live in any marginalized community do you? Have you checked with people that do? Have you reflected on why we are having this discussion in English and not any other language?
Maybe we don't see the full picture yet because we haven't actually spoken to those that would benefit the most from this project? So9q (talk) 07:20, 15 July 2026 (UTC)Reply
Have you checked with people that do? [...] Maybe we don't see the full picture yet because we haven't actually spoken to those that would benefit the most from this project? – Have Abstract Wikipedia developers done these things? Phazd (talk) 02:41, 17 July 2026 (UTC)Reply
LLMs are already replacing wikipedia. We can continue to chant "Wikipedia good, LLMs bad" and pretend it's not happening, or we can figure out how to take the best advantage of the new technology. The former strategy is what the T-Rexes did when those annoying furry mammals started scurrying about. How did that work out? RoySmith (talk) 19:25, 15 July 2026 (UTC)Reply
History does not give you the analogy you think you have. For one thing, T-Rexes were never threatened by mammals. Mammals never contributed to the T-Rexes demise; they were simply the best next thing after they died from a pretty major, unrelated, and seemingly insurmountable reason from outer space. I have no idea what think the T-Rexes should do, except that you would need a giant meteor to strike Wikipedia for your analogy to ring true.The answer to regaining readership from LLMs is obviously not to become an LLM. Ask Keir Starmer about that. Aaron Liu (talk) 19:44, 15 July 2026 (UTC)Reply
I think it's too early to discuss closure, given how recently the project launched tbh. I support pausing the rollout and increasing transparency. I am personally skeptical about this project's chances of success, but WMF seemed to be pursuing something it genuinely believed in, and since it wasn't causing any harm, I hadn't been opposed to continuing it. That said, I think the judgment that it "caused no harm" only held because the project remained a self contained experimental space. Once it is actually integrated into each wikis, that changes. The responsibility for errors would ultimately fall on local communities. Since nothing about this is working properly yet, imo it needs to be rebuilt from the ground up, step by step. --𝓰𝓲𝓷𝓪𝓪𝓷(T/C)15:16, 14 July 2026 (UTC)Reply
My understanding is that the Abstract Wikipedia has not existed for long (March 2026?), and generally I think that sandboxes/tests should be given a bit of time to breath before being shut down. Imagine if Wikipedia was hosted by Encyclopedia Britannica in 2001 and after a few months was evaluated as a final product. That said, in this specific case I think the WMF should do some deep thinking about direction and objectives. The Wikidata/Wikifunctions/Abstract Wikipedia model is clearly something that works very well on paper and makes a lot of conceptual sense to a lot of people, hence the grants and funding. But practically they struggle to get human contributors or produce content of any quality, and are ultimately not a useful resource compared to other approaches to summarizing human knowledge (see the LLMs that are booming right now). The whole conceptual infrastructure around Abstract Wikipedia and its anticedents is flawed, and if we are moving into a world of fewer donations, maybe it would make more sense to refocus away from this branch of experiments. – Ajraddatz (talk) 15:16, 14 July 2026 (UTC)Reply
The project has existed for 6 years. It's now open to volunteers, which is proving that even after 6 years of development it's not close to being useable. That is millions of dollars in investments over that span of time. Wikipedia did not need 6 years to be a success. —Femke 🐦 (talk) 15:46, 14 July 2026 (UTC)Reply
I would like to remind you that it took 25 years of AI image recognition research before OCR became useful and 61 years of AI research before transformers and attention algorithms was invented that could generate text. See timeline by chatgpt. So9q (talk) 07:27, 15 July 2026 (UTC)Reply
By the end of 2001, Wikipedia was a joyfully experimental and sometimes even raucous place, with rapid iteration on norms, scope, and procedures. It was clear to both people involved and observers that something interesting and inspiring was happening, with volunteers developing a shared sense of humor and hopping in to document current events (September 11) and things they loved (poker; the Simpsons), even if it largely wasn't hitting the mark yet as a usable encyclopedia. Abstract Wikipedia, on the other hand... I agree with the RFC author's concerns and proposals regarding Abstract Wikipedia. Dreamyshade (talk) 16:02, 14 July 2026 (UTC)Reply
Abstract Wikipedia model is clearly something that works very well on paper and makes a lot of conceptual sense to a lot of peopleBut...it doesn't "work well on paper" or "make conceptual sense" to the people who are qualified to evaluate theoretical and practical feasibility, hence the damning Google Fellows report and the decades of other failed attempts of this type by academics. JoelleJay (talk) 16:11, 14 July 2026 (UTC)Reply
Fair point on Abstract Wikipedia, though I was referring more generally to Wikimedia's approach towards structured data. Elements of Wikidata have been successful and more widely adopted, including being used off of the Wikimedia network. Viewed overall it seems like a good idea with desirable outcomes (automatic generation of high quality content in underserved languages? sign me up!) but in practice it doesn't attract the critical mass of actual humans needed to make it work. Some thinking should be done as to why that is the case, whether anything can be changed to make it more human-friendly, and if not, what elements can be salvaged as we steer the ship in a different direction. – Ajraddatz (talk) 14:59, 15 July 2026 (UTC)Reply
Support for the first two. I'm okay with giving Abstract Wikipedia more time to mature, but I have serious doubts, especially about the amount of money that should be put into it right now. In it's current state, it's no better than Wikidata as a source of information, and probably much more annoying to generate a useful stub from in any language, let alone it's target languages. Leaf.Sheap (talk) 16:05, 14 July 2026 (UTC)Reply
Keep it in a box: If people want to spend another six year trying to make this usable, they should be allowed to do so, but it should be kept in a leakproof box and never be allowed to change a single byte of any other project until the community decided that is has become usable.
Whether the foundation should spend more money on this is a separate question. I advise anyone who is serious about WMF spending to start by trying to get them to simply tell us the total cost of a single Wikimania so that the donors who paid for it can see what their donations were spent on. --Guy Macon (talk) 16:10, 14 July 2026 (UTC)Reply
If anyone else got curious about the cost of recent Wikimanias after reading this, here's what I could find:
2025-2026 budget: "funding events like Wikimania, the Wikimedia Hackathon and more ($2.7M)"
Consolidated Financial Statements FY2024: "The Foundation also had a change in accounting policy to no longer present the Wikimania event as special event expense...This resulted in a reclassification of $698,141"
Support closure and of course the other options too. If WikiFunctions volunteers and random en.wp-banned editors want to continue spending their time tinkering in Abstract then they can do so in sandbox mode and without WMF funding toward the project's development. WMF can instead go spend its donations on digitizing and hosting physical media archives from developing countries and supporting existing digital media in those places with WikiLibrary subscriptions (e.g. for AllAfrica). JoelleJay (talk) 16:24, 14 July 2026 (UTC)Reply
If you disagree with how a non-profit uses its donations, the solution is to donate to a different one, perhaps one whose mission actually is digitizing and hosting physical media archives from developing countries. Feeglgeef (talk) 17:51, 14 July 2026 (UTC)Reply
Our mission is to "a world in which every single person on the planet is given free access to the sum of all human knowledge". That often includes digitalisation efforts. Affiliates in particular have collaborations with GLAM institutions to digitise their collections and make it accessible to a wider portion of humanity. The underinvestment in Commons means that a lot of this work never reaches Wikipedia or other more visible projects, however. —Femke 🐦 (talk) 18:07, 14 July 2026 (UTC)Reply
That's the vision statement. The mission is broad enough to encompass conventional Wikipedias, Abstract Wikipedia, the Wikisources (which is probably the project type best positioned to steward a scanathon, although Commons would be the direct beneficiary), Wiktionaries, etc. Arlo Barnes (talk) 21:28, 15 July 2026 (UTC)Reply
I don't think that writing articles in a lingua franca resembling a programming language is a good fit for a crowdsourced project. Accordingly, I don't think this initiative is suited to the strengths of the Wikimedia Foundation, and I don't think it should continued to be pursued as something that will fit into a crowdsourced content creation workflow. Thus I support closing down the Abstract Wikipedia project as a public facing project intended to integrate with other Wikimedia sites. I am open to the idea of providing some level of support for ongoing research to continue to explore the concept, although my preference is to let universities provide the bulk of funding, and thus better connect further investigation into the academic ecosystem of peer review. isaacl (talk) 17:58, 14 July 2026 (UTC)Reply
Support all, I'm gonna quote someone from some other godforsaken site, because they said it better than I can: "This is an outdated approach to a problem that the WMF should not be trying to solve. It's kids building a moon rocket in their backyard." I'm flabbergasted that this passed through all the relevant meetings and checks without getting shot down. The mastermind behind it has no background in linguistics, which shines through, but not only that, nobody at any stage appears to have had even a basic understanding. Small wikis appear to have never even been consulted in the proposal, and how the Beta (Alpha) was launched meant they were effectively shut them out from directing the wiki's development, particularly shit when it's their wikis this would affect. How were they ever supposed to maintain the presumably-vast amount of abstract articles? This has been one big exercise in institutional dysfunction, and the resources would be better spent either scaling small wikis organically, or developing more types of wikis for documenting knowledge inspired by local contexts rather than making Eurocentric franchises of enwiki's encyclopedia. Kowal2701 (talk) 18:12, 14 July 2026 (UTC)Reply
Moon rockets exist, and I think everyone agrees kids shouldn't build them, but unpacking the metaphor: does something of this kind already exist? What org is better positioned to allow under-resourced languages to pursue natural language processing and generation? Arlo Barnes (talk) 21:30, 15 July 2026 (UTC)Reply
Here's a better metaphor for you: "it's kids building a perpetual motion machine in their backyard". Never mind that perpetual motion is a solved problem: all respectable scientists will tell you it is impossible. But these kids think they have a chance of actually building one — especially if their effort will somehow, magically, entice all other kids in the world to participate in their crowdsourced project... Oddwood (talk) 23:51, 17 July 2026 (UTC)Reply
Perpetual motion machines are obviated by the rules of thermodynamics, but linguistics isn't a unified field like statistical mechanics is within physics.
Depending on what you think the sink or swim condition is for a project like Abstract Wikipedia, and depending on which linguistic analyses you use, you could either say the job is straightforward ("just" implement the grammar rules of a goal language in functions and make sure the lexicographic data at Wikidata is well-stocked and quality-checked), tricky (some goal languages would require much more preparation than others and still end up clunky), or impossible (a generalized bit of language by definition isn't fitted to the specific needs of a given language community).
As far as your comment about participation, it sounds like you disagree with the wiki way which is fine; but most people here think volunteered, informed, intentional labor just works (for reasons the evidence of which surround us). Arlo Barnes (talk) 05:15, 18 July 2026 (UTC)Reply
Regarding the wiki way: I don't disagree with it; sometimes it obviously works, and sometimes it doesn't. For a viable project you need to reach a critical mass of contributors. This has obviously worked for the English wikipedia, and other large wikipedias and similar large projects; but smaller projects often struggle to get off the ground. Wikinews was shut down recently precisely because it failed to grow in the wiki-way. Somehow I am rather doubtful that this particular niche project can successfully grow in this way. Oddwood (talk) 02:12, 19 July 2026 (UTC)Reply
Support closure. I agree, this project has failed. It is best practice that failed experiments should be killed quickly. There are more boring projects that can help scale smaller wikis which are more feasible to deliver (e.g. categories as structured data). MER-C18:48, 14 July 2026 (UTC)Reply
Support pause: It is clear that the team is mindlessly moving too fast and about to roll out an alpha-at-best (AW) and beta (WF) project across the universe. I disagree with a few premises of the RfC—most importantly that language-agnostic specification is impossible, as Abstract Wikipedia is supposed to define parts of an article by their meaning and not language features, and some articles do demonstrate this. I believe that the promise of the projects is worth a lot. But the WMF has been working on them in a way so that we are still an infinite distance away from that promise. As it stands, AW and WF are hardly approachable.I find the AW response to challenges in content governance unconvincing. When making Wikifunctions, the project understood that users were likely to get things wrong on the new project and only approved the best applications to edit. It only became editable about a year later when it became usable and had developed infrastructure. What makes the team think AW, a project where it is way easier to use the wrong functions or just copyvio and get things wrong in a way that goes against all the ideals of the project itself, can be immediately declared "open beta" and editable by all in such a broken state? Right now, few articles on AW do what it is truly meant to show.Compositions are supposed to be the basic building block/glue that makes the projects work. Wiki-functions are supposed to be modular, and compositions allow them to chain together and do meaningful things. Every single Abstract article is a composition. Yet editing them is somewhat atrocious; what'd take you two minutes in Python or even Scratch regularly turns into 15 minutes in the compositions interface prone to just saying no. I don't think it can be improved much without the aid of a VPL like w:Blockly (of Scratch fame) or w:LabVIEW's G (the official look of this is awful. Check out EV3 for one that looks pretty.). This has been raised before! In fact, it was raised a year before wikifunctions.org was even launched: Phab:T301418. Yet developers have paid it nearly no heed and are rushingto deploy without it. The composition language is also hamstringed by the lack of variables, not even constant variables, that seems to be a big factor in how dang slowly everything loads, because it means functions need to be called again every time its return value is required. But to be fair, it is a functional approach, and this constraint is one template editors are used to.I conditionally oppose closure because I see the potential of the projects. But my condition is that the projects prioritize addressing the concerns with defined deadlines, above all else. At minimum, there needs to be a much easier interface to make compositions (probably blockly), the realization of the promise—made as rebuttal to a major point of the Google Fellows critique—that "The ZObject language will not be exposed to the casual contributor. In many (perhaps most) cases, contributors will see labelized versions of ZObjects.", and much easier ways to work with lexemes in connection with Wikidata entries. Unfortunately, that seems unlikely, as the WMF's relevant devs appear either too interested in working on types and details or excessively sluggish to deliver the everyone-friendly tools that the projects acutely need to work on itself. It's been years. We can't move forward atop a house of cards. Aaron Liu (talk) 18:54, 14 July 2026 (UTC)Reply
Personally, I think this idea is a much more massive waste of resources than even Wikinews ever was, and it is surprising that we don’t even have the full transparency on how many WMF/WM Endowment funds are being wasted on this project while critical parts of our infrastructure are underdeveloped and teams that are supposed to help us are being abolished. We have the chance to nip this in the bud before they waste many more tens of millions of dollars on this wildly unusable project with worst interface ever known to man. Not even programmers would want to participate in this. Support closure. stjn[ru]19:39, 14 July 2026 (UTC)Reply
Oppose 1 and 3 (Oppose Pause and closure). I contribute to Abstract and Wikifunctions, and let me say, I absolutely agree that most of the current pages are worthless. Many of the articles were created by people with no experience in Wikifunctions, meaning that they will be bare-bones and terrible. Many of them haven't been updated with newer functions since the project released. Half of the articles are created by some guy mass creating low-quality articles using his own AWB-like program. I need to reiterate - the option to include Abstract articles in Wikis is not forced by the WMF, it is chosen by the community. As an example, the Spanish Wikipedia will not have Abstract articles until the Spanish community enables them. Therefore, the first point is basically already the case.
The articles are terrible because the actual userbase is busy creating the functions for it - as an example, User:HenkvD added infobox for city just a few days ago. Sure, it's bare bones, and it loves throwing errors, but it's a fantastic first step. I'm current working on creating a function that will create an introductory paragraph for articles about species, which would include their conservation status, describing date, and their family.
Listen, there is so much that is wrong with this project, but that doesn't mean its rotten. Dozens of functions are being contributed weekly, but it's near impossible to find them as a user. The language data is here, but not for the languages which this project is targeted towards. It's a pain in the ass to make functions or edit any Abstract article if you don't have a background in computer science, are proficient in functions, or the patience of Buddha. I agree, we need more transparency about project goals and more accessibility (especially with the UI). I do also think the WMF seems to be rushing rollout, which I think it counterproductive to our goals.
Abstract Wiki hasn't been out for half a year yet, there is not enough content on it to be meaningful. Of course we haven't met the goals for AW, it's only been 4 months. Was the English Wikipedia actually useful in that time frame? If the project ends up failing in the long term, so be it. But we should give it some more time - there is an active community of people working on making it better. EatingCarBatteries (talk) 20:24, 14 July 2026 (UTC)Reply
I also agree that AW has a lot of promise, but it's being developed in a way that seems extremely inefficient and misdirected. Here's an article from the English Wikipedia as it appeared on 13 April 2001, nearly three months after launch: History of Levant. By September (we don't know exactly when; that's the earliest edit entry available on MediaWiki, even though the page clearly existed by April), there was a note added saying the page was #1 on Google's search results.AW in comparison is extremely sluggish or quantity-over-quality, probably because throughout the 4 years of Wikilambda development nobody bothered to make the compositions (and thus Abstract article creation) interface intuitive to humans, while UseModWiki was right there. It seems wrong to have opened up AW for this lambasted false start when its software is still alpha at best. Aaron Liu (talk) 22:40, 14 July 2026 (UTC)Reply
Thanks for sharing this. I have also been contributing functions to WF and I really like where this is going.
I suggest we regard AW as an early research project.
It could become a very useful, albeit complex (functions that call functions) system that might make a lot of sense to marginalized communities and languages that big tech AI companies don't care about.
It's still very early. The semantic types are still being worked out (there are multiple oposals being evaluated, tested and improved) and the community has yet to settle on a way forward. So9q (talk) 07:49, 15 July 2026 (UTC)Reply
Oppose 3 (Oppose closure). As contributor for Abstract Wikipedia and Wikifunctions I mostly agree with @EatingCarBatteries. Abstract Wikipedia is still in Beta. The language functions are not yet mature, I would say just a toddler. Most of the AW articles bot generated texts, with functions that existed at that time. Rolling it out to a language Wikipedia is NOT meant to be a full rollout, but just a first step in the development. Option 1 (Pause) is up to the target Wikipedia's communities. And even then it is on article by article basis. But it is not even working on test.wikipedia.org. On Wikimania a first attempt will be made to have ONE article available in ONE or TWO languages, and I think even that will be a challenge. BUT I am happy to be able to contribute and help get this started. HenkvD (talk) 21:16, 14 July 2026 (UTC)Reply
Supportclosure - Please use readers' donation money on something else (like creating features or tools that editors actually want, see the Community Wishlist for ideas), cause I doubt people who donated want their $$ to go towards keeping "Abstract Wikipedia" live. Thanks. Some1 (talk) 22:24, 14 July 2026 (UTC)Reply
For transparency, I have seen that this request for comment was linked on the Abstract Wikipedia / Wikifunctions Telegram at 15:42 UTC. Chaotic Enby (talk) 23:43, 14 July 2026 (UTC)Reply
Support pause, oppose closure for now, largely per Ajr. I recognise many of the concerns mentioned in this thread, but Abstract Wikipedia has only really existed as a wiki for 4 months. It has potential, and could be helpful in areas where proficiency in a major global language is low (the reality will always be that many small language wikis will never get to the same scale as wikis like en or dewiki). On the other hand, the way abstractwiki seems to be directed seems to be done so in a way that fails to attract any kind of human readership from outside the Wikimedia sphere (and also doesn't really achieve much more than what Wikidata already does), somewhat in a way that some other conlang wikis such as tokwiki do. //shb (t • c)00:17, 15 July 2026 (UTC)Reply
Personally, I believe tokwiki is not that a problem since it does not actively causes trouble in Wikimedia movement. Nor does Abstract Wikipedia currently (by comparison LLM is actively disrupting in Wikimedia movement). GZWDer (talk) 15:44, 15 July 2026 (UTC)Reply
Oppose I'd rather spend my time contributing than engaging in out-of-process wikipolitics. If anyone doubts that I have a very well-informed viewpoint, feel free to investigate my contributions. --99of9 (talk) 00:56, 15 July 2026 (UTC)Reply
None of this is "wikipolitics" (what does that even mean?), nor is it "out-of-process", as the very page section you linked indicates: Extensive consultation with the affected community is crucial before closing a Wikimedia project. This consultation should be open and transparent, allowing all stakeholders to express their opinions and concerns. This discussion right here is the extensive consultation in question. No one really has to care about how "very well-informed" you consider yourself to be, and even less to try to figure that out by themselves; many contributors advocating for different outcomes made the effort to show it by productively engaging with the discussion. If you would rather do something else it is your choice, but please do not dismiss a discussion merely because you find it inconvenient. Choucas 🐦⬛01:33, 15 July 2026 (UTC)Reply
@Choucas: except it is somewhat out-of-process. "Extensive consultation with the affected community" means that the consultation should be held with the Abstract Wikipedia community. As far as I can tell, there has been no consultation on abstractwiki (other than the notification of this RfC), and much of the prior discussion to this happened on enwiki, which is even worse. That's one individual wiki; while enwiki is free to have discussions about abstractwiki's future deployment to enwiki, enwiki doesn't get to decide the future of a completely separate wiki, much less so without discussing it with abstractwiki's community. //shb (t • c)02:16, 15 July 2026 (UTC)Reply
+1 This discussion seems to be part misunderstanding, part fear-venting (wiki community getting inundated with wortless nonsense without being able to cope or have a say in the matter), part "I would like to allocate resources elsewhere", part suggestions for helping improve the goals so they are more specific and measurable and part suggestions for improvement of the UI.
@99of9, @So9q and @SHB2000 I don't see this as being out-of-process. Until Nadzik showed up with a link to the official process yesterday, the actual process of requesting closure of the project was clear as mud. To my understanding LangCom explicitly does not jurisdiction on this and the Sister Projects Task Force was dissolved recently. In addition, the policy being linked to resides on a subpage of a now dissolved committee, making it hard to figure out if the policy is still in effect. Also, given previous precedent in this area of project closure requests and the Wikinews and Wikispore RFC following the SPTF consultation (which was the first time the policy was exercised) in my opinion, a meta RFC was the correct choice to allow for the discussion of the viability of the projectthat allows for the participation of English Wikipedia editors who raised concerns, Abstract Wikipedians, Wikifunctioneers and other small Wikipedians who might share similar concerns given WMF's rather accelerated annual plan. Sohom (talk) 08:43, 15 July 2026 (UTC)Reply
@Sohom Datta: picture this – I start a discussion on my home project, the English Wikivoyage (imagine it's 50 times the size it's now, just for this hypothetical), about the issues the English Wikipedia has. Most of them are genuine legitimate issues, and issues that are pretty widely agreed upon the English Wikivoyage community. So instead of discussing it with enwiki, I go straight to Meta-Wiki, proposing its closure, citing that widespread enwikivoyage support to close enwiki was the reason it should (leaving only a simple notification on enwiki), with the proposal garnering significant support.
If that hypothetical situation sounds absurd, that's because it is; however, that is also the exact scenario happening here. All the discussion prior to the RfC happened primarily on enwiki, with only a singular notification on abstractwiki, doesn't exactly scream "correct choice" to me. At the very least a notification should have been sent out to all wikis, not only to enwiki. //shb (t • c)09:05, 15 July 2026 (UTC)Reply
@SHB2000 I don't think that hypothetical is too absurd, that has been how a lot of closures start imo. Requests for project closures would rarely come from the people most aligned with the mission. What matters is that once we have the questions raised, we have them addressed by the community of the wiki/let them have their say which is the point of the RFC. At the very least a notification should have been sent out to all wikis, not only to enwiki. Good point, I'll make a few notifs. Sohom (talk) 17:23, 15 July 2026 (UTC)Reply
What matters is that once we have the questions raised, we have them addressed by the community of the wiki/let them have their say which is the point of the RFC. Why is an RFC needed for this? The Foundation made a page for responding to these questions and the Abstract Wikipedia community is engaging with it. Was it really necessary to start a formal discussion about closing down the project before that response was finished? Doing that sends the message that the response of the Abstract Wikipedia community will be ignored and closure will be demanded no matter what. Warudo (talk) 18:48, 15 July 2026 (UTC)Reply
@WarudoThe Foundation made a page for responding to these questions I'm sorry to the Foundation folks who helped draft it, but that page is corpo-speak hell. It deflects almost every single question with only concession being around "hey we will document our progress better" which feels very empty and tone deaf. This is echoed even among the comments/engagement by the Abstract Wikipedia community on the talk page as well. A RFC on the other hand is probably the only mechanism we have to resolve disagreements between two projects about policy and has the upside of allowing much more free-form discussion between both folks who are sceptical and those who want the project to succeed while also soliciting much more clearer answers on the touchpoint criticisms that non-abstract wiki community members have. Sohom (talk) 19:32, 15 July 2026 (UTC)Reply
It certainly is corpo-speak hell at the moment but it is presumably not done yet. I think this RFC would end up being opened no matter what but, again, opening it before the response is finished signals that we don't care about what it will end up saying. Warudo (talk) 19:40, 15 July 2026 (UTC)Reply
I mean, a pretty big demand (perhaps even two of them) out of the three is exactly that the WMF give us mensurable deadlines for their great promises related to AW. Aaron Liu (talk) 19:45, 15 July 2026 (UTC)Reply
I didn't expect the draft to change much, and now that it's finished, it indeed didn't change much: diff. Based on the link at the tippy top since this RfC was created, I am sure that the RfC people read the response before opening this discussion. Aaron Liu (talk) 18:23, 16 July 2026 (UTC)Reply
I think you linked to the wrong diff. But in any case, you are correct. It is very disappointing to me that the WMF chose to mark the response as finished a day early and without making any large changes but it is what it is. Warudo (talk) 10:22, 17 July 2026 (UTC)Reply
the Abstract Wikipedia article for Diablo, rendered in English Arguing about the distribution of money from a shared pot is definitely politics, and it is definitely not content contribution. Since the actual affected community has just been prodded a link from the proposer with one prior edit, I do not consider this to be consultation with the affected community. I'm interested in why you feel like enwiki is an affected community, especially since all integration plans involve discussions in advance about whether or not AW adoption is useful to a project. The "informed" comment is to ward off a common RfC tactic of minimising the value of opinions from editors who don't want to spend their time here. Here's what I helped User:Feedmepaperr do instead, and IMO it is evidence enough on its own that AW has sufficient potential. This article is better than almost every non-English article already. AW has not been going for 6 years, it has been in beta for a handful of months. --99of9 (talk) 08:03, 15 July 2026 (UTC)Reply
I'm impressed about this example. As a contributor to both Swedish and Danish lexemes and labels in Wikidata I'm so happy all that hard work on whipping the data into shape is being used in a new way beyond just a limited infobox.
The interesting thing to me is that in both these innovatations there is a strong need for fact-checked good quality open data. You can talk about LLMs that can do impressive things, but they leave no guarantees as to how they got to the result.
Both these examples (AW and Scribe) rely on high quality data and a community of engaged contributors. LLMs also rely in this. But none of the models I have tried so far actually disclose the exact full dataset they train on.
The fact that AW+WF+WD can now generate a decent stub article less than 20 years after launch is really impressive! Compare it to 61 years of AI research before LLMs were invented. AW is already a success seen in that light if you ask me. Something of great value can take a long time to get right. Science is full of examples of that. So9q (talk) 08:26, 15 July 2026 (UTC)Reply
Oppose closure. I see the potential of this project in the fact that the target is not all text, but rather encyclopedic, objective fact driven. However, I think it is better to start the expansion to each language versions after the improvement of the quality of current articles. At present, many Abstract Wikipedia articles are left with only short sentences created as a trial, and still have errors, which make people's impression bad. I think it is better to review the process by deleting stab-like articles, eliminating errors, and focusing on improving the quality of model articles by field. Higa4 (talk) 02:04, 15 July 2026 (UTC)Reply
Support pausing and transparency, Weak oppose closure. I think that if this project can work some years down the line it will be a huge win for linguists and Wikipedians alike, but I don't see that happening within the year, so it needs to be paused. Guy Macon said above about a "leakproof box" and I think this is similar to what I think should happen until it can be proven that this project can output useful encyclopedic content. I've attempted making articles myself, and had... limited success. I share a lot of Chaotic Enby's complaints about the project and how writing articles works. That doesn't mean I'm not excited about the concept of this project though. I'm curious to know how much money is still remaining from the grants mentioned above, and how much this project is really costing. A lot of people seem to mention that this is a waste of money, so I'm curious to know how bad it really is. If we really are hemorrhaging money from this I'd support closure, but if we can keep this running on a reasonable budget that'd be fantastic. There is promise here, however idealistic it seems. Feedmepaperr (talk) 03:58, 15 July 2026 (UTC)Reply
After returning to Abstract Wikipedia for the first time since March, I've found it has actually gotten significantly easier to make decent articles. I've made abstract:Q17198982 based on my enwiki GA en:Diablo, Washington. I took some bits of code from abstract:Q7343 which is another decent article. I got some help from the folks over on the Abstract Wikipedia Telegram channel, but I was mostly able to figure things out myself. Didn't even take me that long either, and was actually kinda fun. Some annoyances I remember from back in March have since been fixed, and generally the site has just gotten better. As for translating the article, which is a large part of the point of Abstract in the first place, over half of the content of the article can actually be successfully translated into Swedish. Now, this is mainly because there's a user somewhere out there who's really intent on making Swedish work in particular, but I'd imagine given enough time that treatment will extend to other languages as well. I still support pausing and transparency but I'd really like to see this project continue to get better over time. I truly believe it can. Feedmepaperr (talk) 07:04, 15 July 2026 (UTC)Reply
Thanks for this @Feedmepaperr. As I mentioned on Discord where you presented this to me first a few hours ago- this is probably one of the best Abstract articles I've seen so I really commend you on that. I still, fundamentally, think this could have been done far quicker and easier using native speakers or machine learning translation tools. qcne(talk)08:10, 15 July 2026 (UTC)Reply
+1 A well oiled AW+WF+WD can beat any of the LLM models any day when it comes to reliable fact-based text generation with full transparency and editability (= no hallucinations, no model bias causd by training data or algorithms, no secret training data, no secret algorithms and no secret training harness, no corporation control, no big datacenters using a ton of resources)
I use LLMs every day, but let's be honest, they are not suitable for generating encyclopedia content which is extremely hard. AW is probably not going to surpass human editors ever, but that's not the goal.
AWs goal as I see it is: to help human editors get started writing fantastic articles in a language they know well together with a minimum of bias and a maximum of ability to change both data and functions that shape the text being generated. So9q (talk) 08:41, 15 July 2026 (UTC)Reply
The others have addressed the LLM suggestion. I'll take the "using" native speakers claim. Here's my proposal for how to measure your claim. Which of the following happens first: 10 language editions of Wikipedia have an article on Diablo as good as this, or the current AW article is made renderable in 10 languages? I bet it is the latter. I'll even spot you a 25 year headstart! 99of9 (talk) 10:44, 15 July 2026 (UTC)Reply
I would say the far more likely scenario is that half of the functions used in that article are deprecated before it gets to 5, as soon the mostly English-speaking, mostly monoglot, mostly non-linguist community finds the next 101 level NLG problem they have cast into the foundations.
The idea that a project that took months to figure out "we can't just have article-ful and article-less functions and expect them to work in both English and French" will be the first to support barely documented Niger-Congo B languages is laughable. REAL MOUSE IRL (talk) 11:33, 15 July 2026 (UTC)Reply
over half of the content of the article can actually be successfully translated into Swedish. Now, this is mainly because there's a user somewhere out there who's really intent on making Swedish work in particular, but I'd imagine given enough time that treatment will extend to other languages as well.Why do you think there will be any linguists in the target minority languages willing and able to put in the amount of work it apparently took this Swede just to reach a level where half the content of one stub-length article can be rendered in their language? Wouldn't these hypothetical people who have the time and background to learn WF and navigate AW UX be much better served by just...spending that time actually contributing to their own Wiki (either organically or via ML/LLM translation)? Why would you expect anyone from communities that already have extremely few (or zero) contributors to their language edition to embrace this extremely new-user-unfriendly platform, especially when the best result they can hope for is a small, stilted collection of unconnected "facts"? And if the goal is to eventually have translation into actual articles rather than handfuls of basic sentences, what does the timeline look like for that? JoelleJay (talk) 13:14, 15 July 2026 (UTC)Reply
I hope that one day making a few specific functions work in your language will not just unlock a few sentences like you mention, but rather thousands of articles for your language wiki. That will just take time though. As I mentioned above, I expect this project to take a while, possibly years, before we get useful content en masse. As of right now, you're correct that a minority language speaker would be better suited just translating individual articles but eventually there'll be more decent articles here than an individual could make on their own, and at that point it'll be useful to learn WF. Feedmepaperr (talk) 05:21, 18 July 2026 (UTC)Reply
Support 1 and 2, Oppose 3. With regards to 1, things are simply too slow and error prone for a rollout. (Though that seems to be a wikifuncitons issue) For 2, Obviously the WMF needs to be transparent about where it's money goes. But the project shows some real promise, the article on the great barrier reef is quite impressive. At 4 months in, killing it seems irrational, so I oppose 3.— The preceding unsigned comment was added by MBAB (talk)
Support all three, but I feel 1 needs tied to 2. Slight preference for 1 over 3, but only if we can get the thing shifted. This can be useful for subs and subs only. :Leo Tolstoy: born :date:, died :date: is :an author: from :The Russian Empire:. :He: is also known as a :Blah blah blah:. :His: best known works are :whichever people prefer:. That is the full use I see of it. An autotranslation of that would let anyone get the basic idea, and it'd provide a starting ground for an article. Jerodlycett (talk) 06:11, 15 July 2026 (UTC)Reply
Oppose to all the suggestions except increased financial transparency. I welcome any suggestions to improve the goals so they are SMART and clear to everyone. Let's fail courageously and transparently 😀.So9q (talk) 09:10, 15 July 2026 (UTC)Reply
Could we please distangle the proposal formation, argument collection and opinion expression? This RfC is going in all directions at once, and becomes incomprehensible for non-native speakers with limited time. Maybe a few quick process questions: did the organizers already talk with the involved staff members? What evidence have they studied? Apparently this was based on a Village Pump discussion on en-wiki, so perhaps I missed something. Effeietsanders (talk) 11:01, 15 July 2026 (UTC)Reply
On comms: I didn't hold separate discussions with the team before opening this. The substance was raised over roughly three months at en:Wikipedia:Village pump (WMF), where staff participated, and both Denny and Sannita have engaged here. So I hope this formalises the discussion via Meta that staff were already part of. I posted RfC notices at Abstract and Wikifunctions.
On evidence: this is set out in the RfC itself (the Google Fellows evaluation, Falk's paper, Dingemanse blog post, the sampled articles, the annual plan, and Chaotic Enby's contributor account written above).
On structure: yeah, it is interleaved and I'm sorry if this wasn't clearly written initially. The three proposals are in the Proposals section above and can be supported or opposed independently. But I also hope this more general Comments section would be a space for editor colleagues to critique, analyse, and discuss the Abstract project in an open way. If a clerk wants to reorganise the discussion into support/oppose subsections that's also fine. qcne(talk)11:30, 15 July 2026 (UTC)Reply
Taking the experience of a single newcomer to the project, and titling it "what contributing actually looks like" was already highly biased as an argumentative tool. Now calling it "evidence" makes it ridiculous. The very structure of the page means that a counterpoint cannot even be put except in an "opinion/comment". As a regular WF/AW contributor, the first time I saw this "evidence" was after many people had made their judgement (because the "comms" did not include a discussion with the primary affected community). --99of9 (talk) 12:04, 15 July 2026 (UTC)Reply
Support closure as per the rule-based translation is a dead end section below. If there is any money or developer time going into this project, it should be stopped. If some volunteers want to continue tinkering, I guess it doesn't hurt but there's no reason to believe this will ever achieve the stated goals. Erynamrod (talk) 12:27, 15 July 2026 (UTC)Reply
Strong oppose Closure: I believe Abstract Wikipedia is currently immature and far from (probably never) replace Wikipedia articles, but have its use case (which maybe very specific in the foreseeable future. (I will explain more later). Oppose Transparency: I don't see the value of it. Oppose Pause the rollout: Abstract Wikipedia is optional, let's prove its specific use case first. (I think your opinion may be changed once an Abstract Wikipedia version of Cebuano Wikipedia go live - this will not be very soon though.)--GZWDer (talk) 13:08, 15 July 2026 (UTC)Reply
User:GZWDer/Cross-wiki content provides some content that can be generated via Abstract Wikipedia in short term. Some are full article; some are part of article or just one sentence.
My advise to Abstract Wikipedia team: the most important thing to do for both Abstract Wikipedia and Wikifunctions is support calling other functions in JS and Python implementation. The next important thing to do for Abstract Wikipedia is to build a function to receive individual label or statement from Wikidata item (without receiving the entire item). The next important thing to do for Wikifunctions is allowing creating functions on-the-fly (i.e. allow a high-order function to return another on-demand runnable function, like fun=bind_first(add, 2) then fun(3)=5).--GZWDer (talk) 14:00, 15 July 2026 (UTC)Reply
Note: Since the very first announcement in 2020 I believe Abstract Wikipedia will not replace Wikipedia articles (i.e. this is seldom a viable way to create Wikipedia articles). The usecase of Abstract Wikipedia is limited, but exists. GZWDer (talk) 15:56, 15 July 2026 (UTC)Reply
Oppose The project needs time to grow and show its value, especially in a time where knowledge creation is increasingly taken out of human hands. The team and community aren't imposing the content on another community and we should let the involved communities decide when and how they want to integrate content from Abstract Wikipedia. --LydiaPintscher (talk) 13:18, 15 July 2026 (UTC)Reply
Support all - This project is based on a fundamentally flawed model of linguistics. Even if it did work, this isn't something that should be done by the WMF. A huge waste of money that could have been spent better; I have no idea how this got this far even. InfernoHues (talk) 15:42, 15 July 2026 (UTC)Reply
Even if it did work, this isn't something that should be done by the WMF.
Aaron Liu, sorry, I should have been more clear. I don't think the WMF should be spending time trying to create a perfect bridge between all languages, even if that were possible to do. InfernoHues (talk) 00:56, 17 July 2026 (UTC)Reply
I'll note that if it can be said that there is a single linguistic model governing AW contributions (which I am not sure of, since there seems to be differing approaches people are taking) it would be generative syntax...contested by some linguists (see linguistics wars) but not 'fundamentally flawed'. Arlo Barnes (talk) 21:43, 15 July 2026 (UTC)Reply
Oppose suggestions 1 and 3 (Pause and closure) (and I'm kinda neutral on suggestion 2). I'm broadly of the view that we (Wikimedians broadly construed, including both the community and the WMF) need to do more fucking aroundinteresting experiments (with appropriate care given to the fact that Wikipedia is a mature and highly-relied-upon resource that we don't want to break for readers or editors). I don't know if Abstract Wikipedia will ever work as fully fleshed out, but I don't think that this is necessarily a problem. I broadly like the idea of centralising a lot of the repetitive busywork of keeping different language editions of Wikipedia in sync, and Abstract Wikipedia is a stab in that direction. As editors, we like to think that carefully crafted prose and meticulously checked and reliable sources are what maketh Wikipedia... and they are obviously important. But huge swathes of the article namespace (on enwiki, at least) are not beautiful hand-crafted pieces of delicately composed prose put togther by a very learned editor who is carefully noting what the Professor Stubbs said and weighing it carefully against an equally respected article by Professor Smith in order to produce a useful introduction to an important topic one might write an essay on during an undergraduate degree. They are geographical stubs on minor Polish roads or small-town railway stations or very pretty but not that exciting medieval churches, or the breakdown of the results of the Netball World Cup, or the Italian offshot of some reality TV show, or so many articles on Telugu-language films and television shows. Lots of these article are basically the same exact paint-by-numbers skeleton with very minor variations. Quite a lot of these articles are based on a source we assume to be valid and which grants a presumption of notability (the U.S. National Register of Historic Places, say). Editors chuck in a couple of extra references (to a dead local newspaper helpfully preserved on the Wayback Machine, perhaps) so as to make sure the notability requirements are met, but ultimately, a lot of Wikipedia is a bunch of useful tabular data with a few sentences or two tacked on for context. A lot of these get written for, say, enwiki and often don't get maintained in English let alone kept in sync when someone does a one-off translation of them into another language. (The same is true in the other direction. See, for instance, the Death anomalies table for a practical example of how the lack of inter-wiki consistency is a problem.) Thanks to not being bound by the physical constraints of print, while Wikipedia is an encyclopedia (as we defensively assert to everyone from corporate PR spammers to people who wish to clutter the place up with poorly-sourced niche fancruft), it has also swallowed up a whole variety of other related but distinct reference works—gazetteers and sporting almanacks and election results listings and law reports and Parliamentary records—all sorts of stuff that would never have been squeezed into the hallowed pages of Britannica. Short of a purge that'd alienate all but the most radical of deletionist ultras (and massively damaging community drama would surely follow that...?), that is going to remain true for the foreseeable future. If, ultimately, what we get out of Abstract Wikipedia is some reusable infrastructure for centralising (and localising) infoboxes and other template-style scaffolding for the long tail of the kind of articles I'm discussing, well, great. Let's see if that happens. Unless there's some particular harm that's done by it (readers turning up there and getting misled? It meaningfully gets in the way of people writing articles?), I'm not sure what the problem is. After the various incidents of community backlash the Foundation has faced when prematurely rolling other stuff out, I'd like to hope they have developed some level of reticence in not botching it in the future by rolling things out prematurely or without appropriate levels of community consultation and support. If they don't, well, that will quite naturally resolve itself in the way you'd expect. Until and unless that happens, I see no reason not to carry on trying interesting experiments. —Tom Morris (talk) 15:50, 15 July 2026 (UTC)Reply
Support 1 and 2. Come from Wu Wiki(Wuu), and if it cannot write Wu sentences well or even write Chinese sentences well, we're quite afraid of it being integrated into our wiki. At least, we need an option to choose whether it is integrated or not.--Jason2016426 (talk) 16:25, 15 July 2026 (UTC)Reply
But what about"integrated into three different language Wikipedias" showed in Status updates? Asking?
And I'm just curious about this project whether helping us reproduce "stubs" easier, so I logged in to have a look, finding it hard to do so, not only to learn the functions, but also not to see all kinds of errors showed by the website. And the results often show maths marks, showing lack of locallization.
And it's quite hard for such kind of tool using functions try to write down all the grammar, then trying to make an article, even to the languages with no people using Wikipedia or something like this. Also ,for those languages with many variants, like Chinese(not only the "simplified" and the "traditional", the "Mandarin"\"Wu"\"Yue"\"Southern Min"\etc.), using Template:NoteTA, people can watch Chinese Wikipedia in 6 versions, editors using different grammars to show the same meaning. This is much more common in Wu Wikipedia, which sparked some edit wars. I'm afraid that functions may not do it well. That's why I'm supporting a pause on the rollout and integration into Wikipedia(NOT OTHER PROJECTS. I think it's quite useful to Wikivoyage when the language problems are solved.), giving editors from Abstract and WF time to make functions and the notes and locallization on them perfect, and also we editors furnishing Wikidata, to make the sentences can be made in the Abstract longer than the sub-stub criteria in many Wikipedias.--Jason2016426 (talk) 06:11, 16 July 2026 (UTC)Reply
Abstract Wikipedia is a project that was supposed to be created sometime. We should develop, and not to mock it when it was juct created. There's another, more important question: why is the project still very raw after six years of development and still is in beta?Таёжный лес (talk) 17:30, 15 July 2026 (UTC)Reply
Abstaining from voting on the three proposals for process reasons, but Commenting that while it is commendable that the RfC author tries to simplify things by specifying "It is not about Wikifunctions", basically, the two projects are near-inseparable (and share the same origins). If Abstract Wikipedia doesn't work out, WF is deprived of its main natural-language dogfooding platform, and much of its reason for being. If Wikifunctions were to go away for whatever reason, Abstract Wikipedia would be instantly unworkable. — Arlo Barnes (talk) 21:56, 15 July 2026 (UTC)Reply
If nothing else, it's an interactive Rosetta Code. But I also think that the "language" of compositions makes it easier for non-programmers and non-English-speakers to contribute bugfixes or test cases, which a template+Scribunto devwiki like Fandom's could not do. YoshiRulz (talk) 15:52, 18 July 2026 (UTC)Reply
You write it in the present tense, but I'm not seeing it happening already. Maybe it will happen someday, but I'm really not sure. I am a programmer and a speaker of English and several other languages, and I find the composition interface very complicated, inefficient, and frustrating. I haven't yet seen a lot of people contributing a lot of compositions, and here we are not talking about the Abstract Wikipedia site, which is very new, but about the Wikifunctions site, which has been active for three years, and which could be used for making functions whose output can be embedded into wiki pages for well over a year.
(How much is "not a lot"? See this query, which shows all the people who ever edited compositions, with edit count. You're the second top compositions editor, @YoshiRulz. There were 149 compositions editors when the data was last updated in May, and it's probably more now, but almost everyone in the list edited them much less than you did. I'll try to update the data ASAP.) Amir E. Aharoni (talk) 16:18, 18 July 2026 (UTC)Reply
I also find editing inefficient and frustrating, and a selfish part of me wishes that they'd spent another year or two on WF before launching AW. This is pure speculation, but maybe the growth curve of attracting editors to WF from other WPs hasn't started yet due to the combination of an obtuse editing interface and the lack of useful layout components. In the meantime I will continue to convert code implementations into compositions so they can be translated. (re: WF:NOT, it gives the criterion as [...] useful and meaningful code, not temporary, arbitrary snippets [like GitHub Gists]. f:Z20741 and f:Z35585 were what I had in mind.) YoshiRulz (talk) 16:58, 18 July 2026 (UTC)Reply
A little update: As promised, I've just updated the data, so now it includes information about edits until the end of June 2026. The change is not big, however. In almost three months since the last update, the total number of user who ever made an edit to a composition implementation grew from 149 to 157, and @YoshiRulz is still all-time #2.
In case anyone is curious, the all-time numbers of users who contributed to implementation in each programming language:
Doing useful work on the composition interface even as a programmer is somehow harder than learning enough JavaScript or Python to do so. Aaron Liu (talk) 19:29, 18 July 2026 (UTC)Reply
I thought Abstract Wikipedia was going to provide automatic descriptions for Wikidata, to help combat database bloat in the same way the mul project was to address labels (and has rather failed, as its allowed usage is so small). Can it handle P31 statements well enough to focus on that limited goal, as it seems to be struggling with anything more. Vicarage (talk) 22:08, 15 July 2026 (UTC)Reply
Yes, that kind of one-line description is more amenable to the structure of these early NLG functions. But because efforts have been focused elsewhere, you'll find it's still not as good as AutoDesc's output. YoshiRulz (talk) 20:03, 16 July 2026 (UTC)Reply
Oppose closure. A lot of the concerns raised here remind me of the opposition to Wikidata from other projects, identifying difficulty contributing and problems keeping to its roadmap, and I can easily imagine this RFC being brought about Wikidata, citing much of the same concerns, in about 2015. That would have been an exceptional mistake. I haven't quite got my head around what Abstract is trying to do, but I'm willing to give it a bit more room to come up with something rather than shutting it down just because it's not looking very good now. All our projects were pretty awful in year one. Andrew Gray (talk) 22:46, 15 July 2026 (UTC)Reply
I don't see the parallel to wikidata. My first introduction to wikidata was at an edit-a-thon where somebody showed me how to set up inter-language links. It took me a little bit to get used to the editing interface, but it was immediately obvious that this was solving an important problem: it turned the O(n^2) task of linking between different language articles on the same topic into a O(n) task. And not only was it solving the problem well, there were no other extant solutions to the problem to compete with it. Wikidata also addressed another big problem which is that while it's tempting to think of the wikipedia category system as a tree, it's not. I'd already been burned by that once when a tool I was building blew up when it encountered loops in the category graph. It's also temping to think of subcategories as implementing is-a relationships, but you quickly learn that's not true either. There are other kinds of relationships expressed, but no indication of which kind you're traversing. And once I was introduced to wikidata, I could quickly see that both the tree-structure and relationship-type problems had been solved. There was no "I haven't quite got my head around what Abstract is trying to do" aspect. The value that wikidata gave me was clear on day one. RoySmith (talk) 15:35, 16 July 2026 (UTC)Reply
Support closure with resources reallocated to useful initiatives. This project should never have been approved as the approach was widely understood by 2020 to be technically non-viable. This 2016 nytimes article covering google translate's cutover to machine learning comes to mind as a moment that the dominance of ML approaches for natural language generation broke through in popular culture, let alone NLP/ML/software engineering communities NicheSports (talk) 05:56, 16 July 2026 (UTC)Reply
Support closure (also support other two as second choices). Apart from all good reasons given by others, I note that neither here nor at the WMF response to enwiki criticism is any mention made of the previous small language disasters, Greenlandic and Scots Wikipedia. Having approval from someone at such a small language wiki to import Abstract Wikipedia "articles" gives zero guarantee that you are actually producing articles in a correct version of that language. Considering how stilted and poor many of these articles are in major languages, I shudder to think how bad they will be in those languages, especially those with a completely different grammar. The comparisons of this 6-years-old project, with multimillion dollar spending and dedicated paid staff, with a small start-up, are laughable. And the example of Wikifunctions "working" as seen by Wort was already debunked at the enwiki discussion, but as is too often the case WMF replies only address the few things they think they can explain or handwave away, and conveniently ignores the things they can't. Perhaps someone pushing Wikifunctions at Croatian Wikipedia (and here) might have first checked some actual dictionaries or even the German Wiktionary[1] which gives a different table. So already Wikifunctions and its WMF defenders are pushing wrong information to the world. Fram (talk) 10:44, 16 July 2026 (UTC)Reply
So already Wikifunctions and its WMF defenders are pushing wrong information to the world Where is that wrong information? The Croatian Wiktionary table you linked to doesn't have any mistakes in it. It is incomplete because there are some alternative forms it does not include but all forms it does include are correct. By your logic, the English Wiktionary is also unreliable. Compare this declension table in the English Wiktionary with the correct one in the Greek Wiktionary. Sure, one of the tables is incomplete. Yet, it doesn't really matter because the form that is listed in the English Wiktionary table is correct. It won't lead to a foreign speaker making a mistake or anything like that. Warudo (talk) 20:42, 17 July 2026 (UTC)Reply
I agree with @Warudo. The important part here is not that whether the information is correct or incorrect. On a wiki, the relevant question is how easy it is to fix it. On Wiktionary, I would know how to fix it. I definitely wouldn't say that it's easy even for people who are experienced with templates, but I know where to start the search for it. With the Wikifunction, I'm really not sure. I kind of guess that it's somewhere in f:Z28929, but even if I'm right, and I am not sure that I am, I would have to spend quite a while to understand that code. And I wonder why should I study this. I don't see how it's better than modules, but I'm open to having my mind changed. Amir E. Aharoni (talk) 21:04, 17 July 2026 (UTC)Reply
Support 3 (closure) > 1 (pause) > 2 (transparency). The entire project is predicated on a misconception of language. Nardog (talk) 11:45, 16 July 2026 (UTC)Reply
Support all three. Abstract Wikipedia is a colossal waste of resources. The foundational idea is incompatible with how language works. Hence the project can never succeed. Joe vom Titan (talk) 15:27, 16 July 2026 (UTC)Reply
Support 1 & 2 Oppose 3. In the sense that abstract Wikipedia serves as a bridge between Wikidata and natural language, by allowing users to curate the order and sense facts are provided, I like the motivation behind the project. As a case study another knowledge graph project, the Cyc project has been generating similaryly bad rule-based natural language sentences about its items for nearly two decades. While silly and not perfect, there is a serious argument to be made that templated sentences are at least factual, and arguably better than nothing, especially in languages where this information is not otherwise available, hence I oppose closure. Of course, I would oppose abstract wikipedia content being allowed or prefered over any human written content for a given language, hence support of 1. Transparency is a no-brainer and I'm frankly surprised finances haven't been disclosed yet. --IntensionalLogician (talk) 16:12, 16 July 2026 (UTC)Reply
I don't think monolingual English speakers like myself should be in a position to decide the fate of this project which has nothing to do with enwp. Weak supportpausing rollout to pilot Wikipedias (I would consider ArticlePlaceholder and AutoDesc to be the bar which must be passed, but the communities in question did ask for it); Supporttransparency I guess; Opposeclosure because it's been barely 4 months since it launched, give it a chance (the 6 years figure includes adding support for WD and NLG to WF, building WF itself, and several prior iterations of designing and prototyping). YoshiRulz (talk) 20:52, 16 July 2026 (UTC)Reply
Support closure - I feel like it would ultimately be cheaper - and more societally beneficial as a whole - to simply spend the money on paying people to catalog and translate important articles into languages that lack them, whether it's from English to something else, or something else to English, and this project is the equivalent of building a supercomputer to invent a perfect field tilling device when any farmer would tell you that you just need a tractor. It's reinventing the wheel and based on a flawed idea that languages require no nuance and one computer system can translate basic ideas into all languages without being stilted or just devoid of context.Zxcvbnm (talk) 19:22, 17 July 2026 (UTC)Reply
I don't see the assumption without being stilted anywhere. AW's goal is to make deterministic and readable content for all languages; that doesn't include "good prose". Aaron Liu (talk) 19:30, 17 July 2026 (UTC)Reply
As noted below, any placeholder articles generated by this project will likely be significantly worse than the user navigating to a (probably English) Wikipedia page and using Google Translate or the like in order to translate the text into their lingua franca. It might even be said that this project would be rendered unnecessary by adding a "this Wiki does not have a page on this, but so and so does. Translate that article into your language?" button on missing pages, utilizing machine learning to fill in the blanks.
The issue isn't necessarily that this project can succeed or not, but that the time and money devoted into it would be misspent time and money, because the problem has already been de facto solved. Zxcvbnm (talk) 06:58, 18 July 2026 (UTC)Reply
Google Translate is not deterministic. At this stage of the models, when an error comes up, people won't realize for a long time, nobody knows what went wrong, and the engineers probably don't know how to fix it within a defined timeframe. Just two months ago it caused (bilingual) me to have a pretty significant miscommunication with someone. As noted above, better articles are very possible, though the WMF currently isn't doing anything to make that easy. Aaron Liu (talk) 13:14, 18 July 2026 (UTC)Reply
I doubt creating a formal language to write translatable fact lists that should produce somewhat natural language is ever going to have an interface that is easy to use.
Why so? The problem of making formal languages easy-to-use has long been solved, and the rest is just concatenation (for non-masters of jargon, putting multiple things together, as in "6"+"7"="67"). We can make the second part at least as easy as Wikidata, which ... is admittedly kind of obtuse, but still much better than the current state of WF. Aaron Liu (talk) 19:34, 18 July 2026 (UTC)Reply
Oppose closure because I think it's too early to discuss. The project has been open for 4 months and I do not share the conviction of some of the other editors that it is based on bad linguistics or that it's dead in the water for any other reason. Therefore, I think the best approach at the moment is to wait and see. Support transparency because honestly that should be a given. Neutral on pausing the rollout because it is a good idea to do it given the current quality of the abstract articles but each community can do that on their own, can't they? Warudo (talk) 20:59, 17 July 2026 (UTC)Reply
Support closure. After so many years and so much money, it is clear to me that the current approach to Abstract Wikipedia is going to cause nothing but harm to the Wikimedia projects and the free knowledge movement. I have not seen any evidence to the contrary, despite following this saga with morbid curiosity for some time now. This needs to end, as perhaps the biggest example of a grant-funded white elephant in WMF history. We also need a post-mortem to examine the quantity of donor funds spent on this project and how that came to pass. I of course support all lesser measures as well, such as a pause and increased transparency. Toadspike[Talk]23:59, 17 July 2026 (UTC)Reply
Support transparency and closure. As someone who has experimented well enough to know that the core foundation of this project, Wikifunctions, is flawed to the point of being unfixable, the entire premise made me very curious but ultimately is flawed. The Google Fellows report put down in writing the exact conclusions I was coming to, which was insane to me when I first read that paper. Kill this with fire. Stop trying to recreate an entirely new visual programming language and pour all the efforts and grant money instead to creating, or at least retooling WF to be, a repository of global templates and Scribunto modules, and creating a proper way to transclude them onto any wiki the same way InstantCommons works everywhere. —UndueMarmot (talk) 07:47, 19 July 2026 (UTC)Reply
The template in question. All the logic appears to be in the /en and /tl implementations, duplicated, so it's no improvement over having separate pages on each language wiki. The Google Fellows report put down in writing the exact conclusions I was coming to [...] Really? There was 3 years of progress between when it was written and when you joined WF, so I find it surprising that you can match all its points to current problems with WF. Or were you referring only to its "Recommendations" section? YoshiRulz (talk) 21:40, 19 July 2026 (UTC)Reply
I find it surprising too that the WF and AW people have hardly addressed the report with actions despite publishing a rather promising response. Aaron Liu (talk) 03:25, 21 July 2026 (UTC)Reply
Close. This is a failed project that relies on bad science and costs millions at a time when the WMF that claims it needs to increase revenue by running fundraising ads all year. BilledMammal (talk) 02:57, 20 July 2026 (UTC)Reply
Stop, rethink, clean up. The project is too early to be rolled out. Remove cross-wiki sitelinks from other projects and pause the creation of new articles. I'm not active in edting Wikifuntions or AW but I have noticed several significant obstacles for Chinese users.
For example, we now cannot generate a sentence like "I have two pens" because we haven't figured out a way to generate Chinese classifiers. "I have two pen" is illegal in Chinese because we need to say "two 支 pen", "two 隻 cat", "two 匹 horse", etc. And imagine doing the mapping for every concept in every Sinitic language (and other languages with classifiers).
The defining sentences are way too anglocentric or eurocentric. Why are we using country (Q6256) to define sovereign states? Can English speakers agree on what a country is? And I fear this cannot be fixed. If we somehow make that not anglocentric, it might still be francocentric, sinocentric or something-centric.
Support closure. The problem that Abstract Wikipedia is trying to solve is either fundamentally impossible or very, very difficult. If the latter is true, I don't have faith that this difficulty can be overcome given some of the questionable technical choices made so far; as a programmer, I found the response to the Google report to be far from satisfactory.
Additionally, the idea that various language groups will utilise this model, which requires a reasonable amount of technical knowledge, instead of just writing or using extant translation methods, is not plausible in my opinion. Refining the interface may make things easier but I just don't see it ever appealing to a wider audience due to the inherent nature of the concept - adding technical language parts and tweaking functions inherently has less mass appeal and a higher barrier to entry than writing text on Wikipedia, uploading images to Commons, or adding data points on Wikidata. Currently, someone can use machine or manual translation, which provides a far lower barrier to entry and better results. In my mind, even a hypothetical mature Abstract Wikipedia is unlikely to possess fewer errors or have any substantial advantage over machine translation; a programmatic and logic-based translation model does not inherently insure against errors or possess an advantage over machine learning. Mir Novov(contribs | talk)05:04, 20 July 2026 (UTC)Reply
Support rollout pause, Oppose closure I beleive the project is still too new to see if it is an inevitable failure. Many of the problems mentioned in the piece are surface level, and while there still are major problems, maybe even foundational problems, it is still too early to kill the project when it just started being publicized broadly. However, those surface level issues do impact the small Wikipedias that would have these articles, so I think we should pause rollout. Icandostuff (talk) 01:27, 21 July 2026 (UTC)Reply
It is hard to know exactly what the different terminology means here, but after reading through some newsletters, the annual report, and the response page, I would support closure in terms of freeing up staff to put their time elsewhere. I am unfamiliar with the overheads and costing of say hosting it for volunteers, but this should not be a core output to the level that it features in the annual plan. In part the deployment has probably been sub-optimal. The decision was made to launch into Beta without having articles. While I don't think that was the right decision, I think I grasp the decision-making behind it. However, that decision-making seems incompatible with the OKR of integrating articles into three Wikipedias. This mismatch feels like it may be related to the project running a few years behind schedule. The 8 July 2026 newsletter opens with "In last week’s newsletter, we shared how Abstract Wikipedia fits into the Wikimedia Foundation’s FY26/27 annual plan: demonstrating Abstract Wikipedia’s viability as a scalable, human-centered way to create multilingual encyclopedic content" (emphasis added), and I just can't find a reading where that seems accurate.Looking at the 1 July newsletter about a demonstration article created for Wikimania, the sample article produces a blank article for me apart from a header box saying it is Abstract Wikipedia (hard to not think of surreal humour). Clicking edit gives me "Wikifunctions returned a failed response: Reached concurrent evaluator call limit in orchestrator, Wikifunctions returned a failed response: Reached rate limit in orchestrator, Wikifunctions returned a failed response: Reached rate limit in orchestrator", although there is a working picture and a timezone box. The response does not seem to address issues raised, there should have been "measurable objectives" before this point. (I come back in thinking here to feeling that it was a mistake to launch without any articles, the 1 July newsletter also states "the idea of Abstract Wikipedia is to provide good, multi-lingual articles in many languages", and if that is the idea, viability would be demonstrated by having good, multi-lingual articles.)On the philosophy I am more cautious because I am not the target market, which is presumably editors of small wikis. However, is there a substantial demand among these wikis for autogenerated articles? If there is, is the demand call for these short and stilted articles over a simple machine translation or other methods of generation? Evidence from the smaller community wikis would be valuable input into this and related discussions, but it seems hard for such input to be that informed when there are no good articles to test with. The mentioned transparency is always a good goal, but in the end this is a very technical project, and even with perfect communication scaling is tricky. If the project manages to find a viable volunteer-driven form, it would not be not so important that it should be the only project to get its own section in the Product & Technology OKRs. CMD (talk) 05:33, 21 July 2026 (UTC)Reply
Support closure The WMF Language Committee has a sensible policy: The Wikimedia Foundation does not seek to develop new linguistic entities; there must be an extensive body of works in that language. It does no good to open a public wiki in a language that no one knows how to write. The translatable abstract language in which Abstract Wikipedia is supposed to be written has not been invented yet; the Abstract Wikipedia team has rejected the existing state of the art for natural language generation on the basis that it fails to handle certain aspects of Niger-Congo B languages’ morphology and produced an alternative that fails to handle certain aspects of all languages. The team seems to have directed almost all of its effort toward developing MediaWiki extensions that barely work and almost none of its effort toward developing a language for writing translatable encyclopedia articles. If that language ever emerges, all of Abstract Wikipedia’s existing articles written in untranslatable Abstract Pidgin English will have to be rewritten. The project should be closed until that day comes. ~2026-41029-42 (talk) 19:55, 21 July 2026 (UTC)Reply
Disclaimer 1: I'm a Language committee member, but in this comment, I'm speaking only for myself and not for the rest of the committee.
Disclaimer 2: What I write here has nothing to do with what I think about Abstract Wikipedia in general. It is only a reply to this specific comment.
With those things out of the way: The Language committee's policy of not allowing projects in "new linguistic entities" doesn't apply to Abstract Wikipedia. I can think of at least three explanations for this. The first is that the policy is about human languages, and this is about what is essentially a programming language. Another one is that despite the name "Abstract Wikipedia", this is not actually an edition of Wikipedia, but a separate multilingual wiki, like Wikidata or Commons. Finally, the Language committee reports directly to the Wikimedia Board of Trustees, and since the Board of Trustees decided to start Abstract Wikipedia, it is not in the Language committee's hands anyway. (I can imagine some scenarios in which the Board would make a decision that would override the Language committee's policy and create a "constitutional crisis", but this is not one of them.)
So please don't try to use this argument. There can be many arguments against (and for) Abstract Wikipedia, and this one is just really not relevant.
Sorry, I didn’t mean to imply that the language committee is or should be involved. I just think the principle is a good one because no wiki can succeed without people who know how to write in its language. If the WMF does, in this case, seek to develop a new linguistic entity, it needs to actually develop it before opening a wiki. ~2026-41029-42 (talk) 16:58, 22 July 2026 (UTC)Reply
Latest comment: 13 hours ago38 comments12 people in discussion
We welcome debate about our project. We have always been transparent about how difficult this project would be. The project is at least as ambitious and challenging as “a free encyclopedia anyone can edit” looked like 25 years ago, or “a knowledge base with hundred thousands contributors” 15 years ago.
Regarding the individual requests:
Re: Pause the rollout. The RFC suggests that we plan to integrate the example articles it lists into unsuspecting language communities without their consent. This is not the case. Rollout means that we make it possible for individual language communities to actively decide that they want to integrate specific, individual articles. They make this decision for each single article, for their own language only.
Re: Transparency on theproject. We are welcoming debate and even harsh criticism on the project. That’s why when the Google fellows wrote their evaluation, we encouraged them to publish. We have been transparently publishing updates about the progress of the project for the past few years. We are currently working, together with the Wikifunctions and Abstract Wikipedia communities, on an answer to recent criticism, and we are planning to publish this here soon. Given the discussion it is clear that questions regarding the feasibility of the project remain. We would like to have a constructive space to answer these. Where could that be?
Re: Close Abstract Wikipedia. Defining metrics and targets for technical, linguistic and quality criteria which can be independently evaluated is a good idea. These are very difficult to measure, and help from the community would be very much appreciated. To help us gauge the success of the project in its first year, we settled on two main metrics: do language communities accept articles from Abstract Wikipedia? And how healthy is the community? We would be very happy to cooperate with the community to define the criteria as suggested by this RFC to keep us honest about being on the right track. Who would like to volunteer to work on this with us?
Here’s a quote from the criticism by Michael Falk mentioned in the RFC: “Wikilambda presents a stark alternative to LLMs… LLMs generate text using opaque algorithms that even their designers struggle to control. Wikilambda makes every part of every algorithm available to anyone. … The role of Wikilambda in all this is to make algorithms “defeasible” … If nothing else, Wikilambda is a thundering critique of corporate AI hype.”
Examples of the current state of articles on Abstract Wikipedia are as convincing as are examples of Wikipedia articles from 2001. The Abstract Wikipedia and Wikifunctions communities are well aware of current shortcomings. Just dip into today’s discussions on our chat. Lively discussions are happening, capabilities are being built out, every single month things get better. Is there stuff that doesn’t work? Sure. That’s why we are saying that the project is in an early stage. We are working on this together. You are welcome to join us. --DVrandecic (WMF) (talk) 19:14, 14 July 2026 (UTC)Reply
On rollout: thank you for clarifying the opt-in basis of the rollout. However, you have not answered my main concern that the Foundation is preparing rollout before it has published the standards by which the content will be judged useful.
On transparency: publishing newsletters and publishing an external evaluation is not the same as publishing the project's costs, measurable success and failure criteria, termination criteria, and an independent up-to-date evaluation of the project as it currently stands.
On a constructive space: it's here.
On metrics: first year metrics are insufficient. do language communities accept articles from Abstract Wikipedia? And how healthy is the community? does not measure if those articles are useful to readers or if the project has achieved its purpose. These criteria should be defined and published before integration, not discovered afterwards by the communities expected to live with it.
On criteria: the project’s basic success criteria and failure conditions should have existed before six years of development and before rollout was planned. I welcome your offer to develop something with the community, but volunteers should not now be asked to invent, retrospectively, the standards by which a multimillion dollar WMF project is deemed minimally viable.
On Falk: he does credit the project with a profoundly moral aim: to give human beings control over information in the Age of GenAI. Yeah, I agree, this is worthy. Falk also, however, ends with a conclusion that Abstract Wikipedia is the latest in a long line of attempts at a perfect language which has evaded so many linguistic alchemists before them.
Volunteers have described this page as a "gutpunch", an assessment I agree with. This page does not provide a place for constructive criticism. It shows in many places disrespect to the volunteers who are contributing to the project with the goal to work towards Wikimedia's vision.
You say that the project should have had success criteria when it started. We did and do. There have been published as our primary goals right back then when the project started: allowing more people to read more content in the language they choose, and allowing more people to contribute content for more readers, and thus increasing the reach of underrepresented contributors. The two metrics we stated, "do language communities accept articles from Abstract Wikipedia? And how healthy is the community?" map to those. --DVrandecic (WMF) (talk) 04:20, 15 July 2026 (UTC)Reply
As I understand it, zero language communities accept articles from Abstract Wikipedia, and thus there is no community health to be assessed. Bluntly, does this not mean that by Abstract Wikipedia's own metrics it has made zero progress towards its goals? Making tthe end goal the only metric is hardly sound project design. Toadspike[Talk]00:10, 18 July 2026 (UTC)Reply
@Toadspike, this is not so true. Even though no language communities accept articles from Abstract Wikipedia now, I could find at least three communities that expressed support for trying it: Bengali, Dagbani, and Malayalam.
There are two other issues though.
The first issue is that at the moment, I couldn't find any abstract articles that can actually be rendered in those languages, although it is possible that I haven't searched well. (It's quite hard to search for an article that can be fully rendered in a language, and it would be nice if it would be easier. @DVrandecic (WMF), consider it a feature request.)
The other issue is that the annual plan demands too little: "one proof of concept article is created on Abstract Wikipedia and integrated in three Wikipedias". I mean, of course there needs to be one article before there are two. But integrating one article is not enough to "make sure that Abstract Wikipedia is viable as a platform for users and sustainable for the Foundation", as the same plan says. Integrating two or more articles based on similar reused functions would actually start showing that it's viable because the whole point of functions is supposed to be effective code reuse.
Of course, there's also the question of what constitutes a good article—this is one of the hardest things to define precisely, although it's quite intuitive for a human Wikipedian to see if an article is good. Amir E. Aharoni (talk) 05:01, 18 July 2026 (UTC)Reply
You cannot reform something with a fundamentally flawed premise. As a programmer, I find it incredibly dubious that programmers would want to participate in a coding project that features both the extremely complicated and nigh incomprehensible JavaScript-based interface which is unavoidable if you want to write any code there and the extremely unreadable software code that reads like Putin’s wet dream. How would joining the project help change those fundamental issues in how the project works? The only thing I can imagine meaningfully contributing to this project at scale is, ironically, an LLM agent, since no human would want to touch this with a ten-foot pole. There are zero meaningful Wikimedia-related problems being solved by Wikifunctions, and quicker it closes, less money from the Endowment we lose supporting something that would be closed anyway in 10 years because it suffers from the same software disease as Structured Discussions / Flow. stjn[ru]21:42, 14 July 2026 (UTC)Reply
Clicking on the first example of a function from abstract:Q408, you get to f:Z36038, which has 3 implementation pages, on all of which the code that actually implements anything looks something like this:
This is unintelligible nonsense even to the most seasoned developer (and a very basic example of a function!). This also, notably, does not use wikitext at all. If you go to f:Z36248, one of the implementations of this thing, the rabbit hole ends up going even further and then, I guess, you are supposed to go down and down and down a list of JavaScript-rendered pages to change anything substantially. The fact that human-readable names are used somewhere in the user interface doesn’t mean that what you came up with isn’t a modern equivalent of brainfuck, if we disregard sunk cost fallacy of 250 newsletters. stjn[ru]16:30, 15 July 2026 (UTC)Reply
I'll quote:
The goal for the ZObject syntax is for it to remain mostly an internal representation. Yes, the expert contributor will be able to use the APIs, and will see the function implementation code in its ZObject format. Yes, there’s always the risk of abstraction leak. But for the majority of the contributor’s experience, the proposed serializers and ongoing design work should allow them to create function implementations as simple as as:
Accomplishing this would require the following features: [...]
These features are either already contemplated for our backend and front-end design, or technically feasible and appropriate for external collaborators–such as Google Fellows–to create and/or contribute to.
The example of the extraordinary complexity is still exactly what contributors are expected to maintain.{{#function:Z29055|L2206|}} exposes this (and L-identifier) syntax as well, and I haven't heard of any plans to change that. This is important because template editors overwhelmingly use the source editor to edit templates. Aaron Liu (talk) 18:20, 15 July 2026 (UTC)Reply
Interesting, I have followed the newsletters and missed that bit. I have written python and js implementations before the compositions became so good that you only have to resort to that in special situations. Nowadays if you want to build a function you compose it in the UI without having to bother about Zobjects at all.
I honestly haven't bothered using a lot of time to learn all the intricacies of Zobjects and everyone does not have to know them to build functions.
Your point is valid for the whole community though, if we were to loose the maybe 5-10 or so most expert contributors that are now active in WF we would probably have issues down the line if nobody would be left to figure the complicated edge cases out. But since I first heard of the project that has never been a real problem. The telegram group is full of friendly and very competent people who help each other out.
So to sum it up: yes Zobjects are complicated, no you don't have to learn them as of june 2026 to contribute any of the high level functions used in AW. So basically what I'm saying is if you don't feel like learning all the details about Zobjects you probably will never have to.
As an aside I personally find the WF community much more engaging and fun to be a part of compared to say the Wikidata one. Thanks to everyone of you who contribute to WF! So9q (talk) 21:23, 15 July 2026 (UTC)Reply
Regarding this claim: "There are zero meaningful Wikimedia-related problems being solved by Wikifunctions"?
Isn't multiple Wiktionaries already using WF to show conjugation tables based on lexemes?
Could it be that you simply haven't researched the utility of WF?
As an aside, I agree that the editing interface for compositions and functions is not ideal. I personally already used LLMs to help me plan compositions (before the copy paste functionality was added).
I also agree that Zobject json is hard to read and understand, but as a programmer I find it interesting and elegant. I haven't bothered writing a userscript to help me read it because I don't have to care about the internal details when I create functions in WF. and others in the community have been very helpful whenever I have had problems with anything.
Maybe you just didn't have the patience to contribute in this early stage of WF and that's ok? You are welcome to suggest improvements to the interface, I'm sure the UX team is interested in hearing how it could be improved. So9q (talk) 09:02, 15 July 2026 (UTC)Reply
> Isn't multiple Wiktionaries already using WF to show conjugation tables based on lexemes? If you mean pages like wikt:hr:Wort, which use the extremely obscure syntax of {{#function:Z29055|L2206|}}, which requires someone to know which lexeme corresponds to which Wiktionary article and which weird Z-number thing corresponds to the conjugation table, then frankly I don’t consider it something worth pouring millions of dollars into, as I said in the previous discussion about the usefulness of it all. stjn[ru]09:17, 15 July 2026 (UTC)Reply
I do also want to check, are there any actual examples of multiple Wiktionaries using it out of their own volition, and not just forced to use them by Denny himself? Because that’s what’s happening on Croatian Wiktionary, all of it was added by him. Are there people who are not Wikifunctions/AWP activists who are longing for those extremely uneditable and obscurely created conjugation tables? stjn[ru]13:27, 15 July 2026 (UTC)Reply
To be fair, Croatian Wiktionary doesn't have that many other contributors. One might say that every current Croatian Wiktionary contributor has been using Wikifunctions ;)
I think that when @DVrandecic (WMF) says One might say that every current Croatian Wiktionary contributor has been using Wikifunctions, he means that he has been the only contributor to the Croatian Wiktionary recently. This is indeed close to the truth. Here's a query that shows the number of edits per account in the Croatian Wiktionary since September 2025. User:Denny, which is the volunteer account of DVrandecic (WMF), made the largest number of edits, 293 as I'm writing this. A bot account is at the second place. The other 49 users made 15 edits or fewer; most of them made 1 or 2.
User:Denny is the only one who added Wikifunctions calls to articles. All of those are declination tables.
He also added these tables to Wiktionary articles in several other languages.
Another user, @Dv103, added such a declination table to one article in the Venetian Wiktionary, wikt:vec:Haus. As far as I can tell, this is the only instance in which someone other than User:Denny used a Wikifunction in a Wiktionary article.
Outside Wiktionaries and Abstract Wikipedia, the only other place where I could find Wikifunctions used in articles is eight pages on the Dagbani Wikipedia.
So far in this comment, everything is supposed to be factual. I cannot emphasize this enough: If my SQL is incorrect, if I missed other users' edits, or if I'm factually wrong about anything else, please tell me.
After the facts above, I'll add a little opinion. As much as I respect User:Denny as a personal friend, as a computer scientist, and as a Wikimedian, I have to disagree with him on this point: The information I'm writing here is more important than the question of showing or not showing the numerical ID of the Z object. Amir E. Aharoni (talk) 12:54, 16 July 2026 (UTC)Reply
I heard about the roll-out but haven't actually seen it in action yet on a Wiktionary, thanks for the link! I hear you have issues with the syntax there. I have not heard similar views expressed before and I have been part of the Wikidata community for years and they have just as esoteric QIDs. Do you have a suggestion for how to make an implementation that is more human-friendly? I personally find it quite elegant, but of course you gotta know where to look for the Zid.
I asked chatgpt to explain the syntax to a new contributor and this was the response. I imagine something like a short manual could be included in mediawikis editing interface whenever the #function syntax is used. Would that help? So9q (talk) 21:29, 15 July 2026 (UTC)Reply
@So9q, declination tables have been available on the more active versions of Wiktionary for many years. They are implemented using templates (and modules). See how it's done, for example, in the "German" section on the pages wikt:sv:Wort, wikt:de:Wort, and wikt:en:Wort.
There are lots of problems with how templates work, and this RFC is probably not the right place to discuss those problems deeply. The syntax for inserting this table in my examples is not much better than the Wikifunctions syntax that @Denny used in the Croatian Wiktionary, and the fact that it's different in each of my examples is itself a major problem.
However, templates have a major advantage over Wikifunctions here, which is more social than technical: Thousands of people know how to create and maintain templates, and they have used their skills effectively to insert useful content into many millions of wiki pages for more than twenty years. Much fewer people know how to create and maintain Wikifunctions. Are Wikifunctions offering people who create and maintain templates any incentive to learn a new skill? Any major technological advantage that convinces them to choose to program their next project as a Wikifunction and not as a template? So far, I haven't seen evidence for that.
Note that I'm not looking for explanation of how Wikifunctions are technically superior to templates. I can find such explanations myself. I am looking for something that actually gets people to choose them over templates.
So as far as I can tell, @Stjn's claim that there are zero meaningful Wikimedia-related problems being solved by Wikifunctions appears to be correct, although I welcome evidence to the contrary. I have to reiterate that I'm not asking for evidence for how Wikifunctions can be used to solve meaningful Wikimedia-related problems; I'm asking for evidence for how Wikifunctions are solving them. Amir E. Aharoni (talk) 05:08, 16 July 2026 (UTC)Reply
If we really want WF to be used by wikis in the future we could decide to deprecate Lua outside WF by say 2040 and make sure WF support Lua also.
But WF currently doesnt support Lua and WF is not supported on a majority of wikis yet.
But if that would become reality, then the communities could easily transfer their special knowledge to WF and continue working there, probably for the benefit of all wikis not just their "home" wiki.
I saw somewhere that Lua support is on the todo list of the WF team but the development of AW has had higher priority. From my perspective the Lua modules are already technical debt. I write a lot of software but I wouldn't want to learn Lua in mediawiki to be honest.
But just like public sector organizations Mediawiki and Wikipedias are complicated machines with a lot of people, knowhow and moving parts. It's probably going to take many years after WF support Lua to get rid of all of Lua in Mediawiki on Wikimedia wikis. Maybe long enough for all the new dev-inclined contributors to just learn WF because its nicer/easier/more powerful. So9q (talk) 18:13, 16 July 2026 (UTC)Reply
Maybe, but how will it happen?
Wikifunctions may feel nicer/easier/more powerful than Lua to you, but at the moment, Wikifunctions are used practically nowhere, and Lua is used practically everywhere. Simply saying that Lua is going to be retired and replaced by Wikifunctions is not going to work. Amir E. Aharoni (talk) 19:54, 16 July 2026 (UTC)Reply
Right now the focus is on making Wikifunctions work great. Currently from my perspective it doesn't because of all the timeout/cache issues. Also it is not clear to me as a contributor where to see details about the timeout and cache in the production system in Grafana / Loki(?) which is sorely needed if people outside the WMF team want to help improve the system.
Chatgpt suggested that we add a regularly running warming of the cache based on the most popular function calls, but that requires access to production statistic that is currently not published anywhere to my knowledge.
I did pioneering(?) work yesterday and got the orchestrator and evaluator running locally to enable easy hacking on it (it took hours, see doc and code). But I have no idea how to send the system stuff to work on.
I have yet to find any documentation in the official repos or the wiki on how to get a whole Wikifunctions system up and running including with import of the current data on WF so it can be tested thoroughly locally.
it doesn't because of all the timeout/cache issues. To be fair, having a system melt down from load when first introduced to a wider audience is a common problem, and falls clearly into the "good problems to have" bucket. For all the things I don't like about AW, let's not get sidetracked on silly stuff like this. Even if it's not the most efficient long-term solution, throw some more hardware at this and get things stabilized well enough to run an effective demo. RoySmith (talk) ) 12:33, 17 July 2026 (UTC)Reply
@RoySmith, performance is one of this project's smallest problems. It can possibly be fixed with more hardware, with a better algorithm, with database or cache optimization, or with some other engineering solution.
My question to @So9q and other big supporters of Wikifunctions and Abstract Wikipedia is not about the performance. It's about the product features: assuming that the performance problems are solved, in which way will Wikifunctions be better than templates and modules? What reason will any editor have to use them even though they are incompatible with wikitext? Amir E. Aharoni (talk) 12:54, 17 July 2026 (UTC)Reply
Thanks for asking that question :). I'm not sure, as I have never met nor talked to a template- or lua-developer in any of the Wikis.
I basically learned just enough about templates and Lua myself to stay away from them :sweat smile:.
I'm not sure if anyone has actually asked or tested WF with them and received feedback. This would probably be a good idea to do sooner rather than later IF the intent of the AW-WF-team is to replace templates and Lua modules with WF long-term. Note the if there. So9q (talk) 10:27, 22 July 2026 (UTC)Reply
@So9q, the question is not even whether they are supposed to replace templates and modules. Modules, for example, can do pretty much everything that templates can, and to my taste, they are better than templates in many ways, and yet, there are still many more templates than modules. In the English Wikipedia, for example, there are more than 600,000 templates, and fewer than 20,000 modules.
The question is different. The question is whether functions will completely replace templates and modules, but whether anyone has any reason to use functions at all. At the moment, I don't see a single scenario for that.
Re: 1: In the latest status update, you said Milestone: By the end of Q2, an article created on Abstract Wikipedia is integrated into three different language Wikipedias. That's the end of this calendar year. The concern is that by the progress made in the last four months, Abstract articles wouldn't seem to be any good by then. We have already identified potential pilot communities and are excited to work with them in Q1/Q2. also paints a picture of "innocent" budding wikis passively accepting integration instead of actively deciding as you claim. Aaron Liu (talk) 22:48, 14 July 2026 (UTC)Reply
@Aaron Liu Just to be clear, we reached out to several communities and only continued the discussion with those who actively supported the idea. We are looking for active support, not just passive support, as you say. Sannita (WMF) (talk) 08:32, 15 July 2026 (UTC)Reply
How does the team define "active support" vs "passive support"? To me, "active" means showing initiative, and thus cannot be shown by reaction. Aaron Liu (talk) 18:29, 15 July 2026 (UTC)Reply
@Aaron Liu We asked several projects if they were interested, and only followed up with those who responded positively to the request. There were project who did not answer at all, and we didn't follow up with them. Sannita (WMF) (talk) 20:56, 15 July 2026 (UTC)Reply
That's nice. For the purposes of my image, though, I'd regard that as passive support; to exaggerate, like provisioning those who establish colonies. Aaron Liu (talk) 02:07, 16 July 2026 (UTC)Reply
I also have a concern about a fundamentally flawed premise. Which parts of building Wikipedia(s) are helpful to automate, and which parts are the creative and deeply human work that volunteers most want to do, and that serve our readers the best? I want human editors to write as people to readers who are people, with messy human sentences, in all languages, especially languages with fewer writers and readers. I want better tools to enable different Wikipedias to more easily adopt material from each other, such as comparing articles across languages, article gap analysis, assisting human translators, and reusing citations. I also want to make it easier and more fun for more people to write better articles more quickly, which means semi-automating more things that aren't writing articles: detection and mitigation of unwanted stuff (spam, COI, UPE, abuse, vandalism, LLM-generated text, etc.), article quality assessment, identification and prioritization of impactful tasks, laborious searches for references in reliable sources, even rough first passes at reference quality checking and citation verification.
Comparing Abstract Wikipedia-generated articles to LLM-generated articles is a bit of a straw man, from my perspective. I believe some of the best uses of LLMs in this movement are to make ambitious and fun tools that help editors without generating article text - like the kinds of tools I mentioned above - and to broaden our pool of tool-makers. There are also people working on public AI alternatives, which are not necessarily contestable but are more transparent. Dreamyshade (talk) 03:53, 15 July 2026 (UTC)Reply
@Dreamyshade: I also want all of these things to happen. I love messy human sentences. We are not taking that away in any way. We are just planning to allow a language community to close some gaps they might have. An article in that language will always take precedence.
Abstract Wikipedia is aiming to support the community to fill in the gaps they want to cover with Abstract Wikipedia, so they can focus on the topics they care about the most. All of this does not take away any of the proposal you mention, which I would love to see happening. --DVrandecic (WMF) (talk) 16:29, 15 July 2026 (UTC)Reply
Latest comment: 1 day ago10 comments6 people in discussion
Hello all!
I am reaching out as a member of the Wikimedia Foundation Board of Trustees and one of its Community & Affiliate liaisons (together with Victoria). We thank you for the comments in this discussion, already present and those that will appear in the coming days. As a general practice, we asked to have a report on the topic of Abstract Wikipedia, and we plan to discuss it soon. This is meant to be a progress update on the project after a few years.
@Nadzik who is the we in "As a general practice, we asked to have a report on the topic of Abstract Wikipedia, and we plan to discuss it soon. This is meant to be a progress update on the project after a few years."? You and Victoria? The Board more generally? Who will see that report and on what timetable? Thanks and best, Barkeep49 (talk) 01:46, 15 July 2026 (UTC)Reply
I would kindly encourage the board to set up a more structured process that they would like the community to follow. This could be fairly high level, but at least should include a solid evidence collection, discussion and opinion collection phase in my opinion. I kindly refer to my earlier comments about the challenges that this style of RfC pose to, for example, equity. In inter-community processes this is even more challenging: especially if there is no established advance notice expectation to stakeholders. Effeietsanders (talk) 11:06, 15 July 2026 (UTC)Reply
There's a procedure (see Nadzik's comment above for the link). The Board + wikimedians + staff spent 3 years developing it, and one of the reasons was that RfCs like this are non-binding. Personally, I see this RfC as a way to establish a 1) local consensus that the Abstract Wikipedia closure requires a serious consideration; in this case 2) a working group, which will write a structured report and submits it to the BoT. Victoria (talk) 14:49, 15 July 2026 (UTC)Reply
Let me clarify my comment: even though there seems to be a procedure to follow for the Sister Projects Task Force, there doesn't seem to be a clean process to initiate it. Even if the RfC is non-binding, it's highly disruptive in its current form, and paints a biased picture. I don't see a constructive process that is clean and can be initiated by the community members above, unless I'm missing something? Effeietsanders (talk) 07:21, 16 July 2026 (UTC)Reply
I'm not sure I understand how "a clean process" would look like. I also don't see why it's disruptive - or more disruptive than the usual RfC. Victoria (talk) 09:26, 16 July 2026 (UTC)Reply
Regarding whether this RFC establishes "consensus that the Abstract Wikipedia closure requires a serious consideration," after almost a week, my count is that the standings are roughly:
Pause the rollout: Strongly supported (~74% in favor).
Transparency: Strongly supported (~80% in favor).
Closure: Highly contested and evenly split (25 Support / 23 Oppose).
I hope and suggest that the Board's working group will focus on creating SMART criteria instead of merely considering whether AWP should be shut down.
The underlying problem, in my opinion, is that the success criteria for AWP in any given language will require meticulous coverage of most of that language's rules of grammar, possibly many times over for different use cases. I don't think people realize what a monumental undertaking this is. According to Cambridge University's English Grammar Profile Online, there are about 1,222 rules of English grammar. I suggest all of them are used in any sizable collection of English Wikipedia articles. I can't even imagine how to grasp the size of that problem for every language. I may be roughly echoing what the Google Fellows said here, but the outcome we have now very much seems to be consistent with simply not owning up to the overwhelming magnitude of any reasonable interpretation of goals as the AWP has stated them. Only the Transparency RFC proposal directives with SMART criteria can balance what has been bitten off with what can be chewed. ~2026-40742-08 (talk) 05:39, 21 July 2026 (UTC)Reply
Rule-based natural language generation is a dead end
Latest comment: 7 days ago10 comments7 people in discussion
As far as I understand, the goal of Abstract Wikipedia is to generate coherent article text from statements in Wikidata. As noted in the previous discussion, it's long been clear that this is a dead end, because every natural language is governed by a huge number of grammatical rules—not hundreds or thousands, but tens, perhaps hundreds of thousands.
I ask everyone discussing this to read this longread — it's an article describing a major project by en:ABBYY (creator of the en:FineReader software) to create a rule-based machine translator. (The article is written in Russian; use your browser's built-in machine translator.) The company spent one hundred million dollars and twenty years of work by dozens of professional linguists to create a machine translator between European languages based on strict rules. By the time the product was even partially ready, the market had been captured by neural network translators, and they failed to recapture their market share. Experience has convincingly demonstrated that no rule-based systems can compete with those based on neural networks. In 2026, trying to compete with neural networks by building a rule-based system is an utterly pointless endeavor. Moreover, the system of these rules itself, the totality of the ways of inflecting words and arranging the places of words in sentences, will be extremely Anglocentric, as has already been convincingly shown in the previous discussion with examples from Japanese and Russian.
People who want to access information in their own language that is only available in another language today (and have for a long time) simply right-click in their browser and call up a translator. There's no point in creating an entire wiki project that, after expending a huge amount of human labor and money, will do the same thing a thousand times worse. (I wrote this message in Russian and translated it using Google Translate.) MBH (talk) 11:46, 15 July 2026 (UTC)Reply
Thank you for sharing this. This is what I was getting at when I wrote conceptually flawed project, based on disproven linguistics in my initial comment. In 2026 we know that such a project is a dead-end both linguistically and technically. These two things are not difficult to realize when spending only a little time studying related historical attempts both on the technical and the linguistic sides. At the end of the day, I agree that it would be great if such a system could work, only we already know that it can't. That this is not something that was realized at any point by any executive involved is frankly flabbergasting and leaves into question what regard for any kind of expertise an organization meant to share knowledge has. The Wikimedia ecosystem is great because it relies on human-made content, amplified by technical means. Stubbornly trying to reverse this paradigm by focusing on technically generated content that then needs to be amplified by humans makes little sense in an age of widespread machine translation (and yes, small languages and communities get the short stick, but focusing on training the very few volunteers of small wikis in impossibly complex systems is a nonsensical goal compared to getting more of them in the communities in the first place). Choucas 🐦⬛12:14, 15 July 2026 (UTC)Reply
I agree. It is essentially accepted common knowledge in the linguistics community that rule-based translation is not feasible. There have been some hybrid attempts (rule-based + machine learning) that have seen moderate success, but creating rule-based translation (and using a man-made interlingua as a pivot language) is not feasible. These have been tried and gone nowhere. I have not seen evidence that those developing AW are aware of the true linguistic hurdles they face, and certainly have not seen any evidence that they've come up with some breakthrough to solve them when no one else has before.
I've seen some working on AW claim this method will prevent bias (I assume as a reaction to the bias inherent in LLM translation), but I vehemently disagree that this would result in no bias. It is impractical to the point of impossibility to capture all nuance of meaning of every language, meaning something needs to be left out, and someone needs to decide what that is (or more likely, the Eurocentric nature of the project will accidentally leave out much). That process introduces bias. Also, meaning cannot be disconnected from its language. When you move information from English to this pivot language, you're changing/removing/altering the meaning, and then when you move it from the pivot language to the target language, you're changing/removing/altering again. This is why interlingua don't work, they are founded an the assumption that meaning can exist separate from language, but it can't. It's just another language with its own limitations.
Honestly, we'd make more progress just setting up some sort of translator mentorship program for editors of minority languages. Erynamrod (talk) 12:15, 15 July 2026 (UTC)Reply
@JWBTH it may be interesting for you to participate here, as I know you believe in quite the contrary — that the field of rule-based language is very promising but just hasn't really been touched properly yet. Well very well (talk) 13:06, 15 July 2026 (UTC)Reply
This is not an opinion about the RFC in general, but just about this particular comment.
Rule-based translation is indeed probably not as powerful in practice as translation based on language models or statistics. However, as far as I understand, Abstract Wikipedia is not supposed to be a system for translation, but a system for writing information in an abstract language that will be rendered in a real human language. Machine translation between human languages requires understanding the input, which is possibly harder than outputting human language, but Abstract Wikipedia doesn't need it because the understanding part is supposed to be done by humans. So it's relatively much easier than full translation.
As an alternative we can consider how MediaWiki interface is built (via translatible message), {{#GENDER}}, etc. It is more viable for Abstract Wikipedia that article be built this way. This will not involve Lexemes (and any I think building articles using Lexemes is not performant). This can still be built inside Abstract Wikipedia - If a user want to see an article in their own language, they only need to translate some reusable message. GZWDer (talk) 16:06, 15 July 2026 (UTC)Reply
I know how messages are built quite well, but Abstract Wikipedia in its current form works completely differently, so unless I am missing something, you cannot actually do it. Amir E. Aharoni (talk) 16:46, 15 July 2026 (UTC)Reply
So I propose that we can built Abstract Wikipedia article via a similar way. This does not need to close down Abstract Wikipedia. GZWDer (talk) 17:06, 15 July 2026 (UTC)Reply
It actually does, because it would be a complete change of architecture and a fresh restart. It will most likely require the rewriting of all the code that was written for Abstract Wikipedia so far. (Although arguably, less code will be needed because it will reuse some existing MediaWiki functionality.) Amir E. Aharoni (talk) 17:18, 15 July 2026 (UTC)Reply
I disagree that AW is rule-based translation. That involves extracting the meaning of natural language involving those complicated rules first and somehow putting it into data. AW eliminates this step, and has people define the meaning. It is this data that is transformed with grammatical rules, not specification of grammatical features themselves. If you see what's inside an example "article" from AW, you'll find that nowhere is the inflections and places of words described, but simply the arrangement of sentences. Every language can specify its own template sentence, inflections, and arrangements. This is far from impossible; we already use that in software localization with translation variables (tvars). See e.g. translatewiki:Gender#Testing_and_more_examples or MediaWiki:logentry-oath-recover (and https://translatewiki.net/w/i.php?title=MediaWiki:Logentry-oath-recover/it&action=edit). AW simply aims to be a more flexible form of that.Whether the interface is easy to approach is a different question to whether the concept is practically feasible. Aaron Liu (talk) 19:08, 15 July 2026 (UTC)Reply
Latest comment: 6 days ago26 comments10 people in discussion
There was a very good "article placeholders" generator prototype on Russian Wikipedia, done using modules and which theoretically could be used with the ArticlePlaceholder extension (which is, unfortunately, unmaintained):
I think Wikifunctions/AWP are essentially trying to do the same thing as those examples but generalised as broadly as possible in terms of both the possible amount of languages served and the possible amount of concepts theoretically described. The problem with this, however, is that any actual real-life example of a generalised solution for this ends up wildly incoherent without humans filtering the output at least somewhat. It is possible to write a Lua module that returns how a model article on a country should look like based on its Wikidata item. However, when it is a generalised solution, what you end up with is stuff like abstract:Q408 (when it actually works and doesn’t just return thousands of errors), which featured such amazing sentences as ‘Australia is the flattest continent in Earth’ (second sentence in it even though it is a country article), ‘Australia is a megadiverse country’ (good luck knowing what that means without actual Wikipedia), and ‘Australia is a middle power’ (in the Middle-earth, I suppose). stjn[ru]13:18, 15 July 2026 (UTC)Reply
Thanks for reading about my country. I'm not saying it's perfect, but you might be interested to know that the three sentences you picked to criticise are all clauses from the lead of the en-wiki featured article: "... making it the sixth-largest country in the world, and is the world's flattest and driest inhabited continent", "It is a megadiverse country, and ... ", "Australia is a middle power, and has the world's thirteenth-highest military expenditure." If it's links/context you're after, they've gone in quite recently (but as you say, the caching problems stop us seeing them). If it's the size of the military you want, it will come. Anyway, this particular article is currently an experiment in how far we can go with adding content. It can't fully render in any other language, so I would not support embedding in other languages, and most big languages have their own article anyway. 99of9 (talk) 14:34, 15 July 2026 (UTC)Reply
It can't fully render in any other language, so I would not support embedding in other languages, and most big languages have their own article anyway.
... And that's really the crux of the matter, isn't it.
This is indeed one of the relatively better articles on Abstract Wikipedia (in the rare case that it actually renders, but that is probably fixable). If an article of this quality can be auto-translated using functions into a "small" language that doesn't yet have an article about Australia, it would be useful. But someone would have to write all the functions that translate it into that language. And once they are written, many of them could be reused for an article about another country. That would be a very good scenario, which would prove that Abstract Wikipedia is viable.
The question, however, is what is easier for Wikipedians who write in that language:
To program those functions, which requires knowledge of programming and very good meta-linguistic knowledge of their language.
To create an article by simply typing it from scratch, by manually translating it, or by machine-translating it (and hopefully reviewing the machine translation).
Wikipedias in the "big" languages, which already have a good article about Australia as you say, tend to have among their editors people who create and maintain templates, modules, and gadgets, and who would theoretically be able to learn the necessary skills to write NLG Wikifunctions for their language. However, since they already have the article in their language, they have very low motivation to learn to write the functions. Wikipedias in "small" languages who don't have a good article about Australia tend not to have such people, so if they want to have an article about Australia, they'll choose #2.
I don't want to speak for other participants of this RFC, so everyone is welcome to correct me if I'm wrong here, but here's what I guess: Most of the people who write comments that express negative opinions about Abstract Wikipedia see that #1 is currently unnecessary for the "big" languages and harder than #2 for the "small" languages. Furthermore, they have a hard time seeing a path to a future in which #1 becomes easier than #2 for anyone, and the arguments from the volunteers and the staff who support Abstract Wikipedia haven't yet convinced them that such a path exists.
In Abstract Wikipedia there is multiple potential way to build an article. Using Wikibase Lexemes is one, but I believe is not best one (since the set of Lexemes is far from complete, and it is nearly impossible to create Lexemes for all proper noun). Using {{LangSwitch}}-like mechanism is another one. GZWDer (talk) 16:02, 15 July 2026 (UTC)Reply
#1 is currently unnecessary for the "big" languages and harder than #2 for the "small" languages. Furthermore, they have a hard time seeing a path to a future in which #1 becomes easier than #2 for anyone - exactly. MBH (talk) 16:49, 15 July 2026 (UTC)Reply
To me, what is in en:Australia does not necessarily matter to what abstract:Q408 contains. Because if the goal of this project is to contain translatable information for other languages to use, then all of those sentences fail at being relevant and coherent enough for an article about the country. If the goal is to just mess around and see how much untranslatable information can be put in a highly indigestible format that requires three minutes to load on a better computer in an incredibly convoluted interface that no one would want to touch, then surely that can be done without wasting resources kindly provided to us by Wikimedia donors. stjn[ru]16:03, 15 July 2026 (UTC)Reply
As I wrote in another section on this page, this is a completely different way to generate text, and it's not at all how Abstract Wikipedia currently works. This RFC is about Abstract Wikipedia as it is now, not about a theoretical project. Amir E. Aharoni (talk) 17:22, 15 July 2026 (UTC)Reply
Other than "augmented text object" described below, this is already possible using the current Wikifunction and Abstract Wikipedia infrastructure (each "Builder" is a ZObject and article stored in Abstract Wikipedia). Just it is not performant, has an ugly UI, and "builder fallback" may need phab:T386422. GZWDer (talk) 17:47, 15 July 2026 (UTC)Reply
If I understand correctly, in the heart of this, there is the function f:Z37812 that can work only in English and Chinese, and works by returning a mostly hardcoded string. I don't think that this was the intention behind Wikifunctions. Amir E. Aharoni (talk) 18:51, 15 July 2026 (UTC)Reply
Yeah, but it can be "fallback" to a more general builder <b>$1</b> is a $3 located in $2. (where $3 is label of d:Q515), and we only need to translate the more general builder (unless in some language the fallback is not grammatical, and needs to be overrided in that specific builder). Anyway this way to build Abstract article is more realistic. GZWDer (talk) 19:00, 15 July 2026 (UTC)Reply
I can't see how this would work for any language that declines its nouns. Let me give you an example from my native language and I'd like it if you told me how it would work under your system. Consider the sentence "Niamey is a city located in Niger" and we'll try to generate it in Greek. If we translate your builder we get "[Nominative definite article of $1] <b>$1</b> είναι πόλη που βρίσκεται σ[accusative definite article of $2] $2." The articles are dependent on grammatical gender which you have acknowledged in your proposal so I won't linger there. The problem lies in the last word which must be in the accusative case. The correct sentence is "Η Νιαμέ είναι πόλη που βρίσκεται στον Νίγηρα." but your builder will only ever generate *"Η Νιαμέ είναι πόλη που βρίσκεται στον Νίγηρας." because the label of Niger (Q1032) is in the nominative case (as it should be). f:Z37801 takes strings as its arguments which means it only ever sees "Νίγηρας"; it doesn't see Q1032 or any lexemes associated with it. It will somehow have to know how to decline this word just from seeing its nominative form, which is not possible in general (see wikt:όρος, two words that have the same lemma form but different declensions). Warudo (talk) 20:06, 15 July 2026 (UTC)Reply
The example from Greek is useful to understand what information can be necessary too. I like the idea and so maybe it is possible to work further on it and improving it to fit more languages. At the end from my point of view there should be tools to serve different ways for creating and modifying articles. At the moment it is the more realistic way to set it on top and convert it to functions in the background. This could be a project for the Wikimania Hackathon. Hogü-456 (talk) 20:36, 15 July 2026 (UTC)Reply
There are multiple solutions of that issue;
One is also using "augmented text object". i.e. store a JSON containing each grammatical case as Greek "label" in Wikidata, and the parameter of Z37801 will not be simple string but an "augmented text object". This is unlikely to ever be complete and we need the second solution as fallback.
Another is can "transclude" a dedicated built function like {{Zxxx|$1}} <b>$1</b> είναι πόλη που βρίσκεται σ{{Zyyy|$2}} {{Zwww|$2}}., with a function (Zwww here) "guessing" (may not be 100% correct) the declination of a word. (Note: define each language item in f:Z37812 as string is just a simplified approach. It can be a function, but currently on-the-fly function is not yet supported in UI)
Anyway, the lexeme approach is not scalable since this require we create a lexeme for every proper noun for every language concerned, and there are potentially billions of proper name; creating a lexeme for each person is likely out of scope. GZWDer (talk) 21:07, 15 July 2026 (UTC)Reply
Or reuse the translatewiki:Grammar mechanism it can be {{GRAMMAR:accusative|$2}} and we transform {{GRAMMAR:accusative|Νίγηρας}} to Νίγηρα via a function (but for words that have the same lemma form but different declensions, we still need lexemes or "augmented text object").--GZWDer (talk) 21:18, 15 July 2026 (UTC)Reply
There is no {{GRAMMAR:|}} mechanism. {{GRAMMAR:|}} is not implemented in Greek. GRAMMAR is also not suitable for the purpose because it is only intended to cover words that occur in wikitext as the output of other magic words according to its documentation. Your hypothetical Zwww function would be a lot more general than that. So, let's talk about that function. It is just not possible to implement. Given a noun (adjectives decline too but I'll ignore them because the function we're discussing won't have to deal with them), it is not possible to figure out which declension pattern to use without checking a dictionary. This is because there are different declensions based on the ending of a word, the accented syllable, its grammatical gender, whether it is parisyllabic or imparisyllabic... The last two are not possible to determine from the structure of the word alone. Even when all of the above are the same, there can be multiple classes: wikt:αγώνας, wikt:ταμίας and wikt:δεκανέας, decline differently (in the plural). Thankfully for us, in the particular case of forming the singular accusative of a noun ending in "-ας" we only care about whether it is masculine or neuter. The other things I mentioned happen to be irrelevant (they only matter for the singular genitive and the plural). Still, they are important context to show just what kind of considerations one has to make.
So, let's get back to Niger and how Zwww would handle it. "Νίγηρας" is a noun ending in "-ας". Checking a dictionary (we've already lost at this point, we might as well check a lexeme) we see it is masculine. Therefore, after consulting our declension table, we find that the accusative case is "Νίγηρα". To prove that gender matters and hopefully also show that it can't be determined from morphology, the unrelated word "γήρας" (old age) is neuter and has an accusative case of "γήρας". The ending stays the same. Warudo (talk) 00:04, 16 July 2026 (UTC)Reply
@GZWDer, @Warudo, just a small technical comment from someone who did dabble in {{GRAMMAR:|}} code in core MediaWiki a bit: At the moment, {{GRAMMAR:|}} is indeed not implemented for Greek, but at least in theory, it can be implemented by someone who knows some PHP and JavaScript (I can help if anyone is interested). I don't recommend implementing it for general language grammar because {{GRAMMAR:|}} is not intended for all kinds of random content; it is primarily intended for handling MediaWiki user interface messages that include parameters that appear in run-time and have to change according to morphology. An easy common example is the "About SITENAME" message that appears at the bottom of every wiki page: in many Slavic languages site names like "Wikipedia", "Wiktionary", etc., have a different ending after the "About" preposition, and this is done using GRAMMAR for Russian, Polish, Ukrainian, etc.
Even more theoretically, {{GRAMMAR:|}} could be repurposed to do more complicated things. My hunch is that doing that would be not much more complicated than implementing WikiLambda and language-specific functions upon it, but that's something that a computer scientist or a software architect can say more about; my experience includes being a software engineer and a product manager, and I never even pretended to be a computer scientist or an architect. Amir E. Aharoni (talk) 09:50, 16 July 2026 (UTC)Reply
If I was a proponent of Abstract Wikipedia, I would avoid using cebWP as an example entirely, since it is a massive failure in Wikimedia governance and most of its content is completely and utterly useless to anyone who speaks Cebuano. A typical article in Cebuano is generated from a database with a bunch of errors and the only non-trivial points there, at least for geographical pages, is the non-precise climate data gathered from another database based on its location. stjn[ru]17:04, 15 July 2026 (UTC)Reply
For the sake of completeness and not commenting on anything pro or contra in this RfC, I wanted to say that Persian Wikipedia also has a similar system called Tofawiki which has been working since 2014 and basically produce the bare-bone layout and text of a new article for users to verify, improve, and then save. Similarly to AW, It uses Wikidata statements to produce text, for example what awards someone has won. It has specifically a class to produce text for biographies (source code) and of course it's quite hacky and quite limited. Here is the output for Alan Turing (and here is the output without any modification). I put the stats on how many articles have been created using tofawiki in phab:P94866 and as you can see a pretty major part of new article creation workflow in Persian Wikipedia was tofawiki. For example, in 2016, it 42% of all new articles were created with help of this tool and in 2025, many years after it was created, it's still 34%.
I'm not saying it can or should replace AW, I'm just mentioning as something to get ideas from (e.g. maybe AW should focus on producing good content for limited type of articles first, like biographies or maybe it should provide the text but let the human make the final call on what goes out.). Amir (talk) 23:47, 15 July 2026 (UTC)Reply
Latest comment: 7 days ago1 comment1 person in discussion
I want to Talk at Wikimania about Abstract Wikipedia and want to Work on improving the ways to contribute to it during the Wikimedia Hackathon. I See there challenges and so far I was Not succesful with contributing to it. From my Point of View the Local language Versions should decide what content they will integrate from Abstract Wikipedia and contributing to Abstract Wikipedia should be easier than now. So If you are at Wikimania onsite in Paris you can Talk to me. Lets Work together in improving the Abstract Wikipeda. Wikimania as an international Event offers the Chance to Exchange ideas with people from small language Versions onsite and onlie. Hogü-456 (talk) 15:06, 15 July 2026 (UTC)Reply
Abstract Wikipedia's Response to English Wikipedia criticism
The Abstract Wikipedia team has drafted a response, which was reviewed and improved by the community. We want to express our gratitude to the community members who have shown their care and spent their valuable time contributing to the answer. All remaining shortcomings are strictly ours. The answer can be found here: m:Abstract Wikipedia/Response to English Wikipedia criticism. You are welcome to comment and to pose further questions and criticism on the talk page. -- DVrandecic (WMF) (talk) 08:55, 16 July 2026 (UTC)
In the Q&A, someone asked whether this RfC had a mandate (as in jurisdiction) to effect closure, to which the speaker's response was to point to the current policy (which I believe is CPP?) and remark on the ineffectiveness of processes with low numbers of participants. YoshiRulz (talk) 18:19, 22 July 2026 (UTC)Reply
This is a subpage; for more information, see the Requests for comments page.
Support pause and transparency; I 
Oppose closure. Dv103 (talk) 15:46, 14 July 2026 (UTC)
conditionally oppose closure because I see the potential of the projects. But my condition is that the projects prioritize addressing the concerns with defined deadlines, above all else. At minimum, there needs to be a much easier interface to make compositions (probably blockly), the realization of the promise—made as rebuttal to a major point of the Google Fellows critique—that "The ZObject language will not be exposed to the casual contributor. In many (perhaps most) cases, contributors will see labelized versions of ZObjects.", and much easier ways to work with lexemes in connection with Wikidata entries. Unfortunately, that seems unlikely, as the WMF's relevant devs appear either too interested in working on types and details or excessively sluggish to deliver the everyone-friendly tools that the projects acutely need to work on itself. It's been years. We can't move forward atop a house of cards. Aaron Liu (talk) 18:54, 14 July 2026 (UTC)
Weak oppose closure. I think that if this project can work some years down the line it will be a huge win for linguists and Wikipedians alike, but I don't see that happening within the year, so it needs to be paused. Guy Macon said above about a "leakproof box" and I think this is similar to what I think should happen until it can be proven that this project can output useful encyclopedic content. I've attempted making articles myself, and had... limited success. I share a lot of Chaotic Enby's complaints about the project and how writing articles works. That doesn't mean I'm not excited about the concept of this project though. I'm curious to know how much money is still remaining from the grants mentioned above, and how much this project is really costing. A lot of people seem to mention that this is a waste of money, so I'm curious to know how bad it really is. If we really are hemorrhaging money from this I'd support closure, but if we can keep this running on a reasonable budget that'd be fantastic. There is promise here, however idealistic it seems. Feedmepaperr (talk) 03:58, 15 July 2026 (UTC)
Strong oppose Closure: I believe Abstract Wikipedia is currently immature and far from (probably never) replace Wikipedia articles, but have its use case (which maybe very specific in the foreseeable future. (I will explain more later). 
Abstaining from voting on the three proposals for process reasons, but 
Commenting that while it is commendable that the RfC author tries to simplify things by specifying "It is not about Wikifunctions", basically, the two projects are near-inseparable (and share the same origins). If Abstract Wikipedia doesn't work out, WF is deprived of its main natural-language dogfooding platform, and much of its reason for being. If Wikifunctions were to go away for whatever reason, Abstract Wikipedia would be instantly unworkable. — Arlo Barnes (talk) 21:56, 15 July 2026 (UTC)
Weak support pausing rollout to pilot Wikipedias (I would consider ArticlePlaceholder and AutoDesc to be the bar which must be passed, but the communities in question did ask for it); 
Neutral on pausing the rollout because it is a good idea to do it given the current quality of the abstract articles but each community can do that on their own, can't they? Warudo (talk) 20:59, 17 July 2026 (UTC)