The following discussion is closed.Please do not modify it. Subsequent comments should be made in a new section.A summary of the conclusions reached follows.
Merge or improve. There seems to be enough support to merge into one page to reduce redundancy, but that overlaps with support for merging and then re-creating a Help page that's more user-friendly. The top priority for participants was for novice users to get good instructions. It sounds like anyone who wants to improve the situation for newbies should feel empowered to make major reorganizing improvements, and open a new discussion if they want feedback on a draft. I'm going to drop the merge tags for now. --Beland (talk)01:29, 5 December 2025 (UTC)[reply]
I am proposing mergingHelp:Translation into this page because it appears to have the same scope, and could therefore benefit from consolidation to focus/centralize our editorial energy.{{u|Sdkb}}talk02:00, 19 January 2024 (UTC)[reply]
Another page, even if slightly redundant, makes absolute sense in Help workspace. It is simply there to help newcomers find their way around.Lectonar (talk)10:33, 3 April 2024 (UTC)[reply]
The other page would be redirected here if merged. Redundant project pagesare bad — they increase the maintenance burden (neither of these two is very good) and confuse newcomers who get overwhelmed by the number of possible places to read help.Sdkbtalk13:37, 3 April 2024 (UTC)[reply]
I am a newbie at translation tools on WP, you -Sdkb - are probably not. I am good enough in several languages to translate well (e.g no native speaker of English, but can discuss even some linguistics in it; did several translations "manually"at WP),but not used to this environment and not yet successful with it's translation tools.
I tried to use them, and didn't succeed yet to finish, and publish, the translation with translation tool yet. I think draft of my translation got discarded in the end, because it wasn't published too long when I was trying to make tool work to the end. I am rereading the instructions before trying again now, and intend to document how I didn't succeed if it should happen again. I also need to reread help files in target language (next intended translation is from English article, and the next from German).
From my point of view, current contents of wikipedia:translate and help:translate articles are not only significantly different,they address different topics. You (Sdkb) address economy, and ease of keeping contents of both articles consistent with your proposal, I am showing you the problem of usefulness of them to a newbie - and I think this priority is higher.
Different topics addressed:
Wikipedia:translate is addressing mostly what you can do when you need (e.g. how request or propose a translation), or want to help with, a translation, and what to do if an existing translation is not yet adequate (e.g. .how to mark it by appropriate template).
Help:translate addresseshow to do the translation (e.g. what policies to keep in mind to adhere to, and how to find, enable, and use the translation tool etc.). That is the piece I think I'll need most at the moment.
Again, from my point of view, if the articles get merged, those two primarily different scopes should be easily found (by a newbie, not only it's editor).
If they are not merged, the preamble (of both current articles) should clearly show this difference (and I'd currently prefer that; might change my mind after next - hopefully successful - try at translation with WP translation tools). Also, in how to translate (current help:translate) should probably be addressed what is in common and what is the difference between sandbox and draft space (I'd feel much more comfortable to experiment with translation tool in sandbox first; the concept of draft space is not even mentioned in (either) current (en) translate article (if draft space exists, the fact is a no-brainer for an old hand, and pure guesswork for a newbie).Marjan Tomki SI (talk)03:59, 15 May 2024 (UTC)[reply]
@Marjan Tomki SI, I agree with you that they have a different scope, but I don't really see any harm in putting them together. We can then work on making the page more easily understandable for editors new to translation. Have you had another try at using the translation tools since you made this comment? How did it go? Can you share what points you feel are most confusing? --asilvering (talk)00:17, 30 July 2024 (UTC)[reply]
poignant personal anecdote, entirely off-topic here
Hadn't had time yet to get to Wikipedia (and mostly to comp at all) till last week or so. In July I did water rescue (and relevant first aid and CPR) training (and passed examinations). That was pretty involved for previous month (almost all comp. time was on that subject too), because parts of my knowledge were pretty outdated.
Last year I lost a friend and sailing colleague to drowning at sailing and wanted to know if anything else could be done for him to survive, and when I was offered this courses I accepted and did my best to learn as much as possible, and also pass that experience (why he got breathing blocked, and lost consciousness at all; we seem to have done everything possible, and seemingly more after, but was not enough) to teaching staff and methodologists to hopefully improve general courses of swimming so that what happened to him would be less probable in similar situations.
I'm currently mostly working on repairing some damage on club sailboats which I also neglected for last month or so, so I am mostly still of comp, and I'll let you know here when I can return to WP, and translations, again.
Regarding the subject of no harm in putting both sides together:I think that's disputable.
It reminds me of putting computer and operating system's general description (which should describe necessary functions and facilities offered, so reader gets the idea what is to be, or can be, or should not be... done with that) and detailed reference manual (which would focus on when, and how to do (or not do) any of those things in detail. And I haven't even mention the part - User Guide - that goes between those two.
My experience (both as a novice and as a teacher, where in both functions I strove for no failures, and absorption of complete knowledge wherever wanted and possible) from several areas (from informatics through general problems solving to sports) is that those different levels are best kept separate (and targeted to type of audience).
For a novice at anything, I try to detect the plateau (when her or his info buffer in the brain is full), and send him or her to do something else for a while (including have a meal, and/or to sleep the problem over). After sleeping over the subject matter is usually consolidated, things not understood get clear etc.
If I were persisting after plateau was reached, time and effort would be wasted. Even more seriously, if a novice is overwhelmed with details, (s)he usually looses patience, and interest in the subject,or even develops aversion to the subject, which is IMO (almost always) something of the worst a teacher can do to a pupil.
But if the subject is structured in an interesting way for a beginner, then the detail an experienced but casual user might need to get quickly reminded about, might take unnecessary time and effort to find.
@Sdkb Having thought about this a bit more, I think it would be better if we moved most of what is in the Help version back to this page, and made the Help version more newbie-friendly. That would distinguish the two more clearly and make them both useful, I think. This isn't an idle suggestion; I'm happy to get to work onWP:HOWTRANS with that in mind, and I've started a talk page thread to that effect. --asilvering (talk)17:16, 1 August 2024 (UTC)[reply]
Ah, I was definitely relying on someone replying about it to remind me that I'd said I was going to do that. I still think it's a good idea to have two separate pages, one that's more "here are the policies" and one that's a more newbie-friendly guide. I don't think I'll have the time to get to it this month since it's peak academic chaos time. --asilvering (talk)02:51, 13 November 2024 (UTC)[reply]
Thanks for ping; as I wrote above, I come to comp (and internet) rarely, so it was luck I saw this already.
On my to-do list there are several articles to be translated from German to Slovenian, but as it can be seen it was several months since I tried - unsuccessfully (and should try to find if I left myself notes what I tried and what the problems were). I have also set a number of{{ill}} links in sl articles, which also call for translations (from English, German, Italian...).
As I wrote, before retirement I was living from informatics (including creating and updating manuals for tools and procedures, and training people to do things), and had several levels of documentation for that. E.g.:
General description: what something - a system, component... - does (or at least is intended to do: functions and facilities...), what components it has and how are they related - essential for acquiring (or not) optional components
Reference manual (all commands with all options etc. - what you can do and how you request it - when you know what you want to do and are just missing details).
User's guide (recommended ways how you can go about tasks, and why)
Technical manual (limitations of the systems and components etc., error messages and recovery and maintenance procedures)
The list is not exhaustive.It was information about same thing, but for different uses (or users). Even same users at different times needed different access when just trying to recall a parameter value, or when trying to recall the reason why not to do a particular procedure in particular situation. So called "step by step" books were possibly useful for total newbies without a teacher that can answer questions, but pretty useless as reference or user guide materials. On the other side, reference manuals and user guides should anyway be understandable to newbies as well, but that is not an easy task (and usually called for authors remembering being newbies, and also testing with newbies).
Managing such is not trivial and might be above capabilities of volunteers, butexample above could clarify why putting everything in one article might not always be optimal.
Up to now
I don't recall to having succeeded to make (and save) a single translation yet, but I didn't yet find time to go thoroughly about that). Several months have passed between tries, so I don't recall details, but following hints and help (that I found up to hen) didn't help me succeed yet.
Hopefully, if tomorrow I succeed to leave four club sailboats I was working on this week operational, I'll try one of translations from to-do list again and report what happened (I hope I made, and expect I'll find, documentation on past tries, and add about new tries (hopefully with more success). If I don't succeed (creating and saving a translation) again, let me know where to discuss what I understand wrong; if I succeed, documented differences between past unsuccessful and successful tries should help improve info for newbies. And of course, when I'll be at it, any help would be welcome.
SupportOn the fence – I don't see any way to easily distinguishWP:Translation fromHelp:Translation for a user looking for one of them other than a name change to both, and even then, the difference seems artificial. The hatnotes help, but are a stopgap and simply illustrate further that users are likely to show up at the wrong place. Conceivably I would change my !vote if we renamed them to:
Then again, that reality check points out the futility of renaming, and would just make things worse. Just merging the two and calling it by either of the two one-word titles, with the section names of the merged article clearly getting the user to the information they want regardless whether they came there for thewhat or thehow is easy and fairly simple to carry out. The original proposal is the best solution; I urge users to support it and carry it out.Mathglot (talk)01:50, 13 November 2024 (UTC)[reply]
I am on Asilverings side here...I see a net plus in having 2 pages: one for "policy", and one a bit teahouse-like. Is the need to merge so dire as to make it absolutely necessary to pour much sweat into this? Fwiw, only experienced users will notice that we have some redundancies in the pages.Lectonar (talk)07:38, 14 November 2024 (UTC)[reply]
I've changed how I think about this in terms of a bolded vote, and to an extent what outcome I would like the see happen. The recent closure and reopening made me realize that some of the opinions expressed in this discussion have some subtleties that aren't well captured by a single, bolded !vote, being binary by nature (if support/oppose are the sole options). That includes my own vote, which I have changed to 'on the fence'. In theory, I can still see some advantage from merging them, but practically speaking less so than before based on comments byLectonar,TSventon, andLargoplazo. What tipped me over into changing my vote was that I don't have a lot of confidence that a merge could be carried out well and in a way that would actually improve things from the way they are now (which is not great in either page) whereas I can envision a plan that would make the Help page much more useful than it is now, and if that happened, the situation with the WP project page might become clearer in comparison and a path to improving it might crystallize. So I guess the 'on the fence' could be read as, 'One page would be great if we could do it well, but I just don't see a way that is going to happen, and an attempt might make things worse, but I do see a way that the overall situation can be improved by concentrating on the Help page first, and then seeing what happens down the road'. This discussion is far older than a typical merge discussion (due to having been forgotten for a year) but if there is still interest and activity I'm hoping that it will remain open and attract additional comment and new contributors. If it is closed soon I would ask the closer to dive deep.Mathglot (talk)20:42, 15 November 2025 (UTC)[reply]
Yes, I too would just prefer that we made one better. Some time ago I started in on this and never got back to it. Since we're not really focusing editorial interest oneither page I'm not sure there's much merit in combining them (I think that effort would be better placed fixing up one or the other), but since I'm not doing any of that work myself I have no intention of getting in the way of someone who wants to redirect one page to the other. I think the lack of comment on this despite having an open merge discussion for so long is all the silence we need for anyone to be able to conclude: no one's working here, so beWP:BOLD. I'd oppose any bold page moves, since that tends to create a lot of work, but if someone wants to roll up an improved draft version of any of these pages, more power to them. --asilvering (talk)20:52, 15 November 2025 (UTC)[reply]
In principle I like the idea of a help page that is user friendly, likeHelp:Talk pages, but I don't think that the current "help " page achieves that. Hence I support a merge at present, but would also support a better help page for translation.TSventon (talk)18:47, 14 November 2024 (UTC)[reply]
In general, I disagree with Largoplazo partly becauseWP:TALK is a guideline andWP:Translation is not and so the situations are not analogous, but that only scratches the surface and hopefully I'll get back to that with more detail. But for now, I just wanted to chime in to agree withTSventon. I also am a big believer in helpful pages that are friendly and welcoming, especially to someone doing something for the first time (kind of likeH:YFA is intended to be) and we don't really have that currently for translation. So, yes to merge at present (let's recall that it always was just one page, until split a few years ago), perhaps to be followed by creation of a better help page that would be better targeted at first-timers, if someone wants to take that on. In that case, I think we would have to define scope carefully, so as not to duplicate the current muddled situation, but I think that could be done.Mathglot (talk)19:44, 14 November 2024 (UTC)[reply]
The discussion above is closed.Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
Post-script: I see this as possibly a subtopic of a larger question involving Wikipedia documentation topics that, like this one, have both a WP project page as well as a Help page, where neither is a redirect. Another example isWP:Substitution andHelp:Substitution, and I am not sure the situation there is any clearer than it is here. Rather than start an individual discussion over there, it might be better to start off with a list to see where we are with this, and maybe have a general discussion at VPI for starters. I'll give this some thought.Mathglot (talk)20:25, 12 December 2025 (UTC)[reply]
The following discussion is an archived record of arequest for comment.Please do not modify it. No further edits should be made to this discussion.A summary of the conclusions reached follows.
Option B is adopted. Numerically, there is a clear majority of !votes in favour of Option B, to adopt this new text as a guideline. Supporters of Option B argue that this route allows machine translation to continue without banning it, while providing baseline guidance for LLM-assisted translation that can be refined in future if needed. Opposers (those arguing Option A) citeWP:CREEP concerns and worries that the guideline will be hard to enforce, but many of these editors nevertheless accept that some form of guidance is beneficial, so the two positions are not entirely incompatible. Option C had minimal support and was rejected by many Option B supporters as impractical or unenforceable. Taking into account both the numerical balance of !votes and the substance of the arguments presented, there is therefore consensus to adopt Option B. — Amakuru (talk)12:39, 10 February 2026 (UTC)[reply]
Should the following be adopted as a guideline for using LLM-assisted machine translation tools?
Option A: Do not adopt as a guideline
Option B: Adopt as a guideline
Option C: Adopt as a guideline, and additionally require a new user right
Scope: These rules apply to machine translation tools that include a large language model ("LLM"). Assume these rules apply to any online translation tool unless you've confirmed there's no LLM element.
When translating text from a non-English Wikipedia into the English Wikipedia mainspace, you may only use these tools when:
a) You are skilled enough in both the origin language and English to confirm the translation is accurate;
b) You've checked for, and removed, allAI hallucinations and core content policy violations;
c) You've checked the sources in the origin language article and you're sure the translated text reflects them fairly, and each fact or claim likely to be challenged is supported by an inline citation to a reliable source; and
You may put the raw LLM-translated text into your userspace (preferred) or draftspace while you work on it. If you do, you must immediately tag it as automatically translated text needing review from a human who is skilled in both languages.
Support B I believe that having up-to-date guidelines in place for LLM-Based translation will be very important in the future. (Side note: I think we should also have specific examples of "Do's and Don't Do's" to help explain this, too.)Areux My User Page17:13, 13 January 2026 (UTC)[reply]
Support B (in reality, I favour C, but given its lack of definition here it is impossible to support it this time) – This proposal will help ensure that the community retains control over who can use AI-based translation tools (including traditional machine translation tools, which unfortunately now incorporate AI elements), and ensure that users of such tools are held accountable for their actions. As I said in the RFCBEFORE discussion, translation tools themselves can be useful, but their utility is entirely dependent on the language proficiency of the user. A user without sufficient proficiency in both component languages of a language pair cannot perform the review required to ensure that a machine-generated translation is accurate, that it reflects the source material, and that it does not contain hallucinations. Therefore, I strongly believe that the principles of language proficiency and translation due diligence should be promulgated as a guideline to protect the encyclopaedia from content that will do its readers a disservice.Yours, &c.RGloucester —☎10:55, 6 January 2026 (UTC)[reply]
Support B This guideline is a new presentation and form of many existing practices developed over years. It is reasonable and conservative in the context of our current practices. Translation is not a common Wikipedia activity, and right now, many people who do translation are thoughtful Wikipedia editors in good standing who already comply with these rules. Because of all the chaos that has recently come from the advent of AI, I think it is timely to anticipate that English Wikipedia's status quo for managing incoming AI translations is going to get disrupted, and I feel that any new English Wikipedia editors who follow these guidelines for translation will find them reasonable and that these guidelines will keep their content high quality.
When themw:Content Translation tool started development around 2014, the consensus was that English Wikipedia's review process was different from that of many other Wikipedia language versions, and that automated tools could carry content out of English Wikipedia to other languages but not vice versa. Until 2019, it was unclear whether machine translations and AI output for translations would get a copyright. We did not settle this for the 2019mw:Content translation/Machine Translation/Google Translate tool integration, but at least we got confirmation that Google was asserting public domain status for the output of Google Translate, and we integrated that into the Wikipedia translation tool. This greatly improved quality of translations.
From 2011-2017 with Wikimedia Medicine, I and many others were part ofWikipedia:WikiProject Medicine/Translation task force, which was an effort to translate the leads of medical articles from English to other languages through partnerships with external nonprofit crowdsourcing organizations which would not edit Wikipedia, but who would recruit human volunteers to translate texts at the request of Wikipedia editors. Those Wikipedia editors could then post that text to Wikipedia articles, without themselves being able to read or verify the text. For that process there were humans and authoritative systems in the loop, but the actual wiki editors who were point of content for other wiki editors were not able to read the content they were posting. This was the state of the art then. While current technology is much better, knowing something about the history of prior translation consensus in Wikipedia can help to set norms.
I see that7804j of theOpen Knowledge Association (OKA) is coordinating AI-assisted human translations of Wikipedia articles. Based on the information I have, those editors are already compliant to what this guideline wants. I wish to encourage more institutions to coordinate more translations, and I think that this guideline and the OKA model are worthy of encouraging to others.
The wiki community has never had a dedicated international event for translation. In 2026Wikitongues will be hosting its first dedicated conference, but the focus of that organization is on language preservation and translation is incidental. Still, that organization's growth and success are indicators that we need policy development on multilingual content development processes, and I think finding consensus on this guideline right now would be good for Wikitongues and other trends to be more accessible across languages. Bluerasberry(talk)15:43, 6 January 2026 (UTC)[reply]
B The alternative appears to be the end of machine translation, for the simple fact that most major translation software now uses LLM, and we have forbidden the use of LLMs to make articles from scratch. Outright banning machine translation would not stop its use, and likely only the inept would be using it then. Better to have a system where the qualified have a guideline to use machine translation, and the inept a clear if exacting path on how to do so. I think a user right would be bureaucratic and hard to enforce/prove.CaptainEekEdits Ho Cap'n!⚓21:51, 6 January 2026 (UTC)[reply]
Basically, the current state of guidelines is ambiguous as to whether machine translation is even allowed at all, as virtually all modern machine translation tools rely upon LLMs, and using LLMs for generating new articles isnot allowed.SuperPianoMan9167 (talk)22:53, 7 January 2026 (UTC)[reply]
The guidelines as written prevent editors from using large language models to generate new pages. All online content translation tools now incorporate AI, so strictly by the rules, you can't translate articles from other-language Wikipedias using them. It's essentially saying all translations must be done by hand -- which is quite a lot like saying editors in WikiProject Mathematics can't use calculators. We have to fix this because it's really quite needlessly impeding the generation of new articles that Wikipedia ought to have.—S MarshallT/C00:24, 8 January 2026 (UTC)[reply]
That's debatable depending on your view of whether historical translation subroutines count as "AI". I'd say not, as originally implemented they had a lot in common with spelling checkers.—S MarshallT/C00:47, 8 January 2026 (UTC)[reply]
I’m sorry, how are we confusing AI translation tools with using LLMs to create articles from scratch? Is that the basis for this RFC? That we are interpretingWP:NEWLLM as referring to whollygenerative AI?— HTGS (talk)01:01, 8 January 2026 (UTC)[reply]
The answers and context you seek are in the humongous thread onWP:VPP, which I can't link because I'm on my phone, but it's currently visible from orbit.—S MarshallT/C01:08, 8 January 2026 (UTC)[reply]
A at the moment. This issue combines issues inherent in translation (any kind, although more common in machine translation), with issues inherent in using automatic text generators, and issues surrounding copying text written by others. The proposal sets up highly stringent criteria with a few assumptions, while also slightly undercutting them. "you must immediately tag it as automatically translated text needing review from a human who is skilled in both languages" is contradictory to the very first point (a). A guideline may be helpful, but it seems that the ideal process as envisioned (checking each source, checking each sentence for hallucinations) leads to a process more complex than just checking the source and writing. That should be advised as an the preferred course of action, rather than creating a target set of guidelines to do something else.CMD (talk)06:16, 7 January 2026 (UTC)[reply]
My understanding is that immediately tagging it as automatically translated text needing review is basically saying to other editors "don't do anything with this text yet, I'm not done reviewing it", while leaving room for someone else to help you with the reviewif they want to. It's a concession for people who prefer to use draft/user space as a personal workspace for content that isn't really ready to enter the collaborative ecosystem. --LWGtalk(VOPOV)19:23, 8 January 2026 (UTC)[reply]
Support B. I initiated thediscussion leading to this RFC to address the ambiguity inWP:NEWLLM. As the founder ofOKA, a non-profit that has created over 6,000 translated articles on English Wikipedia, I believe formalizing these expectations as a guideline is a necessary step. Our internal instructions to editors already include following these practices, and a project-wide guideline would provide a clear, standardized framework for all contributors. I could support Option C as a secondary alternative only if the implementation is lightweight and objective (e.g., a simple form to attest to language skills). I would oppose Option C if it introduces subjective barriers, such as a requirement to review "translation artifacts" or a mandate for a specific amount of "non-translation" contributions, which could unnecessarily hinder qualified bilingual editors.7804j (talk)12:25, 7 January 2026 (UTC)[reply]
Support B, oppose C. This is absolutely a necessary clarification ofNEWLLM. Per the RfCBEFORE discussion, currently machine translation is in limbo, since essentially all such tools use LLMs now (and are far more accurate for it!). These requirements are neither onerous nor exceptional, and their clarification and consolidation will make it easier to deal with misuse of translation tools. I don't see what the point of a (pseudo)userright would be here and share the concerns of those in the discussion section that it would needlessly hinder editors without preventing misuse.Toadspike[Talk]15:50, 7 January 2026 (UTC)[reply]
Support B. This has all the hallmarks of a good guideline. It's comprehensive, but not too complicated and still easy to understand. It has a fixed list of what you have to do, but it also allows for flexible implementation to meet all of those requirements. It is restrictive to curb misuse, but permissive to allow legitimate use. Most importantly, it fulfills the fundamental purpose of a guideline: itguides editors on how to properly use LLMs for translation. Ioppose C at this time because that seems needlessly restrictive, but if having no user right leads to large masses of problematic content, I would support adding an extended confirmed requirement just like that of thecontent translation tool. Finally, if it isn't already obvious, Ioppose A because, like Toadspike said, the current state of policies and guidelines leaves any sort of machine translation in limbo.SuperPianoMan9167 (talk)22:52, 7 January 2026 (UTC)[reply]
A: do not adopt as a guideline.
1) These are not enforceable rules. They are written as strict rules, but should probably be rewritten as advice. If someone breaks one of these mandates, what do we do? We don’t have any mechanism to check users for fluency, we can’t know if they have checked the sources or checked for hallucinations. (The idea that we could implement a user right is emblematic of the misunderstanding here; we cannot stop users from making bad translations by adding unenforceable rules, and a user right cannot stop people from translating text into any page or space.) (Also the proposal says “guideline”, but this advice page is not at that level technically?)
2) Such rules should be applied the same to non-LLM machine translations; in both cases, “hallucinations” can be considered merely “errors”.
3) The current guideline atWP:MACHINETRANSLATION is largely fine (I am not opposed to improvements where needed). Users who will ignore good practice will ignore good rules, and we are just addingCRUFT with this sort of list-of-instructions.
This RFC is well-intentioned, but feels like rules-writing for people who like writing rules. I am all for efforts to curtail misuse of AI, but I don’t see a practical need for it as it has been proposed.— HTGS (talk)22:59, 7 January 2026 (UTC)[reply]
Support A. Reading this fresh after a couple of days off and in addition to HTGS' points above the wording still needs more work before this can be a useful guideline. What first tripped me up this time is that it requires you to have already translated the text and then checked and corrected the output before you are allowed to translate the text (requirement a is fine, that's an attribute of the editor, the others are what they must agree to do when translating each text). Additionally, before any guidelines of this nature can be adopted there first needs to be extant guidance about the interaction between accurate translation and accurately reflecting sources where those differ. If the e.g. German article doesn't contain an inline source does the community prefer that the article is first translated without the source and then a new source added later or that a source be added at the time of the translation? How does one indicate that the source is not an LLM-hallucination? If the e.g. Dutch article doesn't accurately reflect the given source, is it preferable to first translate the incorrect statement and then fix it in a subsequent edit or should it be fixed as part of the translation process? How does one indicate that the change is for accuracy and not an incorrect translation of the article? While ideally the error should be fixed on the source wiki as well, we cannot compel anyone to do that nor can we know they have sufficient writing competency in that language nor sufficient familiarity with that wiki's policies and practices.Thryduulf (talk)12:57, 8 January 2026 (UTC)[reply]
it requires you to have already translated the text and then checked and corrected the output before you are allowed to translate the text I'm not sure I understand this objection. The guideline applies at the point at which you insert the text into Wikipedia with an edit, at which point you must have satisfied requirements b and c. Is there a better way to express this ordering of actions? With respect to "translate and then fix" vs "fix while translating", for clarity of attribution my preference would be for translating first, then expanding/adding sources in additional edits, but either is fine if we are transparent and use good edit summaries. If the edit summary just says "translated from ..." then that edit should not also be inserting novel content. --LWGtalk(VOPOV)19:49, 9 January 2026 (UTC)[reply]
The guideline applies at the point at which you insert the text into Wikipedia with an edit that's not how it is phrased or presented though: it reads as a set of conditions that must be satisfied before you are allowed to use LLMs to translate articles for en.wp.
Depending how you read it, either requirement A or C cannot be met if the article in the language you are translating from is not sourced to en.wp standards and/or misrepresents those sources no matter which order you do it in: If you translate then fix you have not ensured that every claim is supported (requirement C); if you fix as you translate then the translation is not accurate to the original article (requirement A). The intent is obviously not to produce a catch-22 here, but that will be the effect if two reviewers have different opinions about the priority. This shouldn't be difficult to resolve, but it absolutely must be resolvedbefore this proposal or anything like it can be adopted.Thryduulf (talk)20:10, 9 January 2026 (UTC)[reply]
I don't have any good ideas for how to achieve this (otherwise I'd have suggested them), but it might require a complete restructure of how the guidelines are presented (which others have suggested for other reasons too).Thryduulf (talk)20:21, 9 January 2026 (UTC)[reply]
Support A (for now) – I'm not a native English speaker, but this last version sounds very strict and categorical to me. E.g. “you mayonly use these toolswhen” followed by a list of conditions when translation is acceptable. This doesn't sound like a guide, but more like a rule.Grudzio240 (talk)14:07, 8 January 2026 (UTC)[reply]
Support B per Bluerasberry and Toadspike. as a translator, the guideline is quite reasonable.abstaining from C with no objections, as I am not experienced enough to comment.Juwan🕊️🌈14:59, 8 January 2026 (UTC)[reply]
Support B This guideline already follows fromWP:V,WP:TFOLWP, andWP:CIR, but since that's apparently not obvious to everyone I think we should make it explicit. I'm not opposed toC in principle but don't see how it would be implemented in practice, and it seems unnecessary if people will comply withB. --LWGtalk(VOPOV)19:17, 8 January 2026 (UTC)[reply]
Support B with a caveat that "You are skilled enough in both the origin language and English to confirm the translation is accurate" be replaced with "You (or a person you're in contact with) are skilled enough in both the origin language and English to confirm the translation is accurate". When creatingBombing of Düsseldorf in World War II I had a German speaker review the translation; I feel that's in the spirit of the proposal if not in the letter.Koopinator (talk)20:00, 8 January 2026 (UTC)[reply]
"You" can be singular or plural. The "you" in this proposal could mean a collaborating pair or team of editors, where some have high fluency in the source language and others have high fluency in English, provided that the "you" collectively has the capacity to meet all the requirements.—S MarshallT/C00:22, 10 January 2026 (UTC)[reply]
Support B: Looks great. This is needed both as a clarification toWP:NEWLLM and to help manage a real, ongoing problem that is leading to insufficiently reviewed translations popping up at AINB, in edit filter logs, etc. I believe an additional accountability mechanism will be required, but that mechanism does not necessarily need to be a user right, and as I mentioned at the RFCBEFORE can come later.NicheSports (talk)00:49, 9 January 2026 (UTC)[reply]
SupportB (with changes, and C as an acceptable alternative). My preference today isB, with the following changes:
a) & c) – "origin language" --> "source language" (useindustry-standard term), or else: "language of the original article" (descriptive)
c) – "You've checked the sources" -> "You've checked the references" (or, "citations" ); indeed, if worried about the ambiguity of the termsources, why use it here, when there really is a better, non-ambiguous term? Two of them, even.
c) – "fact or claim" --> "assertion" (Wikipediatends to avoid the wordfact)
In reality, I support C (the version I have in my head), with B as the alternative, but C is so vague as to be not ready as an option, because we don't know what we are voting for. I like C in principle, and would be happy to discuss it at length, but it simply isn't ready yet.Mathglot (talk)03:00, 9 January 2026 (UTC)[reply]
@Mathglot "source language" was opposed in the RFCBEFORE because it is potentially ambiguous between the language the article you are translating from is written in and the language the sources that article uses are written in (which are not always going to be the same).Thryduulf (talk)03:30, 9 January 2026 (UTC)[reply]
And it does specifically mean "You have read the sources", not just "you have checked the citations". The purpose of that is to ensure (a) that the original-language article reflects what the sources say, and (b) that the automated translation process hasn't introduced bias. If some of the sources aren't online then you ought at minimum to have read a representative sample of them.—S MarshallT/C09:04, 9 January 2026 (UTC)[reply]
Support B - seems like reasonable guidance, brief, well-written, etc. I do think that because of the rise of LLMs, we should have a guideline that expands onWP:MACHINETRANSLATION, which was written in the pre-LLM era. This one does what I think a guideline should do: it teaches people how to do it right.I agree that the last sentence (If you do, you must immediately tag it as automatically translated text needing review from a human who is skilled in both languages.) should be changed: wedon't want humans to come and review draft text in userspace or draftspace that someone else is working on. It should be tagged with something thatdoesn't ask for human review, something like{{under construction}} but for in-process LLM text. (Maybe{{in-process LLM text}}?) But this one change is minor and doesn't stop me from supporting the draft overall; we can make this one change later.I agree with Mathglot above thatorigin language should besouce language andfact or claim could beassertion, which is shorter, but I don't agree about changingsources toreferences orcitations, because then people might misunderstand and think all they have to check is the citation/reference, and not thesource being cited/referenced. We want people to check the source, not just the citation to the source.Neutral on C - seems likeunnecessary bureaucracy to me, but if people want to do all that (create a new pseudo-right and manage it), meh, let 'em.Levivich (talk)17:55, 10 January 2026 (UTC)[reply]
Okay, this business about "source language" clearly needs to be caught and shot. The problem with saying "source language" is simple. Imagine that I'm translating an article from the French Wikipedia about a Belgian politician. Because I'm translating from the French Wikipedia, the "source language" is French. But the sources in the articlearen't necessarily in French; with a Belgian some might be Dutch. If the politician was Swiss, the origin language might be French, but the sources in the article could be in French, Italian, or one of several flavours of German. Many notable people also have sources in English, ours being the language of the internet, and people from some cultures will also have sources in other languages that reflect their heritage.So there's a clear distinction between the language we're translating from, and the language the citations are in. With translation in general (outside Wikipedia), the phrase "source language" isn't ambiguous. But on Wikipedia, "source" has a specific meaning. The phrase "source language" could well be understood to mean "language the sources are in", and not "language we're translating from". It's going to reduce confusion if our guidance instead says "origin language" to mean the language we're translating from, and "citation language" to mean the language the citations are in.In practice we want both. We want translators to understand the origin language fluently, and we also want them to read the citations (or at bare minimum consult someone who knows the language the citations are in and has read them).—S MarshallT/C12:02, 11 January 2026 (UTC)[reply]
Hmm, yes I see that "source language" can be confusing, too. The way I see it, if someone is translating a French wiki article to English, and the French wiki article uses an Italian source, the English translation must be fact-checked against the Italian source, not against the French wiki article. In my view, it doesn't really matter if the French wiki article accurately summarizes the Italian source, or if the English wiki article faithfully translates the French wiki article, whatreally matters is that the English wiki article accurately summarizes the Italian source.Levivich (talk)19:44, 11 January 2026 (UTC)[reply]
Yes and no. The English translation needs to reflect what the Italian source says, but in some cases also what the French article says about the Italian source - for example it might be citing a source that is contradicted by later sources or which contains some obvious error. This also runs into my point about how guidelines around situations like this (e.g. whether to translate and then fix as a separate edit or translate and fix in the same edit) need to existbefore a guideline like this one.Thryduulf (talk)19:54, 11 January 2026 (UTC)[reply]
If I'm reading the sources in Italian and then writing what they say, then I'm not translating a French article. I'm writing an English article based on foreign language sources. This is often the best way.But there are some genuinely good editors on foreign-language Wikipedias who really know their stuff. If you've got something rated GA in German, then a translation of that is usually a decent starting point for an en.wiki article. But to make it conform to en.wiki conventions you'd always be best off adding more of those little superscript numerals people can click.You can translate into your user space, tag as LLM-tainted and needing checking, and then rewrite; or you can translate into a text file on your PC, rewrite, then upload. I don't care. I care that if your article is or contains or is derived from a translation, then it's flagged as a translation and the origin-language editors get the credit they're due so we comply with the terms of use. (And so that if the origin-language editor turns out to be a hoaxer, we can trace that and re-check.)—S MarshallT/C08:33, 12 January 2026 (UTC)[reply]
That's all good and if we could get consensus for that point of view things would be fine, as long as we get that consensus written down as a guidelinebefore introducing other guidelines that will necessarily sit on top of them such as the ones proposed. However discussions have shown that this point of view is not universally held and so we cannot presume it to be the consensus without discussion.Thryduulf (talk)12:51, 12 January 2026 (UTC)[reply]
Support B Both in an anti-laziness, factuality, and anti-slop standpoint. Coming from someone who checkJapanese Wikipedia idea and sources for an article (seeWP:JAPANBEFORE) some of the articles content there are mostly unreferenced and translating them via LLM would probably produce garbage results and garbage articles here on English Wikipedia.Warm Regards,Miminity (Talk?) (me contribs)05:07, 11 January 2026 (UTC)[reply]
Support B, the four points all seem necessary to me. Automated translation are already widely available, even some web browsers have automated translation built-in. I don't see a hole so great left in enwp that we'd want editors to urgently fill it with automated translation without observing a) through d), so there's value in clearly writing these down.
...andOppose C. For one, I'm not sure I see the point of a flag/bit/perm that can't be enforced by the software. And for another, sending aspiring translators through PERM seems like bureaucratic excess. I'm opposed to this kind of PERM creep onWP:5P3 grounds. Wikipedia's strength is that we don't limit our contributors to a small pool of hand-picked domain experts. Translating an article shouldn't require a license and a job interview!Mlkj (talk)16:05, 12 January 2026 (UTC)[reply]
Option A. If you are an expert in the subject matter then you should be able to check the machine's translation yourself and remove anything you don't think is true. I wouldn't want to prevent, for example, a respected nuclear physics professor from a well-known university from translating a nuclear physics article from German simply because they don't speak German. If they see there's an abundance of information on nuclear physics using what we consider to be reliable sources on another language Wikipedia, I see no reason why people who already know a lot about the subject can't use an AI to translate it as long as they double check their work to make sure there's no hallucinations.Gommeh📖🎮18:12, 12 January 2026 (UTC)[reply]
@Gommeh I'm very confused by this. Option A is retain the status quo, which has no guidelines on this matter so it would not prevent (nor specifically allow) anything. Someone could do what you describe today and be perfectly within all policies and guidelines (as long as they followWP:LLMDISCLOSE, which this proposal does not seek to alter in any way) and would be able to do that if option A gains consensus. If options B or C gain consensus they will not be able to do the translation work in that manner if they are translating an article from another language Wikipedia. If they are writing a new article using reliable sources they discovered from their presence in another language Wikipedia but are not using the other Wikipedia's article in any other way then this proposal is irrelevant to them.Thryduulf (talk)19:50, 12 January 2026 (UTC)[reply]
That's not entirely accurate. A strict interpretation ofWP:NEWLLM would forbid even translations. But I expect that because ofWP:IAR it would be toleratedin practice. Still, A leaves this ambiguity on what's allowed or not7804j (talk)20:02, 12 January 2026 (UTC)[reply]
Machine translation can vary considerably in quality of translation from language to language, and should be used with caution. … Wikipedia consensus is thatan unedited machine translation, left as a Wikipedia article, is worse than nothing.
Option A. Without wishing to give offense to any contributor, my immediate observation of this proposed guideline is that it was most likely written by someone with limited to no experience in translation or pragmatics, either as general fields or in particular relation to transwikifying content. While there are elements that I find unobjectionable, the collective effect of the provisions could create busywork in the form of unnecessary documentation and notation and, of more concern, an excuse for a small army of well-intentioned, but self-appointed and Dunning-Kreuger-fueled, "guardians" leaping upon every opportunity to invoke this new guideline upon anything that they perceive to be even remotely LLM-adjacent, whether they have anything approaching full facility in the involved technologies and languages or not. I am particularly concerned about this considering the manner in which the guideline proposes to police work in progress content in user and draft space. And all of thisWP:BURO/WP:CREEP comes in on the assumption that it is needed to avoid a great calamity of translated misinformation. But that risk is massively overestimated, if this is the proposed solution: machine translation, which has often utilized methodologies shared in common with what are now broadly known under the umbrella term of 'LLM', and is a field which in many ways was a test bench for these technologies well advanced of their broader applications in recent years, is nevertheless very distinct from the more popular applications of those technologies which have given rise to such a borderline moral panic against 'AI' technologies on this project. Specifically of relevance to this proposal, the likelihood of outright "hallucinations", in the way that term is generally applied in AI development, is vastly lower with machine translations (including those produced by LLMs) than it is for monolingual content produced from prompts for other LLMs answer general interest or even specific technical inquiries. This is because most all machine translators, from the earliest and most crude analytic models through recurrent neural nets and cutting edge transformers, are more "bound" to the input (and the syntactic/morphological rules and other elements of descriptive grammars of the involved languages) than are the outputs given by the more attention-grabbing but unbounded (and thus more "error" prone) models driving conversational agents. In my view, the concerns I am seeing voiced here and in various related conversations over the last couple of years suggest a heavy conflations of various methodologies that is leading to unrealistic assumptions about the dangers involved here as compared against, for example, letting an LLM draft content using its generative rules and source info. In short, I find this proposal to be way too much cure, with far too many negative side-effects, seeking to cure a comparably lesser amount of ill.SnowRise let's rap00:19, 13 January 2026 (UTC)[reply]
Support B. LLMs stay well-enough on track with translation that someone who is competent in the target language could use it without much issue. I feel it's reasonable to explicitly outline that expectation of competence in a guideline.Agentdoge (talk)17:55, 14 January 2026 (UTC)[reply]
Support B per RGloucester and Blueraspberry. Well thought out, concise, and straightforward, though I don’t think tagging in draft/user space is necessary.Kowal2701 (talk)17:37, 16 January 2026 (UTC)[reply]
Item "(c)" in the proposal sets the bar higher for translation than for creating an article from scratch (requiring approximately FA-level use of inline citations), and I don't think that's appropriate.WhatamIdoing (talk)00:04, 19 January 2026 (UTC)[reply]
A: Just instruction creep based on the provincial fear of AI: "if there's AI involved in some capacity it's a work of the devil and has to be either forbidden explicitly or behind a mountain of draconic and unreasonable rules". Really, why would LLM-translation justify all those things over plain adjectiveless translations?Cambalachero (talk)16:22, 21 January 2026 (UTC)[reply]
A: Sadly, I have to object due to the last part (the requirement to tag), which I consider discriminatory and privacy invading. We don't require editors to disclose their human-judged levels of language proficiency (what certificates, if any, they have). This is effectively saying "it's ok if you make mistakes as a human, but not ok if you do it with new tools". Meh. I also have problems with c) " You've checked the sources in the origin language article". Again, we don't require that form non-LLM translations, and we shouldn't. It goes againstWP:AGF for the creator(s) of the original article, and realistically it means we are discrminating against offline sources. Ex. someone used an offline book to write an article in language X, now we require the translator to get a copy of that book and check things? Really. No. Nobody does it. I could see this as a Featured-level consideration, but for regular translations? Not realistic; it will be just creating rules that nobody will follow and will encourage people to cheat and ignore more rules, a slippery slope (road to hell, etc.). --Piotr Konieczny aka Prokonsul Piotrus| reply here04:07, 22 January 2026 (UTC)[reply]
B Translating articles is a good thing, but unfortunately all to often it's down by editor without any competency in the language it's being translated from and is many times little more than an automated translation. Having some guidance around how this should be done will be helpful. I'm sure the wording could be improved, but this will work as a start. I see no need forC. --LCUActivelyDisinterested«@» °∆t°
A for now. Most of the proposed guideline as currently written ought to apply equally to all translations, whether or not LLM-assisted. Nobody ought to be translating from other wikis, with or without machine assistance, unless they are sufficiently competent in the source and target languages and take the time to check the translations for errors (including hallucinations, especially hallucinated sources, if an LLM is involved). Verifying the text against sources that were present in the original language text is advisable, sure, but the need to check those original sources is not limited to LLM-assisted translation.Rosbif73 (talk)15:54, 22 January 2026 (UTC)[reply]
B or extend current Machine Translation user right requirements -- Currently the helpful but under-utilized Translation Tool requires autoconfirmed status to operate. I support the policy as proposed but also want to make sure that translating editors know what it means to follow it, so maybe your first translation should come after some prolonged engagement with the encyclopedia. Noting that adopting B without this requirement would imply also editing the guidelines atWikipedia:Content translation tool, which asks non-autoconfirmed users to put their machine translations into ACC drafts.
A for now. I agree with others that this guidance confusingly conflates considerations relevant to translation in general with considerations more relevant to LLM use.WP:MACHINETRANSLATION does deserve an update, but given that we should have a natural bias against adding additional guidelines unless they address a major issue, I think this is not ready quite yet. It's clear that there's a sticking point about how to applyWP:NEWLLM in the case of translations, but I think that would be better resolved by clarifyingWP:NEWLLM. (Relatedly, I'm slightly confused about the scope of this proposal. This would create a new guideline page linked fromWikipedia:Translation, right? Because Wikipedia:Translation is currently an info page...)Suriname0 (talk)01:08, 23 January 2026 (UTC)[reply]
A per Piotrus. I am also confused on the scope of this proposed guideline and why it is specific to LLMs vs machine translation in general (a distinction that is becoming increasing less clear). I also agree with the other editors who note that this guideline would mandate higher standards for a translated article than an article going through AfC or just boldly created in the mainspace, which is an obvious oversight.Katzrockso (talk)07:37, 23 January 2026 (UTC)[reply]
Support A. Setting clear guidelines for this area is important, but I'm concerned that this proposal would be counterproductive.
First, since it leaves a carve-out for machine translation without LLMs, it incentivizes editors to simply use lower-quality machine translation to bypass restrictions. Traditional machine translation is pretty well known to be prone to mistakes if not properly proofread. If we put exacting standards on LLM translation while leaving minimal ones on machine translation, the natural consequence is people using the latter, and creating just as many, if not more, errors, considering that LLM translation outperforms machine translation in many benchmarks.
Second, it goes beyond standards typically expected of translators. Article translation is important because it allows editors who aren't necessarily knowledgeable about the topic to lay the groundwork for knowledgeable editors to contribute. Every article has to start somewhere, yet this proposal would require the equivalent of GA-quality inline referencing. If that's not required for all new articles, then doing so for translation seems arbitrary.
Third, it's difficult to enforce. There's somewhat of a double bind here; any blatant errors associated with LLM hallucinations, such as false citations, would already be covered by existing policies, so criteria b) doesn't add new safeguards. On the other hand, any smaller errors could be the result of good-faith mistakes; I consider myself competent to translate from my native language to English, but it certainly wouldn't be perfect in fidelity. At what point do you draw the line that someone isn't competent to translate, with or without assistance?
Regarding how existing translations interact withWP:NEWLLM, translation isn't equivalent to generation. It's a derivative process based on existing sources, and by definition, is designed to keep the meaning of material with minimal change. If that's not the case and it's a problem that needs to be solved, then I'd support a change in policy, but unfortunately have concerns about the current one. Anyway, I'm open to changing my mind if anyone thinks I've made a mistake in my reasoning. I found HTGS's and Thryduulf's comments particularly convincing.Crestfalling (talk/contribs)23:53, 26 January 2026 (UTC)]][reply]
Support B seems to be the only rational choice. Interested in developingC as it could ensure an audit trail within Wikipedia. Keen to see that implemented, leading to much tigher control of quality, assuming tools/processes are there. Probably knackered already known the WMF.scope_creepTalk11:34, 27 January 2026 (UTC)[reply]
@Scope creep Can you explain how a user right would ensure an audit trail? I don’t understand how this would work, nor how our current changelogs don’t suffice for auditing edits.— HTGS (talk)18:48, 29 January 2026 (UTC)[reply]
Support C Increasingly starting to think that a user-right permission is the best path forward for all LLM stuff in general. Equally importantly,Oppose B, we do not need to enshrine permission for this into policy for everybody.Gnomingstuff (talk)21:35, 28 January 2026 (UTC)[reply]
Support B or C. It's completely unacceptable for people to rely on machine translations without verifying them. Regarding the argument that we might not catch everyone who does it, or that people might falsely accuse each other of this - the same could be said about COIs, or sockpuppetry, or offsite canvassing. We still have policies for these things so we can crack down on itwhen it becomes obvious. Which it often will! "This isn't magically crystal clear in all cases" is not a valid argument to have no policy for it at all - we can still make it clear that something is not allowed, and crack down on it when it becomes obvious. --Aquillion (talk)17:40, 29 January 2026 (UTC)[reply]
Support C or B, I partly agree withGnomingstuff and others that that a user-right permission is the best path forward but I am also not sure about the practicality of enforcing that. I do however fully support that this proposal should be adopted as a guideline.--Gurkubondinn (talk)15:51, 5 February 2026 (UTC)[reply]
Support A. Restricting LLM translation while explicitly carving out the non-LLM ones is strange, as LLMs are much better at translating than the decades-old pre-AI generation of translation tools.Викидим (talk)00:24, 8 February 2026 (UTC)[reply]
Support A per the 'carve-out' reasoning others have stated. There are bad ways to use LLMs to translate (e.g. relying on a model that is too small or didn't have enough exposure to the source or target language) but the frontier models today do better than machine translators alone. By the way,I have found signs of Google Translate behaving in LLM-like ways (e.g. it would explain Chinese idioms in parentheses to me). I think any guidelines we adopt for LLM content or translated content can naturally also apply for LLM-translated content, no? --🔥Komonzia (message)16:04, 8 February 2026 (UTC)[reply]
What user right are you talking about? As far as I know, user rights are settings based on which the Wikipedia software will or won't let a user do certain things or will or won't display certain things to the user. I don't see how that's applicable here.Largoplazo (talk)12:52, 6 January 2026 (UTC)[reply]
User rights (e.g. delete or protect) and user groups (e.g. sysop or bureaucrat) are very specific MediaWiki terms that correspond to things in the code and the database. You can see a list of both atSpecial:UserGroupRights. I think you mean something else. An AFC reviewer is not technically a user right or a user group. Perhaps we should think of a different term for it. –Novem Linguae(talk)13:41, 6 January 2026 (UTC)[reply]
In that case, whatever the designation is called, what would be the effect? My context-free stab at what this might mean is that each time someone adds content to an article and someone suspects it's translated from somewhere, if the contributor has that designation they'll leave it alone but otherwise they're free to start questioning the means of translation?Largoplazo (talk)14:00, 6 January 2026 (UTC)[reply]
Regardingsomeone suspects it's translated from somewhere: if text is translated,attributing it is already required per Creative Commons licensing requirements.The idea would be that contributors with that designation would be trusted to use LLM-powered machine translation responsibly, while contributors without it wouldn't be allowed to do it (the immediate effect being on programs such asOKA, which isexplicitly telling its contributors to useGrok as a starting point for translation), and their translations could be removed instead of waiting for someone skilled enough in the source language to verify them in their entirety. Enforcement would of course be less obvious if it isn't clear whether the content was translated through the help of a LLM, and we should be careful not to make assumptions in that regard.ChaoticEnby (talk ·contribs)14:13, 6 January 2026 (UTC)[reply]
I see where that's coming fro; my worry is still to do with enforcing it and, given my experience with CCI, misuse of the right or pseudo right by established editors.
For starters, how does PERM assess who gets the right? Do we have to quiz somebody on their understanding of the language they wish to translate from? If I manage to convince somebody that I'm fluent enough in Spanish to use a translator, are they also giving me permission to translate from Korean? A while ago, I remember an RfA of a very experienced NPP editor who botched some translations; who would have turned down them for the hypothetical right? I recently(ish) had to talk with a DYK template editor about making sure the articles they were translating were actually supported by the cited sources and not copyright issues; again, that's somebody who got template editor on the basis of their content work. Whatever standards we set, who would stop them from being given the right? And, for a more current example,User:Ekabhishek is an AP admin, but we haveWikipedia:WikiProject AI Cleanup/Noticeboard#Ekabhishek. Would giving them a (pseudo) right, as would undoubtedly happen, make it easier or harder to start threads like that? My CCI experience leads me to believe harder; I'm also having a hard enough time saying "you need to check this text you're translating, you're responsible for it" without the other editor saying "oh, no, its ok, I did, in fact, check enough and I have permission".GreenLipstickLesbian💌🧸14:51, 6 January 2026 (UTC).[reply]
For starters, how does PERM assess who gets the right? Do we have to quiz somebody on their understanding of the language they wish to translate from? Ideally, we would want them to have a demonstrated skill in the languages they wish to translate from, for instance through contributions on that language's Wikipedia edition or a track record of good manual translations.Would giving them a (pseudo) right, as would undoubtedly happen, make it easier or harder to start threads like that? Processing the thread is what would be made easier: if a pattern of mistakes is found (e.g., AI hallucinations that weren't spotted), the pseudoright can be removed, like autopatrolled from users creating multiple articles failing our standards. Seeing it in practice is a good proof that the user did not, in fact, check enough despite their assurances.ChaoticEnby (talk ·contribs)16:17, 6 January 2026 (UTC)[reply]
I don't see it as particularly helpful to create a user permission (and a process for granting it and a process for reviewing its use and a process for revoking it), but if we did do that, then I envisage that the conditions for granting it would be "does a sysop have confidence in your good faith and good judgment".—S MarshallT/C10:04, 7 January 2026 (UTC)[reply]
The proposal to add a user right was doomed by default, as this RfC was started before the details were worked out. How can community members support such a proposal, when it isn't entirely clear what they are voting for in the first place? Might as well forget about it and leave the matter for another RfC.Yours, &c.RGloucester —☎10:48, 7 January 2026 (UTC)[reply]
I said that I supported to a three-pronged format, which I do – but without a clear of definition of what this 'user right' is, how do you expect editors to express their support for it? What conditions must be met for the right's granting? How will we deal with machine translations produced by editors without the right? No text detailing any of these key points has been provided. In any case, it's all water under the bridge now, and this RfC should be allowed to run its course.Yours, &c.RGloucester —☎11:52, 7 January 2026 (UTC)[reply]
I actually see this as somewhat too bureaucratic and adding another layer of complexity which isn't really needed. LLM is more or less frowned upon in Wikipedia as a whole, and now we want to allow another (new) user group to use LLM-powered translation (and yes, only in drafts)? If you were working over atWP:PNT, e.g., you would see very quickly that every kind of machine translation, be they LLM-powered or not, adds more problems than it solves. In the end, to grasp every nuance and being able to evaluate sources, you will still need someone fluentand knowledgeable in both the original languange and English. That might change with the progress of LLMs, but we aren't there yet imho.Lectonar (talk)15:04, 6 January 2026 (UTC)[reply]
In the end, to grasp every nuance and being able to evaluate sources, you will still need someone fluent and knowledgeable in both the original languange and English. Yes, and that is what this guideline aims to formalize. Currently, we have translators encouraged to rely on tools such as Grok, who might not be aware of the pitfalls of using such tools.ChaoticEnby (talk ·contribs)16:20, 6 January 2026 (UTC)[reply]
Why is this applied only to LLM translation? Is there evidence that LLM translation is worse than “traditional” machine translation?— HTGS (talk)02:37, 7 January 2026 (UTC)[reply]
The answer on which is better/worse is probably "it depends", but there are problems specific to LLMs (e.g. their nondeterministic nature; hallucinations) that are at least worth discussing IMO—pythoncoder (talk |contribs)03:27, 7 January 2026 (UTC)[reply]
But we aren’t discussing those problems, we’re just imposing a restriction on their use…? I don’t see how this guideline is any more useful thanWP:MACHINETRANSLATION. It applies more set “rules” but people who would hastily paste machine translated content don’t seem likely to follow rules anyway?— HTGS (talk)07:29, 7 January 2026 (UTC)[reply]
Based on the discussion that led to this RFC, the kind of behavior this guideline is meant to prevent is currently happening even with paid translators from a wiki-specific nonprofit, which is a presumably a category of people who can be relied on to follow guidelines in good faith. --LWGtalk(VOPOV)19:34, 8 January 2026 (UTC)[reply]
That's pretty accurate. For instance, when I translatedInazuma (Genshin Impact) over from Chinese I had to deal with several phrases and terminology unique toGenshin Impact. For example, the term for what we English-speaking players would call Visions is神之眼. Google Translate would translate that back into English as "eye of God", the literal translation. ChatGPT knew better and correctly translated it as "Vision" because it had the capability to determine the context in which the term was used.Gommeh📖🎮17:14, 13 January 2026 (UTC)[reply]
And anecdotally even Google Translate is much better than it used to be. I play a game elsewhere on the internet where people take a source text, and use Google Translate to convert it to a different language then use Google Translate on that result to turn it back to English, marking up the changes and highlighting anything amusing. Over the past couple of years this has gotmuch harder as far more now roundtrips identically and even when it is not identical there are far fewer changes in meaning, even for complex sentences, than there used to be. This is exactly how machine translation should not be used (because it multiplies errors), but for languages that are well-attested online even this now rarely produces much beyond expanding/contracting (e.g. "don't" → "do not" or vice versa) and changes of tense that are either trivial or would be very easy for someone with even basic competence in the languages to identify.Thryduulf (talk)17:29, 13 January 2026 (UTC)[reply]
It would be useful if someone could explain, in a sentence, why the existing guidelines are insufficient to cover this? For all of these bullets other than the one about hallucinations, don't we already require as much for translations (regardless of the tool used)? —Rhododendritestalk \\16:59, 7 January 2026 (UTC)[reply]
Our guidelines for machine translation are relatively bare, and don't even require proficiency in the source language, which is obvious enough for manual translations but not for machine-assisted ones. We also don't require source verification, but only recommend to include the same sources, which can be especially problematic if machine translation distorts the meaning of the text. Currently, OKA editorsare even encouraged to use DeepL Write to proofread their Grok output, and having a guideline we can point to as a bare minimum would help.ChaoticEnby (talk ·contribs)17:12, 7 January 2026 (UTC)[reply]
Are you trying to say the proposal already applies to all machine translation? Because that is not clear to me having read it.— HTGS (talk)23:46, 8 January 2026 (UTC)[reply]
Yep. My error -- too used to machine learning-centric discussions. Literally just tried to explain something to a friend by starting with a contrast between symbolic and statistical AI paradigms and wrote the opposite on Wikipedia. :) Anyway. End of tangent for me. Doesn't affect my initial reservation. —Rhododendritestalk \\00:19, 9 January 2026 (UTC)[reply]
It could in theory, but I believe it is best to first address the most pressing issue, especially since LLM-powered machine translation has a different set of pitfalls (for instance, it is less likely to misunderstand idiomatic expressions, but it carries a much higher risk of distorting the meaning of a sentence entirely, or even adding a new one from its knowledge base). For context, the current guideline achieved its current shape in 2020, before most machine translation software incorporated LLMs.ChaoticEnby (talk ·contribs)19:21, 7 January 2026 (UTC)[reply]
I appreciate the risk assessment, although I'm still not convinced we should create uneven barriers when, based on what I've seen, we'd be making it harder to use the tools that at present seem to outperform the default alternative in standard tasks (google translate). That said, since I'd support adopting this for any machine translation, I'm not going to oppose. —Rhododendritestalk \\19:31, 8 January 2026 (UTC)[reply]
How would the user right work? Would it say that "this user can translate articles from other Wikipedias", or would it be limited to specific languages. Would an editor who got the right to translate from Dutch Wikipedia have to make another request to translate from Afrikaans Wikipedia? I also don't quite see any practical way to prove fluency for the user right other than taking users for their word, which renders the whole premise useless. There are a long list of reasons somebody contributing to English Wikipedia wouldn't contribute to another Wikipedia that are unrelated to fluency, à la the problems that previously afflicted Croatian Wikipedia.1brianm7 (talk)07:47, 8 January 2026 (UTC)[reply]
Now that I think about it, even taking them to their word could be useful, and wouldn't render the premise useless. The idea is that an easily granted user right can be removed if the user is found to break the guidelines (e.g. leaving blatant hallucinations in translations), while enforcing the guidelines without a user right would have to be much more blunt (likely blocks or topic bans).ChaoticEnby (talk ·contribs)08:23, 8 January 2026 (UTC)[reply]
That’s a good point. I’m not sure how low the bar for it being granted should be, but I’d want it to be fairly low. Imagining a scenario where someone has demonstrated competency at translating pages in one language but incompetency in another, it could be beneficial to split the right into stuff like "fr-Page translator" and "it-Page translator".1brianm7 (talk)09:32, 8 January 2026 (UTC)[reply]
My suggestion for changing in tone:
−
Scope:Theserulesapply to machine translation tools that include a large language model ("LLM").Assumetheserulesapplytoanyonlinetranslationtool unless you've confirmed there's no LLM element.When translating text from a non-English Wikipedia into the English Wikipedia mainspace, you mayonly use thesetoolswhen:a) You are skilled enough in both the origin language and English to confirm the translation is accurate;b)You've checked for, and removed, all AI hallucinations and core content policy violations;c)You've checked the sources in the origin languagearticleandyou'resure the translated text reflects them fairly, and each fact or claim likely to be challenged is supported by an inline citation to a reliable source; andd)You'vecompliedwithall the usual translation processes including terms of use-compliant attribution.You may put the raw LLM-translated text into your userspace (preferred) or draftspace while you work on it. If you do, youmustimmediately tag it as automatically translated text needing review from a human who is skilled in both languages.
+
Scope:Thisguidanceapplies to machine translation tools that include a large language model ("LLM").TreatanyonlinetranslationtoolaspotentiallyLLM-assisted unless you've confirmed there's no LLM element.When translating text from a non-English Wikipedia into the English Wikipedia mainspace, you may use thesetools,butyouareresponsibleforensuringthat:a) You are skilled enough in both the origin language and English to confirm the translation is accurate;b)Youhave checked for, and removed, all AI hallucinations and core content policy violations;c)Youhave checked the sources in the origin languagearticle,ensured the translated text reflects them fairly, andthat each fact or claim likely to be challenged is supported by an inline citation to a reliable source; andd)Youcomplywith the usual translation processes including terms of use-compliant attribution.You may put the raw LLM-translated text into your userspace (preferred) or draftspace while you work on it. If you do, youshould tag it as automatically translated text needing review from a human who is skilled in both languages.
Editors who use LLMs to assist their translation might lack thespecific competencies needed to identify the kinds of errors LLMs can introduce.
Problems 1, 2, and 3 call into question whether and which non-English wiki articles should be translated at all, and don't really involve LLMs except to the extent that LLMs may increase the number of people who think they are competent to translate. This RFC is really about addressing problems 4 and 5: editors who use LLMs to translate are likely to produce specific types of errors that translators who do not use LLMs would not produce, so editors who use LLMs need specific competencies and guidance that are different from the competencies and guidance needed by translators who actually translate. --LWGtalk(VOPOV)20:54, 12 January 2026 (UTC)[reply]
I generally agree with that, but there is no sharp division between "editors who use LLMs" and "translators who actually translate" as many people in the latter category also use machine translation (which increasingly incorporate LLMs, transparently or otherwise) as part of their work (to a probably infinitely variable degree).Thryduulf (talk)20:59, 12 January 2026 (UTC)[reply]
I generally disagree wit that. May I ask if you have any experience in using LLMs 1) unrelated to translation, 2) in order to generate a translation? My guesses: 1) yes (lots), 2) not really/sporadically. If you have a couple of examples of a hallucination or an invented source for 2) please post it below or on my talk page. (Need: source text, engine + date or version, and target language text.) Inappropriate tone in translation is possible, I suppose, but I have not seen it. You can even refine a tone of a first attempt because the original de-wiki article, say, was overly academic or jargony, by requesting the tone you want. But I have not done a lot of that, so I cannot generalize. Inaccurate translations do occur with LLMs, sometimes flipping the sense entirely day for night and up for down (very very rarely, and I try to maintain a short list of them), which is a very good reason to require knowledge of both languages. But, hallucinations or invented sources in LLM translation? Never seen it. I would very much like to have examples of that, if you can provide them. Is it possible you are conflating 1) and 2), asSnow Rise mentionedabove?Mathglot (talk)01:29, 13 January 2026 (UTC)[reply]
Examples of LLM-related problems in cross-wiki "translations" are currently being discussed in various places, as Imentioned when HTGS asked the same question above. As far as my personal experience goes, I use LLMs quite a bit in my job for various tasks including translation, and work closely with people whose areas of research include LLM-based translation methods (though that isn't my personal area of expertise). The specific use case that is causing most of the problems here (summarizing and applying non-English sources) is something I do constantly, using both LLM-based and non-LLM-based workflows, so I feel like I'm reasonably aware of the strengths and pitfalls here. --LWGtalk(VOPOV)01:52, 13 January 2026 (UTC)[reply]
Regarding SnowRise's comment, I agree with it in spirit, since as I said in my!vote I think that existing policies already require this level of diligence, but I voted for B because it seems from the discussions onWP:VPP andWP:AINB that not everyone agrees on whatWP:CIR looks like with these tools. --LWGtalk(VOPOV)02:01, 13 January 2026 (UTC)[reply]
Still has the burden problem with "You have checked the sources in the origin language article". What if the sources are offline? Get the book through interlibrary loan? That won't work for many languages; I doubt I could get most Polish books outside Poland, for example. Where's theWP:AGF? Are we switching to mistrusting all other editors now? Sure, I know, there are many errors in sourcing, but the burden on verifying sources is, to me, a Featured level consideration, not something we should throw at simple translations.Piotr Konieczny aka Prokonsul Piotrus| reply here04:12, 22 January 2026 (UTC)[reply]
Try this thought experiment: given thatall Wikipedias are unreliable sources because they are self-published, shouldn't we simply ban translation from other Wikipedias entirely, but allow new articles written from scratch in English using the reliable sources culled from a foreign language Wikipedia article? If a source is on theReliable sources perennial sources list and marked generally unreliable, we do not use it even for a citation, much less copying a whole article from it into Wikipedia (let's assume it has a compatible license). But if we find that same article on a Spanish website that is tagged unreliable, does the act of translating it into English whitewash the taint so it's now okay at en-wiki? And what does this imply about translating articles from Spanish Wikipedia, by definition unreliable?Mathglot (talk)08:12, 15 January 2026 (UTC)[reply]
Well, if the information of the text is relatively the same, then the information has the same unreliability because it is conveying the same information. I don't know if it would be considered "unreliable" to translate from Spanish Wikipedia, since it follows the same core principles as English Wikipedia, though the specifics of other policies differ between Wikipedia languages.Areux (talk)00:03, 16 January 2026 (UTC)[reply]
Areux, Spanish Wikipedia is by definition unreliable (just like English Wikipedia is). This is why you cannot cite Wikipedia in a reference (with exceptions for articles talking about what Wikipedia said about something), namely, because it is unreliable. Not 100% sure what you meant by the first sentence, but if you are saying that the English translation has the same unreliability as the Spanish original, that was precisely the point I was raising in the thought experiment and soliciting feedback about; that is, if we claim that Spanish Wikipedia is unreliable, then how can we import a translation, possibly an entire article, into English Wikipedia, and think that that is somehow okay? Does translation somehow magically wipe the unreliability of the original away? And if it does not wipe it away, should we bar translation from unreliable sources like Spanish Wikipedia (i.e., all Wikipedias)? And if translating Spanish Wikipedia is okay, then what about, oh, say,translating or copying articles fromFandom (which have a compatible license), which we bar from being used in citations because it is unreliable? That is the question I am posing. Here's one:Fandom:Starwars:Order of the Sith Lords; should we just copy that into Wikipedia? What aboutFinalFantasy:es:Final Fantasy XIII (over 100 citations) – should we just translate that into Wikipedia? If not, why not?Mathglot (talk)21:18, 18 January 2026 (UTC)[reply]
Ithink the appropriate response is that we are equally trusting the English Wikipedia page, as it exists, every time we commit a minor edit that builds upon it. Allowing the translation of another Wikipedia implies we believe their standards are at least equal to our own. I say this as devil’s advocate, because I’m not sure I disagree with you right now.— HTGS (talk)23:47, 18 January 2026 (UTC)[reply]
HTGS, an interesting point. I guess I would say, yes and no. Policy (and the Terms of Use statement right above the 'Publish' button) say you are responsible for *your edit*, not everybody else's. When you add a minor edit, you take no responsibility for what is already there, just your minor edit. Otoh, when you translate a whole article (or chunk of one), then your edit is whatever you add to the preview window and submit, so all of what you added—including all the translated words, even if originally written by someone else in another language—is your responsibility.
Your second sentence is interesting as well. I do translations on occasion from a few languages, and although individual articles, and editors, vary in quality, I do *not* believe that on average the foreign Wikipedia articles I look at and/or translate have the same standards as we do at en-wiki. I don't even assume that they would pass en-WP:Notability standards; often I am certain they would not. Bottom line: I do not believe that other Wikipedia standards are roughly equivalent to our own, and I start with the assumption that any article I am looking at may be poorly written, poorly sourced and possibly non-notable. (That can be true of articles here as well, of course, but I don't translate those!)Mathglot (talk)00:08, 19 January 2026 (UTC)[reply]
Someone adds content to English Wikipedia. The addition may or may not be good. It may or may not include citations to reliable sources that are adequate to verify everything it says. That's every day editing on English Wikipedia. Now, suppose some of that content is, in fact, a translation from content on Spanish Wikipedia. That makes it neither more nor less valid an addition to English Wikipedia than it was before you know it had come from Spanish Wikipedia. That the content comes from Spanish Wikipedia adds no assurance that it's any good, but neither is itmore suspect than any other newly added content. Its merits are subject to the same evaluation for quality, and the same remediations for its shortcoming, as any newly posted material. If it comes along thoroughly referenced to sterling sources, then we won't have a problem, though we can certainly evaluate them against our ownWP:RS guidelines. If it doesn't, then we're in the same position we'd be in if it were written from scratch. The person posting it here bears the same responsibility for it as a person posting content they composed themselves, and must understand themselves to be vouching for it in the same measure.Largoplazo (talk)00:13, 19 January 2026 (UTC)[reply]
This hits my points 1) and 2) above. In my view, there's a presumption that editors on the other wiki have read and correctly used the sources they are citing, absent reason to doubt this, just as we presume about other editors' work on enwiki. So by translating their work and bringing it over, we avoid duplicating that work. Just like on here, content that has cues that cause us to question it should be removed if not verified against the the cited sources. The questions under discussion here aredoes the fact that content was translated with an LLM count as a cue causing us to question it? and furtherwhat work should be done (and by who) to restore LLM content to a status where we can presume verifiability? A support vote to this proposal is basically answering those two questions with"Yes" and"theoriginal translator should satisfy a) through d)before inserting the content into mainspace". --LWGtalk(VOPOV)17:14, 16 January 2026 (UTC)[reply]
1.Machine translation was not forbidden, and 2. it seems from this discussion that there is an appetite toallow machine translation, including LLM translation, given sensible precautions are taken.— HTGS (talk)18:58, 29 January 2026 (UTC)[reply]
The discussion above is closed.Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
[Research] Preliminary analysis of AI-assisted translation workflows
Note: To keep the conversation organized, I have primarily posted this at theVillage Pump. I encourage any questions or discussions to take place directly there.
I’m sharing the results of arecent study conducted by the Open Knowledge Association (OKA), supported byWikimedia CH, on using Large Language Models (LLMs) for article translation (which is also very relevant in light of the above RFC). We analyzed 119 articles across 10 language pairs to see how AI output holds up against Mainspace standards.
Selected findings:
LLMs were found to be significantly better than traditional tools at retaining Wikicode and templates, simplifying the "wikification" process.
26% of human edits fixed issues already present in the source article (e.g., dead links), showing that the process improves the original content too.
Human editors modified about 27% of the AI-generated text to reach publication quality.
We found a ~5.6% critical error rate (distortions or omissions). This confirms that "blind" AI publication is not suitable; human oversight is essential.
Claude and ChatGPT led in prose quality, while Gemini showed a risk of omitting text. Grok was the most responsive to structural formatting commands.
Acknowleging limitations: We consider these findings a "first look" rather than a definitive conclusion. The study has several limitations, including:
Subjectivity: Error categorization is inherently dependent on individual editor judgment.
Non-blind testing: Editors knew which models they were using, which likely influenced their prompting strategies.
Sample size: While we processed over 400,000 words, the data for specific model comparisons across all 10 language pairs is insufficient.
Our goal is to provide some data for the community as we collectively figure out the best way to handle these tools. The full report, including the error taxonomy and raw data logs, is availableon Meta.7804j (talk)20:31, 20 January 2026 (UTC)[reply]
Hi@Chaotic Enby: and others. Following the above RFC closure, which found consensus for Option B and the adoption of a new guideline, I have created a new pageWP:LLMTRANSLATE which contains the text of the guideline as agreed.
I implemented it this way because the existing project pageWP:TRANSLATE already contains a substantial amount of background information and advice that has not been designated as guideline, and the adopted guidance is specific to LLM-assisted translation.
The original proposal was to use the section parameter of the guideline template, and incorporate this text here. I cannot agree that there should be a separate page. This simply makes things more confusing for editors seeking to translate articles. The text of LLMTRANSLATE should be merged into this page.Yours, &c.RGloucester —☎13:16, 10 February 2026 (UTC)[reply]
Hi both, unfortunately I don't agree with the suggestion above. It would be confusing for readers to have a guideline hidden amongst what is otherwise an unvetted information page, and in fact the guidance at{{Guideline}} explicitly recommends against this. It says:"[section=y] is only used when an guideline of a particular sort (e.g. a naming convention) is a section in a larger combined guideline" and"The template with or without this parameter should not be used on wikiproject advice pages; they are essays not guidelines." Therefore I think a separate page for the new guideline is required here, as long as the rest of the Translation page does not enjoy guideline status. Cheers — Amakuru (talk)17:35, 10 February 2026 (UTC)[reply]
No worries at all! (I only found out about that piece of guidance myself when I followed the link to the template in question...) That being the case, I suspect the separate page is the only way to go, unless it's folded into some other page that's already a guideline. We can make sure it's prominently linked from all the relevant places. — Amakuru (talk)18:52, 10 February 2026 (UTC)[reply]
This is very unfortunate, Chaotic Enby. I specifically asked you about this point prior to the RfC, andyou said that this guidance would be incorporated into this page as a section. We've only just gone through the process of merging all translation-related guidance into this page – now we are back to taxing editors with having to consult multiple pages. Much as with the user right proposal, this problem has arisen because of the slapdash manner in which you launched this RfC. I hope you will take this as a lesson to clearly definewhat precisely will happen if and when a proposal is adopted in future RfCs.Yours, &c.RGloucester —☎22:59, 10 February 2026 (UTC)[reply]
One may note that the new guidance specifies:You may put the raw LLM-translated text into your userspace (preferred) or draftspace while you work on it. If you do, you must immediately tag it as automatically translated text needing review from a human who is skilled in both languages. It would be helpful if someone more proficient than myself could create a template/categories to facilitate the implementation of this guidance. One may see the existingCategory:Pages with unreviewed translations, but I expect a new one should be created specifically for pages with unreviewed LLM-based translations.Yours, &c.RGloucester —☎23:42, 10 February 2026 (UTC)[reply]
Reopened.FaviFake (talk)09:32, 15 November 2025 (UTC)[reply]
You are invited to join the discussion atTemplate talk:Rough translation § differences between the templates 'cleanup translation' and 'rough translation'.PK2 (talk;contributions)07:55, 15 November 2025 (UTC)[reply]