This RfC is about the future of Abstract Wikipedia (main page). It is not about Wikifunctions, which I've discussed only as the technical infrastructure on which Abstract Wikipedia depends.
Six years after Board approval and three years after the Foundation expected its first new articles to be published, Abstract Wikipedia is live and producing broken nonsense at worst, and single sentence definitions masquerading as articles at best. The Foundation plans to make integration into other language Wikipedias available within months. The 2022 Google Fellows evaluation predicted these failures and the Abstract team rejected its recommendations; and so here we are.
Abstract Wikipedia fails technically, the content fails editorially, the contributor workflow fails practically, and the Annual Plan could declare success without measuring whether the output is accurate or useful.
Abstract Wikipedia was approved by the WMF Board in May 2020. Its stated goal is to generate encyclopaedic content in a language-agnostic way, using Wikifunctions and Wikidata as the building blocks, to allow smaller language projects access to translated articles.
Making more articles available in more languages is a good goal and no one disputes that. What I dispute is this method to achieve it, and six years after approval no one (including the Abstract team) has shown evidence that this method will achieve it either.
I examined a random sample of Abstract articles on 13 July 2026 using Special:Random.
Of thirteen randomly selected pages, four produced only internal error messages. A fifth generated two sentences before failing, and a sixth displayed raw HTML rather than prose. None produced an acceptable encyclopaedia article.
February: Wikifunctions returned a failed response: Invalid key
California:Wikifunctions returned a failed response: ZID not found
oxygen:Reached concurrent evaluator call limit in orchestrator
Hilariously the function that generates the bronze article is literally named (DO NOT USE) SPO sentence (singulars in present) and is used across a bunch of Abstract articles. It triggers the following error:
Bronze is a material.A bronze is a copper-based alloy.
Wikifunctions returned a failed response: no connected implementation yet.
Nice haiku though.
The pages that did render were not articles:
Brussels consists of, in full Brussels is the capital city of Belgium. which is a grammatically correct sentence, but just a Wikidata statement read aloud, not an article about Brussels.
bird is A bird is an avian dinosaur. which... okay, I guess?
animal manages An animal is an organism.An animal is a heterotroph., without bothering to put a space between the sentences.
fire offers Fire is a physical phenomenon. Flame is the part of of fire. which is both ungrammatical and wrong because not all fire has a flame.
Some of it is worse. The Nanjing article generated the following factual errors:
Nanjing is a big city in Jiangsu.Nanjing is a big city in the People's Republic of China.Xuanwu District is the capital city of Nanjing.Lan Shaomin is the head of government of Nanjing.Capital city is the namesake of Nanjing.Nanjing is a big city in Asia.Nanjing is the capital city of Republic of China.
Xuanwu District is not the capital of Nanjing; Lan Shaomin is not the current head of its government; "Capital city is the namesake of Nanjing" is nonsense; and Nanjing's historical status as capital of the Republic of China appears as unqualified present-tense fact because the system cannot yet express the past tense.
This flattens the river, its tributaries, its headwaters, drainage basin, and watershed into a single relation. This is not useful.
The homosexuality article, which I will present without comment:
A homosexuality is a sexual orientation. Gays enter same-sex relationships. Homosexuality exists in 1500 species. Societies persecute gays.
Paul Cézanne contained no text at all, just a heading followed by three HTML links displayed as source markup.
All of the above is the English output, the language the system handles best. There have been documented cases on the Wikipedia:Village pump (WMF) thread of translated language outputs being far worse. Being a mono-lingual speaker, I am only focusing on the English output.
The intended recipients of this content are the smaller language Wikipedias; those with the fewest active editors available to spot and repair systematic grammatical, semantic, factual errors that Abstract generates. Sending terrible generated text to a small project does not actually help them, and terrible generated text carrying the Foundation's name is a serious reputational risk.
Integration into language Wikipedias is being planned before the feasibility of the basic model has been established. I suggest it has failed. Six years in, it is still a research project testing its own premises and has produced no useful output.
The fundamental principle of Abstract Wikipedia rests on the idea that encyclopaedic content can be broken into language-agnostic units and then rendered into any language. But languages do not carve meaning into the same interchangeable pieces.
The project’s own status update admits that even deciding when to use the definite article "the" can become a word-by-word problem across languages; the founder of Grammatical Framework (programming language) Aarne Ranta called it one of the hardest puzzles they had to solve. And the project is trying to do this across the vocabulary and grammar of every language the project hopes to support.
Linguist Mark Dingemanse set the problem out way back in May 2020 in his post Concrete reasons to be skeptical about an ‘Abstract Wikipedia’If even a seemingly innocuous term like “mayor” is subject to this kind of warping of semantic spaces (if it’s available at all), that doesn’t bode well for many other concepts. Six years of development has not produced an answer to him, but instead has produced the article HomerHomer is the part of of Greek mythology which is what happens when a structured relationship is passed through an unsuitable generic English sentence frame without enough semantic information to render it correctly.
Falk's best example is taken directly from Abstract's own architecture example page: San Francisco is the cultural centre of Northern California, as exactly the sort of neutral fact Abstract will one day deliver in every language on Earth. Two of those words are metaphors: "Northern" and "centre" both assume the world is a map, but Jaminjung speakers orient themselves by the flow of the Victoria River, so is Northern California upstream or downstream? Supposedly language-agnostic proposition is already framed through English linguistic and cultural assumptions.
Suppose the rendering worked perfectly; the output would still not be an encyclopaedia. A human editor who does the (difficult!) job of writing an article has to decide which facts matter, what a reader needs to know first, what requires context and attribution, how events relate in time, space, and cause, and what to leave out. Screw is a simple machine. does describe a screw, but it is no one's idea of the right opening sentence of a Wikipedia article about screws.
What Abstract Wikipedia has demonstrated is that some database relationships can be turned into grammatical sentences (infoboxes, census records, some limited structural descriptions etc).
What it has not demonstrated (anywhere, in any language, in six years) is that those sentences can be organised into a useful article. Verbalising structured data has been confused with writing an encyclopaedia.
What contributing to Abstract Wikipedia actually looks like
The team's response to criticism repeatedly frames the current state of the project as a matter of the contributor community that is still developing. I think it is worth showing what "contributing" actually looks like.
Fellow editor User:Chaotic Enby spent about thirty five minutes constructing an Abstract article for Tujiaaspis. This is the best output they were able to produce after thirty five minutes of effort:
Tujiaaspis is a genus in Eugaleaspidiformes. Tujiaaspis is an extinct taxon. Tujiaaspis is a Silurian. Xiushan Tujia and Miao Autonomous County contains Tujiaaspis. Baojing County contains Tujiaaspis.
Tujiaaspises contain fins. Fins contain lengths. Fins make lifts. Fossils make evidences. Galeaspidas contain fins.
Tujia people makes name.
Abstract has no concept of geological period as a temporal qualifier, so it treats "Silurian" as a taxonomic class.
Abstract doesn't know that "evidence" and "name" are mass nouns in English, so it pluralises them. This is the same failure that produced "A homosexuality is a sexual orientation" earlier.
"Tujiaaspises" mechanically applies a regular English plural to a genus name ending in "-is".
With their permission, Chaotic Enby's own observations:
I love how for example, we have separate functions for "Xs verb Ys", and for "X verbs Y", but not for "Xs verb Y". Also how I've only found two verbs ("make" and "contain") that were actually coded in. So we can't even say "fins are elongated", the only options are "fin is an elongation" or "fins contain lengths".
The same thirty five minutes spent writing prose in English or any other language the contributor speaks would have produced a short, useful, correct stub. Instead we've got Tujia people makes name.
Nobody looks at Abstract's composition interface, such as blue's
paragraph (join text-like objects into HTML fragment (Typed list (Object, subject is instance of (string) (wikidata item reference, primary color, language), sentence separator (language), subject is instance of (string) (wikidata item reference, HTML4 named color, language), sentence separator (language), subject is instance of (string) (wikidata item reference, spectral color, language), sentence separator (language), subject is instance of (string) (wikidata item reference, web color, language), sentence separator (language), subject is kind of (Monolingual text) (wikidata item reference, light, language), sentence separator (language), subject is kind of (Monolingual text) (wikidata item reference, cyan, language), sentence separator (language), (DO NOT USE) SPO sentence (singulars in present) (part of, wikidata item reference, seven prismatic colors, language), sentence separator (language), (DO NOT USE) SPO sentence (singulars in present) (part of, wikidata item reference, RGB color space, language), sentence separator (language), (DO NOT USE) SPO sentence (singulars in present) (part of, wikidata item reference, color, language))))}}
and thinks "yes, small-language Wikipedians will happily produce thousands of these". We're facing an editor retention crisis as it is. We cannot afford the energy, time, and money being spent on Abstract Wikipedia.
The WMF Annual Plan for 2026–2027 has Objectives and key results for Abstract Wikipedia. They mostly measure if Abstract Wikipedia can be deployed but not whether it produces actual useful encyclopaedic content.
The stated objective is to Demonstrate Abstract Wikipedia's viability as a scalable, human-centered way to create multilingual encyclopedic content. but the Key Results don't test that claim.
The Q1 Key Result commits to expanding deployment from the first demonstration into the initial target language Wikipedias and scaling to our envisioned 5–10 additional early adopter Wikipedias.
The Q2 Key Result then defines measures that indicate that contributor communities will be able to to create and maintain Abstract Wikipedia articles, Wikifunctions language functions, relevant Wikidata Lexemes, and/or integration into Wikipedia at a rate that can meet the threshold for scalable content viability.
Q1 expands deployment and builds the integration to support five to ten early-adopter Wikipedias. Q2 defines measures intended to indicate whether the content and contributor model are viable. The threshold for scalable content viability isn't published anywhere I can find, and it's due to be defined a quarter after the thing has already shipped. It also doesn't state what result would count as failure or cause the project to stop.
By the end of Q1, increase the number of sentences and core elements in Abstract Wikipedia articles is a measurement of quantity but not quality. It is absolutely not useful to have the 18th longest page on Abstract by bytes Leo Tolstoy return as:
Leo Tolstoy is a writer from Russian Empire.
Leo Tolstoy is a playwright.
Leo Tolstoy is a philosopher.
Leo Tolstoy is a novelist.
Leo Tolstoy is a pedagogue.
Leo Tolstoy is an essayist.
Leo Tolstoy is a children's writer.
Leo Tolstoy is a diarist.
Leo Tolstoy is a prose writer.
Leo Tolstoy is an opinion journalist.
Leo Tolstoy is an Esperantist.
Leo Tolstoy is a pacifist.
Leo Tolstoy is a poet.
Leo Tolstoy is a short story writer.
This just rewards nonsensical listicles and is Goodhart's law in practice. Counting follow-up edits is ambiguous because it's either more engagement or just endless cleanup work from volunteers for nonsensical generated text.
The plan sells Abstract Wikipedia against LLMs on the grounds that it is human-centered, in contrast to an internet increasingly shaped by automatically produced text that is often opaque and unverifiable. Strong agree on the sentiment. But look at what Abstract Wikipedia is like in real life. Human-centred, at current quality, means thirty five minutes, two working verbs, and Fins contain lengths. The Foundation is proposing to scale that to various small-language Wikipedias in Q1.
None of the Key Results measures:
factual accuracy;
grammatical quality;
if qualifiers, dates and sources survive generation;
review by native speakers;
if the output is useful to readers;
if editors find it easier than writing or translating an article directly;
how much maintenance and cleanup is imposed on local communities;
if communities actually even want the generated output.
Latest comment: 26 days ago1 comment1 person in discussion
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
Latest comment: 27 days ago1 comment1 person in discussion
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: 14 hours ago319 comments134 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
If we'd manage to machine translate articles but with the language-smoothness of an AI that would be great. Or if we'd manage to prompt AI to just translate a given article without adding any hallucinations or random removal of any content, that would also be a great alternative. This would probably help small projects more than the robotic-appearing sentences that just express a relationship between X and Y in form of a sentence.
But I got to admit that Abstract output has meme potential.
You could get an initial translation from LLM and smooth it out. I actually did that in the past with some success. With LLMs the problem is they don't deal well with wikilinks, I think at current stage of technology LLM translation assisted by wikidata information about interwiki links would work best (in a way this is already available in Wikipedia translation tools). References are a bit problematic too, but that part is just a matter of LLM's configuration. I think it would be great if some more money would be spent on better translation tools. Nux (talk) 14:46, 26 July 2026 (UTC)Reply
@GZWDer "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".
Is AW intended to produce articles in languages that are rarely spoken, or spoken by few editors? If so, it will be no easier for a human to adjust the output of AW than it would be to adjust the output of a machine translation.
In fact, it will be harder. Both require a native speaker to be found or recruited to read and adjust the output. I don't know why you think humans can't correct errors generated by LLMs.
I don't think LLMs are good for creating articles in WP, but I think they do a better job of translating than using all of the mechanics that AW requires. Using AW is a much longer path. And LLM translation is getting better quickly, while AW might be getting better very slowly.
In addition, in the AW case, the native speaker needs to also master all the technologies that we have seen that are a part of AW.
"Is AW intended to produce articles in languages that are rarely spoken, or spoken by few editors?" - I believe it is one of goals, but not only goal. GZWDer (talk) 13:18, 3 August 2026 (UTC)Reply
@Femke just being able to translate from another language using the browser's translation model to the speaker's language doesn't allow the reader to fully share in the knowledge: they wouldn't be able to edit the article, correct errors, and improve the article. And, in my opinion, that's an important part. --DVrandecic (WMF) (talk) 11:48, 26 July 2026 (UTC)Reply
It takes a few extra steps to contribute in languages you don't speak fluently, but it's certainly possible with these LLMs. For instance, I've been updating the Spanish article on climate change, which contained significant misinformation. And my Spanish is very rusty. —Femke 🐦 (talk) 12:14, 26 July 2026 (UTC)Reply
Like, we're very anti-AI on English Wikipedia. But if you ask people to compare machine translation with Abstract articles, I'm very confident that English Wikipedia will prefer those translations. We're seeing massive improvements finally in the small languages, where even small corpora can be used to generate a decent-quality translator. I only expect this to get better in the next 2 years. —Femke 🐦 (talk) 18:54, 27 July 2026 (UTC)Reply
I am doubtful that asking readers to contribute by learning a new lingua franca that doesn't resemble natural languages is an approach likely to attract many additional editors. isaacl (talk) 16:36, 27 July 2026 (UTC)Reply
@Isaacl That is a misunderstanding of how Abstract Wikipedia works, both currently, and eventually. I am sorry we didn't explain it better. Currently, the text is being constructed through a form-based user interface, in which all parts of the interface can be translated. Eventually, we are aiming for an interface that allows to enter natural language text, and where the appropriate functions and arguments are automatically suggested based on the entered natural language text. In both cases it is not necessary to learn a new language, which I agree with would be a rather big impediment. --DVrandecic (WMF) (talk) 18:14, 27 July 2026 (UTC)Reply
Eventually, we are aiming for an interface that allows to enter natural language text, and where the appropriate functions and arguments are automatically suggested based on the entered natural language text. - @DVrandecic (WMF), where is this plan written? And do you think that you will actually achieve it?
As we had originally anticipated, the system has evolved and changed from the original plan. And by now, we have most of the pieces in place: 1. Wikifunctions is there, for maintaining a library of functions, which can be called from some Wikimedia projects 2. Functions on Wikifunctions can access and process data and lexicographic data from Wikidata 3. Abstract Wikipedia can compose articles from functions on Wikifunctions What is still missing? We are working on the next main step towards enabling the whole project: Integrating articles from Abstract Wikipedia in the language Wikipedias. With that, all the major functionalities of the architecture will be in place. There are still many other things that need to be worked on: scaling the various parts of the system, adding more capabilities (images, categories), building more functions, developing the right types, finding the right abstractions. As the pieces all come into their place, the outline of the puzzle as a whole will become more visible, and the value of the system will start to become real.
At the moment, you appear to be working on "Integrating articles from Abstract Wikipedia in the language Wikipedias", which, according to that update, will complete "all the major functionalities of the architecture".
An "interface that allows to enter natural language text, and where the appropriate functions and arguments are automatically suggested based on the entered natural language text" sounds like something that cannot work without some kind of machine learning or machine translation. And it means that there would yet another major functionality to develop. This one actually looks like it would be more major than any of the previous ones.
The last occasion a future interface upgrade was pointed to in response to criticism, you forgot about it. I worry about a pattern of setting a goal, claiming it is achievable, and then leaving it in the dust after a month—because the team didn't actually give us a timeline for it—and then declaring victory. Aaron Liu (talk) 21:31, 27 July 2026 (UTC)Reply
In fact, on this specific goal: I have been responding to invocations—of the 2016 NYTMag retrospective on rule-based vs ML translation—with that AW is not translation because we define the meaning instead of trying to extract it from all of natural language's nooks and crannies first. You're saying that the project is going to add some sort of extraction from natural language. Do you see the pitfall? Aaron Liu (talk) 21:37, 27 July 2026 (UTC)Reply
The user interface isn't what makes it look different from natural languages. The source in the source editor looks like verbose function calls, which is unlike any natural language. isaacl (talk) 02:29, 28 July 2026 (UTC)Reply
I support closure, along with a full technical and linguistic post-mortem as suggested, and preceded by a freeze in any planned deployment. Abstract Wikipedia is a conceptually flawed project, based on disproven linguistics and reliant on massive community time and effort to barely function at all, all the while being near impossible to contribute to. When reading the newsletters about Wikifunctions/Abstract progress, it feels like a parralel reality to what everyone can see with their own eyes. As Femke said above, bold ideas are good, but they are only worth exploring while remaining clear-eyed about their chances. Abstract Wikipedia is dead in the water and it is time to acknowledge the reality of the situation, not blindly move forward as is currently the plan. What our communities need is efficient and accessible translation tools, so that small Wikipedias can benefit from the good quality general content on the big ones, while big Wikipedias can take in all the unique knowledge contributed to the small ones. This should be an absolute priority if we are to preserve the linguistic diversity that brings so much value to the Wikimedia ecosystem, and I wish the Foundation was laser-focused on helping editors of all languages and editing proficiency build on what we have to make it better, instead of pursuing endeavors such as Abstract. Choucas 🐦⬛12:50, 14 July 2026 (UTC)Reply
In my opinion Wikifunctions and Abstract Wikipedia is extremely flexable. So even the current way to building article in Abstract Wikipedia does not work, we still have other ways (see my comment at #c-GZWDer-20260715160600-Amire80-20260715131200). I believe no way can be used to build a featured article, but in my proposed way one can translate ~6 million cebwiki article to own language by translating ~100 reusable "messages". GZWDer (talk) 16:13, 15 July 2026 (UTC)Reply
If I understand you correctly, to do this, you probably don't need Wikifunctions and Abstract Wikipedia. You can do most or even all of it using MediaWiki's current messages, templates, and modules. This is also similar to what was proposed in Abstract Wikipedia/Google.org Fellows evaluation in 2022. (Please correct me if I'm wrong.) Amir E. Aharoni (talk) 17:39, 15 July 2026 (UTC)Reply
The output of Z32213 is superior as it is labeled as multilingual text. Problems with editing should be solved by making funtions easier to edit, not downgrading output. Aaron Liu (talk) 19:22, 15 July 2026 (UTC)Reply
It is trivial to convert the output to monolingual text. Also, in my opinion articles should use a very specific builder (via builder fallback mechanism). Z28016 is too general to be used directly; it should be wrapped inside a more specific builder.--GZWDer (talk) 19:26, 15 July 2026 (UTC)Reply
If you convert to monolingual text, you will see the exact same toughness appearing as the "builder" scales to more languages; for example, supporting traditional Chinese as well. My point is that the "builder" approach is exactly what AW is using but with better architecture. The goal is to make more functions like Z28016 to express more numerous and more specific things. I'm sure @DVrandecic (WMF) or AW editors could confirm. Aaron Liu (talk) 19:33, 15 July 2026 (UTC)Reply
Oppose anything I'm not convinced this is necessary. I strongly oppose closure, but we don't need to proactively tell the WMF what to do unless something goes wrong. Feeglgeef (talk) 13:24, 14 July 2026 (UTC)Reply
Thanks @Feeglgeef. Your input on the WP:VPW thread was valuable. You yourself have saidAbstract Wikipedia is a viable project. It just needs more time, and, ideally, better technical support. I do agree with those above that Dr. Vrandečić is overstating our progress.
This RfC exists because something has gone extensively wrong, and the WMF is planning to ship it to language Wikipedias anyway. That's the "something" this RfC is responding to. qcne(talk)13:54, 14 July 2026 (UTC)Reply
Support closure, it is very clear at this point, as so eloquently put by qcne, that this project has unfortunately failed. It is vitally important that we do not get caught in a sunk-cost fallacy and are able to close this now rather than after it costs any more time, money, and editor goodwill. CoconutOctopustalk13:29, 14 July 2026 (UTC)Reply
Oppose all the above Isn't it too early for this RFC? The project was released for public preview in March—only four months ago—and it has already demonstrated its technical feasibility. Furthermore, some of the examples cited in the RFC depend entirely on specific function choices. Since this is a community-built project, contributors should remain free to use the functions they prefer. Personally, I feel the repetition of words in every sentence simply shows that active contributors currently view this issue as a low priority. After all, fixing it would require rewriting sentences to use pronouns, or correcting them with a comma-separated list of occupations. John Samuel13:39, 14 July 2026 (UTC)Reply
The project was approved in 2020 and the Foundation expected the first articles in 2023, it is not four months old. Integration into some language Wikipedias is planned for Q1 of the current annual plan. If it is too early to evaluate, it is too early to ship.
Being able to execute functions and display generated sentences does not demonstrate that Abstract Wikipedia can produce encyclopaedic content. If grammatical and factual quality depends entirely on contributors choosing the correct functions, that is not an answer to the concern: it is the concern. qcne(talk)13:47, 14 July 2026 (UTC)Reply
Grammatical and factual accuracy depends entirely on contributors writing the correct sentences and reviewing the edits on Wikipedia proper as well; why you consider that a challenge unique to Abstract Wikipedia is beyond my understanding. AW has significantly fewer editors (active or otherwise) compared to Wikipedia, and many pages have been published by volunteers testing out the system or the functions they have created on their own. Redmin (talk) 05:37, 25 July 2026 (UTC)Reply
@Redmin because you only need basic English to write better sentences. And you only need primary school education to write better sentences in your native language. Abstract wiki is just to complex to use. Nux (talk) 07:35, 25 July 2026 (UTC)Reply
Support pause and added transparency, weak support closure. I shared some of my thoughts with qcne above, and will elaborate further. All in all, I second Femke's approach: innovate, but prune any dead-end branches – which Abstract Wikipedia might just be – before we become subject to the sunk-cost fallacy. Chaotic Enby (talk) 13:58, 14 July 2026 (UTC)Reply
My observations from half an hour of trying to write an article, which should tell you enough about why I feel that way:Verb search is horribly broken. You don't have a catalogue of verbs, or of words, but of Wikidata identifiers, the vast majority of which don't map to any verbs. Want to search make? You have to guess that the relevant Wikidata item is creation (Q11398090). In practice, that means you'll have to search through every lexeme, select one, wait five seconds for the paragraph to load, and pray that it has a verb form. It won't.This also means that context-dependent synonyms will be flattened into a single lexeme. Want to say that fins generate lift? Sorry, they make lifts. Enjoy your galeaspid-owned elevator business.Function search is even more hopelessly broken. The project is strongly typed, with types such as monolingual text (Z11) or string (Z6), but this is very limited in practice: searching for language-agnostic functions will get you swarmed by language-specific implementations.[a]More subjectively, even just basic editing is so annoying. You can't just wade and add sentence-generating functions right away, you have to know how to chain three separate helper functions just to reach the point where you can actually do that. Once you're there, you can't copy-paste blocks easily, you have to click on the menu button, click copy, create a new block, click on the menu button, click paste, and it opens a window to select from everything you copied before. You'll also run into seemingly random errors, such as Reached concurrent evaluator call limit in orchestrator when writing a paragraph with more than six sentences.The function inventory is also very hit-or-miss. There are two "useful functions" lists, Abstract Wikipedia:Useful functions for article composition and Wikifunctions:Catalogue/Natural language operations/Global language functions. The latter has two whole functions for album short descriptions, but none for "X is Y". You have very little flexibility in existing functions: "X verbs Y" and "Xs verb Ys" are separate functions, but there is no "Xs verb Y" or "X verbs Ys" equivalents as far as I know.This transitions neatly into my next point, which is functions are very rigid, and offload a big part of article writing on function developers, while requiring article writers to be intimately familiar with the existing set of functions. Abstract Wikipedia basically relies on functions for everything, with little regards about how natural languages are structured. Abstract articles only superficially resemble a linguistic parse tree, doing away with the very high-level "noun phrase"/"verb phrase"/etc. nodes and replacing them with hyperspecific "X exists in N Ys" functions that remove all the flexibility. I could foresee a different set of much more high-level functions doing better, with tools to parse them from natural languages, but this is far from what we're seeing today on Abstract.Even in that best-case scenario, there is also the issue that semantics can't be neatly separated from syntax when parsing natural language, or when producing it – for a very concrete example, collective nouns take singular or plural agreement in British English[b] depending on the semantic context.This gets multiplied when looking at cross-linguistic variance: let's say you want to make this basic "X is Y" copula function that could work for plural and singular X and Y. Simple enough, right? Well, several languages have multiple copulas (ser and estar in Spanish), and you'll need fine-grained enough distinctions between the various kinds of copulas[c] to make something cross-linguistically robust, while still being intuitive enough for writers unfamiliar with these distinctions. Chaotic Enby (talk) 14:31, 14 July 2026 (UTC)Reply
AW editors have partially or completely rewritten your Tujiaaspis article (but the English view is currently all timed out -_-), removing Fins make lift. and some other calls to f:Z32531 which is known to be unlocalisable. I suspect lift would need to be marked as a mass noun, and then functions changed to respect that, but the en modelling page doesn't mention how that should be done. Abstract articles only superficially resemble a linguistic parse tree, doing away with the very high-level "noun phrase"/"verb phrase"/etc. nodes and replacing them with hyperspecific "X exists in N Ys" functions that remove all the flexibility. It's not possible to use syntax trees for this as they're obviously not cross-lingual. The template-like constructions you're complaining about are the 80/20 solution for generating the same sentence in many, diverse languages, which is why the first NLG functions have used that paradigm. YoshiRulz (talk) 14:49, 17 July 2026 (UTC)Reply
Not the most specialized forms of syntax trees, obviously, but there must be higher-level functions (like genitive constructions) that can have equivalents in various languages. To take a more concrete example: the order of the branches in a tree won't be the same in an SOV language and in an SVO language, but the underlying structure at a more abstract level remains, and that is what we'd like to capture here.Problem with these template-like constructions is that we end up creating hyperspecific functions and putting even more burden to translate each of them into each target language. Chaotic Enby (talk) 15:19, 17 July 2026 (UTC)Reply
@Femke Dud I read that an RFC is not the proper way to request closure of a project? I am actually mixed on these choices, though. But this is certainly a way for us to express our opinion. David10244 (talk) 05:47, 4 August 2026 (UTC)Reply
Hi @David10244: At the moment the Board of Trustees (BoT) has the power to close projects. Before, this power was in the hand of the Sister Projects Task Force, which had members of the BoT and community member decide this together. I don't quite understand why this Task Force was closed. So, this RfC is the way for a community to request action from the Board. The way I understand it, is that we do have the remit stop the rollout onto Wikipedia projects. If the project is deemed too high risk for small-language communities to incorporate, that might not leave the BoT with a feasible route of continuing large investment into the Abstract Wikipedia. —Femke 🐦 (talk) 16:25, 5 August 2026 (UTC)Reply
I suspect the answer to why the sister project task force was closed is that it was created to give legitamacy to the already pre-made decision to close wikinews. Once that was accomplished there was no need to keep it around. Bawolff (talk) 18:05, 5 August 2026 (UTC)Reply
↑I am here using "implementation" as a shortcut – each of these language-specific functions is really a function prototype, which itself has a set of Wikifunctions implementations, either as borderline obfuscated Python/JS code or unreadable function composition.
↑But not in American English, where they are always grammatically singular
Support pause and added transparency, weak support closure. My opinion is that this project will not be viable unless there is machine assistance that helps translate natural language to the Abstract Wikipedia syntax. Perhaps that'd involve machine learning (I realize in the AI-hating zeitgeist this is unpopular to say), but I don't really see any other way for this project to work without machine help. Writing in this syntax is ludicrously difficult even for patient, smart, and dedicated users; I've watched them struggle in real time on video calls and text chats. This is just not a useful project. As Femke said, we should be focusing our efforts elsewhere. Grapesurgeon (talk) 14:03, 14 July 2026 (UTC)Reply
Having machine tools transforming natural language inputs into an abstract parse tree form is probably the best way this project could go, instead of requiring contributors to basically be familiar with a whole new programming language before writing articles. This is the only reason I weakly support closure instead of strongly supporting it – there might just be some way such a project could be achieved, but this is infinitely far from it. Chaotic Enby (talk) 14:08, 14 July 2026 (UTC)Reply
Frankly, I think the best use of the Abstract team's time for the coming financial year is to write honest, exhaustive postmortems on why this whole thing didn't work. Let's at least convert this utter failure into something that researchers and developers of the future can learn from. asilvering (talk) 14:06, 14 July 2026 (UTC)Reply
Support rollout pause, since the current model of representation of abstract content has fundamental issues, and is not scalable to represent more elaborate content in more languages. Currently new models of representing abstract content are being proposed and discussed; many of the concerns expressed in this page are not applicable to Abstract Wikipedia as a whole project, but only to the current state. This is why I think that currently Abstract Wikipedia articles are in no way ready to be integrated into any Wikipedia, but more time is needed to solve these issues.Dv103 (talk) 14:20, 14 July 2026 (UTC)Reply
The way to build article in Abstract Wikipedia needs to be reconsidered (you can see a more proper way by viewing ceb:Special:Random and think how to translate it to your language) but even we consider the current way to build article in Abstract Wikipedia infeasible it does not mean we have no other way. GZWDer (talk) 16:17, 15 July 2026 (UTC)Reply
I'm not sure whether referencing Cebuano Wikipedia is a bad example, or a great example of how good intentions plus automation results in a bad outcome. Arlo Barnes (talk) 20:22, 15 July 2026 (UTC)Reply
Support closure, along with post mortem analysis per User:Choucas. This is a huge waste of the limited resource of the WMF and especially of the editor community. It also threatens to poison smaller wikis with wrong or misleading information, making them unreliable and ultimately useless --Ita140188 (talk) 14:34, 14 July 2026 (UTC)Reply
Oppose closure. At the absolute worst, if someone wants to waste his time, let him waste his time. Abstract Wikipedia and Wikifunctions has a long way to go, but it can literally never get there without a live experiment in trying to make it happen. ―Justin (koavf)❤T☮C☺M☯14:41, 14 July 2026 (UTC)Reply
We're seeing the live experiment right now, and it isn't just Abstract contributor time that is being wasted, but also funding, as well as time and energy from small language communities having to deal with the potential rollout. Chaotic Enby (talk) 14:43, 14 July 2026 (UTC)Reply
This argument only works for the editors of Wikifunctions and Abstract Wikipedia who would not use their editing time there to do anything else. It does not take into account the time the rest of the community is spending to monitor the project or even understand what is going on with it (no small ask), the time (and therefore money) of WMF employees working on it, and above all the potential catastrophic time-sink for small communities at risk of being overwhelmed by the generated "articles". Choucas 🐦⬛14:45, 14 July 2026 (UTC)Reply
support closure. abstract wikipedia is a giant waste of time, and for a movement whose most precious resource is the time of editors, it is potentially a threat to all, especially the editors of small wikis. ltbdl (talk) 14:54, 14 July 2026 (UTC)Reply
Support closure. *Responding to Jsamwrites, dealing with repetitive words is already something the LLMs can handle. Earlier today, I noticed I had used the verb "to contrast" three times in one paragraph and wasn't happy about that. My fix was en:Special:Diff/1364077153. Since you brought up that exact example, I just asked Claude to work on the same issue. He came back with a rewrite which I think is just as good as mine, perhaps even better (and I'm not even counting the typo he pointed out).
As Femke said above (and I also said recently on enwiki), I'm all for investing in speculative projects to solve big problems. I don't begrudge the money spent or the volunteer effort invested. Risk is the nature of speculative projects; the fact that any particular one does not make it to production is neither a condemnation of the project nor of the people who worked on it. But for a project to make sense, there needs to be some plausible expectation that it might work as well as a potential payoff if it does (i.e. solves a problem that needs solving). I'll address each of these in turn.
Can this work? I'm sorry, but I don't think so. I've just read through the project evaluation. To be brutally frank, it seems pretty damning. I see major concerns expressed about both the theoretical aspects (i.e. how to architect a natural language translation system) and practical aspects (how to implement a large-scale software project). The only thing that stood out to me as silly was the gratuitous and parochial swipe at the choice of JSON vs protobufs for data transport. But that was four years ago. Lots of dire predictions of the future have been proven false, so we really need to look at what progress has been made since then. Sadly, I'm not seeing that what has been demonstrated in July 2026 (and again, my apologies to the team for my blunt language here) even meets the standard of a good technology demo, let alone an MVP. And I'm speaking here as somebody who has spent a lifetime in software development and more than once endured the pain of projects that got shut down.
So that brings us to the other big question, does this solve a problem that needs solving? In 2022 when the project started, the answer certainly would have been a resounding "yes". Just like the proliferation of choices for data formats (for example, JSON vs protobuf as mentioned above) and programming languages (Python, JavaScript, or Lua, as discussed in the report) impede technical progress, so does the plethora of human language impede human progress. The need for automated ways to make information written in one language available to people who cannot read that language is obvious. In 2022, machine translation technology was in its infancy, and projects like this offered hope of a way forward. But that was before LLMs burst on the scene. I wouldn't go so far as to say it's an entirely solved problem, but it's a "mostly good enough" solved problem, and still clearly on an upward trajectory. So, even if the Abstract project were to surprise us all and start to work as well as has been promised, all it would be doing is competing with another already proven technology.
In summary, I'm seeing lots of risk with little upside potential. It's time to thank the people who have invested six years of their lives in this (and make sure that their career advancement doesn't suffer simply because they had the bad fortune to be assigned to a project that never shipped) and pull the plug. There are so many other big projects that need working on and not enough resources to work on them all. RoySmith (talk) 15:01, 14 July 2026 (UTC)Reply
I'm thinking you might be discounting the benefits for marginalized communities and languages here.
Big tech AIs to my knowledge does not support small and relatively rare languages well.
This system is being built not to generate English stub articles but to give people access to a way to generate content in very marginalized languages primarily.
Evaluation based on a comparison with the current state of AI should take that into account IMO.
Unfortunately I don't speak a marginalized language or live in any marginalized community do you? Have you checked with people that do? Have you reflected on why we are having this discussion in English and not any other language?
Maybe we don't see the full picture yet because we haven't actually spoken to those that would benefit the most from this project? So9q (talk) 07:20, 15 July 2026 (UTC)Reply
Have you checked with people that do? [...] Maybe we don't see the full picture yet because we haven't actually spoken to those that would benefit the most from this project? – Have Abstract Wikipedia developers done these things? Phazd (talk) 02:41, 17 July 2026 (UTC)Reply
@So9q AW will need speakers of those marginalized languages to check AW's output anyway. As I mentioned above, it seems that AW will need programmers and linguists who speak those marginalized languages natively. That's a big "ask", to put things in corporate-speak. David10244 (talk) 04:57, 3 August 2026 (UTC)Reply
LLMs are already replacing wikipedia. We can continue to chant "Wikipedia good, LLMs bad" and pretend it's not happening, or we can figure out how to take the best advantage of the new technology. The former strategy is what the T-Rexes did when those annoying furry mammals started scurrying about. How did that work out? RoySmith (talk) 19:25, 15 July 2026 (UTC)Reply
History does not give you the analogy you think you have. For one thing, T-Rexes were never threatened by mammals. Mammals never contributed to the T-Rexes demise; they were simply the best next thing after they died from a pretty major, unrelated, and seemingly insurmountable reason from outer space. I have no idea what think the T-Rexes should do, except that you would need a giant meteor to strike Wikipedia for your analogy to ring true.The answer to regaining readership from LLMs is obviously not to become an LLM. Ask Keir Starmer about that. Aaron Liu (talk) 19:44, 15 July 2026 (UTC)Reply
Sure, output from LLMs can have mistakes (although it is quite easy to keep them grounded in information obtained from a structured data repository like Wikidata, so this should not be a major concern if an approach like that were to be taken) but editors can make whatever minor fix needs to be made once they are provided with the generated content. The proposed mechanism for Wikipedia editions to receive AW articles, however, only gives local communities the option to either accept an article as-is with no scope for modification locally or reject it entirely and start from scratch. You could argue that communities can ‘just go and fix the relevant function on Wikifunctions’ but finding the contributors who could do so might be harder for the smaller communities AW is intended to serve. Redmin (talk) 10:15, 25 July 2026 (UTC)Reply
The scope for modification locally is, in the worst case, doing "Select All" on the rendered abstract article and pasting that into the wikitext editor. Is that not the same as your LLM-powered idea? YoshiRulz (talk) 10:24, 25 July 2026 (UTC)Reply
Is that actually how the system is supposed to work? To be clear, I am certainly not in favour of using LLMs to mass-create Wikipedia articles; the bot I have developed is intended for use on third-party sites, I only mentioned it to demonstrate the possibility. That being said, I do think individual users could be given the option to use such text as a starting point (possibly through a less visible Toolforge tool if we are too worried about new users publishing articles without making any addition or modification) for creating articles manually. Redmin (talk) 11:28, 25 July 2026 (UTC)Reply
The current behaviour on testwiki is that Create local article gives you a blank box which is surely not the final design, but I don't know whether it will be {{#function:}} calls for each element of the abstract article's source, or a more familiar wikitext representation backsolved from the resulting HTML. YoshiRulz (talk) 12:48, 25 July 2026 (UTC)Reply
@Redmin You might be agreeing that smaller communities likely won't have the resources, and might not have the expertise (or the desire) to just go fix those functions. David10244 (talk) 05:00, 3 August 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
Sure, but we aren't a research institute. If its going to take another 20 years or something for abstract Wikipedia to be useful, i think that is a good argument to cut our losses now. Bawolff (talk) 20:36, 24 July 2026 (UTC)Reply
By the end of 2001, Wikipedia was a joyfully experimental and sometimes even raucous place, with rapid iteration on norms, scope, and procedures. It was clear to both people involved and observers that something interesting and inspiring was happening, with volunteers developing a shared sense of humor and hopping in to document current events (September 11) and things they loved (poker; the Simpsons), even if it largely wasn't hitting the mark yet as a usable encyclopedia. Abstract Wikipedia, on the other hand... I agree with the RFC author's concerns and proposals regarding Abstract Wikipedia. Dreamyshade (talk) 16:02, 14 July 2026 (UTC)Reply
Abstract Wikipedia model is clearly something that works very well on paper and makes a lot of conceptual sense to a lot of peopleBut...it doesn't "work well on paper" or "make conceptual sense" to the people who are qualified to evaluate theoretical and practical feasibility, hence the damning Google Fellows report and the decades of other failed attempts of this type by academics. JoelleJay (talk) 16:11, 14 July 2026 (UTC)Reply
Fair point on Abstract Wikipedia, though I was referring more generally to Wikimedia's approach towards structured data. Elements of Wikidata have been successful and more widely adopted, including being used off of the Wikimedia network. Viewed overall it seems like a good idea with desirable outcomes (automatic generation of high quality content in underserved languages? sign me up!) but in practice it doesn't attract the critical mass of actual humans needed to make it work. Some thinking should be done as to why that is the case, whether anything can be changed to make it more human-friendly, and if not, what elements can be salvaged as we steer the ship in a different direction. – Ajraddatz (talk) 14:59, 15 July 2026 (UTC)Reply
Support for the first two. I'm okay with giving Abstract Wikipedia more time to mature, but I have serious doubts, especially about the amount of money that should be put into it right now. In it's current state, it's no better than Wikidata as a source of information, and probably much more annoying to generate a useful stub from in any language, let alone it's target languages. Leaf.Sheap (talk) 16:05, 14 July 2026 (UTC)Reply
Keep it in a box: If people want to spend another six year trying to make this usable, they should be allowed to do so, but it should be kept in a leakproof box and never be allowed to change a single byte of any other project until the community decided that is has become usable.
Whether the foundation should spend more money on this is a separate question. I advise anyone who is serious about WMF spending to start by trying to get them to simply tell us the total cost of a single Wikimania so that the donors who paid for it can see what their donations were spent on. --Guy Macon (talk) 16:10, 14 July 2026 (UTC)Reply
If anyone else got curious about the cost of recent Wikimanias after reading this, here's what I could find:
2025-2026 budget: "funding events like Wikimania, the Wikimedia Hackathon and more ($2.7M)"
Consolidated Financial Statements FY2024: "The Foundation also had a change in accounting policy to no longer present the Wikimania event as special event expense...This resulted in a reclassification of $698,141"
Support closure and of course the other options too. If WikiFunctions volunteers and random en.wp-banned editors want to continue spending their time tinkering in Abstract then they can do so in sandbox mode and without WMF funding toward the project's development. WMF can instead go spend its donations on digitizing and hosting physical media archives from developing countries and supporting existing digital media in those places with WikiLibrary subscriptions (e.g. for AllAfrica). JoelleJay (talk) 16:24, 14 July 2026 (UTC)Reply
If you disagree with how a non-profit uses its donations, the solution is to donate to a different one, perhaps one whose mission actually is digitizing and hosting physical media archives from developing countries. Feeglgeef (talk) 17:51, 14 July 2026 (UTC)Reply
Our mission is to "a world in which every single person on the planet is given free access to the sum of all human knowledge". That often includes digitalisation efforts. Affiliates in particular have collaborations with GLAM institutions to digitise their collections and make it accessible to a wider portion of humanity. The underinvestment in Commons means that a lot of this work never reaches Wikipedia or other more visible projects, however. —Femke 🐦 (talk) 18:07, 14 July 2026 (UTC)Reply
That's the vision statement. The mission is broad enough to encompass conventional Wikipedias, Abstract Wikipedia, the Wikisources (which is probably the project type best positioned to steward a scanathon, although Commons would be the direct beneficiary), Wiktionaries, etc. Arlo Barnes (talk) 21:28, 15 July 2026 (UTC)Reply
I don't think that writing articles in a lingua franca resembling a programming language is a good fit for a crowdsourced project. Accordingly, I don't think this initiative is suited to the strengths of the Wikimedia Foundation, and I don't think it should continued to be pursued as something that will fit into a crowdsourced content creation workflow. Thus I support closing down the Abstract Wikipedia project as a public facing project intended to integrate with other Wikimedia sites. I am open to the idea of providing some level of support for ongoing research to continue to explore the concept, although my preference is to let universities provide the bulk of funding, and thus better connect further investigation into the academic ecosystem of peer review. isaacl (talk) 17:58, 14 July 2026 (UTC)Reply
Support all, I'm gonna quote someone from some other godforsaken site, because they said it better than I can: "This is an outdated approach to a problem that the WMF should not be trying to solve. It's kids building a moon rocket in their backyard." I'm flabbergasted that this passed through all the relevant meetings and checks without getting shot down. The mastermind behind it has no background in linguistics, which shines through, but not only that, nobody at any stage appears to have had even a basic understanding. Small wikis appear to have never even been consulted in the proposal, and how the Beta (Alpha) was launched meant they were effectively shut them out from directing the wiki's development, particularly shit when it's their wikis this would affect. How were they ever supposed to maintain the presumably-vast amount of abstract articles? This has been one big exercise in institutional dysfunction, and the resources would be better spent either scaling small wikis organically, or developing more types of wikis for documenting knowledge inspired by local contexts rather than making Eurocentric franchises of enwiki's encyclopedia. Kowal2701 (talk) 18:12, 14 July 2026 (UTC)Reply
Moon rockets exist, and I think everyone agrees kids shouldn't build them, but unpacking the metaphor: does something of this kind already exist? What org is better positioned to allow under-resourced languages to pursue natural language processing and generation? Arlo Barnes (talk) 21:30, 15 July 2026 (UTC)Reply
Here's a better metaphor for you: "it's kids building a perpetual motion machine in their backyard". Never mind that perpetual motion is a solved problem: all respectable scientists will tell you it is impossible. But these kids think they have a chance of actually building one — especially if their effort will somehow, magically, entice all other kids in the world to participate in their crowdsourced project... Oddwood (talk) 23:51, 17 July 2026 (UTC)Reply
Perpetual motion machines are obviated by the rules of thermodynamics, but linguistics isn't a unified field like statistical mechanics is within physics.
Depending on what you think the sink or swim condition is for a project like Abstract Wikipedia, and depending on which linguistic analyses you use, you could either say the job is straightforward ("just" implement the grammar rules of a goal language in functions and make sure the lexicographic data at Wikidata is well-stocked and quality-checked), tricky (some goal languages would require much more preparation than others and still end up clunky), or impossible (a generalized bit of language by definition isn't fitted to the specific needs of a given language community).
As far as your comment about participation, it sounds like you disagree with the wiki way which is fine; but most people here think volunteered, informed, intentional labor just works (for reasons the evidence of which surround us). Arlo Barnes (talk) 05:15, 18 July 2026 (UTC)Reply
Regarding the wiki way: I don't disagree with it; sometimes it obviously works, and sometimes it doesn't. For a viable project you need to reach a critical mass of contributors. This has obviously worked for the English wikipedia, and other large wikipedias and similar large projects; but smaller projects often struggle to get off the ground. Wikinews was shut down recently precisely because it failed to grow in the wiki-way. Somehow I am rather doubtful that this particular niche project can successfully grow in this way. Oddwood (talk) 02:12, 19 July 2026 (UTC)Reply
Support closure. I agree, this project has failed. It is best practice that failed experiments should be killed quickly. There are more boring projects that can help scale smaller wikis which are more feasible to deliver (e.g. categories as structured data). MER-C18:48, 14 July 2026 (UTC)Reply
Support pause: It is clear that the team is mindlessly moving too fast and about to roll out an alpha-at-best (AW) and beta (WF) project across the universe. I disagree with a few premises of the RfC—most importantly that language-agnostic specification is impossible, as Abstract Wikipedia is supposed to define parts of an article by their meaning and not language features, and some articles do demonstrate this. I believe that the promise of the projects is worth a lot. But the WMF has been working on them in a way so that we are still an infinite distance away from that promise. As it stands, AW and WF are hardly approachable.I find the AW response to challenges in content governance unconvincing. When making Wikifunctions, the project understood that users were likely to get things wrong on the new project and only approved the best applications to edit. It only became editable about a year later when it became usable and had developed infrastructure. What makes the team think AW, a project where it is way easier to use the wrong functions or just copyvio and get things wrong in a way that goes against all the ideals of the project itself, can be immediately declared "open beta" and editable by all in such a broken state? Right now, few articles on AW do what it is truly meant to show.Compositions are supposed to be the basic building block/glue that makes the projects work. Wiki-functions are supposed to be modular, and compositions allow them to chain together and do meaningful things. Every single Abstract article is a composition. Yet editing them is somewhat atrocious; what'd take you two minutes in Python or even Scratch regularly turns into 15 minutes in the compositions interface prone to just saying no. I don't think it can be improved much without the aid of a VPL like w:Blockly (of Scratch fame) or w:LabVIEW's G (the official look of this is awful. Check out EV3 for one that looks pretty.). This has been raised before! In fact, it was raised a year before wikifunctions.org was even launched: Phab:T301418. Yet developers have paid it nearly no heed and are rushingto deploy without it. The composition language is also hamstringed by the lack of variables, not even constant variables, that seems to be a big factor in how dang slowly everything loads, because it means functions need to be called again every time its return value is required. But to be fair, it is a functional approach, and this constraint is one template editors are used to.I conditionally oppose closure because I see the potential of the projects. But my condition is that the projects prioritize addressing the concerns with defined deadlines, above all else. At minimum, there needs to be a much easier interface to make compositions (probably blockly), the realization of the promise—made as rebuttal to a major point of the Google Fellows critique—that "The ZObject language will not be exposed to the casual contributor. In many (perhaps most) cases, contributors will see labelized versions of ZObjects.", and much easier ways to work with lexemes in connection with Wikidata entries. Unfortunately, that seems unlikely, as the WMF's relevant devs appear either too interested in working on types and details or excessively sluggish to deliver the everyone-friendly tools that the projects acutely need to work on itself. It's been years. We can't move forward atop a house of cards. Aaron Liu (talk) 18:54, 14 July 2026 (UTC)Reply
Personally, I think this idea is a much more massive waste of resources than even Wikinews ever was, and it is surprising that we don’t even have the full transparency on how many WMF/WM Endowment funds are being wasted on this project while critical parts of our infrastructure are underdeveloped and teams that are supposed to help us are being abolished. We have the chance to nip this in the bud before they waste many more tens of millions of dollars on this wildly unusable project with worst interface ever known to man. Not even programmers would want to participate in this. Support closure. stjn[ru]19:39, 14 July 2026 (UTC)Reply
Oppose 1 and 3 (Oppose Pause and closure). I contribute to Abstract and Wikifunctions, and let me say, I absolutely agree that most of the current pages are worthless. Many of the articles were created by people with no experience in Wikifunctions, meaning that they will be bare-bones and terrible. Many of them haven't been updated with newer functions since the project released. Half of the articles are created by some guy mass creating low-quality articles using his own AWB-like program. I need to reiterate - the option to include Abstract articles in Wikis is not forced by the WMF, it is chosen by the community. As an example, the Spanish Wikipedia will not have Abstract articles until the Spanish community enables them. Therefore, the first point is basically already the case.
The articles are terrible because the actual userbase is busy creating the functions for it - as an example, User:HenkvD added infobox for city just a few days ago. Sure, it's bare bones, and it loves throwing errors, but it's a fantastic first step. I'm current working on creating a function that will create an introductory paragraph for articles about species, which would include their conservation status, describing date, and their family.
Listen, there is so much that is wrong with this project, but that doesn't mean its rotten. Dozens of functions are being contributed weekly, but it's near impossible to find them as a user. The language data is here, but not for the languages which this project is targeted towards. It's a pain in the ass to make functions or edit any Abstract article if you don't have a background in computer science, are proficient in functions, or the patience of Buddha. I agree, we need more transparency about project goals and more accessibility (especially with the UI). I do also think the WMF seems to be rushing rollout, which I think it counterproductive to our goals.
Abstract Wiki hasn't been out for half a year yet, there is not enough content on it to be meaningful. Of course we haven't met the goals for AW, it's only been 4 months. Was the English Wikipedia actually useful in that time frame? If the project ends up failing in the long term, so be it. But we should give it some more time - there is an active community of people working on making it better. EatingCarBatteries (talk) 20:24, 14 July 2026 (UTC)Reply
I also agree that AW has a lot of promise, but it's being developed in a way that seems extremely inefficient and misdirected. Here's an article from the English Wikipedia as it appeared on 13 April 2001, nearly three months after launch: History of Levant. By September (we don't know exactly when; that's the earliest edit entry available on MediaWiki, even though the page clearly existed by April), there was a note added saying the page was #1 on Google's search results.AW in comparison is extremely sluggish or quantity-over-quality, probably because throughout the 4 years of Wikilambda development nobody bothered to make the compositions (and thus Abstract article creation) interface intuitive to humans, while UseModWiki was right there. It seems wrong to have opened up AW for this lambasted false start when its software is still alpha at best. Aaron Liu (talk) 22:40, 14 July 2026 (UTC)Reply
Thanks for sharing this. I have also been contributing functions to WF and I really like where this is going.
I suggest we regard AW as an early research project.
It could become a very useful, albeit complex (functions that call functions) system that might make a lot of sense to marginalized communities and languages that big tech AI companies don't care about.
It's still very early. The semantic types are still being worked out (there are multiple oposals being evaluated, tested and improved) and the community has yet to settle on a way forward. So9q (talk) 07:49, 15 July 2026 (UTC)Reply
Oppose 3 (Oppose closure). As contributor for Abstract Wikipedia and Wikifunctions I mostly agree with @EatingCarBatteries. Abstract Wikipedia is still in Beta. The language functions are not yet mature, I would say just a toddler. Most of the AW articles bot generated texts, with functions that existed at that time. Rolling it out to a language Wikipedia is NOT meant to be a full rollout, but just a first step in the development. Option 1 (Pause) is up to the target Wikipedia's communities. And even then it is on article by article basis. But it is not even working on test.wikipedia.org. On Wikimania a first attempt will be made to have ONE article available in ONE or TWO languages, and I think even that will be a challenge. BUT I am happy to be able to contribute and help get this started. HenkvD (talk) 21:16, 14 July 2026 (UTC)Reply
Supportclosure - Please use readers' donation money on something else (like creating features or tools that editors actually want, see the Community Wishlist for ideas), cause I doubt people who donated want their $$ to go towards keeping "Abstract Wikipedia" live. Thanks. Some1 (talk) 22:24, 14 July 2026 (UTC)Reply
For transparency, I have seen that this request for comment was linked on the Abstract Wikipedia / Wikifunctions Telegram at 15:42 UTC. Chaotic Enby (talk) 23:43, 14 July 2026 (UTC)Reply
Support pause, oppose closure for now, largely per Ajr. I recognise many of the concerns mentioned in this thread, but Abstract Wikipedia has only really existed as a wiki for 4 months. It has potential, and could be helpful in areas where proficiency in a major global language is low (the reality will always be that many small language wikis will never get to the same scale as wikis like en or dewiki). On the other hand, the way abstractwiki seems to be directed seems to be done so in a way that fails to attract any kind of human readership from outside the Wikimedia sphere (and also doesn't really achieve much more than what Wikidata already does), somewhat in a way that some other conlang wikis such as tokwiki do. //shb (t • c)00:17, 15 July 2026 (UTC)Reply
Personally, I believe tokwiki is not that a problem since it does not actively causes trouble in Wikimedia movement. Nor does Abstract Wikipedia currently (by comparison LLM is actively disrupting in Wikimedia movement). GZWDer (talk) 15:44, 15 July 2026 (UTC)Reply
Oppose I'd rather spend my time contributing than engaging in out-of-process wikipolitics. If anyone doubts that I have a very well-informed viewpoint, feel free to investigate my contributions. --99of9 (talk) 00:56, 15 July 2026 (UTC)Reply
None of this is "wikipolitics" (what does that even mean?), nor is it "out-of-process", as the very page section you linked indicates: Extensive consultation with the affected community is crucial before closing a Wikimedia project. This consultation should be open and transparent, allowing all stakeholders to express their opinions and concerns. This discussion right here is the extensive consultation in question. No one really has to care about how "very well-informed" you consider yourself to be, and even less to try to figure that out by themselves; many contributors advocating for different outcomes made the effort to show it by productively engaging with the discussion. If you would rather do something else it is your choice, but please do not dismiss a discussion merely because you find it inconvenient. Choucas 🐦⬛01:33, 15 July 2026 (UTC)Reply
@Choucas: except it is somewhat out-of-process. "Extensive consultation with the affected community" means that the consultation should be held with the Abstract Wikipedia community. As far as I can tell, there has been no consultation on abstractwiki (other than the notification of this RfC), and much of the prior discussion to this happened on enwiki, which is even worse. That's one individual wiki; while enwiki is free to have discussions about abstractwiki's future deployment to enwiki, enwiki doesn't get to decide the future of a completely separate wiki, much less so without discussing it with abstractwiki's community. //shb (t • c)02:16, 15 July 2026 (UTC)Reply
+1 This discussion seems to be part misunderstanding, part fear-venting (wiki community getting inundated with wortless nonsense without being able to cope or have a say in the matter), part "I would like to allocate resources elsewhere", part suggestions for helping improve the goals so they are more specific and measurable and part suggestions for improvement of the UI.
@99of9, @So9q and @SHB2000 I don't see this as being out-of-process. Until Nadzik showed up with a link to the official process yesterday, the actual process of requesting closure of the project was clear as mud. To my understanding LangCom explicitly does not jurisdiction on this and the Sister Projects Task Force was dissolved recently. In addition, the policy being linked to resides on a subpage of a now dissolved committee, making it hard to figure out if the policy is still in effect. Also, given previous precedent in this area of project closure requests and the Wikinews and Wikispore RFC following the SPTF consultation (which was the first time the policy was exercised) in my opinion, a meta RFC was the correct choice to allow for the discussion of the viability of the projectthat allows for the participation of English Wikipedia editors who raised concerns, Abstract Wikipedians, Wikifunctioneers and other small Wikipedians who might share similar concerns given WMF's rather accelerated annual plan. Sohom (talk) 08:43, 15 July 2026 (UTC)Reply
@Sohom Datta: picture this – I start a discussion on my home project, the English Wikivoyage (imagine it's 50 times the size it's now, just for this hypothetical), about the issues the English Wikipedia has. Most of them are genuine legitimate issues, and issues that are pretty widely agreed upon the English Wikivoyage community. So instead of discussing it with enwiki, I go straight to Meta-Wiki, proposing its closure, citing that widespread enwikivoyage support to close enwiki was the reason it should (leaving only a simple notification on enwiki), with the proposal garnering significant support.
If that hypothetical situation sounds absurd, that's because it is; however, that is also the exact scenario happening here. All the discussion prior to the RfC happened primarily on enwiki, with only a singular notification on abstractwiki, doesn't exactly scream "correct choice" to me. At the very least a notification should have been sent out to all wikis, not only to enwiki. //shb (t • c)09:05, 15 July 2026 (UTC)Reply
@SHB2000 I don't think that hypothetical is too absurd, that has been how a lot of closures start imo. Requests for project closures would rarely come from the people most aligned with the mission. What matters is that once we have the questions raised, we have them addressed by the community of the wiki/let them have their say which is the point of the RFC. At the very least a notification should have been sent out to all wikis, not only to enwiki. Good point, I'll make a few notifs. Sohom (talk) 17:23, 15 July 2026 (UTC)Reply
What matters is that once we have the questions raised, we have them addressed by the community of the wiki/let them have their say which is the point of the RFC. Why is an RFC needed for this? The Foundation made a page for responding to these questions and the Abstract Wikipedia community is engaging with it. Was it really necessary to start a formal discussion about closing down the project before that response was finished? Doing that sends the message that the response of the Abstract Wikipedia community will be ignored and closure will be demanded no matter what. Warudo (talk) 18:48, 15 July 2026 (UTC)Reply
@WarudoThe Foundation made a page for responding to these questions I'm sorry to the Foundation folks who helped draft it, but that page is corpo-speak hell. It deflects almost every single question with only concession being around "hey we will document our progress better" which feels very empty and tone deaf. This is echoed even among the comments/engagement by the Abstract Wikipedia community on the talk page as well. A RFC on the other hand is probably the only mechanism we have to resolve disagreements between two projects about policy and has the upside of allowing much more free-form discussion between both folks who are sceptical and those who want the project to succeed while also soliciting much more clearer answers on the touchpoint criticisms that non-abstract wiki community members have. Sohom (talk) 19:32, 15 July 2026 (UTC)Reply
It certainly is corpo-speak hell at the moment but it is presumably not done yet. I think this RFC would end up being opened no matter what but, again, opening it before the response is finished signals that we don't care about what it will end up saying. Warudo (talk) 19:40, 15 July 2026 (UTC)Reply
I mean, a pretty big demand (perhaps even two of them) out of the three is exactly that the WMF give us mensurable deadlines for their great promises related to AW. Aaron Liu (talk) 19:45, 15 July 2026 (UTC)Reply
I didn't expect the draft to change much, and now that it's finished, it indeed didn't change much: diff. Based on the link at the tippy top since this RfC was created, I am sure that the RfC people read the response before opening this discussion. Aaron Liu (talk) 18:23, 16 July 2026 (UTC)Reply
I think you linked to the wrong diff. But in any case, you are correct. It is very disappointing to me that the WMF chose to mark the response as finished a day early and without making any large changes but it is what it is. Warudo (talk) 10:22, 17 July 2026 (UTC)Reply
the Abstract Wikipedia article for Diablo, rendered in English Arguing about the distribution of money from a shared pot is definitely politics, and it is definitely not content contribution. Since the actual affected community has just been prodded a link from the proposer with one prior edit, I do not consider this to be consultation with the affected community. I'm interested in why you feel like enwiki is an affected community, especially since all integration plans involve discussions in advance about whether or not AW adoption is useful to a project. The "informed" comment is to ward off a common RfC tactic of minimising the value of opinions from editors who don't want to spend their time here. Here's what I helped User:Feedmepaperr do instead, and IMO it is evidence enough on its own that AW has sufficient potential. This article is better than almost every non-English article already. AW has not been going for 6 years, it has been in beta for a handful of months. --99of9 (talk) 08:03, 15 July 2026 (UTC)Reply
I'm impressed about this example. As a contributor to both Swedish and Danish lexemes and labels in Wikidata I'm so happy all that hard work on whipping the data into shape is being used in a new way beyond just a limited infobox.
The interesting thing to me is that in both these innovatations there is a strong need for fact-checked good quality open data. You can talk about LLMs that can do impressive things, but they leave no guarantees as to how they got to the result.
Both these examples (AW and Scribe) rely on high quality data and a community of engaged contributors. LLMs also rely in this. But none of the models I have tried so far actually disclose the exact full dataset they train on.
The fact that AW+WF+WD can now generate a decent stub article less than 20 years after launch is really impressive! Compare it to 61 years of AI research before LLMs were invented. AW is already a success seen in that light if you ask me. Something of great value can take a long time to get right. Science is full of examples of that. So9q (talk) 08:26, 15 July 2026 (UTC)Reply
I would have been impressed about the "Diablo" article back in 1970, but as it stands, most of the verbs have the wrong temporal conjugation. Carnildo (talk) 03:05, 28 July 2026 (UTC)Reply
To be fair I would still be impressed in early 2000s so when various simple chatbots poped up along with John Lennon chatbot which was kind of robotic, but almost felt like a conversation. In a way it resembles simple, robotic English generated by AW. Nux (talk) 20:28, 28 July 2026 (UTC)Reply
4 months in alpha I'll agree. Unfortunately we have to argue because the RfC did not present a NPOV timeline (among other biases), and most of the complaints are about things the community could only affect in the last 4 months. Note that the proposal does not seek to close wikifunctions, which would be the natural target of a "6 year" evaluation. Even in that case, WF has only been open to the community for 3 years, (with progressive rollout of features, starting with only strings), so again the community article/function/grammar creation evidence should only be judged against what the community could affect. I'll reply below to your other comment about preparation for "handling what [AW] needs".--99of9 (talk) 10:09, 3 August 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
@So9q Many of us are talking about using LLM for translating articles from other languages into the "little-used" languages. That is far better than trying to use LLM to create new articles.
And yes, I know it's early, but I wouldn't call the Diablo article a "decent" article, or even a "decent stub". I'm daunted by the effort it seems to take, to create that stub. I say this as a computer programmer. I could be wrong, but I see machine translation progressing faster than the AW process will take. David10244 (talk) 05:27, 3 August 2026 (UTC)Reply
The others have addressed the LLM suggestion. I'll take the "using" native speakers claim. Here's my proposal for how to measure your claim. Which of the following happens first: 10 language editions of Wikipedia have an article on Diablo as good as this, or the current AW article is made renderable in 10 languages? I bet it is the latter. I'll even spot you a 25 year headstart! 99of9 (talk) 10:44, 15 July 2026 (UTC)Reply
I would say the far more likely scenario is that half of the functions used in that article are deprecated before it gets to 5, as soon the mostly English-speaking, mostly monoglot, mostly non-linguist community finds the next 101 level NLG problem they have cast into the foundations.
The idea that a project that took months to figure out "we can't just have article-ful and article-less functions and expect them to work in both English and French" will be the first to support barely documented Niger-Congo B languages is laughable. REAL MOUSE IRL (talk) 11:33, 15 July 2026 (UTC)Reply
over half of the content of the article can actually be successfully translated into Swedish. Now, this is mainly because there's a user somewhere out there who's really intent on making Swedish work in particular, but I'd imagine given enough time that treatment will extend to other languages as well.Why do you think there will be any linguists in the target minority languages willing and able to put in the amount of work it apparently took this Swede just to reach a level where half the content of one stub-length article can be rendered in their language? Wouldn't these hypothetical people who have the time and background to learn WF and navigate AW UX be much better served by just...spending that time actually contributing to their own Wiki (either organically or via ML/LLM translation)? Why would you expect anyone from communities that already have extremely few (or zero) contributors to their language edition to embrace this extremely new-user-unfriendly platform, especially when the best result they can hope for is a small, stilted collection of unconnected "facts"? And if the goal is to eventually have translation into actual articles rather than handfuls of basic sentences, what does the timeline look like for that? JoelleJay (talk) 13:14, 15 July 2026 (UTC)Reply
I hope that one day making a few specific functions work in your language will not just unlock a few sentences like you mention, but rather thousands of articles for your language wiki. That will just take time though. As I mentioned above, I expect this project to take a while, possibly years, before we get useful content en masse. As of right now, you're correct that a minority language speaker would be better suited just translating individual articles but eventually there'll be more decent articles here than an individual could make on their own, and at that point it'll be useful to learn WF. Feedmepaperr (talk) 05:21, 18 July 2026 (UTC)Reply
Took me a while to get around to it, but the alt text has been fixed, as well as other localization details. The article may take a second (and maybe a page refresh or two) to load but all the code should work. Feedmepaperr (talk) 09:03, 29 July 2026 (UTC)Reply
Support 1 and 2, Oppose 3. With regards to 1, things are simply too slow and error prone for a rollout. (Though that seems to be a wikifuncitons issue) For 2, Obviously the WMF needs to be transparent about where it's money goes. But the project shows some real promise, the article on the great barrier reef is quite impressive. At 4 months in, killing it seems irrational, so I oppose 3.— The preceding unsigned comment was added by MBAB (talk)
Support all three, but I feel 1 needs tied to 2. Slight preference for 1 over 3, but only if we can get the thing shifted. This can be useful for subs and subs only. :Leo Tolstoy: born :date:, died :date: is :an author: from :The Russian Empire:. :He: is also known as a :Blah blah blah:. :His: best known works are :whichever people prefer:. That is the full use I see of it. An autotranslation of that would let anyone get the basic idea, and it'd provide a starting ground for an article. Jerodlycett (talk) 06:11, 15 July 2026 (UTC)Reply
Oppose to all the suggestions except increased financial transparency. I welcome any suggestions to improve the goals so they are SMART and clear to everyone. Let's fail courageously and transparently 😀.So9q (talk) 09:10, 15 July 2026 (UTC)Reply
Could we please distangle the proposal formation, argument collection and opinion expression? This RfC is going in all directions at once, and becomes incomprehensible for non-native speakers with limited time. Maybe a few quick process questions: did the organizers already talk with the involved staff members? What evidence have they studied? Apparently this was based on a Village Pump discussion on en-wiki, so perhaps I missed something. Effeietsanders (talk) 11:01, 15 July 2026 (UTC)Reply
On comms: I didn't hold separate discussions with the team before opening this. The substance was raised over roughly three months at en:Wikipedia:Village pump (WMF), where staff participated, and both Denny and Sannita have engaged here. So I hope this formalises the discussion via Meta that staff were already part of. I posted RfC notices at Abstract and Wikifunctions.
On evidence: this is set out in the RfC itself (the Google Fellows evaluation, Falk's paper, Dingemanse blog post, the sampled articles, the annual plan, and Chaotic Enby's contributor account written above).
On structure: yeah, it is interleaved and I'm sorry if this wasn't clearly written initially. The three proposals are in the Proposals section above and can be supported or opposed independently. But I also hope this more general Comments section would be a space for editor colleagues to critique, analyse, and discuss the Abstract project in an open way. If a clerk wants to reorganise the discussion into support/oppose subsections that's also fine. qcne(talk)11:30, 15 July 2026 (UTC)Reply
Taking the experience of a single newcomer to the project, and titling it "what contributing actually looks like" was already highly biased as an argumentative tool. Now calling it "evidence" makes it ridiculous. The very structure of the page means that a counterpoint cannot even be put except in an "opinion/comment". As a regular WF/AW contributor, the first time I saw this "evidence" was after many people had made their judgement (because the "comms" did not include a discussion with the primary affected community). --99of9 (talk) 12:04, 15 July 2026 (UTC)Reply
Support closure as per the rule-based translation is a dead end section below. If there is any money or developer time going into this project, it should be stopped. If some volunteers want to continue tinkering, I guess it doesn't hurt but there's no reason to believe this will ever achieve the stated goals. Erynamrod (talk) 12:27, 15 July 2026 (UTC)Reply
Strong oppose Closure: I believe Abstract Wikipedia is currently immature and far from (probably never) replace Wikipedia articles, but have its use case (which maybe very specific in the foreseeable future. (I will explain more later). Oppose Transparency: I don't see the value of it. Oppose Pause the rollout: Abstract Wikipedia is optional, let's prove its specific use case first. (I think your opinion may be changed once an Abstract Wikipedia version of Cebuano Wikipedia go live - this will not be very soon though.)--GZWDer (talk) 13:08, 15 July 2026 (UTC)Reply
User:GZWDer/Cross-wiki content provides some content that can be generated via Abstract Wikipedia in short term. Some are full article; some are part of article or just one sentence.
My advise to Abstract Wikipedia team: the most important thing to do for both Abstract Wikipedia and Wikifunctions is support calling other functions in JS and Python implementation. The next important thing to do for Abstract Wikipedia is to build a function to receive individual label or statement from Wikidata item (without receiving the entire item). The next important thing to do for Wikifunctions is allowing creating functions on-the-fly (i.e. allow a high-order function to return another on-demand runnable function, like fun=bind_first(add, 2) then fun(3)=5).--GZWDer (talk) 14:00, 15 July 2026 (UTC)Reply
Note: Since the very first announcement in 2020 I believe Abstract Wikipedia will not replace Wikipedia articles (i.e. this is seldom a viable way to create Wikipedia articles). The usecase of Abstract Wikipedia is limited, but exists. GZWDer (talk) 15:56, 15 July 2026 (UTC)Reply
Oppose The project needs time to grow and show its value, especially in a time where knowledge creation is increasingly taken out of human hands. The team and community aren't imposing the content on another community and we should let the involved communities decide when and how they want to integrate content from Abstract Wikipedia. --LydiaPintscher (talk) 13:18, 15 July 2026 (UTC)Reply
Support all - This project is based on a fundamentally flawed model of linguistics. Even if it did work, this isn't something that should be done by the WMF. A huge waste of money that could have been spent better; I have no idea how this got this far even. InfernoHues (talk) 15:42, 15 July 2026 (UTC)Reply
Even if it did work, this isn't something that should be done by the WMF.
Aaron Liu, sorry, I should have been more clear. I don't think the WMF should be spending time trying to create a perfect bridge between all languages, even if that were possible to do. InfernoHues (talk) 00:56, 17 July 2026 (UTC)Reply
I'll note that if it can be said that there is a single linguistic model governing AW contributions (which I am not sure of, since there seems to be differing approaches people are taking) it would be generative syntax...contested by some linguists (see linguistics wars) but not 'fundamentally flawed'. Arlo Barnes (talk) 21:43, 15 July 2026 (UTC)Reply
Oppose suggestions 1 and 3 (Pause and closure) (and I'm kinda neutral on suggestion 2). I'm broadly of the view that we (Wikimedians broadly construed, including both the community and the WMF) need to do more fucking aroundinteresting experiments (with appropriate care given to the fact that Wikipedia is a mature and highly-relied-upon resource that we don't want to break for readers or editors). I don't know if Abstract Wikipedia will ever work as fully fleshed out, but I don't think that this is necessarily a problem. I broadly like the idea of centralising a lot of the repetitive busywork of keeping different language editions of Wikipedia in sync, and Abstract Wikipedia is a stab in that direction. As editors, we like to think that carefully crafted prose and meticulously checked and reliable sources are what maketh Wikipedia... and they are obviously important. But huge swathes of the article namespace (on enwiki, at least) are not beautiful hand-crafted pieces of delicately composed prose put togther by a very learned editor who is carefully noting what the Professor Stubbs said and weighing it carefully against an equally respected article by Professor Smith in order to produce a useful introduction to an important topic one might write an essay on during an undergraduate degree. They are geographical stubs on minor Polish roads or small-town railway stations or very pretty but not that exciting medieval churches, or the breakdown of the results of the Netball World Cup, or the Italian offshot of some reality TV show, or so many articles on Telugu-language films and television shows. Lots of these article are basically the same exact paint-by-numbers skeleton with very minor variations. Quite a lot of these articles are based on a source we assume to be valid and which grants a presumption of notability (the U.S. National Register of Historic Places, say). Editors chuck in a couple of extra references (to a dead local newspaper helpfully preserved on the Wayback Machine, perhaps) so as to make sure the notability requirements are met, but ultimately, a lot of Wikipedia is a bunch of useful tabular data with a few sentences or two tacked on for context. A lot of these get written for, say, enwiki and often don't get maintained in English let alone kept in sync when someone does a one-off translation of them into another language. (The same is true in the other direction. See, for instance, the Death anomalies table for a practical example of how the lack of inter-wiki consistency is a problem.) Thanks to not being bound by the physical constraints of print, while Wikipedia is an encyclopedia (as we defensively assert to everyone from corporate PR spammers to people who wish to clutter the place up with poorly-sourced niche fancruft), it has also swallowed up a whole variety of other related but distinct reference works—gazetteers and sporting almanacks and election results listings and law reports and Parliamentary records—all sorts of stuff that would never have been squeezed into the hallowed pages of Britannica. Short of a purge that'd alienate all but the most radical of deletionist ultras (and massively damaging community drama would surely follow that...?), that is going to remain true for the foreseeable future. If, ultimately, what we get out of Abstract Wikipedia is some reusable infrastructure for centralising (and localising) infoboxes and other template-style scaffolding for the long tail of the kind of articles I'm discussing, well, great. Let's see if that happens. Unless there's some particular harm that's done by it (readers turning up there and getting misled? It meaningfully gets in the way of people writing articles?), I'm not sure what the problem is. After the various incidents of community backlash the Foundation has faced when prematurely rolling other stuff out, I'd like to hope they have developed some level of reticence in not botching it in the future by rolling things out prematurely or without appropriate levels of community consultation and support. If they don't, well, that will quite naturally resolve itself in the way you'd expect. Until and unless that happens, I see no reason not to carry on trying interesting experiments. —Tom Morris (talk) 15:50, 15 July 2026 (UTC)Reply
Support 1 and 2. Come from Wu Wiki(Wuu), and if it cannot write Wu sentences well or even write Chinese sentences well, we're quite afraid of it being integrated into our wiki. At least, we need an option to choose whether it is integrated or not.--Jason2016426 (talk) 16:25, 15 July 2026 (UTC)Reply
But what about"integrated into three different language Wikipedias" showed in Status updates? Asking?
And I'm just curious about this project whether helping us reproduce "stubs" easier, so I logged in to have a look, finding it hard to do so, not only to learn the functions, but also not to see all kinds of errors showed by the website. And the results often show maths marks, showing lack of locallization.
And it's quite hard for such kind of tool using functions try to write down all the grammar, then trying to make an article, even to the languages with no people using Wikipedia or something like this. Also ,for those languages with many variants, like Chinese(not only the "simplified" and the "traditional", the "Mandarin"\"Wu"\"Yue"\"Southern Min"\etc.), using Template:NoteTA, people can watch Chinese Wikipedia in 6 versions, editors using different grammars to show the same meaning. This is much more common in Wu Wikipedia, which sparked some edit wars. I'm afraid that functions may not do it well. That's why I'm supporting a pause on the rollout and integration into Wikipedia(NOT OTHER PROJECTS. I think it's quite useful to Wikivoyage when the language problems are solved.), giving editors from Abstract and WF time to make functions and the notes and locallization on them perfect, and also we editors furnishing Wikidata, to make the sentences can be made in the Abstract longer than the sub-stub criteria in many Wikipedias.--Jason2016426 (talk) 06:11, 16 July 2026 (UTC)Reply
Currently Standard Chinese is using zh-Hans, zh-Hant, and zh-HK. It is said last year they would've support script variant converting soon. Wonder when. 魔琴 (talk) 03:10, 23 July 2026 (UTC)Reply
Abstract Wikipedia is a project that was supposed to be created sometime. We should develop, and not to mock it when it was juct created. There's another, more important question: why is the project still very raw after six years of development and still is in beta?Таёжный лес (talk) 17:30, 15 July 2026 (UTC)Reply
Abstaining from voting on the three proposals for process reasons, but Commenting that while it is commendable that the RfC author tries to simplify things by specifying "It is not about Wikifunctions", basically, the two projects are near-inseparable (and share the same origins). If Abstract Wikipedia doesn't work out, WF is deprived of its main natural-language dogfooding platform, and much of its reason for being. If Wikifunctions were to go away for whatever reason, Abstract Wikipedia would be instantly unworkable. — Arlo Barnes (talk) 21:56, 15 July 2026 (UTC)Reply
If nothing else, it's an interactive Rosetta Code. But I also think that the "language" of compositions makes it easier for non-programmers and non-English-speakers to contribute bugfixes or test cases, which a template+Scribunto devwiki like Fandom's could not do. YoshiRulz (talk) 15:52, 18 July 2026 (UTC)Reply
You write it in the present tense, but I'm not seeing it happening already. Maybe it will happen someday, but I'm really not sure. I am a programmer and a speaker of English and several other languages, and I find the composition interface very complicated, inefficient, and frustrating. I haven't yet seen a lot of people contributing a lot of compositions, and here we are not talking about the Abstract Wikipedia site, which is very new, but about the Wikifunctions site, which has been active for three years, and which could be used for making functions whose output can be embedded into wiki pages for well over a year.
(How much is "not a lot"? See this query, which shows all the people who ever edited compositions, with edit count. You're the second top compositions editor, @YoshiRulz. There were 149 compositions editors when the data was last updated in May, and it's probably more now, but almost everyone in the list edited them much less than you did. I'll try to update the data ASAP.) Amir E. Aharoni (talk) 16:18, 18 July 2026 (UTC)Reply
I also find editing inefficient and frustrating, and a selfish part of me wishes that they'd spent another year or two on WF before launching AW. This is pure speculation, but maybe the growth curve of attracting editors to WF from other WPs hasn't started yet due to the combination of an obtuse editing interface and the lack of useful layout components. In the meantime I will continue to convert code implementations into compositions so they can be translated. (re: WF:NOT, it gives the criterion as [...] useful and meaningful code, not temporary, arbitrary snippets [like GitHub Gists]. f:Z20741 and f:Z35585 were what I had in mind.) YoshiRulz (talk) 16:58, 18 July 2026 (UTC)Reply
A little update: As promised, I've just updated the data, so now it includes information about edits until the end of June 2026. The change is not big, however. In almost three months since the last update, the total number of user who ever made an edit to a composition implementation grew from 149 to 157, and @YoshiRulz is still all-time #2.
In case anyone is curious, the all-time numbers of users who contributed to implementation in each programming language:
Doing useful work on the composition interface even as a programmer is somehow harder than learning enough JavaScript or Python to do so. Aaron Liu (talk) 19:29, 18 July 2026 (UTC)Reply
I thought Abstract Wikipedia was going to provide automatic descriptions for Wikidata, to help combat database bloat in the same way the mul project was to address labels (and has rather failed, as its allowed usage is so small). Can it handle P31 statements well enough to focus on that limited goal, as it seems to be struggling with anything more. Vicarage (talk) 22:08, 15 July 2026 (UTC)Reply
Yes, that kind of one-line description is more amenable to the structure of these early NLG functions. But because efforts have been focused elsewhere, you'll find it's still not as good as AutoDesc's output. YoshiRulz (talk) 20:03, 16 July 2026 (UTC)Reply
Oppose closure. A lot of the concerns raised here remind me of the opposition to Wikidata from other projects, identifying difficulty contributing and problems keeping to its roadmap, and I can easily imagine this RFC being brought about Wikidata, citing much of the same concerns, in about 2015. That would have been an exceptional mistake. I haven't quite got my head around what Abstract is trying to do, but I'm willing to give it a bit more room to come up with something rather than shutting it down just because it's not looking very good now. All our projects were pretty awful in year one. Andrew Gray (talk) 22:46, 15 July 2026 (UTC)Reply
I don't see the parallel to wikidata. My first introduction to wikidata was at an edit-a-thon where somebody showed me how to set up inter-language links. It took me a little bit to get used to the editing interface, but it was immediately obvious that this was solving an important problem: it turned the O(n^2) task of linking between different language articles on the same topic into a O(n) task. And not only was it solving the problem well, there were no other extant solutions to the problem to compete with it. Wikidata also addressed another big problem which is that while it's tempting to think of the wikipedia category system as a tree, it's not. I'd already been burned by that once when a tool I was building blew up when it encountered loops in the category graph. It's also temping to think of subcategories as implementing is-a relationships, but you quickly learn that's not true either. There are other kinds of relationships expressed, but no indication of which kind you're traversing. And once I was introduced to wikidata, I could quickly see that both the tree-structure and relationship-type problems had been solved. There was no "I haven't quite got my head around what Abstract is trying to do" aspect. The value that wikidata gave me was clear on day one. RoySmith (talk) 15:35, 16 July 2026 (UTC)Reply
Support closure with resources reallocated to useful initiatives. This project should never have been approved as the approach was widely understood by 2020 to be technically non-viable. This 2016 nytimes article covering google translate's cutover to machine learning comes to mind as a moment that the dominance of ML approaches for natural language generation broke through in popular culture, let alone NLP/ML/software engineering communities NicheSports (talk) 05:56, 16 July 2026 (UTC)Reply
Support closure (also support other two as second choices). Apart from all good reasons given by others, I note that neither here nor at the WMF response to enwiki criticism is any mention made of the previous small language disasters, Greenlandic and Scots Wikipedia. Having approval from someone at such a small language wiki to import Abstract Wikipedia "articles" gives zero guarantee that you are actually producing articles in a correct version of that language. Considering how stilted and poor many of these articles are in major languages, I shudder to think how bad they will be in those languages, especially those with a completely different grammar. The comparisons of this 6-years-old project, with multimillion dollar spending and dedicated paid staff, with a small start-up, are laughable. And the example of Wikifunctions "working" as seen by Wort was already debunked at the enwiki discussion, but as is too often the case WMF replies only address the few things they think they can explain or handwave away, and conveniently ignores the things they can't. Perhaps someone pushing Wikifunctions at Croatian Wikipedia (and here) might have first checked some actual dictionaries or even the German Wiktionary[1] which gives a different table. So already Wikifunctions and its WMF defenders are pushing wrong information to the world. Fram (talk) 10:44, 16 July 2026 (UTC)Reply
So already Wikifunctions and its WMF defenders are pushing wrong information to the world Where is that wrong information? The Croatian Wiktionary table you linked to doesn't have any mistakes in it. It is incomplete because there are some alternative forms it does not include but all forms it does include are correct. By your logic, the English Wiktionary is also unreliable. Compare this declension table in the English Wiktionary with the correct one in the Greek Wiktionary. Sure, one of the tables is incomplete. Yet, it doesn't really matter because the form that is listed in the English Wiktionary table is correct. It won't lead to a foreign speaker making a mistake or anything like that. Warudo (talk) 20:42, 17 July 2026 (UTC)Reply
I agree with @Warudo. The important part here is not that whether the information is correct or incorrect. On a wiki, the relevant question is how easy it is to fix it. On Wiktionary, I would know how to fix it. I definitely wouldn't say that it's easy even for people who are experienced with templates, but I know where to start the search for it. With the Wikifunction, I'm really not sure. I kind of guess that it's somewhere in f:Z28929, but even if I'm right, and I am not sure that I am, I would have to spend quite a while to understand that code. And I wonder why should I study this. I don't see how it's better than modules, but I'm open to having my mind changed. Amir E. Aharoni (talk) 21:04, 17 July 2026 (UTC)Reply
Support 3 (closure) > 1 (pause) > 2 (transparency). The entire project is predicated on a misconception of language. Nardog (talk) 11:45, 16 July 2026 (UTC)Reply
Support all three. Abstract Wikipedia is a colossal waste of resources. The foundational idea is incompatible with how language works. Hence the project can never succeed. Joe vom Titan (talk) 15:27, 16 July 2026 (UTC)Reply
Support 1 & 2 Oppose 3. In the sense that abstract Wikipedia serves as a bridge between Wikidata and natural language, by allowing users to curate the order and sense facts are provided, I like the motivation behind the project. As a case study another knowledge graph project, the Cyc project has been generating similaryly bad rule-based natural language sentences about its items for nearly two decades. While silly and not perfect, there is a serious argument to be made that templated sentences are at least factual, and arguably better than nothing, especially in languages where this information is not otherwise available, hence I oppose closure. Of course, I would oppose abstract wikipedia content being allowed or prefered over any human written content for a given language, hence support of 1. Transparency is a no-brainer and I'm frankly surprised finances haven't been disclosed yet. --IntensionalLogician (talk) 16:12, 16 July 2026 (UTC)Reply
I don't think monolingual English speakers like myself should be in a position to decide the fate of this project which has nothing to do with enwp. Weak supportpausing rollout to pilot Wikipedias (I would consider ArticlePlaceholder and AutoDesc to be the bar which must be passed, but the communities in question did ask for it); Supporttransparency I guess; Opposeclosure because it's been barely 4 months since it launched, give it a chance (the 6 years figure includes adding support for WD and NLG to WF, building WF itself, and several prior iterations of designing and prototyping). YoshiRulz (talk) 20:52, 16 July 2026 (UTC)Reply
Support closure - I feel like it would ultimately be cheaper - and more societally beneficial as a whole - to simply spend the money on paying people to catalog and translate important articles into languages that lack them, whether it's from English to something else, or something else to English, and this project is the equivalent of building a supercomputer to invent a perfect field tilling device when any farmer would tell you that you just need a tractor. It's reinventing the wheel and based on a flawed idea that languages require no nuance and one computer system can translate basic ideas into all languages without being stilted or just devoid of context.Zxcvbnm (talk) 19:22, 17 July 2026 (UTC)Reply
I don't see the assumption without being stilted anywhere. AW's goal is to make deterministic and readable content for all languages; that doesn't include "good prose". Aaron Liu (talk) 19:30, 17 July 2026 (UTC)Reply
As noted below, any placeholder articles generated by this project will likely be significantly worse than the user navigating to a (probably English) Wikipedia page and using Google Translate or the like in order to translate the text into their lingua franca. It might even be said that this project would be rendered unnecessary by adding a "this Wiki does not have a page on this, but so and so does. Translate that article into your language?" button on missing pages, utilizing machine learning to fill in the blanks.
The issue isn't necessarily that this project can succeed or not, but that the time and money devoted into it would be misspent time and money, because the problem has already been de facto solved. Zxcvbnm (talk) 06:58, 18 July 2026 (UTC)Reply
Google Translate is not deterministic. At this stage of the models, when an error comes up, people won't realize for a long time, nobody knows what went wrong, and the engineers probably don't know how to fix it within a defined timeframe. Just two months ago it caused (bilingual) me to have a pretty significant miscommunication with someone. As noted above, better articles are very possible, though the WMF currently isn't doing anything to make that easy. Aaron Liu (talk) 13:14, 18 July 2026 (UTC)Reply
I doubt creating a formal language to write translatable fact lists that should produce somewhat natural language is ever going to have an interface that is easy to use.
Why so? The problem of making formal languages easy-to-use has long been solved, and the rest is just concatenation (for non-masters of jargon, putting multiple things together, as in "6"+"7"="67"). We can make the second part at least as easy as Wikidata, which ... is admittedly kind of obtuse, but still much better than the current state of WF. Aaron Liu (talk) 19:34, 18 July 2026 (UTC)Reply
Oppose closure because I think it's too early to discuss. The project has been open for 4 months and I do not share the conviction of some of the other editors that it is based on bad linguistics or that it's dead in the water for any other reason. Therefore, I think the best approach at the moment is to wait and see. Support transparency because honestly that should be a given. Neutral on pausing the rollout because it is a good idea to do it given the current quality of the abstract articles but each community can do that on their own, can't they? Warudo (talk) 20:59, 17 July 2026 (UTC)Reply
Support closure. After so many years and so much money, it is clear to me that the current approach to Abstract Wikipedia is going to cause nothing but harm to the Wikimedia projects and the free knowledge movement. I have not seen any evidence to the contrary, despite following this saga with morbid curiosity for some time now. This needs to end, as perhaps the biggest example of a grant-funded white elephant in WMF history. We also need a post-mortem to examine the quantity of donor funds spent on this project and how that came to pass. I of course support all lesser measures as well, such as a pause and increased transparency. Toadspike[Talk]23:59, 17 July 2026 (UTC)Reply
Support transparency and closure. As someone who has experimented well enough to know that the core foundation of this project, Wikifunctions, is flawed to the point of being unfixable, the entire premise made me very curious but ultimately is flawed. The Google Fellows report put down in writing the exact conclusions I was coming to, which was insane to me when I first read that paper. Kill this with fire. Stop trying to recreate an entirely new visual programming language and pour all the efforts and grant money instead to creating, or at least retooling WF to be, a repository of global templates and Scribunto modules, and creating a proper way to transclude them onto any wiki the same way InstantCommons works everywhere. —UndueMarmot (talk) 07:47, 19 July 2026 (UTC)Reply
The template in question. All the logic appears to be in the /en and /tl implementations, duplicated, so it's no improvement over having separate pages on each language wiki. The Google Fellows report put down in writing the exact conclusions I was coming to [...] Really? There was 3 years of progress between when it was written and when you joined WF, so I find it surprising that you can match all its points to current problems with WF. Or were you referring only to its "Recommendations" section? YoshiRulz (talk) 21:40, 19 July 2026 (UTC)Reply
I find it surprising too that the WF and AW people have hardly addressed the report with actions despite publishing a rather promising response. Aaron Liu (talk) 03:25, 21 July 2026 (UTC)Reply
Close. This is a failed project that relies on bad science and costs millions at a time when the WMF that claims it needs to increase revenue by running fundraising ads all year. BilledMammal (talk) 02:57, 20 July 2026 (UTC)Reply
Stop, rethink, clean up. The project is too early to be rolled out. Remove cross-wiki sitelinks from other projects and pause the creation of new articles. I'm not active in edting Wikifuntions or AW but I have noticed several significant obstacles for Chinese users.
For example, we now cannot generate a sentence like "I have two pens" because we haven't figured out a way to generate Chinese classifiers. "I have two pen" is illegal in Chinese because we need to say "two 支 pen", "two 隻 cat", "two 匹 horse", etc. And imagine doing the mapping for every concept in every Sinitic language (and other languages with classifiers).
The defining sentences are way too anglocentric or eurocentric. Why are we using country (Q6256) to define sovereign states? Can English speakers agree on what a country is? And I fear this cannot be fixed. If we somehow make that not anglocentric, it might still be francocentric, sinocentric or something-centric.
Thank you for your function. Yeah I understand that it's feasible, but it requires much, much effort. It's dreadful. --魔琴 (talk) 03:05, 23 July 2026 (UTC)Reply
Support closure. The problem that Abstract Wikipedia is trying to solve is either fundamentally impossible or very, very difficult. If the latter is true, I don't have faith that this difficulty can be overcome given some of the questionable technical choices made so far; as a programmer, I found the response to the Google report to be far from satisfactory.
Additionally, the idea that various language groups will utilise this model, which requires a reasonable amount of technical knowledge, instead of just writing or using extant translation methods, is not plausible in my opinion. Refining the interface may make things easier but I just don't see it ever appealing to a wider audience due to the inherent nature of the concept - adding technical language parts and tweaking functions inherently has less mass appeal and a higher barrier to entry than writing text on Wikipedia, uploading images to Commons, or adding data points on Wikidata. Currently, someone can use machine or manual translation, which provides a far lower barrier to entry and better results. In my mind, even a hypothetical mature Abstract Wikipedia is unlikely to possess fewer errors or have any substantial advantage over machine translation; a programmatic and logic-based translation model does not inherently insure against errors or possess an advantage over machine learning. Mir Novov(contribs | talk)05:04, 20 July 2026 (UTC)Reply
Support rollout pause, Oppose closure I beleive the project is still too new to see if it is an inevitable failure. Many of the problems mentioned in the piece are surface level, and while there still are major problems, maybe even foundational problems, it is still too early to kill the project when it just started being publicized broadly. However, those surface level issues do impact the small Wikipedias that would have these articles, so I think we should pause rollout. Icandostuff (talk) 01:27, 21 July 2026 (UTC)Reply
It is hard to know exactly what the different terminology means here, but after reading through some newsletters, the annual report, and the response page, I would support closure in terms of freeing up staff to put their time elsewhere. I am unfamiliar with the overheads and costing of say hosting it for volunteers, but this should not be a core output to the level that it features in the annual plan. In part the deployment has probably been sub-optimal. The decision was made to launch into Beta without having articles. While I don't think that was the right decision, I think I grasp the decision-making behind it. However, that decision-making seems incompatible with the OKR of integrating articles into three Wikipedias. This mismatch feels like it may be related to the project running a few years behind schedule. The 8 July 2026 newsletter opens with "In last week’s newsletter, we shared how Abstract Wikipedia fits into the Wikimedia Foundation’s FY26/27 annual plan: demonstrating Abstract Wikipedia’s viability as a scalable, human-centered way to create multilingual encyclopedic content" (emphasis added), and I just can't find a reading where that seems accurate.Looking at the 1 July newsletter about a demonstration article created for Wikimania, the sample article produces a blank article for me apart from a header box saying it is Abstract Wikipedia (hard to not think of surreal humour). Clicking edit gives me "Wikifunctions returned a failed response: Reached concurrent evaluator call limit in orchestrator, Wikifunctions returned a failed response: Reached rate limit in orchestrator, Wikifunctions returned a failed response: Reached rate limit in orchestrator", although there is a working picture and a timezone box. The response does not seem to address issues raised, there should have been "measurable objectives" before this point. (I come back in thinking here to feeling that it was a mistake to launch without any articles, the 1 July newsletter also states "the idea of Abstract Wikipedia is to provide good, multi-lingual articles in many languages", and if that is the idea, viability would be demonstrated by having good, multi-lingual articles.)On the philosophy I am more cautious because I am not the target market, which is presumably editors of small wikis. However, is there a substantial demand among these wikis for autogenerated articles? If there is, is the demand call for these short and stilted articles over a simple machine translation or other methods of generation? Evidence from the smaller community wikis would be valuable input into this and related discussions, but it seems hard for such input to be that informed when there are no good articles to test with. The mentioned transparency is always a good goal, but in the end this is a very technical project, and even with perfect communication scaling is tricky. If the project manages to find a viable volunteer-driven form, it would not be not so important that it should be the only project to get its own section in the Product & Technology OKRs. CMD (talk) 05:33, 21 July 2026 (UTC)Reply
Support closure The WMF Language Committee has a sensible policy: The Wikimedia Foundation does not seek to develop new linguistic entities; there must be an extensive body of works in that language. It does no good to open a public wiki in a language that no one knows how to write. The translatable abstract language in which Abstract Wikipedia is supposed to be written has not been invented yet; the Abstract Wikipedia team has rejected the existing state of the art for natural language generation on the basis that it fails to handle certain aspects of Niger-Congo B languages’ morphology and produced an alternative that fails to handle certain aspects of all languages. The team seems to have directed almost all of its effort toward developing MediaWiki extensions that barely work and almost none of its effort toward developing a language for writing translatable encyclopedia articles. If that language ever emerges, all of Abstract Wikipedia’s existing articles written in untranslatable Abstract Pidgin English will have to be rewritten. The project should be closed until that day comes. ~2026-41029-42 (talk) 19:55, 21 July 2026 (UTC)Reply
Disclaimer 1: I'm a Language committee member, but in this comment, I'm speaking only for myself and not for the rest of the committee.
Disclaimer 2: What I write here has nothing to do with what I think about Abstract Wikipedia in general. It is only a reply to this specific comment.
With those things out of the way: The Language committee's policy of not allowing projects in "new linguistic entities" doesn't apply to Abstract Wikipedia. I can think of at least three explanations for this. The first is that the policy is about human languages, and this is about what is essentially a programming language. Another one is that despite the name "Abstract Wikipedia", this is not actually an edition of Wikipedia, but a separate multilingual wiki, like Wikidata or Commons. Finally, the Language committee reports directly to the Wikimedia Board of Trustees, and since the Board of Trustees decided to start Abstract Wikipedia, it is not in the Language committee's hands anyway. (I can imagine some scenarios in which the Board would make a decision that would override the Language committee's policy and create a "constitutional crisis", but this is not one of them.)
So please don't try to use this argument. There can be many arguments against (and for) Abstract Wikipedia, and this one is just really not relevant.
Sorry, I didn’t mean to imply that the language committee is or should be involved. I just think the principle is a good one because no wiki can succeed without people who know how to write in its language. If the WMF does, in this case, seek to develop a new linguistic entity, it needs to actually develop it before opening a wiki. ~2026-41029-42 (talk) 16:58, 22 July 2026 (UTC)Reply
Support pause, Abstain transparency, Oppose closure (at this stage). I think abstract wikipedia needs to prove itself before seeking integration. It has not yet. I dont mean it needs to be perfect, just prove its viable at all. I do think they deserve some time to do so (we may be six years in, but we are much shorter in when it comes to actually doing the project). I've had my doubts about the project for years now. Even ignoring how experimental the project idea is in general, the implementation seems very over engineered and waterfall-y. I think there are quite a few red flags here separate from the inherent riskiness of the project idea. Nonetheless people involved deserve a reasonable chance to try and make it work. They just have to actually do so before integrating with other things. Bawolff (talk) 06:01, 23 July 2026 (UTC)Reply
However just to be clear, this project has been given a lot of rope. Even if i oppose closure at this time, i think at the very least this RFC should be a shot across the bow that AW needs to start demonstrating viability ASAP. I would very easily change my vote to close if things don't start looking much more promising in the next six months. Bawolff (talk) 21:32, 24 July 2026 (UTC)Reply
Support closure. The main problem with Abstract Wikipedia is not technical, though there are certainly many bugs. The problem is that it is predicated on how English works. I'd want to see evidence that linguists (not software engineers) believe that this project is viable.
Even then, Abstract Wikipedia articles are cookie-cutter pieces of trash which lack the human soul that makes Wikipedia, Wikipedia. This is a waste of money, and we need to cut out losses. Best, HouseBlaster (talk • he/they) 13:14, 24 July 2026 (UTC)Reply
AW isn't predicated on how English works, only some of the current prototype functions are. The platform itself is flexible to a fault. YoshiRulz (talk) 13:23, 24 July 2026 (UTC)Reply
Support Pause rollout, increase transparency, slight support for closure. When I first heard about Abstract Wikipedia, I didn't quite understand the whole point and wasn't very convinced. When it went public in March, I've tried looking at Abstract Wikipedia and adding an article about Bratislava. I tried for about 10 minutes to generate "Bratislava is the capital city of Slovakia" (which I tried copying over from another page!) only to be met with errors and nothing working. Quickly gave up. (I've now done it, it took 3 mintues to copy from another article and it's incredibly user-unfriendly, I have to say.) Seeing this project 4 months later - during which I forgot about it - with roughly the same issues is saddening. The search function is entirely useless, making it hard to even navigate the project, let alone create something. (Am I supposed to look up Q numbers on Wikidata first? Surely not! Then I can just use Wikidata instead.) Even though I agree this is a potentially dead end for language generation and difficulty of translation (as stated below; have you seen how many word forms some languages use? For this to be viable, you need a case marking (and even then the case might differ for different languages), whether a word is plural or not, sooo many other forms, that it's gonna be unbearable eventually...), as well as a potential waste of funds, I think it's an interesting project (as a curiosity of how far it can be pushed) and I definitely support the idea to make the knowledge accessible to everyone. However, I am not sure Abstract Wikipedia is viable right now. I also don't understand - I've not been following the project, so that doesn't help - why so many things are failing and why these are not rolled out one after the other after they work properly. What do the errors even mean? I feel like rolling out too many things without checking everything works is a part of the reason this project's state is questionable (this is touched upon in the Key Results section). Also, it takes an incredibly long time to generate articles with 3 sentences - I'm not sure how this is gonna translate to actually long articles. ~KormiSK (talk) 13:23, 24 July 2026 (UTC)Reply
Regarding generation speed, generated articles that are eventually delivered to the language editions would be cached (and the cache would be invalidated and regenerated periodically), not generated from scratch every time a reader wants to access those articles. Redmin (talk) 04:23, 28 July 2026 (UTC)Reply
Support closure: Probably a dead end. Overtly ambitious (reminds me of similar extreme endeavors such as Principia Mathematica by Russell) attempt at creating a "every description for every topic for every language" generator, when there's no need for such a monstruosity. LLMs do that in a much more clever mechanism than brute force language into functions. Knowledge should remain written by humans. Biographies, history, politics, love, war... I don't want an auomatic detailed list of factoids about a massacre in any language! If we want to bring people closer to data (not knowledge), then the solution is much more simple. Below there is an example of a viable system (more viable for some more regular languages), that involves creating per-topic per-language templates that are essentialy written by humans in their language. We should spend the money and effort in creating a system that helps language communities around the world create and maintain those templates. Ignacio Rodríguez (talk) 14:07, 24 July 2026 (UTC)Reply
Support pause, Support transparency, Abstain closure in this stage. User-friendliness can be worked on. Transparency is necessary s. t. the reader can know how the results are created, why a function returns errors, etc. I support pausing rollout s. t. one can work on these. Alfa-ketosav (talk) 14:17, 24 July 2026 (UTC)Reply
Support pausing rollout but Oppose closure for now. I find the concept of Abstract Wikipedia interesting and I see potential in it becoming a central multilingual Wikipedia that connects different languages within an article. Even though limitations are present, like you are unable to form sentences freely and every sentence has to conform to a fixed structure, I do recognise its potential and there are editors who are willing to develop it and give it structure. New functions can be created to form new sentence structures. I suggest taking things one step at a time as we are unable to 100% forsee how the project will actually develop. Yes, many articles do not make much sense currently, as Abstract Wikipedia is still in its infancy phase and many things require development and refinement. To deprive it of its growth and potential seems inappropriate as there is a group of editors working on it now. Abstract Wikipedia is only 4 months old, hence it is relatively early to start a RFC and propose its closure. I suggest pausing rollout till we have something presentable, but I oppose closure for now. Let it develop, and let it unleash its potential. If the project really fails to work out, we can always start another RFC to decide how we want to deal with it. Jianhui67talk★contribs15:38, 24 July 2026 (UTC)Reply
I support shutting down the project. Its concept is obviously flawed and unviable; it is particularly disheartening to see something like Wikinews shut down without proper discussion, while people cling desperately to a project like this. Especially when the team responsible for its development treats the community so disrespectfully. Лоття (talk) 15:55, 24 July 2026 (UTC)Reply
Support closure. A typical case of sunk cost. The whole system is way too convoluted. Basic sentence-generation functions are still not implemented on any language other than english and the only answer is to blame a lack of community for it. But large language communities have no reason to go and take time to adapt all necessary functions to their language (provided they understand how to do it: I tried for several hours, but Wikifunctions system is just too complicated for me). Smaller communities will rarely have enough people to do the work. closure and not pause because we do not need volunteers wasting their efforts on a stillborn project. Escargot bleu (talk) 17:22, 24 July 2026 (UTC)Reply
That page doesn't load for me, but the functions I've looked at only "support" many languages in the sense that they take a language as an input parameter. They don't support languages in the sense of actually generating content in that language. Carnildo (talk) 06:47, 30 July 2026 (UTC)Reply
It's back up now. If I randomly select f:Z36218 near the top, and then pick abstract:Q1186 where it's called from, I can switch to any of the 13 languages which that function is implemented in and see its output (in the second paragraph). YoshiRulz (talk) 20:35, 30 July 2026 (UTC)Reply
If I switch to Bangla (one of those 13 languages), I get "কেরলের official name হল Keralam।", which looks like some sort of Bangla-English hybrid. If instead I go to the function page and ask for the highest point of Kerala, I get "কেরলের সর্বোচ্চ বিন্দু হল Q485550✏️। " (yes, with a pencil icon). Switching to Dutch, I get "Wikifunctions returned a failed response: No matching lexeme for item in language".
Yes, in theory, it's implemented in 13 languages, but one of those 13 produces an outright failure, and another is clearly incorrect. Carnildo (talk) 21:43, 30 July 2026 (UTC)Reply
I get "কেরলের official name হল Keralam।", which looks like some sort of Bangla-English hybrid. This was because official name (Q11938905) doesn't have a label in Bangla, even though official name (P1448) does. It now falls back to the latter. If instead I go to the function page and ask for the highest point of Kerala, I get "কেরলের সর্বোচ্চ বিন্দু হল Q485550✏️। " (yes, with a pencil icon). Again, the mountain in question doesn't have a label in Bangla. The pencil is a hyperlink to Wikidata, an invitation for the reader to contribute. This is about as good as we can be expected to do, outside of hypothetically borrowing and transliterating from a neighbouring language, which I know Mahir256 has put some thought into. Switching to Dutch, I get "Wikifunctions returned a failed response: No matching lexeme for item in language". That's meant to be a call-to-action as well, but the metadata inside the Error object (which amounts to LexemeSense(nl):item for this sense (P5137)=official name (Q11938905)) isn't surfaced to the user. I've found where the lexeme lookup was and set it up to use labels as a fallback. I hope you can see now that AW is, for better and for worse, a wiki project. My 2 code changes took only a few minutes to find and a few more to fix; I spent more time writing this reply. YoshiRulz (talk) 23:42, 30 July 2026 (UTC)Reply
You, as an experienced user, were able to understand the failures and make the changes in just a few minutes. I tried fixing a missing link between a Spanish lexeme and a Wikidata entry last night; it took me 45 minutes, ten browser tabs, and I'm still waiting on a cache invalidation to see if my fix worked or not. Once it does, I expect I'll be able to add a test case that points out at least two errors in the Spanish implementation of Z26039. Carnildo (talk) 00:20, 31 July 2026 (UTC)Reply
@YoshiRulzYes, you fixed some bugs quickly, but why did you claim that in that window, you can switch to any of 13 languages and see (meaningful?) output, what is clearly not the case?
The person I was responding to seemed to be confused by the esoteric system WF uses for functions which have separate implementations (code paths) for each language. (And the comment 2 above that went so far as to claim that Basic sentence-generation functions are still not implemented on any language other than english.) I'm not here to stubbornly insist that AW works well, I only want to clear up misconceptions. There's always going to be Items with missing labels, and not many languages have good Lexeme coverage at the moment. One way of getting more mileage from the Lexemes we do have is described in Mahir's Wikimania talk, section 5. But we'll still need to consider when to "give up" and how we convey that to readers. YoshiRulz (talk) 18:57, 3 August 2026 (UTC)Reply
@YoshiRulz, can you say more about how to use this tool? I click "Configurable by Language" and I get some links and numbers, but I don't know what to do after that. How can I, for example, see a list of functions that are often used in abstract articles, but aren't implemented for Hebrew? Or to see a list of functions that are implemented for Hebrew, so that I can test that they are implemented well? Amir E. Aharoni (talk) 20:09, 30 July 2026 (UTC)Reply
It works for me but doesn't sort them by frequency. It lists missing functions under "Missing from configurations". It appears there are absolutely no implementations in Hebrew. Aaron Liu (talk) 23:37, 30 July 2026 (UTC)Reply
I do not like the confrontational tone of this RfC. It does not sufficiently assume good faith, and belittling other people’s efforts is inappropriate. Nevertheless, the substance of the RfC is convincing: even after six years of development, Abstract Wikipedia remains unusable.
It was an interesting idea at the outset, but today even tools such as Reasonator or the Commons Wikidata Infobox produce better results than Abstract Wikipedia. Practically any LLM, including open-source models, can also achieve much better results far more efficiently with a prompt such as: “Propose an encyclopedic article based only on data at https://www.wikidata.org/wiki/Qxx.”
Therefore, Support to pause the rollout - the project is still very far from being ready for deployment and appears to be more of a dead end. Support for transparency. Weak support for closure - it is difficult to make a decision without the data that should be provided under the previous point. Jklamo (talk) 18:34, 24 July 2026 (UTC)Reply
Support closure. I have to say that I never thought the project was very promising, and for its intended purpose, it is now also kind of outdated / outdone by what AI / LLMs can perform with the existing encyclopedic material, if one would want to use them (I'm against doing this in Wikimedia projects, though). I just don't see the point anymore. Also, I always felt uncomfortable with this attempt to squeeze "encyclopedic content" in such an "universal array", as it runs counter to the ideal of carefully written and thought through articles in each individual language, where the authors are able to respect language and cultural characteristics, which simply isn't possible with such an approach. So, I'd say: Yes, forget it, it's the wrong approach. By the "classical" approach of writing individual articles by individual editors for each language, we can of course not produce that much "content" - but it's unique and really human writing. We must accept that we will not always have large Wikipedia editions in every language. (A few words about myself: Active contributor to German-language Wikipedia since 2004, author of a few featured articles, admin there and on Wikimedia Commons, so I have a bit of experience here). Gestumblindi (talk) 19:16, 24 July 2026 (UTC)Reply
Support closure. If we are still asking this question six years on with very little to show for the work done to date, that fact alone answers itself. I spent a few weeks working on Wiki Functions (I know this about Abstract Wikipedia, but one uses the other), and I found it difficult to see how it was ever going to work. Things have doubtless improved since I last contributed, but we are largely using the approach of writing a text-based knowledge system for software (instead of a version control system like git). It seemed to me it was written bottom up rather than top down, so there was no direction, just people working on what seemed useful to them. On most wiki projects, that doesn't matter, as it's text-based knowledge. You know you'll need a page about a topic, and you'll soon find out if two people are working on the same thing, and either merge or one of them will be adopted. With software, you need to know where you are heading, and have a plan and a vision. Six years on, that's clearly not happening. Abstract Wikipedia may have been addressing what was perceived to be a big problem at the time it was conceived, but the world has moved on, and there are much higher priorities now. At best, it can be mothballed. GrimRob (talk) 20:21, 24 July 2026 (UTC)Reply
I strongly support closure. I think this might have worked some day in the past maybe... It won't work now, it's just years behind anything people are already doing with LLMs. And from what the current CEO said recently [2], it doesn't seem like WMF wants to invest in generating content with LLMs. Abstract wiki I think already demonstrated that this is not the way to generate readable articles. Some parts of the experiment might be reused for article guidnece... maybe. Maybe for prefilling infobox and some lists? Nux (talk) 23:34, 24 July 2026 (UTC)Reply
Oppose. Reliable, deterministic, and fact-based text generation without hallucinations is important and the base for infoboxes and small texts for small encyclopaedias. Conny (talk) 04:07, 25 July 2026 (UTC).Reply
Support transparency and closure. I think it's good that WMF tries to swing for the fences and experiment. But the people that I find most credible have all said that it should close, and there should be an effort made to learn from this experience, why Abstract Wikipedia did not work and what lessons can learnt from this so other things may be able to be built. Abzeronow (talk) 05:59, 25 July 2026 (UTC)Reply
Support closure. This program puts far too great a burden on the few native speakers of smaller language communities and threatens to drown their whole language in computer generated trash. Jcwf (talk) 08:12, 25 July 2026 (UTC)Reply
Support 2. transparency, being more transparent is never a bad thing in my opinion. Oppose 1. Pause and 3. Closure, the project has only been open to the public since March, it is to early to tell if the project will fail or not. JhowieNitnek (talk) 12:43, 25 July 2026 (UTC)Reply
Oppose closure, although I agree that too much effort has went into the current integration Abstract Wikipedia. I understand that for enwiki the described articles might be considered insufficient, but for other wikis they area a perfectly adequate start. The described deployment plan is sane and does not impose anything on the communities. What I support is a re-evaluation of the approach to a more modern one, taking into account the possibility to use Ai with (trusted) humans in the loop. Strainu (talk) 14:22, 25 July 2026 (UTC)Reply
Comment Not !voting because I reckon it’s up to the WMF to decide what to do with its money. However, as a developer with a background in computer science, I don’t see this project going anywhere (and I did read the various responses), and as a contributor and administrator of a Wikipedia and a Wiktionary in a minority language (@So9q: you asked if these were considered so I’m here), I don’t see any sign whatsoever that it could be useful. The Diablo example given by 99of9 isn’t convincing at all; frankly, having no article is better than having a localised version of that, and something better could easily be generated by a bot like in the infamous Cebuano wiki (not that I’m encouraging it). If anything could help minority language wikis, it would be making what already exists easier to use: I know at least two users who don’t translate the Wikidata items that appear in infoboxes / databoxes because it looks too difficult to them, no matter how I explain how it’s done. Huñvreüs (talk) 14:43, 25 July 2026 (UTC)Reply
Support closure and the various other options that don't go as far secondarily. LLMs have made this project obsolete. People interested in keeping small languages alive should interview and record native speakers, write and digitize their works and allow AI's to train on the material. --Rolluik (talk) 15:28, 25 July 2026 (UTC)Reply
Keep it in a leakproof box: Let's see if people want to work on it, while ensuring that its content does not affect other projects. It should be evaluated annually. If it is still underperforming in the 2030s, we will have to shut down this project. Cantons-de-l'Est (talk) 17:41, 25 July 2026 (UTC)Reply
Support closure, support transparency. Volunteers should never have been asked to spend time on this before a working POC. A project without proper fail criteria should not be granted more time to prove itself.
Note on communication: a newsletter is not transparency. Transparency does not only mean public information, but accessible information. On the Village Pump, volunteer community members were left without answers for months. The provided response to criticisism does not actually address the concerns raised. And the global community was kept out of the loop on the project's status, as the Meta page was never brought up to date. If you are being paid to build a project of this size, you should recognise that your stakeholders and the volunteer community do not have the time or the means to dig for information that should have been readily available. As far as I'm concerned, this project is being kept obscure on purpose.
This is apparent in how many of us here still lack a proper understanding of the project. For example, LLMs can replace this project for languages with a large corpus, but not for small ones. And it seems that this project turned into more about solving the underlying language translation problem than about delivering the wikibenefit it was expected to. A good comparison is ArticlePlaceholder, which can already surface most of the "knowledge" held in Wikidata in a comprehensible form, at a fraction of the cost of Abstract Wiki. Honestly, if we had simply paid people to write articles with the money spent here, we would have more valuable content by now.
The community has had little chance to understand the decisions of the elected Board and committee members, because the project's progress was not tracked on the designated platform, nor presented anywhere in a form that is a simple or honest read. This also raises concerns about how the Foundation's paid projects are handled and tracked. The policy on closing wiki projects has come up repeatedly. That policy protects volunteers from losing their projects, but on a paid project it inverts into a shield, letting any funded initiative survive by simply dodging the criteria. Also consider that seemingly no one is clearly responsible for the documentation on Meta, so a project can intentionally withhold facts about its own progress. This creates the worst kind of conflict of interest, when team’s livelihood is on the line.
I want to tie into what Choucas said earlier: "…while big Wikipedias can take in all the unique knowledge contributed to the small ones." I feel that at its core this project is colonial, given that the intro on Meta reads: “…any non-English language Wikipedia would be able to have this language-independent article translated." Read without good faith, "the sum of all knowledge" becomes English knowledge. Shipping this without guardrails also gives zero thought to how it can degrade a language's corpus, and the language itself, by introducing translations with non-existent syntax and grammar. Boro (talk) 21:37, 25 July 2026 (UTC)Reply
Support closure; 1 and 2 are the bare minimum. I’m constantly surprised when the Abstract Wikipedia team posts to our project board asking for community participation with absolutely nothing to show for it. As the RfC opener contextualized, the project is highly ambitious and – although we are told it’s “possible” – we’re never shown anything that inspires any confidence. On the contrary, everything I saw when I browsed the project was utterly disappointing. How can we buy into something that is disappointing with the promise that if we invest a lot of community effort into it, it just might work? Polomo (talk) 02:21, 26 July 2026 (UTC)Reply
I want to add that I concur with other “support closure” arguments here that point out that this project has the potential to do more harm than good to small/minority/endangered languages; that it seems to have been conceived without proper consideration or consulting of these topics; and that it may be colonial in philosophy. I don’t want to assume that the AW team was this careless, but they don’t make it easy to learn any information that says they were not. Polomo (talk) 20:38, 26 July 2026 (UTC)Reply
Support closure – Abstract Wikipedia is a failure in its current form. Language is not LEGO as I used to believe, unless you're considering constructed languages like Esperanto (which has 16 core grammatical rules). Whereas LLMs and machine translation fare better in this regard. Plus I agree with some other "support" !votes. Sbb1413 (he) (talk • contribs) 08:58, 26 July 2026 (UTC)Reply
Weak supportclosure: I just don't really see the point, if you need an article in your language about a certain topic you have Wikipedia, if you want data you have Wikidata. If there is not an article on Wikipedia in your language, and you are fine with a half-baked article, you could either use translation software that translates the article from another language to the language you need, or use some software that converts Wikidata information on that topic to an article. Either way, I don't really see the point of Abstract Wikipedia, it seems complicated to contribute to, and the articles I've seen are not good at all. But my support closure stands as weak because I might be wrong since I'm not an expert on this matter of Abstract Wikipedia and there could be legitimate reasons of why its existance could make sense that I'm currently ignoring. --Antimundo (talk) 10:00, 26 July 2026 (UTC)Reply
Oppose closure / stop / pause / whatever interruption, we will literally never achieve anything new if we are not allowed to experiment and expect to have a ready product immediately. Wikipedia would not have existed without a Nupedia failure. I am not particularly interested in contributing to Abstract Wikipedia in its current form but I don't want to prevent others from doing it. I don't think any unusual transparency is needed: as far as I know, Abstract Wikipedia has separate funding so it's not competing with other Wikimedia projects, maybe we need more transparency if it starts competing with other projects — NickK (talk) 15:50, 26 July 2026 (UTC)Reply
Radical rethink required, failing that Weak supportclosure as second-best option. First of all, let me say that the current horrendous state of output is not a reason to stop. LLMs like GPT2 in 2019 or so were pretty weak and nonsensical. (But supporters of Abstract shouldn't pretend the current output is any good, either.) If there was a light at the end of the tunnel here, it'd be worth plowing through intermediary woes. The core question remains, though, if this is a good idea in the first place. This 2016 article on the switch of Google Translate from rule-based models to machine learning is something I'm sure some are already familiar with, but should be read regardless - even for the language pairs the absolutely most amenable to rule-based translation, like English-French (has a huge corpus of professionally translated equivalent documents from the Canadian government), had the machine learning model blow the rules-based model out of the water. And, of course, machine learning is the engine behind large language models. Now, this isn't to say that rules-based models are useless. You can introspect them and their rules very directly and see why it produces certain output, which lets you tweak mistakes or subtleties. Sometimes that's what you want. But the current "goal" of Abstract Wikipedia seems to be very directly competing with "use an LLM prompted with a Wikidata URL", which seems something utterly futile to try to beat, even with 10x the budget. An LLM will have picked up all sorts of language subtleties that a rules-model can never have on when a word or phrasing is appropriate. If we did have the goal of producing such articles, we'd be better off creating a Wikipedia-focused LLM forked off existing LLMs. (And... this is probably unwise too, I'm not actually recommending that, even aside from any community resistance.) Now. This doesn't mean Wikifunctions and Abstract is pointless. But it needs to lean into what it does do well, the places that aren't just worse than an LLM. If Abstract and Wikifunctions can figure out that role, it's worth continuing, but it needs to make that proposal and be something the community and the board buys into. Better Wikidata query -> article integration? Parsing claims in raw text into Wikidata statements and references? Something like that. SnowFire (talk) 19:51, 26 July 2026 (UTC)Reply
Abstract Wikipedia is not a translation service, it is natural language generation. That NY Times article is not relevant. The goal of AW is not to create articles in (quoting the article) Spanish, French, Portuguese, German, Chinese, Japanese, Korean and Turkish, but the hundreds of smaller languages which are not currently served by LLM-powered translators and are unlikely to be in the near- to mid-term. YoshiRulz (talk) 20:24, 26 July 2026 (UTC)Reply
Then why are they pushing it towards "Bengali, Dagbani, and Malayalam"? The first and third are widely available in LLMs, and even Dagbani has dedicated LLM-powered translators (e.g. huggingface). Fram (talk) 20:45, 26 July 2026 (UTC)Reply
No, these are presented below by the WMF as their first target languages, with communication with them from May 2026. So it seems as if your understanding of the goal of AW doesn´t match what the WMF is doing. Fram (talk) 21:23, 26 July 2026 (UTC)Reply
These were posted below, e.g. this post by Sannita inviting the Bengali wikipedia (hardly a small language or one underrepresented in LLM translations) on 13 May 2026. Prhaps don't just rely on the AW team's account, which says things like "Now that we have demonstrated the system works end-to-end" and has a list of "approved" Abstract articles (approved by whom and how? Mystery!) on testwiki[3], where none of the 5 listed pages gives any results... Oh well, considering that they used the one-sentence Abstract "article" on Paris as their show-off page on Wikimania, even though it is rather dreadful and has the poor image "File:Panoramic view on the illuminated Rue de Rennes and Notre-Dame de Paris at sunset France.jpg" which despite its title does't show the Notre-Dame at all (it has been renamed after my comment here), I don't think they really believe that this is a viable tool for article creation for very small languages anyway, but just want to keep the project rolling for as long as possible. As for "to hear the other side", this RfC is about Abstract, not about Wikifunctions.
Anyway, still would like to hear anyone from the WMF discuss how they will avoid another Greenlandic or Scots drama result. So far, this has been completely avoided, almost as if they have no answer for this at all. Fram (talk) 07:25, 27 July 2026 (UTC)Reply
While dreadful, I picked the image to convey the urban fabric better than an image of a famous landmark could. As far as the scowiki comparison, it would probably be handled a similar way: revert edits by those who don't understand the language as evaluated by those who do. And each wiki would have the final call on importing the abswiki article. Arlo Barnes (talk) 19:22, 28 July 2026 (UTC)Reply
Handled a similar way as the Scots Wikipedia? That's letting it rot for over a decade, with thousands of articles in a fake approximation of what the language looks like to a non-native speaker? "And each wiki would have the final call on importing the abswiki article. " Just like each wiki has the final call in creating their own articles, which created the Scots and Greenlandic issues. These small language wikipedias in general don't have the necessary numbers to write and maintain even the most important articles, opening the doors for well-meaning (or not) others to "help". "Most articles are short or unintelligible, and machine-generated content[...]has frequently produced nonsense that could misrepresent the language." was the official result of one of these. Instead of stopping this, the WMF is now creating a tool to accelerate this. Fram (talk) 07:14, 30 July 2026 (UTC)Reply
YoshiRulz: Of course that NYT article is relevant. Machine learning models are used all the time for natural language generation, whether the base language is Wikidata or Serbian, it's the same problem exactly. And if you set the goal of natural language generation for languages with a less deep corpus of expertise, the case for rules-based models gets weaker, not stronger. There's at least a zillion different books on say German grammar, including very high-quality ones produced by linguists and the like, that could produce a Wikidata-to-basic-valid-German article given enough time and effort. But if you're targeting less common languages, then that won't always exist, and you're more likely to get what 1 or 2 volunteers with spare time think is valid (less common language), if anything at all. SnowFire (talk) 23:02, 26 July 2026 (UTC)Reply
Oppose all the above. I'm against closing it. It goes against Wikipedia's spirit of making knowledge accessible in all languages, even if it's in a simple form. Рыцарь поля (talk) 07:41, 27 July 2026 (UTC)Reply
Support all three options. I agree with most of the critique here. I have tried it for the Ukrainian language, and the experience was pretty awful. Most of the time it refused to load any sentences by showing timeout errors or reached max entries. When it loads, then it just produces unnatural sentences with a lot of mathematical symbols of set operations, foreign endings like s for plural, and just full sentences in English or Russian. If you want to improve that, you need to browse through complicated trees of functions in Wikifunction and create a Ukrainian realization for it to work properly. Also, there is a performance issue: if you want to get a page in your language first, you need to wait before Abstract wiki processes it in a number of languages, and then it gets to Ukrainian. For example, the article about Australia loads approximately 30 minutes before the first sentence appears in Ukrainian. --Repakr (talk) 09:55, 27 July 2026 (UTC)Reply
Support pausing the rollout and pushing for greater transparency. It seems that small language communities do not realize what they are stepping into (the examples at the start of this request are quite glaring, but have the editors actually seen these?), and rolling out the project in its current state would, honestly speaking, just hurt Wikipedia's reputation as a trusted source of knowledge. --Deinocheirus (talk) 11:31, 27 July 2026 (UTC)Reply
Strong Oppose. For the first point, the rollout hasn't even started, so there is nothing to pause (the current roadmap IIUC is to plan to start very limited tests on 3-5 wikipedias in months if not a year, that could be paused/delayed only if/when we get there). Criteria are a nice idea, nothing prevent anyone to write them (on the contrary, it could be very useful for the community). Also the sampling is not representative of Abstract Wikipedia (the most obvious problem have already been quickly and easily fixed ; the community is looking into delete a lot of bad apples). Overall, this is the type of arguments I've seen at the creation of Wikipedia, Commons or Wikidata. And yes, the wiki way is messy, yes it is hard (especially at the begining) ; but in the end, it's worth it. Cheers, VIGNERON * discut.14:31, 27 July 2026 (UTC)Reply
Support all: Pause, Closure (maybe after pause), and Transparency, the latter with following addition: reveal the technical cost on both the server side and the user side. Electricity and REE are scarce. Demanding a computer with 4 x 4 GHz and 16 GiO RAM to get a lousy article, while 20 years ago a way better article was accessible via Lynx or some other low-cost browser on a early Pentium with 64 MiO RAM is just insane. Taylor 49 (talk) 15:19, 27 July 2026 (UTC)Reply
Support My take is that Abstract Wikipedia still needs a lot of work to be done in order to render it a viable project. I think it was worth it because we need basic research into wikis and knowledge and all in general, and the commercial platforms will not do what we are interested in because they have preferred to be evil. However, I think the results from Abstract Wikipedia do not warrant further development. I do not think they will improve substantially and so I would like to see it closed, with a solid final report on the results we can draw from the project. This is why I support the closure of Abstract Wikipedia. Thanks to everyone who contributed to Abstract Wikipedia. Regards, Aschmidt (talk) 18:50, 28 July 2026 (UTC)Reply
Support proposals 1 and 2 but a very weak Oppose for closure at the present moment. I've tried contributing to Abstract Wikipedia but it is simply far too complex. Rolling this out will severely damage the content of other wikis and place editing out of reach for many editors. While the concept behind the Abstract Wiki has potential, there needs to be a major rework of implementation. FlammablePizza (talk) 19:02, 28 July 2026 (UTC)Reply
Support pause and transparency, Oppose closure. I agree the project in its current states has many problems, but I think it is still too early for discussion for closure. I do believe the project deserves a chance to show its potential. Thanks. Tvpuppy (talk) 19:30, 28 July 2026 (UTC)Reply
Strong supportall. Some projects just don't work, and this is one of them. We must have the courage to close down a project that isn’t working, as we did with Wikinews. Even if the project isn't closed or put on hold, transparency is absolutely necessary. --Smaug the Golden (talk - my contributions) 20:16, 28 July 2026 (UTC)Reply
Supportpause and transparency. I don't support closure per se, but it's clear to me as someone who's moderately bilingual with some experience in natural language generation that the current approach can't work. Abstract Wikipedia as it currently exists should be scrapped as a failed prototype, with the knowledge gained used as the basis for trying some other approach. --Carnildo (talk) 08:26, 30 July 2026 (UTC)Reply
Closure The project seems completely utopian, unrealistic and, frankly, a huge waste of time and money. Even more so when automatic translation is reaching levels which, while maybe not perfect, are miles ahead of whatever Abstract Wikipedia could ever dream to be. — The preceding unsigned comment was added by Sandrobt (talk) 12:07, 30 July 2026 (UTC)Reply
Strong support for all of the three suggestions, preferring Closure as fast as possible. As others said before (and me six years ago), the project is based on a total misconception of natural language and, therefore, bound to fail (hopefully without producing damage to the language versions during its crash). I really don't understand that money and labor is spent in this considerable degree for something like nuclear fusion - without any resaonable prospect for use but with considerable risk.--Mautpreller (talk) 19:16, 30 July 2026 (UTC)Reply
Oppose. Yes, the project is immature and proofs have to be made. Yes, the conceptions of natural language are a bit utopic. Yes, the risks with having occidental bias are considerable. But do you another project that is not supposed to work, utopic (and with occidental bias as well)? Hint : it finishes with "pedia". Let's continue to try this for now, the usecase is nice. Ornithorynque liminaire (talk) 20:33, 30 July 2026 (UTC)Reply
Support closure. This project is futile and a complete dead end, both in theory and in practice. It is thoroughly, fundamentally, conceptually misconceived, as was obvious a decade ago, not to mention now. Also support pause, of course. Adumbrativus (talk) 08:04, 31 July 2026 (UTC)Reply
Support all three, per Choucas, Jklamo, Jcwf, Polomo, Taylor49, and others. I still cannot see how abstract articles can ever be fully language-neutral. As mentioned by @Qcne (citing Falk) above, even things as "simple" as cardinal directions are not universally used, and I know several Wikipedia editions (including that of my heritage language, Komering) that prefer to use relative orientation (e.g. seawards, landwards, downstream and upstream) when locating places. Of course, this does not mean that speakers of Komering cannot understand or express the concept of “North” (language determinism is pseudoscience), only that doing so would be atypical in the context of discourses about locations among speakers of Komering.
If supporters of AWP themselves do not think that it will ever be able to replace the complexity and diversity of human language prose, what even is the point of creating abstract articles, as opposed to, say, displaying a series of Wikidata statements as placeholders? Unless you are assuming minoritized, low-resource language readers would prefer factoids in half-readable skeletons (that they need to maintain) over simple lists of statements (or no content), I do not see how this will help them. If anything, it comes across as patronizing to me, who is a speaker of minoritized languages myself and has worked with multiple language communities in contributing to Wikimedia projects (bringing these up for the sake of users asking for “Global South” and “small wikis” rep). I concur with @Polomo in that AGF is really the only thing restraining me from accusing the whole thing as a colonial undertaking. — swarabakti💬04:34, 2 August 2026 (UTC)Reply
Support closure and nuke from orbit. The project in its current form is clearly doomed, and any further attempt to follow the current design is simply going to be flushing away money that could usefully be spent elsewhere. It has never produced any significant useful results, and for a wide variety of reasons - technical, linguistic and practical - is unlikely ever to be able to do so. This makes me sad, because its goals were worthy and all the work to this point has clearly been performed in good faith. But it is at the moment of negative value, and building on it will only waste even more money and time. It should thus be archived to a public read-only code repository and then the wiki taken down completely. I would welcome the creation of a viable successor project with similar goals, for example by using GF as its underlying theory, but if such a successor project is ever to be created, it should be built from scratrch with a new design that takes on the advice that was ignored earlier, and can demonstrate to a community and expert review that its goals are actually possible before beginning any new work. I'd also suggest that te Wikifunctions project be paused at the same time until there can be a proper review of the idea of continuing work on it without Abstract Wikipedia to justify it. Based on what I've seen, the result of that review would also be likely to be negative. The Anome (talk) 13:47, 3 August 2026 (UTC)Reply
I support the closure. I'm an engineer in my native language section, and for me, contributing to Abstract Wikipedia was too confusing and difficult from the start. It hasn't gotten any easier over the years. Instead of using modern neural networks, the authors try to solve the problem with cumbersome, esoteric programming methods and linguistic rules.Writing code for Abstract Wikipedia requires a huge amount of specialist effort, and the result is primitive, clumsy, and dry text.Millions of Wikimedia Foundation funds have already been spent on the project. This is a waste of donations on a dead-end IT startup.To preserve culture, small language sections value texts written by native speakers, not clumsy machine translations.After years of work, it's less useful than a template card. It won't be useful in the future either. Carn (talk) 13:33, 3 August 2026 (UTC)Reply
This was written by an editor of the Russian Wikipedia. Some terms here are based on the Russian wiki jargon and may be hard to understand for people who are accustomed to English wiki jargon. Some clarifications, without expressing opinions:
Engineer : roughly equivalent to interface editor or template editor
Native language section : edition of Wikipedia in my language
IT : software (in English, "IT" is used more for "ops" or "system administration", and in Russian it's more broad for all software)
Another clarification: It hasn't gotten any easier over the years. AW hasn't been around for a year yet. Your account hasn't been linked to AW, and while it was linked to WF, you have no recorded edits there. Can you expand on when you tried editing and what problems you ran into? YoshiRulz (talk) 19:09, 3 August 2026 (UTC)Reply
Support closure. The project is folly and the money should be redirected to Commons or another project that is actually useful. Where were all these critical voices when the project was first proposed? I guess hindsight is 20/20. Nosferattus (talk) 15:00, 3 August 2026 (UTC)Reply
Strongly support closure. Abstract Wikipedia/Wikifunctions should not have been approved in the first place due to lack of genuine community consultation. It was approved 3 weeks after it was proposed on Meta (which is lightning speed) because it was proposed by a former board of trustee, contrast that to Wikispore and WikiJournal's proposals which are still lingering in the purgatory for 7 years and counting despite both proposals being much further advanced along the pipeline. This whole Abstract Wikipedia has signs of cronyism written all over it. It started off as a good idea. But here we are, 6 years later, we see the end result of a project that failed to execute properly, did not receive community scrutiny to flesh out the details and challenges while wasting donors' money into seven-figures. OhanaUnitedTalk page03:33, 4 August 2026 (UTC)Reply
Strongly support closure. The phrase "Language is not Lego" sums it up perfectly. The project is based on a false premise, namely that encyclopedic texts can be generated automatically. Beyond simple statements like "Paris is the capital of France", this purely modular approach is incapable of producing texts — due to the many differences between languages, it’s simply not the case that all terms can be translated 1:1 into all other languages, and because encyclopedic articles require the structuring of knowledge—and that cannot be automated. The whole idea was a mistake from the start. --Holder (talk) 03:44, 4 August 2026 (UTC)Reply
Support points 1 & 2, as it is clearly not ready to be deployed, even more so in less well supported languages, and the community should know the cost of the project. That said, I think volunteers there should be given more time to see if it can improve, as the Abstract Wikipedia implementation was only released a few months ago. --YodinT10:59, 4 August 2026 (UTC)Reply
Strongly support closure. While I loved the idea of Abstract Wikipedia at first, editing it feels like a janky mess. As it currently is, you can barely do anything beyond the simplest of sentence structures, and you're lucky if you can even get those to succeed. Even if it did work flawlessly, the whole idea is rooted in a flawed understanding of language, in my opinion (see Falsehoods programmers believe about languages). I wish Abstract Wikipedia could be more than what it is, but if I'm being honest, we already have something that allows us to put together pieces of structured information, and it's called Wikidata. I think things like this would be better accomplished with Wikidata anyways. WikipediholicRat (talk) 09:50, 5 August 2026 (UTC)Reply
Which of the assumptions in that list do you think Abstract Wikipedia is based on? It's mostly stuff about UI translation which doesn't apply to a responsive Web interface, and punctuation/capitalisation choice. YoshiRulz (talk) 16:53, 5 August 2026 (UTC)Reply
The fundamental assumption of Abstract Wikipedia is sitting right there at #1: "Sentences in all languages can be templated as easily as in English: '{user} is in {location}' etc." In the given template, for example, many languages vary the "in" based on the nature of the location. Carnildo (talk) 20:23, 5 August 2026 (UTC)Reply
If you click Explain... it goes on to describe preposition agreement and inflection, which are currently delegated to the language-specific implementations. (I just fixed up the English implementation to use the correct preposition. I don't speak Czech but I gather it's meant to be na Marsu, so that will need a similar fix.) The {user} is in {location} example is also possible with flexible templates like MediaWiki's system messages or Firefox' Fluent. YoshiRulz (talk) 21:39, 5 August 2026 (UTC)Reply
You're busy falling for #6. The English "on" relationship you're using for describing the location of Olympus Mons maps variously to "de", "del", "sobre", or "en" in Spanish; this sort of many-to-many mapping is very common for prepositions. Carnildo (talk) 00:13, 6 August 2026 (UTC)Reply
My point was that it doesn't matter that different languages make different distinctions when picking a preposition/affix, because that logic isn't being done by the top-level multilingual function, it's being done by the language-specific implementations. The helper function for picking an English preposition only takes the (outer) location as an argument, but its counterpart in Spanish can take both the subject and location as arguments if necessary; they're completely independent. YoshiRulz (talk) 20:47, 6 August 2026 (UTC)Reply
The issue isn't that it can't be done, the issue is that you run into a combinatorial explosion of special cases. Your helper function, for example, is accumulating a list of location types that use some preposition other than "in". Further, that function is used in state location using entity and class, monolingual. Not all classes use in/on/at when stating their location: "Denali is a mountain in Alaska", but "Browne Tower is a subpeak of Denali" (regions are another class that generally use "of").
Once you're done encoding all the special cases across all the languages you intend to support, I expect you'll find that it would have been faster to simply translate the sentence. Carnildo (talk) 21:57, 6 August 2026 (UTC)Reply
Conditional support 1+2: Pause rollout & Transparency. Oppose 3: Closure.
I am fairly ok with the WMF having moonshot projects, notwithstanding fair concerns about smart allocation of financial resources, and staff and volunteer efforts. And I accept that taking risks means that sometimes some projects will fail, but a culture that allows taking some (measured) risks, allows for some of the projects to possibly succeed. So I support Abstract Wikipedia's continued development, and having patience with it -- as long as it is kept separate.
I support transparency, but not as strict, constraining tool that creates hard deadlines or hard milestones that if not met inevitably lead to closure. Setting goals and benchmarks is good as a healthy measure, not as a stick or threat of closure. Of course, at some point, if the progress is insufficient, closure is still an option. Financial transparency would also be good.
Further, since some of the funding for it has come from institutional grants, I find it more acceptable to keep the project going. Also, it is ambitious, but there are some smart, credible people behind it, and I think they can proceed in pursuing this project, even when there are difficulties. In other words, I am opposed to direct integration.
However, keep Abstract Wikipedia in a box while using redirects; such that each article is clearly branded as Abstract Wiki. You can make those easily accessible from Wikipedia through a redirect into them, without directly messing with Wikipedia.
A final note: Wikipedia should be preeminently human-made; human editors can evaluate sources, understand context, exercise judgment, take responsibility for their contributions. Human authorship also makes contributing more intellectually rewarding for those creating it. And for those reading it, it also creates a different quality; human-written text has a value of its own. Wikipedia should preserve that character—and should not make human participation more technically complicated, or become subservient quality checkers of machine-generated content.Al83tito (talk) 10:20, 5 August 2026 (UTC)Reply
WikipediholicRat, thank you for your response, and to clarify: I was not necessarily responding to anyone's argument to the contrary, and instead aiming to reinforce the argument for why I'd keep machine-generated Abstract Wikipedia separate from the human-made Wikipedia. Cheers. Al83tito (talk) 13:56, 5 August 2026 (UTC)Reply
Abstract Wikipedia is preeminently human-made: the parts on-site ("abstract articles"), the parts on Wikifunctions, and to some extent the parts on Wikidata. Also, to your point about keeping it separated after integration, that is exactly the plan. Here's what it looks like on testwiki. YoshiRulz (talk) 17:02, 5 August 2026 (UTC)Reply
So you can either edit the Abstract article (which at the moment starts with 2 errors), or you can create a local article from scratch, but you can't actually use the Abstract article as a basis to start a local article? Then what's the point? Fram (talk) 17:15, 5 August 2026 (UTC)Reply
Support 2, no opinion on 1. Re 3, it depends on transparent success criteria that are tied to reader-focused metrics and a clear date for a go/no go decision. Alaexis (talk) 22:05, 5 August 2026 (UTC)Reply
Support pause and transparency, weak oppose closure. My view is that the project is possible, but very difficult. In my opinion the project could be saved by following these steps:
Remove or depreciate all functions and pages on the current wiki.
Give 20 paid linguists or 100 volunteer experts from the community(not necessarily with degrees, but people who know enough about linguistics) a year or two to find out what the best structure is for what is effectively a new universal language
For each language you want to support, have a group of 4 or 5 paid field linguists or 10 community members acting as field linguists interview people who speak that language for a month or two to get enough grammatical information for accurate translation into abstract form.
Even with these steps, MBH makes a good point below that something super similar has been tried with approximately the same resources before, and that didn’t ever get good enough for arbitrary text translation. Hopefully this project won’t be aiming that high(this project is only looking to add a collection of sentence structures, not every possible one), but this result at least means it will always sound clunky in some way(more so in smaller languages because there are less people working on them.) The page MBH mentioned also says in all caps “linguistics is not necessary,” but if we are given the imperative to make these structures be understandable and changeable by humans, using linguistic concepts that are already known to be possible for humans to understand makes sense, even though the page says this is a bad way of doing it, it is a way of doing it.
When I poked around AW in I believe late May, early June, I saw 5-10 major contributors there with some knowledge in linguistics between them, who were putting in a laudable effort trying to get AW into a form that is useful. This is going towards good enough, but I think going too slowly.
Above, Arlo Barnes mentioned the wiki way, which is a page I hadn’t seen before, but illustrates the problem with AW. It says “The wiki way is to make bad edits easy to correct, rather than hard to make.” But in AW a bad edit could be the decisions of which functions to use made by an earlier community, and changing that would mean re-writing every page in the wiki. For AW to be a true wiki, first the language it is written in has to be fully defined. Also, to edit any page in AW that you don’t like the structure of, you have to learn the Abstract Language, which I don’t see being vastly easier than learning a normal language(which takes years to get fully fluent in.)
I’ve heard other people talk about using machine translation/LLMs to find the structure in small languages, but I advise people to first ask linguists whether AI is good at such tasks. LLMs have a reputation for being better than the average person but worse than experts at a given task.
I want to emphasize the difference between knowing how to speak a language and knowing how to explain the structure of a language. Linguists know how to do the latter, and not necessarily the former. With native speakers it’s the opposite. This is why I think AW needs some sort of traveling group that knows how to squish languages into AW as opposed to letting the small language communities figure it out.
I’ve heard Abstract Wikipedia be compared to the ambitious project that was early Wikipedia, but one difference is that Wikimedia is now a big, slow-moving, organization.
I admit one problem with getting linguists working on this is that all of them will probably refuse on the basis that this project is impossible.
I would not be surprised if the numbers I guess in this post are an order of magnitude off. If anyone wants to posit their own likely values for any numbers I mention, go ahead. Math Bard (talk) 01:03, 7 August 2026 (UTC)Reply
Strongly support pause and transparency. For transparency, in addition to the information called for here, I urge those involved to spend serious time on a "post-mortem". I understand why this idea seemed exciting six years ago; I do not understand why we would continue to pursue it now. I think there is genuinely much of value to be learned from what did not work here -- enough for multiple very useful academic journal articles. I also support closure. LEvalyn (talk) 22:00, 7 August 2026 (UTC)Reply
Support closure. A poor attempt to do something that clearly can't be done using the technology being used, and likely can't be done at all, for which the utility if it actually could be done is anything but self-evident anyway. A waste of time and money. AndyTheGrump (talk) 16:59, 9 August 2026 (UTC)Reply
Strongly support (1) pause and (3) closure, support (2) report of resources expended.For the projects, this is functionally equivalent to the debacle with Scots Wikipedia: it will dilute and thereby undermine content in those languages. It furthermore increases the already present risk of vandalised and otherwise incorrect content propagating to projects and from them to the wider knowledge community via machine reading. It's also a waste of resources, but that's less important than the integrity of the reader-facing work, and the rights of participants in all projects to drive content creation in their languages and with appropriate context in its style of writing. Yngvadottir (talk) 18:24, 9 August 2026 (UTC)Reply
Strongly Support pause/closure/transparency. AW produces nothing of value and much to waste editors' time and attention. Per Femke et al, the project has failed irreparably—until the community decides otherwise. —Fortunaimperatrix 19:34, 9 August 2026 (UTC)Reply
Support for pause and transparency, Weak Support for closure As someone who speaks or understands multiple languages I was sceptical of this project from the minute I heard about it as it goes against everything I understand about languages, but I figured people who work on this would probably know something I don't, but seeing what I have seen here, it is clear that its not the case. It is clear that the project in its current state is nowhere near ready to be use anywhere outside of a test environment and at the very least the WMF need to slow down until there is something that actually functions. The interface is clunky and difficult to navigate, the barrier to entry for editing is far too high be able to build a volunteer base to sustain such a project and the articles I've seen so far are either broken or just a brief collection of barely connected factoids presented with little to no context. I've seen plenty of examples of well meaning editors on enwiki who want to improve representation of countries which don't have a large editor base that end up spreading a lot of mis-information by not understanding the sources they are using or the language and not understanding the limits of their knowledge, and something like abstract wikipedia has the potential to replicate this across many languages at once leaving editors who speak these poorly represented languages with an impossible to manage workload. I might be ok with the WMF doing the bare minimum to keep this project online and allow the volunteers who actually want to play around with it an opportunity to test and and show that they can make something useful out of it, but beyond that the WMF shouldn't be throwing good money after bad on the continuing development of this project that appears to be going nowhere fast. Giuliotf (talk) 13:08, 10 August 2026 (UTC)Reply
Latest comment: 4 days ago49 comments16 people in discussion
We welcome debate about our project. We have always been transparent about how difficult this project would be. The project is at least as ambitious and challenging as “a free encyclopedia anyone can edit” looked like 25 years ago, or “a knowledge base with hundred thousands contributors” 15 years ago.
Regarding the individual requests:
Re: Pause the rollout. The RFC suggests that we plan to integrate the example articles it lists into unsuspecting language communities without their consent. This is not the case. Rollout means that we make it possible for individual language communities to actively decide that they want to integrate specific, individual articles. They make this decision for each single article, for their own language only.
Re: Transparency on theproject. We are welcoming debate and even harsh criticism on the project. That’s why when the Google fellows wrote their evaluation, we encouraged them to publish. We have been transparently publishing updates about the progress of the project for the past few years. We are currently working, together with the Wikifunctions and Abstract Wikipedia communities, on an answer to recent criticism, and we are planning to publish this here soon. Given the discussion it is clear that questions regarding the feasibility of the project remain. We would like to have a constructive space to answer these. Where could that be?
Re: Close Abstract Wikipedia. Defining metrics and targets for technical, linguistic and quality criteria which can be independently evaluated is a good idea. These are very difficult to measure, and help from the community would be very much appreciated. To help us gauge the success of the project in its first year, we settled on two main metrics: do language communities accept articles from Abstract Wikipedia? And how healthy is the community? We would be very happy to cooperate with the community to define the criteria as suggested by this RFC to keep us honest about being on the right track. Who would like to volunteer to work on this with us?
Here’s a quote from the criticism by Michael Falk mentioned in the RFC: “Wikilambda presents a stark alternative to LLMs… LLMs generate text using opaque algorithms that even their designers struggle to control. Wikilambda makes every part of every algorithm available to anyone. … The role of Wikilambda in all this is to make algorithms “defeasible” … If nothing else, Wikilambda is a thundering critique of corporate AI hype.”
Examples of the current state of articles on Abstract Wikipedia are as convincing as are examples of Wikipedia articles from 2001. The Abstract Wikipedia and Wikifunctions communities are well aware of current shortcomings. Just dip into today’s discussions on our chat. Lively discussions are happening, capabilities are being built out, every single month things get better. Is there stuff that doesn’t work? Sure. That’s why we are saying that the project is in an early stage. We are working on this together. You are welcome to join us. --DVrandecic (WMF) (talk) 19:14, 14 July 2026 (UTC)Reply
On rollout: thank you for clarifying the opt-in basis of the rollout. However, you have not answered my main concern that the Foundation is preparing rollout before it has published the standards by which the content will be judged useful.
On transparency: publishing newsletters and publishing an external evaluation is not the same as publishing the project's costs, measurable success and failure criteria, termination criteria, and an independent up-to-date evaluation of the project as it currently stands.
On a constructive space: it's here.
On metrics: first year metrics are insufficient. do language communities accept articles from Abstract Wikipedia? And how healthy is the community? does not measure if those articles are useful to readers or if the project has achieved its purpose. These criteria should be defined and published before integration, not discovered afterwards by the communities expected to live with it.
On criteria: the project’s basic success criteria and failure conditions should have existed before six years of development and before rollout was planned. I welcome your offer to develop something with the community, but volunteers should not now be asked to invent, retrospectively, the standards by which a multimillion dollar WMF project is deemed minimally viable.
On Falk: he does credit the project with a profoundly moral aim: to give human beings control over information in the Age of GenAI. Yeah, I agree, this is worthy. Falk also, however, ends with a conclusion that Abstract Wikipedia is the latest in a long line of attempts at a perfect language which has evaded so many linguistic alchemists before them.
Volunteers have described this page as a "gutpunch", an assessment I agree with. This page does not provide a place for constructive criticism. It shows in many places disrespect to the volunteers who are contributing to the project with the goal to work towards Wikimedia's vision.
You say that the project should have had success criteria when it started. We did and do. There have been published as our primary goals right back then when the project started: allowing more people to read more content in the language they choose, and allowing more people to contribute content for more readers, and thus increasing the reach of underrepresented contributors. The two metrics we stated, "do language communities accept articles from Abstract Wikipedia? And how healthy is the community?" map to those. --DVrandecic (WMF) (talk) 04:20, 15 July 2026 (UTC)Reply
As I understand it, zero language communities accept articles from Abstract Wikipedia, and thus there is no community health to be assessed. Bluntly, does this not mean that by Abstract Wikipedia's own metrics it has made zero progress towards its goals? Making tthe end goal the only metric is hardly sound project design. Toadspike[Talk]00:10, 18 July 2026 (UTC)Reply
@Toadspike, this is not so true. Even though no language communities accept articles from Abstract Wikipedia now, I could find at least three communities that expressed support for trying it: Bengali, Dagbani, and Malayalam.
There are two other issues though.
The first issue is that at the moment, I couldn't find any abstract articles that can actually be rendered in those languages, although it is possible that I haven't searched well. (It's quite hard to search for an article that can be fully rendered in a language, and it would be nice if it would be easier. @DVrandecic (WMF), consider it a feature request.)
The other issue is that the annual plan demands too little: "one proof of concept article is created on Abstract Wikipedia and integrated in three Wikipedias". I mean, of course there needs to be one article before there are two. But integrating one article is not enough to "make sure that Abstract Wikipedia is viable as a platform for users and sustainable for the Foundation", as the same plan says. Integrating two or more articles based on similar reused functions would actually start showing that it's viable because the whole point of functions is supposed to be effective code reuse.
Of course, there's also the question of what constitutes a good article—this is one of the hardest things to define precisely, although it's quite intuitive for a human Wikipedian to see if an article is good. Amir E. Aharoni (talk) 05:01, 18 July 2026 (UTC)Reply
@Qcne If this is supposed to be the constructive space, where can I answer and discuss the arguments in the RFC head text (e.g. to the Sections "Sample of articles" or "Language is not Lego"?) Can I just be bold and edit them? Do I comment right in the sections? Am i supposed to discuss them down here, after all the votes and comments, where it is basically invisible to an unsuspecting reader of this page? --DVrandecic (WMF) (talk) 12:22, 26 July 2026 (UTC)Reply
No, please don't edit my original content. You are absolutely free to create a new section at the bottom or top titled something like "Developer discussion". qcne(talk)15:23, 26 July 2026 (UTC)Reply
You cannot reform something with a fundamentally flawed premise. As a programmer, I find it incredibly dubious that programmers would want to participate in a coding project that features both the extremely complicated and nigh incomprehensible JavaScript-based interface which is unavoidable if you want to write any code there and the extremely unreadable software code that reads like Putin’s wet dream. How would joining the project help change those fundamental issues in how the project works? The only thing I can imagine meaningfully contributing to this project at scale is, ironically, an LLM agent, since no human would want to touch this with a ten-foot pole. There are zero meaningful Wikimedia-related problems being solved by Wikifunctions, and quicker it closes, less money from the Endowment we lose supporting something that would be closed anyway in 10 years because it suffers from the same software disease as Structured Discussions / Flow. stjn[ru]21:42, 14 July 2026 (UTC)Reply
Clicking on the first example of a function from abstract:Q408, you get to f:Z36038, which has 3 implementation pages, on all of which the code that actually implements anything looks something like this:
This is unintelligible nonsense even to the most seasoned developer (and a very basic example of a function!). This also, notably, does not use wikitext at all. If you go to f:Z36248, one of the implementations of this thing, the rabbit hole ends up going even further and then, I guess, you are supposed to go down and down and down a list of JavaScript-rendered pages to change anything substantially. The fact that human-readable names are used somewhere in the user interface doesn’t mean that what you came up with isn’t a modern equivalent of brainfuck, if we disregard sunk cost fallacy of 250 newsletters. stjn[ru]16:30, 15 July 2026 (UTC)Reply
I'll quote:
The goal for the ZObject syntax is for it to remain mostly an internal representation. Yes, the expert contributor will be able to use the APIs, and will see the function implementation code in its ZObject format. Yes, there’s always the risk of abstraction leak. But for the majority of the contributor’s experience, the proposed serializers and ongoing design work should allow them to create function implementations as simple as as:
Accomplishing this would require the following features: [...]
These features are either already contemplated for our backend and front-end design, or technically feasible and appropriate for external collaborators–such as Google Fellows–to create and/or contribute to.
The example of the extraordinary complexity is still exactly what contributors are expected to maintain.{{#function:Z29055|L2206|}} exposes this (and L-identifier) syntax as well, and I haven't heard of any plans to change that. This is important because template editors overwhelmingly use the source editor to edit templates. Aaron Liu (talk) 18:20, 15 July 2026 (UTC)Reply
Interesting, I have followed the newsletters and missed that bit. I have written python and js implementations before the compositions became so good that you only have to resort to that in special situations. Nowadays if you want to build a function you compose it in the UI without having to bother about Zobjects at all.
I honestly haven't bothered using a lot of time to learn all the intricacies of Zobjects and everyone does not have to know them to build functions.
Your point is valid for the whole community though, if we were to loose the maybe 5-10 or so most expert contributors that are now active in WF we would probably have issues down the line if nobody would be left to figure the complicated edge cases out. But since I first heard of the project that has never been a real problem. The telegram group is full of friendly and very competent people who help each other out.
So to sum it up: yes Zobjects are complicated, no you don't have to learn them as of june 2026 to contribute any of the high level functions used in AW. So basically what I'm saying is if you don't feel like learning all the details about Zobjects you probably will never have to.
As an aside I personally find the WF community much more engaging and fun to be a part of compared to say the Wikidata one. Thanks to everyone of you who contribute to WF! So9q (talk) 21:23, 15 July 2026 (UTC)Reply
@So9q When it was said "We are moving towards a UI..." quoted just above, is that done yet? Can we see what an article looks like in that UI please? David10244 (talk) 05:57, 3 August 2026 (UTC)Reply
The paper was written before code converters, sure, but that just means e.g. you can return a BigInt instead of a ZObject. It still means you need to lookup those machine-generated labels:
functionZ13578(Z13578K1){returnZ13578K1+1n;}
This is the current implementation. Plus, NaturalNumber (Z13518) happens to be a type that's easy to represent in JavaScript. Anything a little more complicated like Monolingual Text (Z11), which has a language and a string, you'll see something like this:
For fairness, that is an example that doesn't have a converter. For the similarly-(or even more )complex Gregorian calendar date (Z20420), which has a year and a day, the converter means you can say,
return{K1:BigInt(parseInt(a[2])+(parseInt(a[2])<0?2:0)),//this might not support big numbersK2:parseInt(a[1])-1,K3:parseInt(a[0])};
, instead of wrapping that in the boilerplate. But surely, there's a way to cut down on the boilerplate by default, and only need the full version when it's deviating? Why must me write what WikiLambda surely can infer from the function definition? Even Java has changed their infamy into the simple voidmain(){}. The still somewhat unreadable Z20420 example should be the bare minimum, and AW launching without what was promised is an example of all the handwavy progress on mud footing that we've seen. Aaron Liu (talk) 14:37, 6 August 2026 (UTC)Reply
The problem isn't the detail (in fact I'm not sure what you mean by that. There's not much detail at all. They're objects with "keys" (attributes), period.) but that you have to constantly reference a dictionary of all those IDs to understand JS and Python implementations. Aaron Liu (talk) 14:20, 6 August 2026 (UTC)Reply
Regarding this claim: "There are zero meaningful Wikimedia-related problems being solved by Wikifunctions"?
Isn't multiple Wiktionaries already using WF to show conjugation tables based on lexemes?
Could it be that you simply haven't researched the utility of WF?
As an aside, I agree that the editing interface for compositions and functions is not ideal. I personally already used LLMs to help me plan compositions (before the copy paste functionality was added).
I also agree that Zobject json is hard to read and understand, but as a programmer I find it interesting and elegant. I haven't bothered writing a userscript to help me read it because I don't have to care about the internal details when I create functions in WF. and others in the community have been very helpful whenever I have had problems with anything.
Maybe you just didn't have the patience to contribute in this early stage of WF and that's ok? You are welcome to suggest improvements to the interface, I'm sure the UX team is interested in hearing how it could be improved. So9q (talk) 09:02, 15 July 2026 (UTC)Reply
> Isn't multiple Wiktionaries already using WF to show conjugation tables based on lexemes? If you mean pages like wikt:hr:Wort, which use the extremely obscure syntax of {{#function:Z29055|L2206|}}, which requires someone to know which lexeme corresponds to which Wiktionary article and which weird Z-number thing corresponds to the conjugation table, then frankly I don’t consider it something worth pouring millions of dollars into, as I said in the previous discussion about the usefulness of it all. stjn[ru]09:17, 15 July 2026 (UTC)Reply
I do also want to check, are there any actual examples of multiple Wiktionaries using it out of their own volition, and not just forced to use them by Denny himself? Because that’s what’s happening on Croatian Wiktionary, all of it was added by him. Are there people who are not Wikifunctions/AWP activists who are longing for those extremely uneditable and obscurely created conjugation tables? stjn[ru]13:27, 15 July 2026 (UTC)Reply
To be fair, Croatian Wiktionary doesn't have that many other contributors. One might say that every current Croatian Wiktionary contributor has been using Wikifunctions ;)
I think that when @DVrandecic (WMF) says One might say that every current Croatian Wiktionary contributor has been using Wikifunctions, he means that he has been the only contributor to the Croatian Wiktionary recently. This is indeed close to the truth. Here's a query that shows the number of edits per account in the Croatian Wiktionary since September 2025. User:Denny, which is the volunteer account of DVrandecic (WMF), made the largest number of edits, 293 as I'm writing this. A bot account is at the second place. The other 49 users made 15 edits or fewer; most of them made 1 or 2.
User:Denny is the only one who added Wikifunctions calls to articles. All of those are declination tables.
He also added these tables to Wiktionary articles in several other languages.
Another user, @Dv103, added such a declination table to one article in the Venetian Wiktionary, wikt:vec:Haus. As far as I can tell, this is the only instance in which someone other than User:Denny used a Wikifunction in a Wiktionary article.
Outside Wiktionaries and Abstract Wikipedia, the only other place where I could find Wikifunctions used in articles is eight pages on the Dagbani Wikipedia.
So far in this comment, everything is supposed to be factual. I cannot emphasize this enough: If my SQL is incorrect, if I missed other users' edits, or if I'm factually wrong about anything else, please tell me.
After the facts above, I'll add a little opinion. As much as I respect User:Denny as a personal friend, as a computer scientist, and as a Wikimedian, I have to disagree with him on this point: The information I'm writing here is more important than the question of showing or not showing the numerical ID of the Z object. Amir E. Aharoni (talk) 12:54, 16 July 2026 (UTC)Reply
I heard about the roll-out but haven't actually seen it in action yet on a Wiktionary, thanks for the link! I hear you have issues with the syntax there. I have not heard similar views expressed before and I have been part of the Wikidata community for years and they have just as esoteric QIDs. Do you have a suggestion for how to make an implementation that is more human-friendly? I personally find it quite elegant, but of course you gotta know where to look for the Zid.
I asked chatgpt to explain the syntax to a new contributor and this was the response. I imagine something like a short manual could be included in mediawikis editing interface whenever the #function syntax is used. Would that help? So9q (talk) 21:29, 15 July 2026 (UTC)Reply
@So9q, declination tables have been available on the more active versions of Wiktionary for many years. They are implemented using templates (and modules). See how it's done, for example, in the "German" section on the pages wikt:sv:Wort, wikt:de:Wort, and wikt:en:Wort.
There are lots of problems with how templates work, and this RFC is probably not the right place to discuss those problems deeply. The syntax for inserting this table in my examples is not much better than the Wikifunctions syntax that @Denny used in the Croatian Wiktionary, and the fact that it's different in each of my examples is itself a major problem.
However, templates have a major advantage over Wikifunctions here, which is more social than technical: Thousands of people know how to create and maintain templates, and they have used their skills effectively to insert useful content into many millions of wiki pages for more than twenty years. Much fewer people know how to create and maintain Wikifunctions. Are Wikifunctions offering people who create and maintain templates any incentive to learn a new skill? Any major technological advantage that convinces them to choose to program their next project as a Wikifunction and not as a template? So far, I haven't seen evidence for that.
Note that I'm not looking for explanation of how Wikifunctions are technically superior to templates. I can find such explanations myself. I am looking for something that actually gets people to choose them over templates.
So as far as I can tell, @Stjn's claim that there are zero meaningful Wikimedia-related problems being solved by Wikifunctions appears to be correct, although I welcome evidence to the contrary. I have to reiterate that I'm not asking for evidence for how Wikifunctions can be used to solve meaningful Wikimedia-related problems; I'm asking for evidence for how Wikifunctions are solving them. Amir E. Aharoni (talk) 05:08, 16 July 2026 (UTC)Reply
If we really want WF to be used by wikis in the future we could decide to deprecate Lua outside WF by say 2040 and make sure WF support Lua also.
But WF currently doesnt support Lua and WF is not supported on a majority of wikis yet.
But if that would become reality, then the communities could easily transfer their special knowledge to WF and continue working there, probably for the benefit of all wikis not just their "home" wiki.
I saw somewhere that Lua support is on the todo list of the WF team but the development of AW has had higher priority. From my perspective the Lua modules are already technical debt. I write a lot of software but I wouldn't want to learn Lua in mediawiki to be honest.
But just like public sector organizations Mediawiki and Wikipedias are complicated machines with a lot of people, knowhow and moving parts. It's probably going to take many years after WF support Lua to get rid of all of Lua in Mediawiki on Wikimedia wikis. Maybe long enough for all the new dev-inclined contributors to just learn WF because its nicer/easier/more powerful. So9q (talk) 18:13, 16 July 2026 (UTC)Reply
Maybe, but how will it happen?
Wikifunctions may feel nicer/easier/more powerful than Lua to you, but at the moment, Wikifunctions are used practically nowhere, and Lua is used practically everywhere. Simply saying that Lua is going to be retired and replaced by Wikifunctions is not going to work. Amir E. Aharoni (talk) 19:54, 16 July 2026 (UTC)Reply
Right now the focus is on making Wikifunctions work great. Currently from my perspective it doesn't because of all the timeout/cache issues. Also it is not clear to me as a contributor where to see details about the timeout and cache in the production system in Grafana / Loki(?) which is sorely needed if people outside the WMF team want to help improve the system.
Chatgpt suggested that we add a regularly running warming of the cache based on the most popular function calls, but that requires access to production statistic that is currently not published anywhere to my knowledge.
I did pioneering(?) work yesterday and got the orchestrator and evaluator running locally to enable easy hacking on it (it took hours, see doc and code). But I have no idea how to send the system stuff to work on.
I have yet to find any documentation in the official repos or the wiki on how to get a whole Wikifunctions system up and running including with import of the current data on WF so it can be tested thoroughly locally.
it doesn't because of all the timeout/cache issues. To be fair, having a system melt down from load when first introduced to a wider audience is a common problem, and falls clearly into the "good problems to have" bucket. For all the things I don't like about AW, let's not get sidetracked on silly stuff like this. Even if it's not the most efficient long-term solution, throw some more hardware at this and get things stabilized well enough to run an effective demo. RoySmith (talk) ) 12:33, 17 July 2026 (UTC)Reply
@RoySmith, performance is one of this project's smallest problems. It can possibly be fixed with more hardware, with a better algorithm, with database or cache optimization, or with some other engineering solution.
My question to @So9q and other big supporters of Wikifunctions and Abstract Wikipedia is not about the performance. It's about the product features: assuming that the performance problems are solved, in which way will Wikifunctions be better than templates and modules? What reason will any editor have to use them even though they are incompatible with wikitext? Amir E. Aharoni (talk) 12:54, 17 July 2026 (UTC)Reply
Thanks for asking that question :). I'm not sure, as I have never met nor talked to a template- or lua-developer in any of the Wikis.
I basically learned just enough about templates and Lua myself to stay away from them :sweat smile:.
I'm not sure if anyone has actually asked or tested WF with them and received feedback. This would probably be a good idea to do sooner rather than later IF the intent of the AW-WF-team is to replace templates and Lua modules with WF long-term. Note the if there. So9q (talk) 10:27, 22 July 2026 (UTC)Reply
@So9q, the question is not even whether they are supposed to replace templates and modules. Modules, for example, can do pretty much everything that templates can, and to my taste, they are better than templates in many ways, and yet, there are still many more templates than modules. In the English Wikipedia, for example, there are more than 600,000 templates, and fewer than 20,000 modules.
The question is different. The question is whether functions will completely replace templates and modules, but whether anyone has any reason to use functions at all. At the moment, I don't see a single scenario for that.
@RoySmith I would disagree with this. Caching and throwing hardware at the problem are band-aids. They can help things and might be part of a solution, but they aren't a replacement for appropriate architectural decisions, the same way a band-aid isn't sufficient if you cut off your leg. Everyone is talking about the inherent complexity of the problem space, but i actually suspect the more immediate reason this project will fail is due to the incidental complexity of implementation choices, especially the design of wikifunctions. Bawolff (talk) 21:47, 24 July 2026 (UTC)Reply
Sure, I understand that. But right now, there's a proof-of-concept demo which is falling flat because of what appears to be simple resource exhaustion issues leading to timeouts. What we really want to be evaluating is how well the fundamental concept of text generation works (or doesn't). If throwing a bit of hardware at the problem will let us get past the resource exhaustion problems, that's a useful short-term fix. RoySmith (talk) 22:00, 24 July 2026 (UTC)Reply
Re: 1: In the latest status update, you said Milestone: By the end of Q2, an article created on Abstract Wikipedia is integrated into three different language Wikipedias. That's the end of this calendar year. The concern is that by the progress made in the last four months, Abstract articles wouldn't seem to be any good by then. We have already identified potential pilot communities and are excited to work with them in Q1/Q2. also paints a picture of "innocent" budding wikis passively accepting integration instead of actively deciding as you claim. Aaron Liu (talk) 22:48, 14 July 2026 (UTC)Reply
@Aaron Liu Just to be clear, we reached out to several communities and only continued the discussion with those who actively supported the idea. We are looking for active support, not just passive support, as you say. Sannita (WMF) (talk) 08:32, 15 July 2026 (UTC)Reply
How does the team define "active support" vs "passive support"? To me, "active" means showing initiative, and thus cannot be shown by reaction. Aaron Liu (talk) 18:29, 15 July 2026 (UTC)Reply
@Aaron Liu We asked several projects if they were interested, and only followed up with those who responded positively to the request. There were project who did not answer at all, and we didn't follow up with them. Sannita (WMF) (talk) 20:56, 15 July 2026 (UTC)Reply
That's nice. For the purposes of my image, though, I'd regard that as passive support; to exaggerate, like provisioning those who establish colonies. Aaron Liu (talk) 02:07, 16 July 2026 (UTC)Reply
I also have a concern about a fundamentally flawed premise. Which parts of building Wikipedia(s) are helpful to automate, and which parts are the creative and deeply human work that volunteers most want to do, and that serve our readers the best? I want human editors to write as people to readers who are people, with messy human sentences, in all languages, especially languages with fewer writers and readers. I want better tools to enable different Wikipedias to more easily adopt material from each other, such as comparing articles across languages, article gap analysis, assisting human translators, and reusing citations. I also want to make it easier and more fun for more people to write better articles more quickly, which means semi-automating more things that aren't writing articles: detection and mitigation of unwanted stuff (spam, COI, UPE, abuse, vandalism, LLM-generated text, etc.), article quality assessment, identification and prioritization of impactful tasks, laborious searches for references in reliable sources, even rough first passes at reference quality checking and citation verification.
Comparing Abstract Wikipedia-generated articles to LLM-generated articles is a bit of a straw man, from my perspective. I believe some of the best uses of LLMs in this movement are to make ambitious and fun tools that help editors without generating article text - like the kinds of tools I mentioned above - and to broaden our pool of tool-makers. There are also people working on public AI alternatives, which are not necessarily contestable but are more transparent. Dreamyshade (talk) 03:53, 15 July 2026 (UTC)Reply
@Dreamyshade: I also want all of these things to happen. I love messy human sentences. We are not taking that away in any way. We are just planning to allow a language community to close some gaps they might have. An article in that language will always take precedence.
Abstract Wikipedia is aiming to support the community to fill in the gaps they want to cover with Abstract Wikipedia, so they can focus on the topics they care about the most. All of this does not take away any of the proposal you mention, which I would love to see happening. --DVrandecic (WMF) (talk) 16:29, 15 July 2026 (UTC)Reply
Latest comment: 7 days ago25 comments13 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
This feels like weasel words. Will the report be shared or only information from the report be shared? These are very different things. Bawolff (talk) 19:36, 24 July 2026 (UTC)Reply
It wouldn't be responsible of the Board to promise that the report will be shared, when they don't know what will be in the report. What if the report describes an unpatched security threat, a sensitive legal issue, a personnel situation, or other information that needs to be kept confidential? Even if nothing is confidential, what if the people writing the report know in advance that it will be published, so they decide to turn it into a media-friendly slide deck instead of addressing the subject more seriously? WhatamIdoing (talk) 23:33, 24 July 2026 (UTC)Reply
For the first part that could be covered by redacting specific sentences or paragraphs, however i think its really unlikely to be an issue here. For the second part, i dont really agree, but its still a reasonable position to have. All i'd ask is if that is the position of the board they should own it and be explicit about it, not hide behind double meanings. Bawolff (talk) 06:01, 25 July 2026 (UTC)Reply
I think that Whatamdoing explainedvery well above why we probably won't able to publish the whole report.
There was always a tension between people requiring the radical transparency from the WMF and the operational necessity to keep at least some cards close to the chest. Now that WMF is under increased pressure from the organised hostile agents including the governments, it's become even more important not to disclose any data, which could give them an opening to harm the Community. Victoria (talk) 09:39, 3 August 2026 (UTC)Reply
This feels like an incredibly poor excuse to not provide transparency in this case. There is both no such data about this specific project and no reason the report can't be published while redacting some parts. stjn[ru]23:20, 3 August 2026 (UTC)Reply
I would kindly encourage the board to set up a more structured process that they would like the community to follow. This could be fairly high level, but at least should include a solid evidence collection, discussion and opinion collection phase in my opinion. I kindly refer to my earlier comments about the challenges that this style of RfC pose to, for example, equity. In inter-community processes this is even more challenging: especially if there is no established advance notice expectation to stakeholders. Effeietsanders (talk) 11:06, 15 July 2026 (UTC)Reply
There's a procedure (see Nadzik's comment above for the link). The Board + wikimedians + staff spent 3 years developing it, and one of the reasons was that RfCs like this are non-binding. Personally, I see this RfC as a way to establish a 1) local consensus that the Abstract Wikipedia closure requires a serious consideration; in this case 2) a working group, which will write a structured report and submits it to the BoT. Victoria (talk) 14:49, 15 July 2026 (UTC)Reply
Let me clarify my comment: even though there seems to be a procedure to follow for the Sister Projects Task Force, there doesn't seem to be a clean process to initiate it. Even if the RfC is non-binding, it's highly disruptive in its current form, and paints a biased picture. I don't see a constructive process that is clean and can be initiated by the community members above, unless I'm missing something? Effeietsanders (talk) 07:21, 16 July 2026 (UTC)Reply
I'm not sure I understand how "a clean process" would look like. I also don't see why it's disruptive - or more disruptive than the usual RfC. Victoria (talk) 09:26, 16 July 2026 (UTC)Reply
Regarding whether this RFC establishes "consensus that the Abstract Wikipedia closure requires a serious consideration," after almost a week, my count is that the standings are roughly:
Pause the rollout: Strongly supported (~74% in favor).
Transparency: Strongly supported (~80% in favor).
Closure: Highly contested and evenly split (25 Support / 23 Oppose).
I hope and suggest that the Board's working group will focus on creating SMART criteria instead of merely considering whether AWP should be shut down.
The underlying problem, in my opinion, is that the success criteria for AWP in any given language will require meticulous coverage of most of that language's rules of grammar, possibly many times over for different use cases. I don't think people realize what a monumental undertaking this is. According to Cambridge University's English Grammar Profile Online, there are about 1,222 rules of English grammar. I suggest all of them are used in any sizable collection of English Wikipedia articles. I can't even imagine how to grasp the size of that problem for every language. I may be roughly echoing what the Google Fellows said here, but the outcome we have now very much seems to be consistent with simply not owning up to the overwhelming magnitude of any reasonable interpretation of goals as the AWP has stated them. Only the Transparency RFC proposal directives with SMART criteria can balance what has been bitten off with what can be chewed. ~2026-40742-08 (talk) 05:39, 21 July 2026 (UTC)Reply
Oh wow, I represent zhwiktionary. I do agree with your point, but the operational definition of "home wiki" as "where you created your account" seems very flawed. Aaron Liu (talk) 20:12, 25 July 2026 (UTC)Reply
Lol yeah, I am much more active at Indonesian, Betawi, and Komering projects in the last year or so, but it records my "home wiki" as enwiki. — swarabakti💬05:01, 2 August 2026 (UTC)Reply
That's a brilliant tool, was thinking about this the other day. Interestingly, Requests for comment/Artificial intelligence policy (which was MassMessaged very early and not born out of a discussion on a particular wiki) has 28% enwiki, but 95% from European-language wikis (the 5% is for Thai and Indonesian) (though it has 174 participants instead of just the 36 listed by the tool, and it gives different results if I refresh it?). Kowal2701 (talk) 22:12, 25 July 2026 (UTC)Reply
@WhatamIdoing: Keep in mind that this is a very flawed tool that doesn't count all participants. I couldn't see myself in the list once so something is clearly wrong. stjn[ru]07:34, 1 August 2026 (UTC)Reply
Latest comment: 2 days ago18 comments10 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
The (at this point hypothetical) [...feature] where the appropriate functions and arguments are automatically suggested based on the entered natural language text would be an editing aid, separate from the 'rendering' of abstract articles into natural language. A saw a design mock-up for that feature a couple years ago when I joined WF, but I've lost the link (it's probably one of c:Category:Wikifunctions videos). YoshiRulz (talk) 15:38, 28 July 2026 (UTC)Reply
I disagree that AW is rule-based translation. That involves extracting the meaning of natural language involving those complicated rules first and somehow putting it into data. AW eliminates this step, and has people define the meaning. It is this data that is transformed with grammatical rules, not specification of grammatical features themselves. If you see what's inside an example "article" from AW, you'll find that nowhere is the inflections and places of words described, but simply the arrangement of sentences. Every language can specify its own template sentence, inflections, and arrangements. This is far from impossible; we already use that in software localization with translation variables (tvars). See e.g. translatewiki:Gender#Testing_and_more_examples or MediaWiki:logentry-oath-recover (and https://translatewiki.net/w/i.php?title=MediaWiki:Logentry-oath-recover/it&action=edit). AW simply aims to be a more flexible form of that.Whether the interface is easy to approach is a different question to whether the concept is practically feasible. Aaron Liu (talk) 19:08, 15 July 2026 (UTC)Reply
Becuase all you're really doing is rewrite Wikidata statements in natural language, this is not really an example of the general translation problem, some version of AW might be possible, but you would in any case end up at best with a superior version of Reasonator or the bot-generated articles in cebwiki. "London is the capital city and largest city of the United Kingdom" / "Londyn jest stolicą i największym miastem Wielkiej Brytanii" / "London ist die Hauptstadt und größte Stadt des Vereinigten Königreichs", and so on might be plausible outputs, but honestly this sort of glorified templating of "X relation Y" is not a particularly interesting achievement. Spending a week or two experimenting with vibe-coding a proof-concept prototype of this using something like Claude Fable to write code using some mixture of GF, templates, Lua modules, Wikidata APIs etc. would be a good start before even considering proposing building something like AW. Massively funding a project like this without even a simple POC has been a disaster, and it should stop now. The Anome (talk) 14:12, 4 August 2026 (UTC)Reply
What do you consider "a simple POC"? There was a Lua prototype before the project was funded.A much superior version of Reasonator in natural language is exactly what AW wants to be, plus unlike Wikidata, it's theoretically possible to write out a sequence of events. I think that concept shows a lot of promise; language is just templating too.I agree with the implied point that the amount of time spent to make just this seems quite shoddy. Aaron Liu (talk) 14:44, 6 August 2026 (UTC)Reply
Latest comment: 17 days ago27 comments11 people in discussion
There was a very good "article placeholders" generator prototype on Russian Wikipedia, done using modules and which theoretically could be used with the ArticlePlaceholder extension (which is, unfortunately, unmaintained):
I think Wikifunctions/AWP are essentially trying to do the same thing as those examples but generalised as broadly as possible in terms of both the possible amount of languages served and the possible amount of concepts theoretically described. The problem with this, however, is that any actual real-life example of a generalised solution for this ends up wildly incoherent without humans filtering the output at least somewhat. It is possible to write a Lua module that returns how a model article on a country should look like based on its Wikidata item. However, when it is a generalised solution, what you end up with is stuff like abstract:Q408 (when it actually works and doesn’t just return thousands of errors), which featured such amazing sentences as ‘Australia is the flattest continent in Earth’ (second sentence in it even though it is a country article), ‘Australia is a megadiverse country’ (good luck knowing what that means without actual Wikipedia), and ‘Australia is a middle power’ (in the Middle-earth, I suppose). stjn[ru]13:18, 15 July 2026 (UTC)Reply
Thanks for reading about my country. I'm not saying it's perfect, but you might be interested to know that the three sentences you picked to criticise are all clauses from the lead of the en-wiki featured article: "... making it the sixth-largest country in the world, and is the world's flattest and driest inhabited continent", "It is a megadiverse country, and ... ", "Australia is a middle power, and has the world's thirteenth-highest military expenditure." If it's links/context you're after, they've gone in quite recently (but as you say, the caching problems stop us seeing them). If it's the size of the military you want, it will come. Anyway, this particular article is currently an experiment in how far we can go with adding content. It can't fully render in any other language, so I would not support embedding in other languages, and most big languages have their own article anyway. 99of9 (talk) 14:34, 15 July 2026 (UTC)Reply
It can't fully render in any other language, so I would not support embedding in other languages, and most big languages have their own article anyway.
... And that's really the crux of the matter, isn't it.
This is indeed one of the relatively better articles on Abstract Wikipedia (in the rare case that it actually renders, but that is probably fixable). If an article of this quality can be auto-translated using functions into a "small" language that doesn't yet have an article about Australia, it would be useful. But someone would have to write all the functions that translate it into that language. And once they are written, many of them could be reused for an article about another country. That would be a very good scenario, which would prove that Abstract Wikipedia is viable.
The question, however, is what is easier for Wikipedians who write in that language:
To program those functions, which requires knowledge of programming and very good meta-linguistic knowledge of their language.
To create an article by simply typing it from scratch, by manually translating it, or by machine-translating it (and hopefully reviewing the machine translation).
Wikipedias in the "big" languages, which already have a good article about Australia as you say, tend to have among their editors people who create and maintain templates, modules, and gadgets, and who would theoretically be able to learn the necessary skills to write NLG Wikifunctions for their language. However, since they already have the article in their language, they have very low motivation to learn to write the functions. Wikipedias in "small" languages who don't have a good article about Australia tend not to have such people, so if they want to have an article about Australia, they'll choose #2.
I don't want to speak for other participants of this RFC, so everyone is welcome to correct me if I'm wrong here, but here's what I guess: Most of the people who write comments that express negative opinions about Abstract Wikipedia see that #1 is currently unnecessary for the "big" languages and harder than #2 for the "small" languages. Furthermore, they have a hard time seeing a path to a future in which #1 becomes easier than #2 for anyone, and the arguments from the volunteers and the staff who support Abstract Wikipedia haven't yet convinced them that such a path exists.
In Abstract Wikipedia there is multiple potential way to build an article. Using Wikibase Lexemes is one, but I believe is not best one (since the set of Lexemes is far from complete, and it is nearly impossible to create Lexemes for all proper noun). Using {{LangSwitch}}-like mechanism is another one. GZWDer (talk) 16:02, 15 July 2026 (UTC)Reply
#1 is currently unnecessary for the "big" languages and harder than #2 for the "small" languages. Furthermore, they have a hard time seeing a path to a future in which #1 becomes easier than #2 for anyone - exactly. MBH (talk) 16:49, 15 July 2026 (UTC)Reply
To me, what is in en:Australia does not necessarily matter to what abstract:Q408 contains. Because if the goal of this project is to contain translatable information for other languages to use, then all of those sentences fail at being relevant and coherent enough for an article about the country. If the goal is to just mess around and see how much untranslatable information can be put in a highly indigestible format that requires three minutes to load on a better computer in an incredibly convoluted interface that no one would want to touch, then surely that can be done without wasting resources kindly provided to us by Wikimedia donors. stjn[ru]16:03, 15 July 2026 (UTC)Reply
As I wrote in another section on this page, this is a completely different way to generate text, and it's not at all how Abstract Wikipedia currently works. This RFC is about Abstract Wikipedia as it is now, not about a theoretical project. Amir E. Aharoni (talk) 17:22, 15 July 2026 (UTC)Reply
Other than "augmented text object" described below, this is already possible using the current Wikifunction and Abstract Wikipedia infrastructure (each "Builder" is a ZObject and article stored in Abstract Wikipedia). Just it is not performant, has an ugly UI, and "builder fallback" may need phab:T386422. GZWDer (talk) 17:47, 15 July 2026 (UTC)Reply
If I understand correctly, in the heart of this, there is the function f:Z37812 that can work only in English and Chinese, and works by returning a mostly hardcoded string. I don't think that this was the intention behind Wikifunctions. Amir E. Aharoni (talk) 18:51, 15 July 2026 (UTC)Reply
Yeah, but it can be "fallback" to a more general builder <b>$1</b> is a $3 located in $2. (where $3 is label of d:Q515), and we only need to translate the more general builder (unless in some language the fallback is not grammatical, and needs to be overrided in that specific builder). Anyway this way to build Abstract article is more realistic. GZWDer (talk) 19:00, 15 July 2026 (UTC)Reply
I can't see how this would work for any language that declines its nouns. Let me give you an example from my native language and I'd like it if you told me how it would work under your system. Consider the sentence "Niamey is a city located in Niger" and we'll try to generate it in Greek. If we translate your builder we get "[Nominative definite article of $1] <b>$1</b> είναι πόλη που βρίσκεται σ[accusative definite article of $2] $2." The articles are dependent on grammatical gender which you have acknowledged in your proposal so I won't linger there. The problem lies in the last word which must be in the accusative case. The correct sentence is "Η Νιαμέ είναι πόλη που βρίσκεται στον Νίγηρα." but your builder will only ever generate *"Η Νιαμέ είναι πόλη που βρίσκεται στον Νίγηρας." because the label of Niger (Q1032) is in the nominative case (as it should be). f:Z37801 takes strings as its arguments which means it only ever sees "Νίγηρας"; it doesn't see Q1032 or any lexemes associated with it. It will somehow have to know how to decline this word just from seeing its nominative form, which is not possible in general (see wikt:όρος, two words that have the same lemma form but different declensions). Warudo (talk) 20:06, 15 July 2026 (UTC)Reply
The example from Greek is useful to understand what information can be necessary too. I like the idea and so maybe it is possible to work further on it and improving it to fit more languages. At the end from my point of view there should be tools to serve different ways for creating and modifying articles. At the moment it is the more realistic way to set it on top and convert it to functions in the background. This could be a project for the Wikimania Hackathon. Hogü-456 (talk) 20:36, 15 July 2026 (UTC)Reply
There are multiple solutions of that issue;
One is also using "augmented text object". i.e. store a JSON containing each grammatical case as Greek "label" in Wikidata, and the parameter of Z37801 will not be simple string but an "augmented text object". This is unlikely to ever be complete and we need the second solution as fallback.
Another is can "transclude" a dedicated built function like {{Zxxx|$1}} <b>$1</b> είναι πόλη που βρίσκεται σ{{Zyyy|$2}} {{Zwww|$2}}., with a function (Zwww here) "guessing" (may not be 100% correct) the declination of a word. (Note: define each language item in f:Z37812 as string is just a simplified approach. It can be a function, but currently on-the-fly function is not yet supported in UI)
Anyway, the lexeme approach is not scalable since this require we create a lexeme for every proper noun for every language concerned, and there are potentially billions of proper name; creating a lexeme for each person is likely out of scope. GZWDer (talk) 21:07, 15 July 2026 (UTC)Reply
Or reuse the translatewiki:Grammar mechanism it can be {{GRAMMAR:accusative|$2}} and we transform {{GRAMMAR:accusative|Νίγηρας}} to Νίγηρα via a function (but for words that have the same lemma form but different declensions, we still need lexemes or "augmented text object").--GZWDer (talk) 21:18, 15 July 2026 (UTC)Reply
There is no {{GRAMMAR:|}} mechanism. {{GRAMMAR:|}} is not implemented in Greek. GRAMMAR is also not suitable for the purpose because it is only intended to cover words that occur in wikitext as the output of other magic words according to its documentation. Your hypothetical Zwww function would be a lot more general than that. So, let's talk about that function. It is just not possible to implement. Given a noun (adjectives decline too but I'll ignore them because the function we're discussing won't have to deal with them), it is not possible to figure out which declension pattern to use without checking a dictionary. This is because there are different declensions based on the ending of a word, the accented syllable, its grammatical gender, whether it is parisyllabic or imparisyllabic... The last two are not possible to determine from the structure of the word alone. Even when all of the above are the same, there can be multiple classes: wikt:αγώνας, wikt:ταμίας and wikt:δεκανέας, decline differently (in the plural). Thankfully for us, in the particular case of forming the singular accusative of a noun ending in "-ας" we only care about whether it is masculine or neuter. The other things I mentioned happen to be irrelevant (they only matter for the singular genitive and the plural). Still, they are important context to show just what kind of considerations one has to make.
So, let's get back to Niger and how Zwww would handle it. "Νίγηρας" is a noun ending in "-ας". Checking a dictionary (we've already lost at this point, we might as well check a lexeme) we see it is masculine. Therefore, after consulting our declension table, we find that the accusative case is "Νίγηρα". To prove that gender matters and hopefully also show that it can't be determined from morphology, the unrelated word "γήρας" (old age) is neuter and has an accusative case of "γήρας". The ending stays the same. Warudo (talk) 00:04, 16 July 2026 (UTC)Reply
@GZWDer, @Warudo, just a small technical comment from someone who did dabble in {{GRAMMAR:|}} code in core MediaWiki a bit: At the moment, {{GRAMMAR:|}} is indeed not implemented for Greek, but at least in theory, it can be implemented by someone who knows some PHP and JavaScript (I can help if anyone is interested). I don't recommend implementing it for general language grammar because {{GRAMMAR:|}} is not intended for all kinds of random content; it is primarily intended for handling MediaWiki user interface messages that include parameters that appear in run-time and have to change according to morphology. An easy common example is the "About SITENAME" message that appears at the bottom of every wiki page: in many Slavic languages site names like "Wikipedia", "Wiktionary", etc., have a different ending after the "About" preposition, and this is done using GRAMMAR for Russian, Polish, Ukrainian, etc.
Even more theoretically, {{GRAMMAR:|}} could be repurposed to do more complicated things. My hunch is that doing that would be not much more complicated than implementing WikiLambda and language-specific functions upon it, but that's something that a computer scientist or a software architect can say more about; my experience includes being a software engineer and a product manager, and I never even pretended to be a computer scientist or an architect. Amir E. Aharoni (talk) 09:50, 16 July 2026 (UTC)Reply
If I was a proponent of Abstract Wikipedia, I would avoid using cebWP as an example entirely, since it is a massive failure in Wikimedia governance and most of its content is completely and utterly useless to anyone who speaks Cebuano. A typical article in Cebuano is generated from a database with a bunch of errors and the only non-trivial points there, at least for geographical pages, is the non-precise climate data gathered from another database based on its location. stjn[ru]17:04, 15 July 2026 (UTC)Reply
For the sake of completeness and not commenting on anything pro or contra in this RfC, I wanted to say that Persian Wikipedia also has a similar system called Tofawiki which has been working since 2014 and basically produce the bare-bone layout and text of a new article for users to verify, improve, and then save. Similarly to AW, It uses Wikidata statements to produce text, for example what awards someone has won. It has specifically a class to produce text for biographies (source code) and of course it's quite hacky and quite limited. Here is the output for Alan Turing (and here is the output without any modification). I put the stats on how many articles have been created using tofawiki in phab:P94866 and as you can see a pretty major part of new article creation workflow in Persian Wikipedia was tofawiki. For example, in 2016, it 42% of all new articles were created with help of this tool and in 2025, many years after it was created, it's still 34%.
I'm not saying it can or should replace AW, I'm just mentioning as something to get ideas from (e.g. maybe AW should focus on producing good content for limited type of articles first, like biographies or maybe it should provide the text but let the human make the final call on what goes out.). Amir (talk) 23:47, 15 July 2026 (UTC)Reply
This is the way. I had thought about this before. Close AW, and create an extension or a system to simplify the creation of local language "article templates". Ignacio Rodríguez (talk) 13:36, 24 July 2026 (UTC)Reply
Latest comment: 26 days ago1 comment1 person in discussion
I want to Talk at Wikimania about Abstract Wikipedia and want to Work on improving the ways to contribute to it during the Wikimedia Hackathon. I See there challenges and so far I was Not succesful with contributing to it. From my Point of View the Local language Versions should decide what content they will integrate from Abstract Wikipedia and contributing to Abstract Wikipedia should be easier than now. So If you are at Wikimania onsite in Paris you can Talk to me. Lets Work together in improving the Abstract Wikipeda. Wikimania as an international Event offers the Chance to Exchange ideas with people from small language Versions onsite and onlie. Hogü-456 (talk) 15:06, 15 July 2026 (UTC)Reply
Abstract Wikipedia's Response to English Wikipedia criticism
The Abstract Wikipedia team has drafted a response, which was reviewed and improved by the community. We want to express our gratitude to the community members who have shown their care and spent their valuable time contributing to the answer. All remaining shortcomings are strictly ours. The answer can be found here: m:Abstract Wikipedia/Response to English Wikipedia criticism. You are welcome to comment and to pose further questions and criticism on the talk page. -- DVrandecic (WMF) (talk) 08:55, 16 July 2026 (UTC)
In the Q&A, someone asked whether this RfC had a mandate (as in jurisdiction) to effect closure, to which the speaker's response was to point to the current policy (which I believe is CPP? edit: see above) and remark on the ineffectiveness of processes with low numbers of participants. YoshiRulz (talk) 18:19, 22 July 2026 (UTC)Reply
That person was me, the question that I asked was: "do you think that the Abstract Wikipedia RfC has the mandate to ask for more transparency from the board and the WMF at large on the significant amount of money being spent on the project?". I personally have a very different (and much more negative memory) of the answer the speaker (Victoria) gave. To my understanding she opened the response with a "yes" and then went on to make a caricature of this RFC itself basically saying that the participants were a misinformed group of people from the global north who have no idea what was going on. In theory, this is a valid opinion that somebody can have, but personally the response given has undermined my belief in the board's impartiality to this RFC especially since Victoria is a member of the board and is explicitly authorized to liaison for the board to the community. Sohom (talk) 07:29, 23 July 2026 (UTC)Reply
From what I remember, Victoria first implied that the RfC didn't have a mandate for closure specifically, following which I bugged Sohom to ask this question, leading to the much more blurry answer about whether it had a mandate for transparency. Do you still have the transcript of her full answer? Chaotic Enby (talk) 12:00, 23 July 2026 (UTC)Reply
Yes, there is a mandate. I mean, as I said, the procedure is still there and it shows how you can ask for closure of a project. [Whether it's] a long-standing project like Wikispecies (just an example), or Abstract Wikipedia which is [a] developing project. But is it developing fast enough, considering that we are having problems with AI and falling [...] readership? I'm just saying that the problem with the movement—this is our strength, but this is our weakness as well—that we are very decentralised and we don't know what the other parts are doing. As [? koʃek] said, some parts were already mature and it didn't work. Maybe it could have worked in their case, but by the time they realised what was happening, it was too late. Here again, [regarding] mature communities: If you look at people that [have] started talking about Abstract Wikipedia, it's the same Global North people, so we don't know what people in ESEAP [think] about it. But there is a procedure. It is a procedure that requires work, requires [you] to show that Abstract Wikipedia (for example; I don't know) doesn't work. In the RfC, it was like "I looked at five articles and they don't work," and then people who work on Abstract Wikipedia come and tell "Oh, but here's ten articles that work." How can you draw a conclusion from it? I don't [know]. But what I would encourage people [to do] is to go to the policy which is there, to look at it, to go through it, to collect the data and submit it to the Board of Trustees, right? And that would be the correct procedure. I [? missed] someone's name, and the rest of the text in [brackets] was added by me to keep it readable. YoshiRulz (talk) 11:44, 24 July 2026 (UTC)Reply
FWIW, the main reason enwiki is still so dominant in the movement (relative to other projects) after 25 years is a direct result of WMF policy. Enwiki appears to still be prioritised and privileged because it brings in the most donor money, and all the WMF appears to care about is their bottom line and financial sustainability/longevity. If they actually upheld the values of the movement, they'd instead prioritise smaller wikis and use enwiki's reach to focus on developing those projects where there is the most potential for furthering the movement's goals (and no, such a pivot shouldn't be an opportunity for the WMF to centralise more power in their own hands at the expense of the communities). Instead, small wikis are usually shut out of meta discussions and everything revolves around enwiki (how does meta not have an inbuilt feature that machine translates comments fgs, why is everything still done in English). Ofc it's also a result of the WMF being an American org instead of a proper global one (creating a Wikimedia United States would be a step in the right direction). All in all, comments like Victoria's above are taking the piss, and are a dereliction of responsibility. Kowal2701 (talk) 12:00, 24 July 2026 (UTC)Reply
Absolutely...the prevailing attitude of not consulting the abstractwiki community prior to creating this RfC, when they are the primary affected community, is very showing. //shb (t • c)12:35, 24 July 2026 (UTC)Reply
Absolutely ridiculous. At this point arguing that Abstract Wikipedia "works" and it's just that "global north" people select "5 bad articles" is a bad faith argument in my opinion. The whole project is obviously broken, and it would look broken to people in the global south even more, since English is practically the only language that at least sometimes produce intelligible results. Trying with Italian for example (another language I know, and with a large speaking population) I cannot find a single article that makes sense (most are completely empty or just a list of errors) Ita140188 (talk) 08:36, 24 July 2026 (UTC)Reply
How was the “global south” consulted before starting the project? Indeed it’s easiest to make this work for English. I want to know how it’s even a little bit useful for minority languages (which are the selling point of AW) with few editors. These few editors could invest their time (less time?) into producing actual in-depth human-written material, which they presumably already know how to do, instead of having to learn and tame the Abstract Wikipedia programming language. Even the Abstract Wikipedia developers haven’t managed to make functions that produce correct grammar in English, and somehow random people are supposed to be able to do that for their own languages off the top of their heads? Polomo (talk) 02:53, 26 July 2026 (UTC)Reply
Latest comment: 7 days ago25 comments10 people in discussion
Above we have a long list of "random" articles that show failures. Could someone link, say, half a dozen articles that they consider to be among the best content produced by Abstract Wikipedia or, if it's already here somewhere and I missed it, point me to where I could find that? - Jmabel (talk) 21:47, 24 July 2026 (UTC)Reply
I actually just raised a concern about how difficult it is to find Abstract articles on that wiki, given that there is a lack of visible categorization (probably due to there being a lack of wikitext).
Here are some pretty good English-language articles that I can find (many of these use newer functions which are lacking foreign-language implementation, and I'm sure there are other decent ones).
As of a couple weeks ago, there is a bug where the software will try to call every function at once, which can make it so the entire page throws a "Reached time limit in orchestrator" error. This issue is being tracked and worked on right now.
Thanks for asking. A few weeks ago the rendering and caching services were switched over, and and until these are made more durable, you will see errors in most articles at the moment. Here are some screenshots I've collected from the Telegram channel over the last month. Please bear in mind:
AW has only been open for editing since 19 March 2026.
Before then, we had done a lot of work on Wikifunctions, but most of it was general in nature rather than linguistic.
When it was opened we saw the structure we would need to produce functions for, which were not necessarily the formats we expected.
Things like links, images, and redlinks were not available initially.
Every new feature needs new functions before it can be used in AW.
New language constructs to broaden the range of expressions also need to be made first on WF.
Even since release, entirely to focus on AW, I have spend most of my editing time on WF not AW.
Even much of that time has been testing concepts of what to show in languages which are not yet configured, to ensure they don't get slabs of error messages as their first introduction to AW.
Early articles are often experimental, we need to figure out what we can do and what we can't, or want to test new features. One editor even ran a semi-automated bot early on, which produced a lot of the "random" articles, which are slated for cleanup.
We editors did not expect to have to justify our existence with robust articles within months of accessing a new project.
Most non-English languages have not yet been widely configured, so apart from the Swedish example, you should not expect them to render well in other languages yet.
Even in the long term, the expressivity of these articles should not be compared to English Wikipedia (the source of this RFC). These are intended as an (community-optional) backstop when a local language article is not in place. Some of the topics covered in these screenshots have only a handful of local language articles about them.
Nobody thinks these articles should go into language Wikipedias before the community receiving them are happy that they are ready both in abstract and in their language. There was always complete consensus on this.
It’s tempting to laugh at the inclusion of The inventor of carbon was Antoine Lavoisier as an example of the best of Abstract Wikipedia, but perhaps it can be instructive. The sentence relies on the Wikidata property discoverer or inventor (P61), a concept that English has multiple words for with different nuances. There will be many such cases in many languages. In general, what can you do to ensure the correct word is chosen and avoid generating blatant factual errors? ~2026-41029-42 (talk) 04:30, 25 July 2026 (UTC)Reply
You can laugh, it's okay. I did too (I'm a chemistry academic). There are many possible approaches to improving this. "Ensure" is a strong word, so I won't promise that (and neither does en-wiki). It could be anything from splitting properties, to Wikidata qualifiers, to item-type categorisation/inference, to using the entire property label and staying ambiguous. But at the end of the day the language community won't accept it on their wiki until it is good enough. The omnibus function that created that sentence hopes to deal with almost all Wikidata properties, which is obviously a big ask, and already some specific properties have split off their handling to more nuanced functions (this can be per language). --99of9 (talk) 06:15, 25 July 2026 (UTC)Reply
@99of9 thanks for the better examples. It does sound kind of better in English. You do realise that this is much worse than what most language models can give us, right? Google's AI mode will give you better summary and for most topics will be accurate and in my language (and sometimes more up to date then Wikipedia). When you explicitly ask GPT for a summary of an English article and translate e.g. to Polish you will get even better results and hardly ever get hallucinations... At this rate it doesn't seem like Abstract wiki concepts of generating articles will give us anything good any time soon. Plus as you said (or seems to have said) you need A LOT of knowledge and be very tech savvy to do abstract articles (wikifu devs + abstract wiki magician), and that's not a resource we have in abundance in the Wikimedia Communities. Nux (talk) 07:15, 25 July 2026 (UTC)Reply
@User:Nux Your comment comes across as patronising in English (your favourite LLM could tell you this). I'll AGF for now, but I'll wait until you rephrase if you want me to substantively reply. --99of9 (talk) 05:53, 26 July 2026 (UTC)Reply
@99of9 I understand that we disagree, but you seem to suggest that I know only what LLMs tell me. My opinion is based on my experience and knowledge from before transformers where invented. I've studied AI on a university, I did both very simple fuzzy logic stuff, programmed 2 neurones networks as well as a bit bigger ones for recognising digits and also helped doing OCR for music notation. I also observed the creation of deep neural networks and learned on IT conferences how scientists do labelling and use various tricks to get to better AI tools. My interest in AI is mostly a hobby now, but I'm not a dude who just uses LLMs. I'm a dev that knows a thing or two. I was hoping Abstract wiki would get somewhere interesting, but I also think in science it is also important to recognise when the route is not correct. I look at the examples and I see we're not there. I saw examples of tech that already is much better, even examples presented on this Wikimania research path. Nux (talk) 13:41, 26 July 2026 (UTC)Reply
No, I am not suggesting anything about your expertise, just that the tone of your comment, especially "You do realise that this is much worse than what most language models can give us, right?" in this context comes across as patronising in English. I appreciate that this may not have been your intent, in which case I will happily continue the discussion if it is amended. --99of9 (talk) 13:48, 26 July 2026 (UTC)Reply
I'm not an English native speaker. That was just a question. I know some people in the community don't use LLMs for ideological or other reasons. Some use it with success even for editing Wikipedia. Don't know what is your experience. Nux (talk) 19:11, 26 July 2026 (UTC)Reply
Apologies for the delayed reply. Are you proposing that the readers should use LLMs in this way for any content they do not have on their language-wiki? I have a few concerns with this as a "solution":
It only tends to work well for languages with a big online training corpus. (For example, test your in-browser translation to Polish of today's featured article: azb:گنجعلی_صباحی. Polish and Azerbaijani are not even particularly obscure examples!)
It does not (yet?) reliably reference the summary well.
The reader must always be on their guard for hallucinations (but where can they check?).
The reader is required to rely on a commercial provider that has its own biases and interests (perhaps subtle advertising or similar).
You should not expect that it will always be free. Will poor countries be subsidised by OpenAI?
The summary must be generated separately for every article reader, an incredible waste of resources.
The Wikimedia movement didn't even try to help!?
Even if Abstract Wikipedia stays more repetitive and less expressive, it will not fall into any of these traps in the long term. As far as I can see, every single dot point is in our favour. --99of9 (talk) 07:23, 1 August 2026 (UTC)Reply
@99of9 A solution might be to have cached LLM translations of the first few paragraphs or a summary of the first few paragraphs of a good article. Another solution would be to generate stuff with Wikifunctions, but then use an LLM to make the article sound less robotic ("X is Y" repeated many times).
test your in-browser translation to Polish of today's featured article: azb:گنجعلی_صباحی. Azerbaijani seems to work fine in GPT as far as I can tell [4] (though someone who knows the language would have to verify). Even PLLuM kind of works with Azerbaijani, which is a Polish government AI project focused on Polish and striving for ethical model development [5]. It seems to have struggled with birthplace translation, though, and introduced some problems. Still, it's impressive for a Polish language model (I was sure it wouldn't even try to translate). PLLuM works better when handling data from Wikidata, i.e. handling information in Polish and English to create sentences. It would probably work even better with proper configuration (perhaps lowering temperature)... But plwiki is a large wiki with a large community, so I doubt the community would accept creating articles with either Wikifunctions or LLMs. So that just shows it is possible with LLMs. Not sure if AW even tried to explore this avenue recently (models change a lot in recent years). I know that WMF is exploring using some LLMs for tagging articles for review (for now for Stewards).
The summary must be generated separately for every article reader, an incredible waste of resources. The same is true for AW, is it not? The goal of the AW project at the moment is to generate the summary with HI and manual human labour. That's a lot of labour and effort if you want to do it manually for millions of articles. Personally, I think human resources are scarcer than GPUs Wikimedia can buy. The results from Wikifunctions are not very smooth sentences, as many people have said here in this RFC. I think even algorithmic bots actually do better with enough data (you can easily create articles about cities with bots, some wikis did that, plwiki did that).
The Wikimedia movement didn't even try to help!? I don' think that is true. I looked at Wikifunctions some time before, tinkered with some beta and reviewed some functions. Personally, I never saw it as something that would work on a bigger scale (just too complex), so I just observed. But we actually had a person from plwiki who did a lot to promote WF in the plwiki community. That person is very intelligent and talented, and he was able to create some translations and even some functions... Perhaps you, 99of9, you just don't see how special you are to be able to edit WF and AW. Yes, this is a compliment for you :). It's not good for WF/AW, though, that they require very special skills and learning a lot.
Also note that if AW is used for small languages and the language quality is bad, chances are AI tools will be bad too (and might get worse). I mean, if PLLuM, GPT, or any other language model were learning from X is Y sentences, then the results would probably be pretty poor. And so tools for machine translation for small languages might actually get worse. That is also one of the fundamental problems with AW and something to think about carefully. That was the topic of one of the research studies presented at Wikimania [6] (the 3rd study presented there). Nux (talk) 13:01, 1 August 2026 (UTC)Reply
While it wouldn't be prose, imagine how much more than this a fraction of this budget could give us if invested in development of a good presentation layer on top of Wikidata. Not to mention what a well-invested half million or so could do by way of tools to make it easier for non-techies to usefully enter data into Wikidata. (And, to be honest, this is barely prose anyway.) - Jmabel (talk) 20:04, 25 July 2026 (UTC)Reply
I have no objection to those suggestions. I don't think they are in competitions with the WF or AW community's contributions. If it's about the money, that's above my pay grade, but I guess your proposals would not receive grant funding. "Barely" sure, but please consider the dot point context above. --99of9 (talk) 05:58, 26 July 2026 (UTC)Reply
New language constructs to broaden the range of expressions also need to be made first on WF.
Most non-English languages have not yet been widely configured
So it’s already hard enough to do for big languages, yes? Languages with communities that can make a much better standard Wikipedia article in less time. Then, how hard of a time will speakers of minority languages have when trying to configure this for their own languages? That’s the closest to a selling point I’ve heard of regarding AW – and I still can’t conceive of how it could possibly work. If the science does check out (which I have seen no examples that it does, just assurances), it’s pointless and unsustainable. Polomo (talk) 03:01, 26 July 2026 (UTC)Reply
If you compare configuring all configurable functions in a whole language to writing a standard single article, then sure, it's not even close. But once a language is fully configured, it applies to all Abstract articles (of which there could eventually be millions). The exact difficulty at the Wikifunctions end is not simple to quantify, depends on the complexity of your language, and depends on what breadth of expression we want to get to. Editors are trying it now in whatever langauges they speak (e.g. there are 30 different language configurations of one of the simplest functions f:Z26043), but I think we'll get a better sense of how to do it well as we try it. If you'd like to try in pt-BR, the community would be happy to help. Can you be more explicit about what an "example" that shows "the science checks out" would look like to convince you? --99of9 (talk) 06:21, 26 July 2026 (UTC)Reply
@99of9: I should clarify, yeah: of course science isn’t something that’s proven by examples. What I was getting at is the dissatisfaction I have with Abstract Wikipedia’s communication and outreach. I apologize if this is long, and I don’t expect you to reply.
I first heard of the project when they were asking people to suggest names for it. The brief description in the mesaage seemed surreal and, when I tried to learn more about AW, it was much easier to find everything that’s wrong with it than the things that are being done right. It seems so obvious to want to know “is it possible?”, “has something similar already been done?”, and yet not the FAQ nor this apparently relevant page actually give clarity on this, beyond saying “yes, definitely”. On the other hand, it’s not hard to find statements that not only cast doubt on the project’s basic viability but also put the development process into question, like the The Signpost article from 2023.
Many of the “support closure” voters above say they’re skeptical that AW’s goals for natural language generation are even feasible. Someone who is sure that they are might claim that these voters are disinformed and that, since the project is theoretically feasible and just currently embrionary, there’s no reason to close it. But that ignores the important issue of trust — in order to be possible, AW needs language communities to dedicate an enormous amount of effort in it; and you need to trust the concept in order do that. By doing very little to convince a layman of the basic fact (?) that it’s possible, by not addressing skepticism or doing so very poorly, and by at times almost asking for bad publicity, I think what the AW team has done is cultivate pretty widespread distrust. This was our reaction at the English Wiktionary, and I expect the average person’s thought process to be more or less similar.
It’s the AW team’s responsibility to ensure proper communication with the communities and people it wishes to invite as collaborators, and due to faults in this respect, there’s a general distrust of the project, as I see it. And that’s reason enough to close it: our contribution isn’t deserved right now. Maybe, in the future, the project can be re-pitched and we can be convinced, with more communication, that it holds water. Currently, in this RfC, no one seems to be doing very well at convincing the skeptics. Polomo (talk) 20:06, 26 July 2026 (UTC)Reply
Part of the issue with trust, is it now feels like the project is too big to fail. I think a lot of people who supported it initially were expecting small experiments that build on each other, demonstrating viability with each step. Instead we have spent 6 years building the "perfect" version without any validation that things are on the right track. Even if this is possible on a linguistic front (big if), i'm doubtful we're actually going to build it succesfully because we aren't testing it MVP by MVP but instead constructing it as a giant waterfall. Bawolff (talk) 16:47, 27 July 2026 (UTC)Reply
I expect it would be quite instructive to try to get that article on carbon working in Spanish: you'll need to come up with a way to programmatically decide if that "was" in the first paragraph should be translated as "era", "fue", "estaba", or "estuvo". (Assuming that function Z37104 only deals with the singular. If it can also generate plurals, you've got another four conjugations to deal with.) Carnildo (talk) 09:25, 28 July 2026 (UTC)Reply
"6 years devoted to WF": WF has been open to the community for 3 years, (with progressive rollout of features, starting with only strings). I don't know the internal development process before that, but it's very clear that WF has made great strides both from the technical side and the community since then.--99of9 (talk) 10:23, 3 August 2026 (UTC)Reply
Preparation for "handling what [AW] needs": this may be hard to understand for outsiders, but the WF community were mostly building non-NLG functions, and certainly non-HTML functions until we saw the interface that AW has. This does mean that newcomers who just want to write abstract articles and don't want to contribute to functions are still waiting for lots from WF, but it's not a good reason to close access. --99of9 (talk) 10:23, 3 August 2026 (UTC)Reply
Also someone forgot to annouce the outcome of the vote scheduled for early December. Anyway, the term "Abstract Wikipedia" that won with something between minus ONE and plus ONE vote (the announcement is messy, how many did vote in those extra rounds and where?) causes just confusion. More nonsense in a word dominated by AS (Artificial Stupidity).
This "Abstract Wikipedia" heavily relies on "WikiFunctions" (at least no "Wikipedia" misnomer here) that I did not succeed to understand either. My limited testig did not find anything useful there. Why two programming languages, but none of them is LUA already widely used on wikis? On the special page wikt:sv:Special:Senaste_ändringar I can read (it has been there for some months):
> Visa kategorisering av sidor | ⧼wikilambda-rc-hide-wikifunctions⧽ | Visa Wikidata
If I understand correctly, the issue with recent changes can only be seen by people who disabled the filters interface or don't run JavaScript. It is certainly a bug, albeit a relatively minor one. I reported it at https://phabricator.wikimedia.org/T433309 because I love reporting (and, time permitting, fixing) bugs related to translatable messages.
As for JavaScript in general, I'd say that Abstract Wikipedia should probably cache a fully-rendered version of the page and show it to people who for whatever reason don't run JavaScript. I'm really not an expert on caching and performance, but my intuition tells me having such a cached version is probably a good idea in any case. Amir E. Aharoni (talk) 20:50, 27 July 2026 (UTC)Reply
Latest comment: 3 days ago25 comments7 people in discussion
I wasn't able to attend this workshop and just watched the abstract wiki workshop yesterday. I thought it would be a workshop showing the best use cases of how this works. I also tried to be positive about it (even though I worked with wikifunctions before), but the workshop didn't go well. I know presentations of experimental features don't always work, and that's fine. I wouldn't nitpick about experimental stuff. But Abstract Wikipedia is 3-6 years old (in development since at least 2020, with Wikifunctions generally available since July 2023). I would expect the basic stuff to be working by now.
My thoughts after seeing the workshop and tinkering with AW a bit more:
Even basic functions in English were not working (again, it's fine when experimental stuff is not working, but here basic functions in the most basic language are failing a lot of the time).
You have to write all articles by hand. I was sure there would be some magic shown that would allow you to quickly create 100k articles about cities in Africa, Europe etc., but it seems all articles are individual creations.
You cannot even copy e.g. Nigeria to Asmara and expect it to resolve magically.
When asked how to list all values from WD, people were encouraged to pick and choose which values to use instead of just listing them. This makes it even harder to quickly create many articles.
There is no copy & paste between articles. It's not just that things will not work when you copy them, you actually cannot copy.
There is no easy copy & paste inside an article. Spreadsheets allow selecting fragments and copying them for reuse. Instead, you have to use menus, which again makes things very slow and tedious.
Source editing is really visual editing. I thought I just didn't know how to switch, but there seems to be no code editor, which would at least allow copy & paste.
Diffs are not readable. It's just a lot of Z12345, which is obviously not good (see e.g. [7]). This was already mentioned by stjn, amongst others.
The editor interface is not readable (even though it is visual). It looks like a complicated spreadsheet with Prolog functions.
References are misleading. In terms of Wikipedia, a reference to a different Wikimedia project is not a valid reference (and many WD refs are references to Wikipedia).
Functions that are supposed to be generic are not generic. It surprised me a lot that even the basic X is a(n) [instance of] Y is not generic enough for small languages.
Not shown on the workshop but functions for Introductory paragraphs seem promising. Not easy and only seem to be in English, but it's something.
So at the moment this is not even viable for creating articles for Simple English Wikipedia. This just doesn't seem workable in any way. And I want to stress that I used the Prolog language. I didn't like it, but I was one of the few people in my year who understood it. I look at the current state of Abstract Wikipedia and it looks way more complex than Prolog.
Perhaps a different approach to generating articles would be to have functions defined for specific groups of articles (species, people, cities and villages, countries, etc.). I'm not sure this would work with Wikifunctions alone, though. Perhaps some combination with LLMs could help, even if only for smoothing out the language with a near-zero temperature. Also taking infobox from Commons, which is better then what AW shows now.
I like the overall goal of making a large number of placeholder articles available in many languages. That would be great. Many articles on plwiki were created just to have an interwiki link to enwiki. However, I'm not convinced the current approach of AW can achieve that goal. Nux (talk) 15:55, 30 July 2026 (UTC)Reply
Only a narrow thing: There actually is some copying and pasting in the composition editing interface, which is used on all the Abstract Wikipedia articles as well as in composition implementations on Wikifunctions. This capability was added a few months ago. You have to go into edit mode in the article from which you want to copy, click the three vertical dots next to the part you want to copy, and select "Copy to clipboard". Then you can edit the article to which you want to copy, click three vertical dots, and select "Paste from clipboard". It mostly works as you would expect, although it provides relatively little help with actually creating the article. (Also, while copying is sometimes needed of course, it would be smarter if instead of copying, there were more functions with parameters that encapsulate logic instead of forking it.) Amir E. Aharoni (talk) 16:39, 30 July 2026 (UTC)Reply
Yes, that was demonstrated in the workshop. That vertical dots is what I meant by using menus: Instead, you have to use menus, which again makes things very slow and tedious.Nux (talk) 23:48, 30 July 2026 (UTC)Reply
References are misleading. In terms of Wikipedia, a reference to a different Wikimedia project is not a valid reference (and many WD refs are references to Wikipedia). If you could point me to an example, I believe it would be easy to filter those out. The problem I'm seeing with citations currently is that many are just links to the relevant statement on Wikidata instead of pulling from that statement's reference(s). YoshiRulz (talk) 20:52, 30 July 2026 (UTC)Reply
More generally, Abstract Wikipedia references are not much more than popups with hyperlinks. They aren't even formatted as footnotes, so they aren't visible in print, and at least theoretically, abstract articles can be printed.
References in Wikipedia are sophisticated systems that check argument validity, link to various identifiers, format the titles and the names, show relevant and readable error messages, etc. Abstract Wikipedia isn't even close to that.
Of course, the footnote display and printing issue can be fixed. And more broadly, it took Wikipedia's references a few years to develop into the sophisticated and iconic system that they are today, and it required coding by volunteer and paid engineers in core MediaWiki and several extensions, as well as years of templates and modules work by wiki editors. So it may be legitimate to give Abstract Wikipedia a few years to develop its own good references system. This, however, begs the question: If Wikipedia's references work, why develop something new from scratch in a completely different language (probably Composition and maybe Python and JS instead of PHP, wikitext, and Lua) and with a completely different formatting system (Wikifunctions HTML fragments instead of wikitext)? What advantage do Abstract Wikipedia's references have—or may potentially have—that the current references don't? Amir E. Aharoni (talk) 22:03, 30 July 2026 (UTC)Reply
Links in AW refs are to Wikidata, and Wikidata can contain references like this [8], [9]... and probably almost everything that links to P143: imported from Wikimedia project. I would expect there to be a lot of usages of P143 and more in the future, because I know at least one WD gadget that adds refs like that. I don't know about small wikis, but that quality of references is one of the major reasons plwiki is not using Wikidata even in infoboxes. Personally, I would use Wikidata more, but that is plwiki community ruling in many cases.
Anyway that part might be saved by at least not using P143 refs... But then you would have a lot of information without sources on AW. Adding a ref manually with wikitext would work, but refs are not structural and some parts of refs require translation and localisation. Nux (talk) 00:10, 31 July 2026 (UTC)Reply
The references you're most likely seeing are likely the ones I constructed for f:Z36218 so that it would show where it got the data from. @Amire80 these ones only have bare hyperlinks, because that's what I coded, it's not a fundamental constraint. (I don't know the answers your detailed questions, but I don't feel fundamentally constrained by the HTML choice so far.) @Nux we can already retrieve the WD statement reference (Which as you say is often currently P143, a WD problem, not "ours".), but I haven't written a general ref formatter yet. Here is a recent example of a specified-by-editor reference that can translate and localise abstract:Q137785666. Nothing amazing yet, but we've only been building AW displays for about 4 months. --99of9 (talk) 11:11, 31 July 2026 (UTC)Reply
@99of9 AW is working with WD to create articles. Every problem in WD is AW problem. Again, I know now plwiki community would not accept AW articles with refs like that and would not accept articles without refs (we actually voted on more strict rules for refs). Young communities or small wikis might be more permissive, I know plwiki used to be more permissive when I started in 2005 when many articles where created as stubs (one paragraph articles)... But we created stubs because it was easy. UX of AW is really bad even for dev like me. Some things in AW are (or seems to be) just fundamentally not practical. Nux (talk) 11:19, 31 July 2026 (UTC)Reply
I'm not sure what "detailed" questions are you referring to. I'm asking about a specific thing: What is the justification for reimplementing references in Wikifunctions when there's already a fairly well-functioning stack that implements references in Wikipedia? This stack consists of the Cite extension, the Visual Editor components for it, the Citoid service, the local custom Citoid configurations in several languages, the multiple modules and templates that implement footnote formatting in several languages, some bots and tools that process them (such as IABot), and several other components. All of them were developed because they addressed real needs of real editors. All of them will have to be rewritten for Abstract Wikipedia, because Abstract Wikipedia does not support wikitext, templates, modules, Cite, Citoid, etc. What is the justification for this rewriting? Will the Wikimedia sites' editors get better references as a result? Amir E. Aharoni (talk) 12:03, 31 July 2026 (UTC)Reply
I don't think rewriting all those Wikitext-based citation tools to work with compositions/ZObjects is one of the project's goals. The citations should be stored in Wikidata as structured data, then formatted using the same few functions (analogous to templates) which can each be translated. YoshiRulz (talk) 18:02, 31 July 2026 (UTC)Reply
Well, that's the problem, though: functions aren't analogous to templates. Templates and modules support wikitext, and functions don't, so they can't provide the same functionality, at least not without a lot of work. And the question is what is this good for. Maybe it's good for something, but I don't see it. Amir E. Aharoni (talk) 18:57, 31 July 2026 (UTC)Reply
@Nux I agree with most of your feature requests. We have filed phabricator tasks for many of them in the four months since the AW interface has been released (most of your requests are AW focused, as opposed to being issues underlying WF). If you want to have a say in which ones were most frustrating for you, there's a survey about similar issues at f:Wikifunctions:Wikimania_2026_survey. Can you also say more about the issue you found with "X is a(n) [instance of] Y" not being generic enough for small languages? I'm not sure I've come across that yet. This kind of issue has happened before, causing us to deprecate, split or focus an NLG function. It's not ruinous, but you've found an issue in a reasonably common function, so it would be worth looking at. --99of9 (talk) 08:33, 1 August 2026 (UTC)Reply
@99of9 thanks for the info. That thing about X is Y was mentioned by JDForrester in the workshop. As I understand this the concept might not be translatable to all languages... but perhaps that was just a figure of speech (maybe he just wanted to say languages are complicated). You might need to ask him. Nux (talk) 11:34, 1 August 2026 (UTC)Reply
For an example of a very widely-used language that doesn't have the concept of "X is Y", try Spanish. You can express "X is an essential attribute of Y" ("soy wikipedista") or "X is an incidental aspect of Y" ("estoy aquí"), but there's no generic "is" relation. And you can't programmatically select between the two, because there are situations where both are correct, but with different meanings. Carnildo (talk) 22:53, 3 August 2026 (UTC)Reply
AW doesn't have a generic "X is Y". The function discussed is specifically the "instance of" meaning, which IIRC would only use ser and never estar except with intentional rhetoric. Aaron Liu (talk) 14:49, 6 August 2026 (UTC)Reply
Instance-of "is" is uniformly "ser", but has-attribute "is" can be variously "ser", "estar", "tener", or occasionally some other verb such as "sentirse". Carnildo (talk) 22:18, 6 August 2026 (UTC)Reply
I was going to say Wikifunctions doesn't have an has-attribute function, but it has "specific property of subject is value", so fair enough. Aaron Liu (talk) 17:11, 7 August 2026 (UTC)Reply
English happens to be very easy with these sentences: subject + is / are + predicate. You can think of it as a privilege that English has. I once presented a talk about this.
Other languages are much more complicated. In some of them, the copula verb changes by the gender of the subject. In some of them, articles are needed before or after the subject or the predicate, and the articles may also change according to the gender or the sounds of the word. In some of them, the subject and the predicate themselves may change morphologically. These are just the most basic examples of complications that I can think of from a few languages that I know well, and other languages have more complications.
All of it is probably fixable, but requires a lot of effort for each language, much more than for English. It's daunting for me to even start thinking about implementing a function that does this. Amir E. Aharoni (talk) 17:33, 1 August 2026 (UTC)Reply
In some languages you also need to consider the context in discourse. For example in Betawi, you could say "X entu Y" at the beginning of a topic, but always "X nih/tuh/tèh Y" if X is already mentioned, or "X mah/sih Y" if it introduces a new or contrastive information (cf. also Sundanese mah, téh, and téa). — swarabakti💬04:49, 2 August 2026 (UTC)Reply
You could theoretically use generic "X entu Y" all the time but this would be extremely unnatural (it's as if writing one-sentence paragraphs every time). — swarabakti💬04:50, 2 August 2026 (UTC)Reply
That's an amazing example, thank you.
Frankly, some abstract articles in English say "X is A. X is B. X is C. X is D. X is E."... and that's not very natural in English either, even if it's kind of grammatical. The reasons for it are different, but the result is similar. Amir E. Aharoni (talk) 05:47, 2 August 2026 (UTC)Reply
As Amir suggests, this is also unnatural and something we want to change in English. A few different approaches are being tried. My personal expectation is that we will have a generation of functions where we are asked to feed in the "context" of the fragment (for example: "is this QID the subject of the page?", "has this QID been mentioned (and linked) already?" and similar). One tiny prototype of this has started showing up in f:Z38488 with a parameter "entity repeated?" causing a switch to a pronoun in English. You can see an example of how that plays out in abstract:Q2409 (not an amazing article overall, but just to show the idea). Other more sophisticated approaches may work even better, but need to be developed and tested first. --99of9 (talk) 03:02, 3 August 2026 (UTC)Reply
Thanks, yes, if this is what JDForrester was referring to, then this is understood and addressable. <X P31 Y> is still a well-defined concept in those languages, so we can keep the abstract structure of the function. But the actual configuration into different languages is more complex. I agree that English often gets away with being "simple". I had a go at a French function with gendered articles, inheriting the gender of the object to the subject, and elision based on pronunciation of "h". It was certainly harder, and I understand your apprehension. Some languages will certainly take more time and expertise than others to set up. 99of9 (talk) 02:52, 3 August 2026 (UTC)Reply
Latest comment: 1 day ago5 comments3 people in discussion
I would make the following observations.
1. Abstract Wikipedia content, as distributed, is simply HTML (or, in future, any other agreed presentation format); the distribution mechanism is independent of how that output is produced (so it could, for example, be generated by a bot or with AI assistance).
2. Abstract Wikipedia is a repository of language-neutral encyclopaedic content representing the current editorial consensus of its contributors.
3. At present, Wikifunctions is the only technical mechanism through which that consensus can be expressed and rendered.
4. Alternative mechanisms for expressing, refining and rendering that consensus are matters for an eventual Abstract Wikipedia community to explore, as resources and priorities permit.
5. The Abstract Wikipedia community will naturally be driven by the needs of participating language communities, particularly those seeking reusable encyclopaedic content to complement their local editorial workflows.
6. Participation in Wikifunctions is therefore a natural consequence of Abstract Wikipedia’s current implementation, whether through direct function development or by articulating editorial requirements.
7. The longer-term justification for Abstract Wikipedia depends not on the elegance of its internal architecture but on whether language editions find its content sufficiently useful to integrate into their editorial processes. In practice, that depends on reliable technical integration.
It is not clear to me that cancelling the planned rollout would, in itself, represent a material cost saving. What it would do, however, is eliminate the opportunity to assess the practical usefulness of the current implementation in delivering editorial content to the language communities it is intended to serve. Without that opportunity, it is difficult to judge either the viability of the current technical approach or the nature and composition of an eventual Abstract Wikipedia community. I therefore Oppose pausing the rollout. GrounderUK (talk) 13:06, 4 August 2026 (UTC)Reply
Untold millions of dollars have been already spent developing this clumsy and broken pie in the sky project, so stopping it would undoubtedly allow material cost savings. stjn[ru]10:59, 8 August 2026 (UTC)Reply
Whatever has been spent cannot be recovered. Any future spending needs to be justified. My point is quite specifically that cancelling the rollout does not in itself represent a material cost saving for the Foundation. GrounderUK (talk) 15:00, 8 August 2026 (UTC)Reply
Not in the real world. No one is paid any less, so the putative saving can only be assessed as an opportunity cost. In practice, it is unlikely to be material either way. GrounderUK (talk) 09:26, 9 August 2026 (UTC)Reply
Communities of contributors to "smaller" languages
Latest comment: 4 hours ago7 comments5 people in discussion
Not expressing an opinion about the RFC questions, just making a meta-observation.
Some commenters in this RFC wrote that most of the people who participate in this discussion are editors in wikis in the "bigger" languages, whereas editors of "smaller" languages are barely heard, even though they are one of the primary target audiences of Abstract Wikipedia.
This is definitely a problem, but not for totally obvious reasons. One way to interpret this is that some "big" language editors who support closure are trying to deprive "small" languages of a useful tool. I cannot get into anyone's mind, but I'd venture to guess that this is really not the intention of anyone who wants to close this project. And even if it was true, it still wouldn't be the important question.
A somewhat more important question is whether contributors to "small" languages are willing to get the abstract articles. There actually is an answer to this, more or less: The staff reaches out to them and some reply positively. It's good, right?
Well, not really, because this is not the most important question either.
The two most important questions are different, and they go together:
Are any editors in "small" languages willing to contribute their time effort into writing functions that process words and grammar rules in their language and generate text in them?
If there are editors who are willing to do that, can they actually learn the current toolkit of Wikifunctions, implementations, tests, compositions, lexemes, etc., and do they actually use it? Do they feel that this toolkit is good enough for them? Can they accomplish actual tasks using it? Not just disparate functions that output a date in that language or convert a verb to an imperative, but functions that generate whole abstract articles?
They, the "small" language editors have to do it. People who know only English, German, or French cannot do it for them. At most, they can help them formulate those rules as algorithms and work with the speakers of smaller languages to write them as functions, but even this is not scalable in the long term: they will have to do it themselves, and they will have to curate the content of the abstract articles even after the infrastructure starts working.
I'm not saying that this is not possible. Maybe it is. I'm saying that the way to involve those editors in this discussion is to ask those questions and to get convincing answers.
Why aren't they participating in the RFC now? I don't know. Maybe they just didn't hear about the RFC. Maybe some of them know about it, but feel that the discussion is too technical. If that's the case, it's probably a bad sign: I might be wrong, but if they can't participate in this discussion, they probably won't be able to write functions, so their answer to both of my questions would probably be "No". Correct me if my logic is faulty.
People who support this project will have to reach out to editors of smaller projects and get their answers to those questions. (Hint: posting a link to the RFC to the "village pump" of a low-activity wiki doesn't guarantee that editors in that language will know about the RFC.) Amir E. Aharoni (talk) 17:06, 5 August 2026 (UTC)Reply
Hello, I'm from the Belarusian Wikipedia, a small project for which AW is being developed. I think that the abstract Wikipedia currently looks like an experiment in NLG. The Belarusian Wikipedia has few technical resources, and maintaining even our own templates and modules is difficult. Writing wikifunctions for AW in our language would be unrealistic. Many of Belarusian Wikipedia contributors are already using templates based on Wikidata, without much concern for the quality of the results. Using AW will only exacerbate this.
At the same time, cross-language content could theoretically be useful for my language as an extension of Wikidata. It would be great to have cross-language templates, modules, and a category system. I think AW has set itself a difficult task, although it would be better to start with simpler tasks, monitoring their success in smaller languages to understand when to stop. The Belarusian Wikipedia currently contains many short articles with information from Wikidata (taxa, populated places, astronomical objects, athletes), which could be replaced with content from AW. For example, be:Алікуківі (village in Estonia), be-tarask:Фабіё Канавара (football player). This provides the current football club roster from Wikidata — the information is language-independent and could be stored in AW. It would be great if the development of AW focused on solving such specific questions, rather than NLG.--Artsiom91 (talk) 05:40, 8 August 2026 (UTC)Reply
"Intro for species" assumes that hypernyms for species are consistent across languages. They aren't: for example, "big cat" is a generally Western classification; in other cultures, the smallest grouping that contains all five members of Panthera might be the felines, the carnivores, predators in general, or even "animals".
The same problem affects Wikidata. Years ago, I very naïvely hoped that Wikidata would get people to collaborate across languages and organize articles about species in a way that balances local cultures and languages with the universal scientific taxonomy. As much as I generally love Wikidata, I have to admit that this doesn't seem to have happened, at least not completely. I still keep running into Wikipedia articles about animals as famous as elephants, whales, and badgers that have messy interlanguage links because of inconsistent naming in different languages. If I knew more about biology, perhaps I'd try to get more involved in fixing it, but unfortunately I don't.
That is to say, if Wikidata hasn't helped fix this problem, I doubt that Abstracts Wikipedia will, because it is much more complicated than Wikidata. Amir E. Aharoni (talk) 23:07, 10 August 2026 (UTC)Reply
WMF really seems to take this into consideration /s
Latest comment: 1 hour ago39 comments14 people in discussion
Something like this new section] started by the WMF makes it really obvious how much they care about whatever is said about their pet project. Chances of the WMF voluntarily agree to even a pause seems to be close to zero. Chances of the WMF taking any of the major concerns serious is equally small.
To give an idea of how completely blind they rush into things just to meet some arbitrary deadlines and be able to report another "success" in the WMF communications, we have for example a list of Abstract articles available in Dagbanli (one of the three proposed pilot languages): [10]. Great, let's click on "Jupiter":
"This language is not supported yet.
The language "Dagbani" has not yet been included in the list of languages for which Abstract Wikipedia articles are generated. See list of enabled languages"
I shouldn't have picked Dagbanli? Well, it's one of the languages they suggest when I pick e.g. Dutch[11] "Er zijn nog geen Abstract Articles beschikbaar in het Nederlands. Ze zijn ook beschikbaar in andere talen: English, français, Deutsch, español, português, dagbanli, മലയാളം, Igbo en Hausa." Which is incorrect Dutch, but is simply false. It's not just Dagbanli, I get the same "not yet included" message when I pick one of the 5 articles for Portuguese...
Ah, but French works, hurrah! First article (suggested by them, not deliberately picked by me), Douglas Adams:
"Douglas Adams (11 mars 1952 – 11 mai 2001) was an Englishman auteur ou autrice, auteur comique, and scénariste. Douglas Adams est l'autrice de Le Guide du voyageur galactique."
Yep, this is so so ready to roll out to actual live Wikipedias, it sure won't give laughable results.
Want another one? Perhaps the second suggestion, Jupiter?
"Content unavailable ⤒ grand { planète ∩ système solaire } = Jupiter.🔧 Jupiter est une géante gazeuse."
Third one? London?
"Le Londres est la capitale du Royaume-Uni. ⤒ grand { ville ∩ Royaume-Uni } = Londres.🔧 ⤒ peuplé { ville ∩ Royaume-Uni } = Londres.🔧 Londres est sur le Tamise"
Other available languages are equally bad, "Wikipedia ist eine Enzyklopädie. Wikipedia exists in 362 languages. It is named after Wiki and Enzyklopädie."
Again, these are the languages they have declared to be available, with the articles they have declared to be ready, in a proposal launched by the WMF to put these on live Wikipedias. If they had checked these like I just did, they would have probably been embarassed enough not to suggest "building up to the first pilot release of cross-wiki abstract articles" in general, and certainly not with these articles.
Why they would post such a tone deaf thing at a time the whole project is already in jeopardy is beyond me. All it does is show why this RfC is needed, and why the WMF should start testing things, be critical for themselves, and open to criticism from others, instead of just posting shiny happy nonsense. Fram (talk) 13:09, 7 August 2026 (UTC)Reply
I am a bit lost. What is it that you find really disappointing? To ask the community which topics might make for good pilot articles? --15:17, 7 August 2026 (UTC) DVrandecic (WMF) (talk) 15:17, 7 August 2026 (UTC)Reply
Can't speak for Qcne, but for me:
To pretend as of this whole page and the rather clear call to pause this isn't happening
To point to a page which is in many aspects terrible, without either realising or acknowledging this, as if it is useful to point to it when
The languages of the supposed pilots aren't even supported (although they are claimed to be)
The (only) 5 example articles all give terrible results in the few languages which supposedly are supported
Why would anyone think it appropriate to talk about starting the pilot when confronted with this? Did Jdforrester never look at the actual articles on that page, or doesn't he care. And did you read the post I made about it and don't care either, or did you just ignore it completely? It's almost as if the corporate speak which has brought the board and the WMF upper echelons into disrepute is obligatory at other levels as well. Fram (talk) 15:56, 7 August 2026 (UTC)Reply
Hi @DVrandecic (WMF). No, obviously not. What's disappointing is that while the RfC is asking the WMF to pause rollout until basic quality criteria and independent review exist, the team is continuing to build towards a crosswiki pilot and presenting five example articles to demonstrate the system without actually testing whether these articles work?
If these arent considered go-to demonstration example articles, then fine, but then why are they being presented as demonstrators for a pilot release?
To be honest I don't think we are ready to start adding new articles at full speed. Only a few functions can be used properly, and not many functions can be used in enough other languages. Furthermore the performance is so bad that most of the functions will time-out. Personally i consider the AW articles as sandboxes to experiment on, not yet articles that are well constructed.
This was exactly my concern behind the RfC in the first place. Deployment planning appears to be running ahead of establishing whether the output meets any actual defined quality threshold. What criteria will an article and language actually have to meet before it is made available in the pilot? Because the ones exampled clearly don't have any? qcne(talk)15:57, 7 August 2026 (UTC)Reply
May I rephrase to see if I understand the implied request here and as described in the proposal to pause the rollout: instead of allowing a small autonomous language Wikipedia community to decide autonomously whether they want to integrate an article from Abstract Wikipedia, an "independent review", probably composed by contributors from larger Wikipedias, has to decide whether the small language Wikipedia communities are allowed to do so and if the article is good enough in the language of the small Wikipedia, because the small language communities must not be trusted to make this decision themselves autonomously? --DVrandecic (WMF) (talk) 08:27, 8 August 2026 (UTC)Reply
No, you may not rephrase because that is not at all what the RfC proposes. It is frustratingly innacurate.
Nobody is proposing that editors from large Wikis decide whether a smaller Wiki is "allowed" to use Abstract content.
The RfC Proposal: that the Foundation actually establishes that the system meets some basic published technical, linguistic, quality criteria with linked success/failure criteria; and that each local community decides whether it actually wants to use it through their "local processes".
So, independent assessment of whether the system works, and local autonomy over whether to adopt it. I also note that that part of the proposal ("Transparency") has substantial support from editors across a wide range of Wiki projects. qcne(talk)08:44, 8 August 2026 (UTC)Reply
Given this answer, I actually don't think we are this far apart.
Do you think that the local communities would decide to integrate articles that don't meet linguistic quality criteria? I would hope not. So I entirely agree that the local communities should decide, based on their local processes.
I don't know about the "Foundation establishing that the system meets some basic published technical, linguistic, quality criteria" -- I don't understand what that means, and why this is necessary, instead of simply leaving it to the local communities to make this decision. --DVrandecic (WMF) (talk) 17:54, 8 August 2026 (UTC)Reply
I have tried to explain this repeatedly to you. The WMF is developing and proposing deployment of the system, so the burden is on the WMF to demonstrate beforehand that it meets some minimum published standard of technical reliability, factual accuracy, and linguistic quality. I don't know how else to explain this. Currently it seems that every small Wiki is effectively being asked to perform the project's QA for itself, including discovering systemic problems which may have nothing to do with that community. I hope you agree that is not a good burden to put on small communities.
Local communities should decide whether the content is good enough for their Wiki. But they should be making that decision about a system whose basic capabilities and limitations have already been established, not being used to establish them.
And this brings me back to my original question: what criteria will an article and language actually have to meet before you make them available in the pilot? qcne(talk)18:28, 8 August 2026 (UTC)Reply
I believe factual accuracy and linguistic quality are the responsibility of the contributors to Abstract Wikipedia, Wikifunctions and Wikidata. GrounderUK (talk) 19:50, 8 August 2026 (UTC)Reply
Agreeing with Qcne here: Abstract Wikipedia needs quality control. Your proposition suggests that the larger language-Wikipedia communities regulate the smaller ones. This would only bring quality control to the smaller communities. We need quality control for all the language-Wikipedia communities.
So think how efficient it would be if that quality control happened higher up, within Abstract Wikipedia itself. This would save all Wikipedia volunteer communities from having to do for you the extensive quality control that is needed. You cannot take a problem that you don’t know how to solve because you didn’t think this all the way through first, a problem that is quite arguably your responsibility as the dev team to solve, and impose the long and tedious solving of that problem on all language-Wikipedia volunteer communities instead.
You are Abstract Wikipedia’s developers. Develop it.
This seems like an actively malicious way to phrase what qcne is arguing.
To turn it around: The Abstract team is proposing for a small wiki to act as pilot users. they have proposed a number of articles to test. At the same time they seem to have spent no time on actually making sure that these proposed articles lead to any result at all that is even worth commenting on. So to me it seems just disrespectful towards the time of the small wiki editors to ask them to review a process that doesn't work at all. They're just going to tell you that it was not helpful and the articles are not useful.
Yeah, what the previous two replies said. You have basically ignored everything that has been said, every issue that has been pointed out, every very basic problem, because "think of the children"! It's insulting to the small language Wikipedias and to all other people who took the time to actually look at the project, the results, and the building blocks used to get to those results. "the small language communities must not be trusted to make this decision themselves autonomously?" Don't you mean "the small language communities must not be trusted to make this decision with imput from anyone else than the WMF?" It's not the small language wikis I don't trust (although, one of the issues the WMF has completely failed to answer is how you will avoid a new Scots or Greenlandic scenari), it's (based on everything we have seen so far, and the replies in this very thread) the WMF I don't trust. Disingenious replies (by you, by Forrester, ...) are unlikely to sway anyone and only strengthen the concerns. If you won't address these many concerns, then it sure looks as if you can't address them. Fram (talk) 11:36, 8 August 2026 (UTC)Reply
I have asked, I think repeatedly, where a good place to discuss the existing, substantial criticism is. A meta RFC regarding the closure of the project does not seem like a place where a constructive discussion of the project can happen. If I missed a suggestion for such a place, I ask for forgiveness, this discussion has been rather large and meandering. I recognize that there are some valid questions raised, and I would like to answer and discuss these. --DVrandecic (WMF) (talk) 17:57, 8 August 2026 (UTC)Reply
So you first try to completely dismiss this (right above), and when that predictably fails completely, you go back to claiming that you really are wanting to discuss the "some valid questions" that have been raised, but we just don´t give you a location to do so. Really sounds like you take this as serious as Forrester does. Does anyone at the WMF actually really care about this at all? Fram (talk) 18:45, 8 August 2026 (UTC)Reply
We can collect unanswered questions for you under #Developer comment if you don't have the time or patience to re-read everyone's comments. I will say I have also found your selective pattern of replying to be frustrating. If there's a question about finances you can't answer or something, then at least say you can't answer. YoshiRulz (talk) 19:02, 9 August 2026 (UTC)Reply
@DVrandecic (WMF), you say: A meta RFC regarding the closure of the project does not seem like a place where a constructive discussion of the project can happen.
Why not, actually?
Deletion discussion on Wikipedia quite often end in keeping the page whose deletion was proposed if people bring up good arguments against deletion, even though it always begins from someone's proposition that it should be deleted.
Both the people who want to pause the integration and the people who want to move forward with it really amuse me. Both sides are counting chickens before they're hatched because there aren't any articles to integrate anyway.
Surely no one wants to integrate an article that just says "An apple is a fruit." into any wikis, right? Right?
An article like Australia would be not bad to integrate, but it doesn't work in any of the target languages, and no one is going to integrate it before it does, right?
It's not a chicken-and-egg problem because good fully translated abstract articles can be first developed on Abstract Wikipedia and then integrated into the local Wikipedias.
In case it isn't clear, I actually hope that the Abstract Wikipedia don't chicken out, and do try to run this integration experiment despite this RFC, in which many people express their skepticism about it. I just suspect that there will be no good articles to integrate, and if that will be the case, then no damage will be done to the Wikipedias in those languages, but it will raise even bigger questions about Abstract Wikipedia's viability.
In the less-likely case that there will be good and fully translated articles to integrate, then it's even cooler, but as I wrote in another comment, the whole point is that there should be more than one such article, and that the editors in those languages would be able to do it themselves and not with the help of grants, AW developers, "partners" (whatever that means), Wikimedia Germany, etc. If it's just one article written with a lot of external help, then it's not really useful. Amir E. Aharoni (talk) 20:05, 8 August 2026 (UTC)Reply
I think it is, for the reasons I hope I articulated at #Developing the Abstract Wikipedia community. Until there is working integration through to a local Wikipedia, there really is very little incentive for its contributors to devote their precious time to improving either their language’s functions or Abstract Wikipedia content (or even the lexicographic data on Wikidata). Yes, it’s a challenging infrastructure to work with (including Wikidata and Wikifunctions here), but until we have real contributors trying to deliver for their communities, it’s hard to guess what improvements would add most value (and that applies especially to the community-developed functions on Wikifunctions, which is where the NLG capabilities will reside, at least initially). GrounderUK (talk) 20:37, 8 August 2026 (UTC)Reply
One question I have is why are we starting with small language wikis where we would be trying to find people to work on Abstract Wikipedia from an already tiny userbase as opposed to starting from already active wiki communities (e.g. English, French, Italian, Polish, Japanese) which have a large community and where you are more likely to find people who are both willing and able to work on this and build something that works before then propagating that out to smaller wikis? Giuliotf (talk) 13:39, 10 August 2026 (UTC)Reply
I suspect the real reason is something along the lines of "to provide a show for the donors", but there's a practical reason to avoid most of the larger languages, and especially English: you're likely to get monolingual speakers baking Germanic and Italic grammatical assumptions and Western cultural assumptions into the foundational functions.
(We're seeing that already, with things like sentence-generation functions that assume English rules about the use of definite/indefinite articles -- and then get those rules wrong.) Carnildo (talk) 23:21, 10 August 2026 (UTC)Reply
The whole "article-ful" vs. "article-less" thing was misunderstood: Those are (or were) the English labels for those functions because that's a simple way to explain the difference to English speakers. The actual semantic distinction is whether or not the subject Item is a 'class' (has a subclass of (P279) statement). And as I've already explained to you, the use of definite articles is handled per-language, by using heuristics which approximate "correct"/fluent usage. YoshiRulz (talk) 23:48, 10 August 2026 (UTC)Reply
Z32965 and Z32962 are hardly the only functions that generate text with articles -- or to use the wrong ones.
(And if the difference between those two functions is simply the presence or absence of a (potential) P279 statement, that needs to be documented somewhere.) Carnildo (talk) 01:49, 11 August 2026 (UTC)Reply
@DVrandecic (WMF): So let me ask you something in a similar fashion you just used. If there is one or two people in a smaller language community that would help you burn even more money on a clearly futile venture, while, judging by the announcements you post, also enriching themselves at least a little bit through grants funding (how come you don't want them to develop these functions for free? maybe because it's completely useless?), we are supposed to ignore the fundamental issues with the project that make it almost impossible to do anything useful at scale? stjn[ru]14:09, 8 August 2026 (UTC)Reply
My reading is that the initial pilot would be limited to between eight and ten articles on one local Wikipedia edition. There is no suggestion that the articles are currently ready or that the initial pilot is imminent. GrounderUK (talk) 13:53, 7 August 2026 (UTC)Reply
Perhaps, but "To demonstrate the system at all, we picked five general topics: Paris and London, Wikipedia, and our commonly-used "example" topics of Douglas Adams and Jupiter. (You can see the available list at Special:PreviewAbstract.)" How out-of-touch do you have to be to link to that page and those articles as pages to "demonstrate the system", or to set up a SpecialPage with "Abstract Articles available in français" (and other languages)? The post was "We're building up to the first pilot release of cross-wiki abstract articles", not: "hi, people actually working on this, any idea what timeframe would be possible to have any articles available for a first pilot release?" It's just another example of the "we don't test anything (but pretend otherwise), we don't acknowledge issues, we just declare victory" attitude. Fram (talk) 14:01, 7 August 2026 (UTC)Reply
I don’t hear any declarations of victory. No doubt it suits the developers to start with an extremely limited pilot rollout, and it should certainly be something of a relief to the small community of volunteers who will have to provide both the abstract content and the functions that turn it into actual content for the target languages. That having been said, I don’t think it would have been difficult to find a volunteer to compose the appropriate request. GrounderUK (talk) 14:39, 7 August 2026 (UTC)Reply
The plan is to have these target articles in live Wikipedias before the end of September. That's what they are "building up to", and for which apparently there are no blockers, just need to pick the best of the crop. Owner of this Key Result is James Forrester. Their post isn't some empty "hey, how are things going" post, it's a direct step to roll this out, by someone who has either never looked at the actual articles, or has looked but doesn't care as long as he meets his deadline. As if everything is working fine, just like we see time and time again in the weekly newsletters about Abstract, or comments made by others. See also the non-answer by Danny above, as if the post by Forrester and the replies here were simply about "To ask the community which topics might make for good pilot articles?" and not about an actual planned rollout, supported by posting to dreadful articles. Fram (talk) 16:03, 7 August 2026 (UTC)Reply
The "Key result" is described as "By the end of Q1, ensure that fragment rendering performance of the integration into Wikipedias is maintained without regression as deployment expands from the first demonstration into the initial target language Wikipedias, so that the system remains responsive and welcoming to editors as they draft changes.". I have, by the way, no idea why Bangla, a major language and a large Wikipedia, is among the three target Wikipedias, as that kind of language version was never the intended purpose of Abstract Wikipedia. I also have no idea why they plan on putting "articles" into Wikipedias when this is not what they are doing: what they show in those Wikipedia's can not be edited onwiki, as it is not in Wikitext, so can not be fully integrated (e.g. no categories as of now) and not be further maintained locally: an Abstract article either stays an abstract article, maintained on Abstract + Wikifunctions + Wikidata, or needs to be completely redone from scratch in the target Wikipedia if you want an actual local version.
I don't think anyone has worked out how they will assure that if someone from language X changes a function to make it better for their language, that all the other languages who have the same Abstract article will still work. There is no guarantee that a function or Abstract article changed to make it better in e.g. Dangla, won't cause errors or worse articles in Hausa, and vice versa.
As an example, let's say the article "Paris" (one of the 5 demo articles, the one shown at Wikimania, so again not an attempt by me to pick the worst one) is used in 5 language versions. Now, it has the sentence "Paris is named after Parisii." Oh, this should "Paris is named after the Parisii". I'll change the function (or write a new one?) for this. I test it, okay, the English now is correct. Is the Abstract Article "Paris" in those 5 languages where it is shown still working? Do we get an error? Do we get no error but a grammatical mistake? I don't know, no one does. Just one tiny example of the countless issues with this approach, which should perhaps be solved before even a beta rollout? Fram (talk) 16:19, 7 August 2026 (UTC)Reply
Abstract Wikipedia seems to be heading in the direction of high-level monolingual functions wrapped by language selectors ("person lead sentence with occupations, English" wrapped by "select function based on language") rather than low-level multilingual functions ("X is instance of Y"). This eliminates the risk of cross-language damage, but comes at the cost of needing to re-implement each function for each supported language. Carnildo (talk) 18:17, 7 August 2026 (UTC)Reply
And the same issie I described remains at the very least when someone expands an article. Adding a new factoid to an Abstract article would require editors from all languages that use this article to check this, or else you get either the nonsense I showed above from the "ready" example articles in French or German, or something which may look good if you don't know the language ("Paris was named after Parisii") but isn't grammatically or otherwise correct anyway. Basically, there is zero guarantee that, even if you have something acceptable today in your language-Abstract copy, it will still be acceptable tomorrow, even with good faith improvements to the base Abstract article. Fram (talk) 11:28, 8 August 2026 (UTC)Reply
@Qcne: Hey there. It is not my place to tell the Board of the Foundation what should or should not be in the annual plan. I look forward to this community process completing and then appropriate decisions being made, of course. Jdforrester (WMF) (talk) 19:46, 7 August 2026 (UTC)Reply
Thanks. I wasn't asking you to tell the Board what should be in the Annual Plan.
You're the named owner of DE2.1, the Key Result under which integration is being expanded into the target Wikis.
I asked you whether you've read this RfC and whether any of the comments raised here are being taken into account.
Given that meta RfCs usually take a while to find a closer, can you confirm you'll follow community norms and not create a fait accompli by starting a rollout? It seems there is consensus in this discussion to halt the rollout. The assessment of whether the community is of the opinion that the project should be closed is something an independent closer should assess, and is more clearly advisory, given that the board decides on the closure of projects at the moment. —Femke 🐦 (talk) 20:53, 7 August 2026 (UTC)Reply
@Jdforrester (WMF), DVrandecic (WMF), and Sannita (WMF): I note Femke's comment and endorse their request for the developers to abide by community norms. I hope we will see a pause while we await closure for this RfC so the WMF can then deliberate on the results before making their decision on the best way to proceed, informed by community feedback. The Anome (talk) 22:28, 7 August 2026 (UTC)Reply
Latest comment: 1 hour ago2 comments2 people in discussion
The examples of broken and nonsensical articles in the background section have each been improved since this RFC was started. Using Abstract's Special:Random indicates there has not been an overall improvement of articles, just on the ones brought to attention by this RFC. Here's a 5-page random sample with their revisions that I was able to get today, 10 August 2026:
"Hakone Shrine is a Shinto shrine in Japan.Hoori is the saijin of Hakone Shrine."
Broken formatting. Article is interesting and has some actual semantic meaning past what a Wikidata item would include, including relational data. Hard to access that data; no Wikipedia or Wiktionary pages in my language for what "saijin" means. I was hoping I might be able to use the Abstract page for saijin but it's broken.
I don't know enough about WMF project planning or computational linguistics to add to the discussion about whether this is fundamentally flawed, but wanted to point out to new readers of this RFC that the examples given in the background may, about a month later, look substantially more complete and well-made than the average Abstract Wikipedia article. Eyesinthefire (talk) 21:08, 10 August 2026 (UTC)Reply
Because fresh cherry-picking is the way to patch up an argument whose cherry-picked foundations fell out from under it. I've fixed the formatting of those 6 articles, and started expanding the chess article. YoshiRulz (talk) 02:18, 11 August 2026 (UTC)Reply
This is a subpage; for more information, see the Requests for comments page.
Support pause and transparency; I 
Oppose closure. Dv103 (talk) 15:46, 14 July 2026 (UTC)
conditionally oppose closure because I see the potential of the projects. But my condition is that the projects prioritize addressing the concerns with defined deadlines, above all else. At minimum, there needs to be a much easier interface to make compositions (probably blockly), the realization of the promise—made as rebuttal to a major point of the Google Fellows critique—that "The ZObject language will not be exposed to the casual contributor. In many (perhaps most) cases, contributors will see labelized versions of ZObjects.", and much easier ways to work with lexemes in connection with Wikidata entries. Unfortunately, that seems unlikely, as the WMF's relevant devs appear either too interested in working on types and details or excessively sluggish to deliver the everyone-friendly tools that the projects acutely need to work on itself. It's been years. We can't move forward atop a house of cards. Aaron Liu (talk) 18:54, 14 July 2026 (UTC)
Weak oppose closure. I think that if this project can work some years down the line it will be a huge win for linguists and Wikipedians alike, but I don't see that happening within the year, so it needs to be paused. Guy Macon said above about a "leakproof box" and I think this is similar to what I think should happen until it can be proven that this project can output useful encyclopedic content. I've attempted making articles myself, and had... limited success. I share a lot of Chaotic Enby's complaints about the project and how writing articles works. That doesn't mean I'm not excited about the concept of this project though. I'm curious to know how much money is still remaining from the grants mentioned above, and how much this project is really costing. A lot of people seem to mention that this is a waste of money, so I'm curious to know how bad it really is. If we really are hemorrhaging money from this I'd support closure, but if we can keep this running on a reasonable budget that'd be fantastic. There is promise here, however idealistic it seems. Feedmepaperr (talk) 03:58, 15 July 2026 (UTC)
Strong oppose Closure: I believe Abstract Wikipedia is currently immature and far from (probably never) replace Wikipedia articles, but have its use case (which maybe very specific in the foreseeable future. (I will explain more later). 
Abstaining from voting on the three proposals for process reasons, but 
Commenting that while it is commendable that the RfC author tries to simplify things by specifying "It is not about Wikifunctions", basically, the two projects are near-inseparable (and share the same origins). If Abstract Wikipedia doesn't work out, WF is deprived of its main natural-language dogfooding platform, and much of its reason for being. If Wikifunctions were to go away for whatever reason, Abstract Wikipedia would be instantly unworkable. — Arlo Barnes (talk) 21:56, 15 July 2026 (UTC)
Weak support pausing rollout to pilot Wikipedias (I would consider ArticlePlaceholder and AutoDesc to be the bar which must be passed, but the communities in question did ask for it); 
Neutral on pausing the rollout because it is a good idea to do it given the current quality of the abstract articles but each community can do that on their own, can't they? Warudo (talk) 20:59, 17 July 2026 (UTC)
Strong support all. Some projects just don't work, and this is one of them. We must have the courage to close down a project that isn’t working, as we did with Wikinews. Even if the project isn't closed or put on hold, transparency is absolutely necessary. --Smaug the Golden (talk - my contributions) 20:16, 28 July 2026 (UTC)
Oppose pausing the rollout. GrounderUK (talk) 13:06, 4 August 2026 (UTC)