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.
State of play
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.
Language is not Lego
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.
Test against the WMF Annual Plan
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.
Key Results
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.
Proposals
Latest comment: 1 month ago2 comments1 person in discussion
Pause the rollout
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
Transparency
The Foundation should publish:
Success criteria with measurable outcomes;
Termination criteria for the conditions under which the project would be closed;
Cost including all expenditure to date;
An independent evaluation both technical and linguistic, by evaluators outside the project team.
Closure
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: 1 month ago91 comments45 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
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
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
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
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
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
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. 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. 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 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
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
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
Oppose suggestions 1 and 3 (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
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
Developer comment
Latest comment: 1 month ago19 comments8 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
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
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 ;)
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
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 month ago6 comments5 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
Rule-based natural language generation is a dead end
Latest comment: 1 month ago9 comments6 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
Wikidata-based alternative without lexemes
Latest comment: 1 month ago13 comments6 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
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
Latest comment: 1 month 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
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). 
