Talk:Community Wishlist/W78

MinT for reader

FYI WMF Language team are developing a similar feature "MinT for Wiki Readers" that allows readers generate automatic translation (use the MinT service). See also the recent update of this project. SCP-2000 05:02, 1 August 2024 (UTC)

Very interesting, thanks for this info – I'll look further into it but there are many differences. Three of the larger differences to my proposal is that I'm proposing that these sites are not generated dynamically but are available as static and often indexed websites, that errors are correctable and the MT improvable via specifying rules or errors, and that the most advanced machine translation tools are used where I doubt that MinT is nearly as good as DeepL for example but I could be wrong.

Possibly MinT could be used for what is proposed here and I will look into this further and maybe make a talk page post there. Prototyperspective (talk) 11:09, 1 August 2024 (UTC)

Thanks @Prototyperspective for this detailed and documented wish, and to @SCP-2000 for sharing MinT for Readers.
I wanted to share a bit more context on the impact MinT has had: https://diff.wikimedia.org/2023/11/20/unlocking-the-worlds-languages-in-wikipedia-a-look-into-mints-impact-so-far/ and share some feedback from users https://diff.wikimedia.org/2023/11/21/what-users-think-about-the-machine-in-translation-mint-service/
I wanted to flag that our processes align with a lot to what you're suggesting: 1. Leverage existing wiki content to populate a language version of the same content, via Machine translation. 2. Allow editors to "fix" or amend machine translation to ensure the translation is sensible for the local wiki. JWheeler-WMF (talk) 12:22, 2 August 2024 (UTC)

ContentTranslate is more similar, German Wikipedia UI here (not enabled on English Wikipedia). It allows the user to pick an article in a different language, gets a machine translation, translated links (using Wikidata) and sometimes even translated templates too - depending on templatedata.

Wikidata is supposed to tackle the update problem, but in reality, wikipedias do not want to use it. The reason wikipedias will not uses are bad sources. That is a social issue, that the wishlist will not fix, but let´s continue exploring the technical side. Let´s explain further with an example. Let´s say there is a country article, so we want at least a population number and the president. The population number could use the magic word "plural" and the sentance changes using that depending on the number of the population. With the president, some languages require the word "president" to change depending on whether the president is a male or female, which the "gender" parser function handles. MediaWiki translations have been using the "plural" and "gender" parser functions for over a decade without major issues. For example, the message "X has 10 contributions" is actually the same for a user with 1 contribution, just plural changes the word from "contributions" to "contribution".

Since both ContentTranslate and MinT for Readers exists, there is a large overlap, and my opinion is that this wish needs to be slimmed drastically down to what they do not have. Snævar (talk) 03:19, 13 March 2025 (UTC)

MinT Automatic translation including a bug due to templates

Wouldn't say it's more similar. I knew about it when I wrote the first version of this proposal but I didn't know about MinT. While ContentTranslate makes use of machine translation, I think it can't be used for what's proposed here while MinT maybe could be. and sometimes even translated templates too Haven't tried it in a while though and it's great for the one article at a time approach...does it by now also translate templates like mainly citation templates? Wikidata is supposed to tackle the update problem What do you mean and how would Wikidata address/solve it? Let´s say there is a country article, so we want at least a population number and the president. No, not just the lead or some plain data facts – the whole thing. needs to be slimmed drastically down to what they do not have It's about a fundamentally different thing. There is not much to slim down. If you have a question about something I'd love to explain it but this is about something very different than slowly translating a small subset of articles one at a time in isolation and at just one point in time (ContentTranslate) and MinT is kind of early stage so it's hard to tell where there are overlaps but I think what's proposed here would be either most feasible as an continuation/expansion of it or would make use of MinT.

I just tried the beta version of MinT again now and it's looking real interesting (despite of bugs, see screenshot) – yes maybe I should make a separate proposal about some specific things I propose to change about it instead of proposing a system at end-stage holistically (more about a path toward this). For example, a key thing is that articles, once baseline quality is reached, can be found via the Web search and aren't generated dynamically. The former is a huge advantage in itself but both are also needed to enable the postediting fixing/highlighting across articles. In any case, I'll need to refer back to this proposal there too since it only makes much sense when understanding how this Translation system is intended to ultimately function like (section "Post-machine-translation error correction module" is key to this). Note that it's not just errors but also things like specifying that it should not translate "Our World in Data" since that is the name of the organization etc. Prototyperspective (talk) 22:44, 28 March 2025 (UTC)

Keeping translations in sync

In UKWP, I use a respective version of en:Template:Translated page with version and insertversion parameters, specifying a source's and a translation's revisions respectively. I keep a list of articles I've translated in uk:User:Olexa Riznyk/Переклади, and use uk:User:Olexa Riznyk/translations status.js script that represents this list as a sortable table with columns #, Article, Importance, Source language, Translation age in days, Number of days the translation is outdated, Number of source changes since translation, Source size change since translation. I use it to decide when to update translations. When I update a translation, I update version and insertversion as well, of course. Something similar could theoretically be used per category, per project etc. for their respective articles that have en:Template:Translated page on their Talk pages. Meanwhile, using insertversion allows to easily see what changes have been made to a target article after a translation, and this is also valuable, sometimes contributing to updates of a source article. --Olexa Riznyk (talk) 14:40, 2 August 2024 (UTC)

wikitext markup

GPT-4 (in ChatGPT+), with some prompt engineering, deals with wikitext markup pretty well. You could look through edit history of uk:User:Olexa Riznyk/Чернетка/Конструювання підказок, where I was adding a next section translated by GPT-4 as is, and then fixing the translation. I was considering to creat create custom actionse for the GPT to pull interwiki data, but I'm actually pretty happy with it suggesting wikilinks naïvely, as it often suggest missing redirects. But I'm thinking about implementing actions anyway. --Olexa Riznyk (talk) 14:51, 2 August 2024 (UTC)

Whether to store raw machine translations, and when to involve humans

I don't share the fear that some external actor would create a machine-translated Wikipedia. What for, if an online translation is built into modern browsers? I also use the built-in translation in Chrome to read articles in Wikipedia languages I don't know. I cannot imagine that I, as a user, would need a stored raw machine-translated Wikipedia.

I don't know the sutiation in other Wikipedia languages, but in Ukrainian it is pretty common to translate articles from other languages rather than to write them from scratch, at least in domains I am intersted in. Wikipedia is a community project, and it doesn't make sense to stay isolated in own language's community capacity only, not utilizing the capacity of others.

Of course, Wikipedia infrastructure for translating content and for maintaining (updating) translations could be much better. I gave up using Wikimedia's translation infrastructure: it was too glitchy, too inconvenient, it handled wikitext markup terribly, and it didn't learn in context at all (from my corrections of previous sections' translations). I use ChatGPT Plus with some prompt engineerig, and get petter performance. ChatGPT Plus provides a possibility to create actions for getting data from web, like interwiki data (although, I do not use this yet, I'm pretty satisfied with "guessed" wikilinks, they sometimes highligh a lack of some redirects).

As for me, ideally, it would be to have a translation system, based on some generative LLM with RAG for enriching its context with "closest" source-translation pairs from updates of previous article's seciions' translations, as well as from translations of other articles, collected by usage of Template:Translated page, including its version and insertversion properties. This should make updating translations very convenient and pretty robust, as previous translation pair of the same article would be used in LLM's context as well.

Although, there is an additional danger when machine translations becomes "near perfect": that humans will tend to save its output without checking it thoroughly. Some LLMs are capable of outputting their certanties in parts of their output. It would be good for a translation system to provide its human users with these certanties, so that they don't miss important part needing their verification, and so that they would better understand their responsibility for what they accept.

Usage of Template:Translated page with version and insertversion properties (or something like that) creates a possibility for automatic tracking how outdated existing translations are, and how much they need attention to be updated (how big or old out-of-sync source or target changes are). This could be shown per user's watchlist, per category, per wikiproject, whatever.

--Olexa Riznyk (talk) 17:45, 4 August 2024 (UTC)

First of all thanks for your insights above, I don't think I will be able to respond to them but they could be useful for this proposed project to see how you used AI tools for related tasks.

It's not necessarily a fear, it could also be the case that against odds it turns out to be better than if WMF was to be implementing it, e.g. quicker development (e.g. due to larger share of resources being spent on tech development) and maybe it's another open source organization. More likely it would simply be best if Wikimedians in standard ways built this.

• Here's what for: the mention error correction and the findability. People don't search the Web in Norwegian and then notice they don't find what they looked for and turn to the English Wikipedia article and let it get machine translated through some extension they have installed. People don't do that and I don't worry much about things that are hypotheticals of what they could do. The issue starts already with that the starting point is not Wikipedia but a Web search engine and these days the content or answers to their queries finds the searcher, not the other way around. The Wikipedia/MLWP article needs to find the user to which it is relevant.

Moreover, people equate their native language Wikipedia with Wikipedia – if there is a Wikipedia article related to their query but the info they're looking for is not there and/or it is very short/low-quality then people would consider that a case closed for Wikipedia and look for other sources in their language rather than go to some other language WP and let it get dynamically translated.

Furthermore, there are many more advantages beyond the error correction such as including a video or image in the corresponding language rather than the source's article's.

Translating articles often is good and all but have you read the section about "The problems addressed here": they get out of sync as they don't change when the source article changes, it requires a lot of time compared to an adjustable MT system and is not done at scale, and most importantly: Ukrainian Wikipedia is also much smaller than ENWP - that is it has less-comprehensive, less-sourced, fewer articles just like any other Wikipedia with the largest ones being German and Spanish Wikipedia which I've both edited and seen this in many cases even when not looking at the statistics like the one included in the proposal.

Great point about clarifying uncertainties – I thought maybe two MT tools could be used and then the diffs be used in a similar way but it would be better if the MT tools themselves would clarify which parts may be uncertain such as due to ambiguous wording like "light" which can be translated to totally "Licht" and "leicht" in German or "ligero" in Spanish. All of such things only becomes possible once there is a machine translation and correction system. Another potential thing like that would be to highlight things as needing review when one translated article gets a 'post MT error correction' e.g. in the next iteration considering this correction and considering similar translations with greater 'uncertainty' so that the uncertainty is high enough for the part to be flagged as needing human checking. In this previous example, the sentence could be sth like "…narrow columns spanned by light ceilings" and a user error-corrected one language from "bright ceilings" to "lightweight ceilings" – then the other language translations are also adjusted and in the next iteration when another article has a similar sentence e.g. connecting pillars/columns to ceilings/roofs, it has larger uncertainty for it to not mean "bright" and/or greater likelihood of it to mean "lightweight".

The problems of articles being out of sync is not mainly about tracking how out of sync they are. For example the target article is also changed by other editors in the meantime and it's very resource-intensive and cumbersome to get it in sync again. Prototyperspective (talk) 22:06, 4 August 2024 (UTC)

Existing diffs of MT-adjustments

Isaac (WMF) provided some relevant info in some phab issue where I mentioned this proposal: MinT apparently has some dataset of post-MT-adjustments, see "in [11]" here (info here). In "Translated Sections:" there are three values: source content, machine translated content, final published content. This may be useful for testing or for building systems that make use of such diffs. It's however very different from the adjustments-diffs part of this proposal, for the following reasons (maybe I got one or two a bit wrong):

• it only has the first adjusted version (by the editor who originally publishes the first version of the section) but here contents would continue getting adjusted indefinitely
• it only works with a very small subset of articles that have been translated (even just those translated using some particular tool) – this doesn't work with millions of already-available static articles.
• each individual adjustments is not e.g. tagged/classed for why it was changed (probably not important) and a full section diff, not diffs where one issue is fixed at a time; relevant to this is that in what's proposed here when contributors fix issues in one article it often also affects many other articles which have the same issues (by either fixing them directly as well with a tag for the diff or by flagging the phrase as needing review)
• the part about learning from these diffs to flag or adjust / correct other phrases seems missing – this is just a dataset and afaik it's not used to improve the MinT translation model(s) either
• people may add or alter content instead of just adjusting or correcting (in MTWP semantic flaws would need to be corrected in the source article)
• it seems like many Wikipedias don't use the tools whose use would be required for this dataset so the dataset misses many languages

Note that this proposal is much broader than learning from adjustments-diffs which is just one component of it.

Moreover, I asked people at MinT whether specifying 'low certainty/confidence of correct translation' for phrases is possible which is one part of this proposal and suggested that the project proposed here could become a successor project to "MinT for wiki readers" at some point (e.g. once MTs reached a certain baseline quality). Prototyperspective (talk) 16:52, 11 November 2024 (UTC) added 2 more points. --Prototyperspective (talk) 11:57, 16 November 2024 (UTC)

Hosting country?

Not sure if such a project should be hosted by WMF in the USA, as implied by this proposal. After all, Americans would benefit a lot less than e.g. Spanish-speakers if this proposal is implemented. Perhaps the same thing should in parallel be proposed at some of the larger European Wikimedias. Then we can see who is willing to fund this project. Wikimedia Deutschland in particular has done a great job developing (but not hosting) Wikidata. Joe vom Titan (talk) 13:50, 29 November 2025 (UTC)

Good question! However, the wish as currently written does not imply this needs to be or should be hosted by WMF in the USA. If there's something in it that suggests so, please let me know where so it can be edited.

I think at Here is a key consideration: if the Wikimedia movement does not set up such a project I think at some point some external actor or organization will do so and it's better if we as Wikimedians set it up. it's made clear that this is something I'm proposing to all of Wikimedians, including all Wikimedians who are already organized in national chapters. The Community Wishlist isn't just for the WMF in the USA to implement.

I hope this will be implemented as a Wikimedia project/subsite/site, and not by an external organization. (And I think it's urgent that Wikimedians get there first and build this as part of the Wikimedia ecosystem instead of some external organization setting up a new competition.)

I agree that native English speakers – those who search the Web in English – benefit the least if that was implemented. And I think there are good reasons to be concerned about Wikimedia projects and data being hosted in the USA. If this was hosted in the US, I think the issues can be mitigated by it all being open source software and regular dumps of data. One could also host it redundantly in multiple countries. Prototyperspective (talk) 23:37, 1 December 2025 (UTC)

The lead sentence on the Community Wishlist page states The Community Wishlist is a forum for Wikimedia project contributors to share ideas or "Wishes" to improve our product and technology, and then collaborate with each other and the Wikimedia Foundation to prioritize and solve these opportunities together. (emphasis added). By posting on a subpage, you imply that this should be implemented by the WMF which is in the USA. Joe vom Titan (talk) 18:32, 4 December 2025 (UTC)

No, that is not true. The Community Wishlist is for the entire Wikimedia community. See for example Contributors may support and comment on focus areas, which will then be adopted by Wikimedia Foundation teams, Community Tech, affiliates, or volunteer developers. If you still have doubts you could ask on the Community Wishlist talk page. There also is a tag for community opportunity wishes that the WMF won't pick up or not any time soon. Prototyperspective (talk) 19:08, 4 December 2025 (UTC)

Open Knowledge Association

Open Knowledge Association OKA developed by en:User:7804j is the best developed test case we have of this.

There is recent discussion of their process at en:Wikipedia_talk:Translation#Survey and in multiple other places. Bluerasberry (talk) 16:13, 16 February 2026 (UTC)

Interesting, it does seem like a relevant organization. However, it's not a test case of what's proposed here. If OKA is interested to scale up their translation work several hundred-fold then I think they should look into this wish. I'll see whether I ask about this on its talk page; maybe also linking W376: Better article translation system if they're only interested in reforming the traditional translation system. Prototyperspective (talk) 18:41, 16 February 2026 (UTC)

OKA has done 5000+ machine translations published in the Wikimedia platform. What path do you propose to take to get to universal translation, that you imagine not having a test case of a few thousand articles first? Bluerasberry (talk) 19:16, 16 February 2026 (UTC)

A test case of a few thousand articles sounds good and is probably needed. I don't understand how your comment relates to mine as I said nothing about such – the translations they did are not made via a system like the one proposed here so the number of articles they translated one at a time seems fairly unrelated if I'm not mistaken. Prototyperspective (talk) 21:00, 16 February 2026 (UTC)

@Prototyperspective: What do you see that is so different about the translation process that OKA uses as compared to the one you are proposing here? It seems the same to me. Bluerasberry (talk) 23:06, 17 February 2026 (UTC)

Centralize discussion

To advance discussion about translation, I suggest starting a discussion list like the one at en:Wikipedia:Manual_of_Style/Gender_identity#Discussion_timeline. This issue arises repeatedly and has for years, and it would be helpful to have a directory to collect threads. I think several hundred people have already posted about this and we could bring them more together. Bluerasberry (talk) 16:13, 16 February 2026 (UTC)

This would happen once the project proposed here is launched at some prototypical stage. If you know of more such discussions, you could list them here. I don't think it would be very useful to put the cart before the horse and aggregate discussions and decisions about things relevant to translations beforehand. I may have somewhat misunderstood what you were asking however. What the several hundred people discussed seems to be individual standardization & decisions relevant to translation or content overall, not sth directly connected to what's proposed here. Prototyperspective (talk) 18:46, 16 February 2026 (UTC)

┌─────────────────────────────────┘
Assuming that the thread is "Wikimedia projects should have a en:social machine for providing multilingual content access", then here are prior conversations and topics

• http://magnusmanske.de/wordpress/archives/138 "The Reason For It All" 2014
• en:Wikipedia:Writing articles with large language models
• en:Wikipedia:WikiProject Medicine/Translation task force
• Simple English Wikipedia
• http://oka.wiki
• Wikitongues
• mw:Content Translation
• mw:Content translation/Machine Translation/Google Translate
• Abstract Wikipedia
• https://translatewiki.net/

The reason I think it would be useful to index prior conversations is that Wikimedia's strength is more in human governance and deciding ethics and values, and not because our technology is superior to contemporary competitors. Either it is now, or soon will become, trivial to use third party tech to achieve perfect translations. The thing that we have that big tech companies have not yet achieved is legitimate human governance to review and challenge the tech outputs. It is really hard to convene actual humans who care to apply ethics in these situations, and who are independent and not positioned in the conversation by a commercial interest. We can do that, and that could happen if we remember our cultural history of translation. Bluerasberry (talk) 19:12, 16 February 2026 (UTC)

The concept of social machine is very fitting here. As far as I can see all but the Abstract Wikipedia are about the traditional one article at a time translation and I addressed this methodology and AW in the wish description as well as here plus made a little post at the AW talk page. It's a different approach and I'm skeptical it can scale and work well in the sense of complex long articles like Glymphatic system or Art being in the AW albeit this AW 'Architect' tool looks interesting. None of these links are discussions about what's proposed here. I don't think it will be trivial to achieve perfect translations. This is also explained in the wish; for example tools may often translate 'The Guardian' not seeing how it's the title of a news org and if you think this can be fixed there's also other types of issues that are often trivial to humans but not machines. But if you're right about 'perfect translations' becoming trivial soon, then this all the more reason to implement what's proposed here. I waited quite a while until proposing this as I thought some other people may be better positioned to get this off the ground who eg may implement a small prototype right away or things of that sort but it didn't happen so I posted this here with relatively low visibility; somebody could get the other translation-related projects or people involved but it seems rather unlikely to be the best starting ground for this given that users there usually have invested their time and effort in working within another model of translation. When people are invested into sth, partly but not only due to sunk cost fallacy. (I mean that model was very reasonable to work in and was/is probably the most effective way to contribute to smaller Wikipedias for quite a while but new things are possible now.) I think they'd be more interested in improving that model of translation which is what W376: Better article translation system is about. I'm aware of most of these projects so I do remember and honor these projects; I'm not sure what you propose regarding these. Prototyperspective (talk) 23:22, 16 February 2026 (UTC)

@Prototyperspective: Your proposal has humans in the loop, so it is 1 article at a time also, right?

I could be more precise about linking to prior discussions but this proposal here and those seem similar to me. I am not getting what you see as so different in this proposal. Is it apparent to you what I do not understand? I do not understand why you are not seeing all of these listed projects as prior prototypes of machine translation projects. Bluerasberry (talk) 23:13, 17 February 2026 (UTC)

Also re your reply in the thread above, please reread the proposal. Yes, humans are in the loop. The diagram at the top should explain this proposal but please make sure to read good chunks of it t least, especially as various common and likely questions are addressed within the wish. Prototyperspective (talk) 00:06, 18 February 2026 (UTC)

@Prototyperspective: The most unusual position you are taking is that you want to have a second copy of every Wikipedia article in every language in "Machine Translated Wikipedia", for readers who want to read an AI-generated alternative to the human-written Wikipedia articles. I imagine that you wish to promote exchange between MT/AI-Wikipedia and human Wikipedia versions, typically with humans pulling AI-generated content into the human versions. The other unusual position that I see you proposing is doing this nearly all at once, with little or no human review of most content. I think AI services can manage that - including by adding fact-checking to simple translation - but so much human replacement is contrary to Wikimedian editorial consensus. I believe that Wikimedian editorial consensus a mix of all the projects and discussions which I linked above, with the major difference between that and your proposal being much, much more community human review of every step of the process.

Have I interpreted what you were trying to communicate? For your image atFile:Machine Translated Wikipedias.png, the norm right now is that the bottom right box is "sync with a (human) Wikipedia version" instead of having an AI version. Other than that, I think all the processes in that diagram could be replaced with what could be called our current translation social machine.

Sound all correct to you? Bluerasberry (talk) 18:14, 18 February 2026 (UTC)

No, not in every language but those where 1) the baseline translation is of sufficient quality (example: Spanish) and 2) where there's a sufficient number of contributors to improve the quality over time.

Innovation and progress happens with things that are unusual so I have no issue with it being unusual.

who want to read an AI-generated alternative please reread – it's not AI-generated, which is a word that has a meaning, and LLMs won't be used here either.

No, it does not sound correct. The current translation social machine has not made >6 million high-quality articles available to the millions of people who search the Web in Hindi or Chinese. If you're not interested and don't see the value of this, that's fine with me too. Prototyperspective (talk) 19:36, 18 February 2026 (UTC)

@Prototyperspective: First let me do a vibe check. I have been in the wiki translation space for about 15 years and in the wiki space for AI and automation for about 10 years, so I am really enthusiastic about both of these. I am very interested and see a lot of value in this. That is apparent to you, correct? Could I invite you to talk by voice or video - en:User:Bluerasberry/chat?

Okay, so I hear that you propose to break this down by language, so in blocks of about 6 million at a time. I get that, and I know at that scale sets of 1000s of articles are a low percentage of the total, but can you tell me more about how you get from 0 machine translated articles to 6 million? I am trying to get more information from you about the part in the middle, where I presume that humans review test sets of 1000s of articles using human activities like community, discussion, human review processes, and checks on things like values and ethics. Is it your wish to get from 0 to 6 million without those things in between? I am still really not understanding what precedents in Wikimedia projects you value for this proposal, and if you value none of them, I want to hear why that is.

And likewise - if you are not interested and do not see the value of my questions, then I can leave you be. Bluerasberry (talk) 21:26, 18 February 2026 (UTC)

Thanks for your involvements, I'm well aware of how active you're at the technical / meta and metascience-related topics and follow many of your contributions with great interest. Thanks for the invite but I prefer to stay pseudonymous for a variety of reasons.

Yes, the details would be developed and refined iteratively as things are being built – it wouldn't be a batch of ~6 M pages; it would start with maybe a thousand as the test set and then contributors can come in and do what's described in this wish until most of the major issues have been resolved, then the next probably larger batch would be added where things really get going as one can then find more flaws and caveats etc until 4–11 million pages are available. It may make sense to exclude for example articles with citation issues (eg missing citations), articles only available at low quality, and articles with contents that had technical issues in the smaller batches. It can be more articles than the largest WP has (English Wikipedia with ~7 M) because the best-quality article from well-translatable languages for any given topic would be chosen as the source and there's subjects with some Wikipedia article(s) but no EN WP one.

The diagram describes how to get there and names MinT (alternatives to it could also be considered). As the wish clearly describes, the quality of the overall set is improved as a whole and (usually minor) issues with it fixed over time by the WPMT contributors. With this one can leverage synergies, fix&flag flaws at multiple places at once, etc one can't do with traditional conventional conservative ways or however one would like to describe the way you keep on describing. There don't need to be any precedents. MinT for readers as noted high up in this page is the closest to it and I've already asked for feedback on its talk page. I value other approaches too, which is basically why I made that other wish about improving the conventional article translation system. I was just asking to please read the wish first, eg carefully look at the diagram which explains it except for some common questions similar to the ones you asked thatI think are answered in the remainder of the wish text. Prototyperspective (talk) 00:22, 19 February 2026 (UTC)

From what I understand about this project I support and would contribute to it. Best wishes with advancing this to the next steps of actualization. When there are community discussions about this then please put me on the contact list to join. Bluerasberry (talk) 17:07, 23 February 2026 (UTC)

Thank you; will do that! Prototyperspective (talk) 17:11, 23 February 2026 (UTC)