Abstract Wikipedia:Response to English Wikipedia criticism
This is a historic page, the content has been frozen and moved to Meta.
The team has drafted a response to the criticism expressed by various users of English Wikipedia towards the Abstract Wikipedia project. We are now opening the draft to you users, to allow you to contribute to it and have your say.
If you want to suggest changes or edits, please use the talk page. Please, keep a polite and constructive tone.
The editing period will be open until July 17. The final result of this editing will be published on Meta, and will be linked to the English Wikipedia community.
A discussion happening on English Wikipedia raised a number of questions and concerns about the Abstract Wikipedia project. We read the discussion and reflected with the team and the wider Wikifunctions and Abstract Wikipedia community on how to respond and what it means for our way forward.
We grouped the feedback into categories of concerns that we are going to address.
Natural language generation feasibility across diverse languages
[edit]The discussion surfaced concerns about whether Abstract Wikipedia can reliably generate natural-language output from abstract representations across languages with very different structures. The concern is not only whether the current examples work, but whether the underlying approach can scale beyond relatively simple sentence patterns and languages that are easier to support.
Our answer to this is yes, the approach can reliably generate natural language output from abstract representations across very different languages. We are not inventing anything new, natural language generation is an established research field. We are particularly inspired by Grammatical Framework, which is available in dozens of languages, but also Apertium is another example for parts of our pipeline. The second question - whether this can scale to our setup and ambition - remains more open. We will test some of the underlying assumptions directly in Fiscal Year 2026–2027, using measurable objectives to assess whether our approach is working.
English-centred design or perception
[edit]Several comments say, or strongly imply, that the system feels English-centred in its function names, examples, documentation, and current outputs. Even though the underlying model is designed and engineered to be semantic and language-independent, contributors may experience it as English-first if the concepts are explained through English grammar or English sentence patterns.
That is currently the case. Wikidata started almost in the same way: English was considered the main language of expression in the community because of the multilingual nature of the project, but with time multilinguality took over and language coverage got better. We expect a similar path for both Wikifunctions and Abstract Wikipedia, when the community will grow to include new people coming from new backgrounds.
Generated article quality
[edit]In the discussion many examples are mentioned where output technically exists but is not considered useful, natural, article-like, or publication-ready. The concern is that successful rendering can still produce text that is grammatically incorrect, repetitive, too thin, misleading, mixed-language, or not recognisable as encyclopedic article content.
This is a concern that we share, but the capabilities of systems such as Grammatical Framework and the development of systems such as Wikidata and frankly Wikipedia, gives us reasons to believe that the results will get better with time, and with the expansion of the community. It is also important to remember that Abstract Wikipedia’s goal is not to match the quality of prose of English Wikipedia, but to produce accurate and useful articles that any language community can use to fill current gaps. The choice will remain within that community. If you're familiar with mw:Extension:ArticlePlaceholder or toolforge:autodesc, our goal is to meet and then surpass their usefulness to readers, while keeping all the logic editable on WF/AW by the community.
We are also very thankful to the nascent Wikifunctions and Abstract Wikipedia communities for all their contributions. They are helping develop a new project and working through difficult questions, such as what to show when language resources are missing, when is fallback behaviour appropriate, and when should outputs simply fail, etc. We would like to ask external critics to be particularly kind and respectful when commenting on the contributions of these volunteers.
Content governance and control
[edit]Related to the last concern, the discussion points to low-quality or mass-created abstract content as a project risk, not only an individual-user problem. The concern is that poor content can quickly shape perception of the project, create cleanup burdens, and make the system look less mature before the model has been properly validated.
While we understand the root of this concern, we can safely say that the existing community on Abstract Wikipedia is already acting on this, by discussing article quality and establishing their own policies. We trust the judgement of the community about finding the right way to address these problems. As the system gets more expressive and articles improve in quality, poor-quality articles will also become easier to spot, as well as potentially correctable with the help of new editing and moderation tools.
Technical performance and stability
[edit]As part of the discussion failures, timeouts, slow rendering, caching problems, and broken navigation are reported. The concern is that, even where the content model might work in principle, the current technical experience is not yet stable or reliable enough for normal wiki use.
This is a very valid concern that the development team shares. We have made big improvements and will continue to address these issues in the Fiscal Year 2026-2027. This is a complex system and while we do not expect to solve everything at once, we continue to make significant progress. Our strategy will be to deploy small changes frequently, so the improvements will be incremental.
Release maturity / beta-readiness expectations
[edit]A question surfaced whether the current state of Abstract Wikipedia matches the expectations created by a public beta release. The concern is not only that there are bugs, but that basic workflows, rendering reliability, documentation, and output quality may feel too immature for the way the project is currently presented.
As with the previous concern, our strategy will be to continue to release often and early, with the goal to improve constantly. We hear you and we will be more careful when it comes to communicating the status of the project to ensure accuracy. We are monitoring progress constantly, and will not announce new milestones before it is time.
Contributor pathway and small-community capacity
[edit]The discussion raises a concern that contributing to Abstract Wikipedia and Wikifunctions is difficult to understand, especially for non-English contributors and smaller language communities. The concern is that the project may depend on communities doing substantial prerequisite work across several systems before they can benefit from the output.
Indeed, there is some work that a language community needs to do and some learning curve to tackle. It is also true that the amount of work that users need to do to reach a result will be significantly lower than creating and maintaining a full-fledged Wikipedia on their own. We are still figuring out how to structure and capture that work. We expect that once the first few languages have walked the path, we will be able to sketch out and plan (more) efficient pathways for the other communities as well, based on the learnings from the pioneering communities. We agree that it is currently difficult to find that pathway, but it’s because we are still discovering it together, and we are working to make sure it will get easier with time.
Dashboard metrics and labelling
[edit]The new dashboard (abstract-data tool) was specifically criticised for using labels that may overstate readiness or count the wrong things as progress. The concern is that dashboard categories may imply that content is closer to publication-readiness than it really is, especially if they are based on technical rendering, missing local articles, or partial outputs rather than linguistic quality, usefulness, or review.
We are listening to this feedback, and we’re reviewing our wording, explicating terms, and toning it down where appropriate. Our objective is to produce content that can be reusable by smaller communities, so it is our shared vision to report and reflect real data about it.
Transparent documentation and progress reporting
[edit]Beyond the dashboard, the discussion raises a concern that project documentation and public reporting do not clearly explain the current scope, status, limitations, roadmap, and actual progress. The concern is that contributors may struggle to understand what currently works, what is still experimental, what is known to be incomplete, and how the project’s public updates relate to the current user experience.
We acknowledge that our documentation is a bit lagging behind, especially on Meta. We were using our Wikifunctions & Abstract Wikipedia newsletter to showcase our new features and improvements, but over time it is clear that it is becoming harder to search and find answers in the text of many (250 and counting) issues. We hear this criticism: we will improve our documentation, aiming to make it more up to date, and easier to navigate.