Problem: Some templates in different wikis have similar functionality, but it's unnecessarily difficult and time-consuming to copy them from one wiki to another.
Who would benefit: Volunteers who edit in more than one wiki and who copy, adapt, and translate information from one wiki to another.
More comments: There need to be some json on Commons or other way for users to translate parameters of templates and templates names. For citation templates there would be great if there would be possibility to implement some logic, like ru_author = en_last1 .. ", " .. en_first1 etc.
A very, very, long-desired wish - if it can be done in a fashion that somehow avoids disrupting the larger local communities by bulking out the templates themselves or the lists of templates that would be a positive. While Abstract will eventually get round to some form of this, because it's a smaller component of their overarching plan, a more tailored project might be more beneficial Nosebagbear (talk) 15:13, 18 November 2020 (UTC)[reply]
This is very much in the high cost/high benefit category—it seems like a daunting task, but the savings in duplicated editor effort will make it worth it. I'm not sure if the community wishlist team would be able to take it on, though. {{u|Sdkb}}talk02:57, 19 November 2020 (UTC)[reply]
I updated a task, I think we can eat elephant part by part. Articles are not always translated entirely. Sometimes it is necessary to translate a single section, and it is convenient to do this by copying the wikitext. At the same time, templates are often found in wikitext on local languages. And it's good if these are english templates, there are often local analogues for them. In some wikis cite web analogues has "URL" and not "url" parameter name. Replacing template names and parameters can be automated. If users will have opportunity to insert analogs of parameter names themselves (I don’t know how best to do this, via wikidata or by filling in json tables), then data will be collected that can be used in the future directly for global templates. Carn (talk) 13:24, 19 November 2020 (UTC)[reply]
Complete infrastructure standardization/unification would be GREAT. And IMHO the EN wikipedia has the most complete and good standard. Making a scalable version of template (basic, rich, full) maybe a good solution for translations or for smaller audiences or countries. But using the SAME template could help a LOT the work of a global wikipedia. This is a standard in every kind of structured and collaborative work :) --Wikit2006 (talk) 22:06, 22 November 2020 (UTC)[reply]
See the big section I added after the "Discussion" section. If User:Carn agrees to these ideas, I recommend rephrasing the top as follows:
"Problem: Small or new wikis don't have template infrastructure. Old versions of templates that they copy from big wikis are not updated properly." -> This should be changed. This problem is very real and important, but the truly complete solution for this is doing the whole Global templates proposal, which is probably too big for the Community Tech team. It should be done, but at this stage, I recommend addressing a different, smaller problem: "Some templates in different wikis have similar functionality, but it's unnecessarily difficult and time-consuming to copy them from one wiki to another."
"Who would benefit: Volunteers editing templates and modules and users of small wikis." -> I recommend changing it to "Who would benefit: Volunteers who edit in more than one wiki and who copy, adapt, and translate information from one wiki to another."
The current proposal at the top says: "There need to be some json on Commons or other way for users to translate parameters of templates and templates names". In the big section I added, I explain my current proposal for how this will work. Very briefly, I recommend not changing anything at this point, but simply reuse the current algorithm in Content Translation, which is based on TemplateData, and making it available to more users. --Amir E. Aharoni (talk) 13:39, 26 November 2020 (UTC)[reply]
Admin from SqWiki here. Truth is small Wikis (like we are) rely mostly on EnWiki for everything. Most of our new articles come from CTT from EnWiki. Same is also true for technical things like templates, etc. In most cases, the workflow used to "create" a new template by a user is this: Starts to write something translating from EnWiki. -> Realizes a certain template is missing in SqWiki. -> Copy-pastes the template from EnWiki, importing it, usually without translating its components. -> Saves it as a template with the same name as in EnWiki, without a doc subpage and continues working on the page it was working with when the "template inconvenience" presented itself. 90% of our templates are with English names and without explanatory subpages (documentation) because of this process. They are not even connected on Wikidata, because people don't bother to do so. Actually that's where the untranslated title comes into help because you can search for it on EnWiki to read its documentation if you want to change something (and hopefully connect them on Wikidata). So anything that helps facilitate template importation and, hopefully, change the aforementioned workflow, is a very good thing to have. - Klein Muçi (talk) 12:01, 27 November 2020 (UTC)[reply]
OK, so I'm in a strange conflict of interest here: I'm writing this as User:Amire80, a volunteer editor in several wikis, but I should mention that I'm also User:Aaharoni-WMF, a staff member of the Wikimedia Foundation, in the team that develops Content Translation, which is related to this project. I'm also the author of mw:Global templates and most of its subpages. With these disclaimers out of the way:
Global templates were already proposed in the Community wishlist in 2015, and came in at #3. On the results page it's listed as "in development", but it wasn't actually developed: it was, understandably, too big for the Community tech team, and it somehow slipped from the Parsing team plans, too. However, the wish is very much alive, and lots of people still think it's necessary (one example). So what can be done by the Community Tech team as a reasonable step towards making this come true?
The appropriate thing to do about templates translation in the context of Community Tech is to implement my suggestion in https://phabricator.wikimedia.org/T243150: build a Template adaptation service and the frontend for this service. Here's how it will work:
Refactor the part of cxserver that adapts templates in Content Translation, so that it would be usable not just in Content Translation, but also in the wiki syntax editor and in Visual editor. (cxserver is a simple backend Node.js service that works together with Content Translation. One of its functions is template adaptation.)
The technology for mapping template titles and parameter names doesn't change at this stage, and remains the same as in Content Translation / cxserver. The algorithm is as follows:
If the template page in the source wiki is not linked to anything in the target wiki through a Wikidata sitelink, fail: "This template is not associated with any template in the target wiki".
If the template page in the source wiki is linked to a template in the target wiki through a Wikidata sitelink, use the title of the target template for adaptation.
Check whether the target template has TemplateData defined. If not, fail: "The target wiki does not have TemplateData".
Check each parameter name in the transclusion and search for it in the target template's TemplateData:
If there is a parameter with the same name, use it.
If there is no parameter with the same name, but there is a parameter with the same alias, use the main name of that parameter.
If nothing could be found in the previous two points, fail: "Parameter $1 couldn't be found in the target wiki" (replace $1 with the parameter name).
The parameter values are copied as-is. Auto-adapting parameter values can be added in the future, but it's not a part of this proposal.
There will be no functional change for end-users of Content Translation. The code from cxserver will be moved to a separate service, and Content Translation will just switch to using that service for template adaptation.
Global template wiki syntax adaptation tool frontend, with empty fieldsGlobal template wiki syntax adaptation tool frontend, with input and output When editing in the 2010 wikitext editor, people will have a new button: "Adapt a template". This button will allow the following (see the mockups):
The editor copies the wikitext of a template transclusion in another wiki. For example, a transclusion of {{Cite encyclopedia}}.
The editor clicks the "Adapt a template" button in the toolbar. Clicking the button shows a dialog box. This dialog box has a selector for the source wiki, and two text fields: Source template and Target template. The "Source template" is editable, the Target template field is read-only.
The editor selects the source wiki in the wiki selector, for example "English Wikipedia". The target wiki is the current wiki, in which the page is being edited.
The editor pastes the template source to the top box.
The box queries the template adaptation service.
If the adaptation worked, the adapted template output is shown in the Target template field.
If the adaptation failed, the reason for the failure is shown (see the "fail" points in the adaptation algorithm above).
When editing on mobile devices, a similar dialog can be shown.
When editing in Visual Editor, the template can be simply copied from one wiki and pasted in another. This will work similarly to copying and pasting wikitext and converting it to rendered HTML on the fly. When copying, the source wiki name will be stored in the clipboard. When pasting, VE will query the template adaptation service and try to adapt the template. If it fails, VE will show the reason.
When editing in the 2017 wikitext editor, it will work similarly to VE, and the "Adapt a template" button can be available, too.
Why do I believe that it's a good task for Community Tech?
It's relatively small.
It doesn't change any deep algorithms, and only gives editors more convenient access to already-existing technologies.
It fits together well with existing editing tools, and once it's deployed it simply becomes a part of the editing workflow.
It adds a tool that is not specifically about languages and translation, but also about any cross-wiki activity. For example, copying a template transclusion from English Wikisource to the English Wikipedia is sometimes needed.
It's somewhat comparable to the TemplateWizard extension, on which the Community Tech team already worked in the past.
Template adaptation service flowchart. This proposal deals only with the API entry point, the gray process boxes, and the green result box. The blue boxes will be in a future project, but this project here is supposed to be forward-compatible with it.
Why develop it now? Why not wait for the start of the work on the Global templates repository? It's not certain when will the work on the Global templates repository begin, or whether it will begin at all. Whenever this happens, it will be a very large project. On the other hand, the template adaptation service proposed here is a much smaller project, and it will be immediately useful to editors in all editing interfaces: wikitext 2010, wikitext 2017, mobile, Visual editor, and Content translation.
Where does it fit in the bigger Global templates roadmap? If and when the full-fledged Global templates repository will become available, such a service will be needed. If this project is done, then it will already be mostly available! The service's API will remain the same, and using the global repository instead of local TemplateData will become a new branch in the algorithm. (See the attached flowchart.) All the client editors probably won't need any modification.
@Amire80 - there is d:Wikidata:Property proposal/Wikipedia infobox field active now, and some broadside view would be helpful. Such properties of templates will allow us to see (preferably, of course, in automatic mode) which templates are most ready for transfer to a centralized repository.
If the data is stored in the form of tables on commons, then the tool for working with such a table (script in the browser), together with the tool for using such a table for translation (button in the text editor) will help the community. If now there are some options for centralized storage of templatedata, we must immediately link this solution with it. At least I'm talking about the data storage format. It is not our job to create more unnecessary duplication in an attempt to combat unnecessary duplication. Carn (talk) 09:59, 6 December 2020 (UTC)[reply]
The reason for delveoping it now is that it's needed now. I don't underant why its such as major problem, tho it might be if implemented at once for all languages. DGG (talk) 10:27, 29 November 2020 (UTC)[reply]
@Amire80: If defining new variables in templates was possible, wouldn't this be just the matter of mapping $english_variable:={{{localized_parameter_name}}} and calling the en.wiki template within a localized wrapper template? Also, with local template variables some nested template code would be much more comprehensible. Ponor (talk) 08:19, 3 December 2020 (UTC)[reply]
This assumes that English templates are some kind of a "main" version, which is tempting, but wrong. English is, indeed, the main source for translation for many languages, but not for all. Some wikis use other languages as the source for translating content or importing tools: Spanish, French, Russian, German, Polish, Indonesian, Chinese, and so on. In addition, "just [...] calling the en.wiki template" sounds easy, but actually it's quite difficult: Evidently, software developers have attempted to implement cross-wiki transclusion since 2004, and never managed to complete it. It will certainly be done some day, but it will have to be done in baby steps.
More generally, the $english_variable:={{{localized_parameter_name}}} syntax you are proposing may be good, but it's new. Any new syntax will require much more development resources from the engineers, and much more adaptation effort from the template maintainers on the wikis. What I propose here doesn't add any new syntax, but uses the existing wiki markup and TemplateData. Even the adaptation algorithm that I propose is already implemented in the code of cxserver, and I only propose to refactor it so that it would be directly usable from all versions of the wiki syntax editor and the Visual editor (currently it's only usable from Content Translation).
Strong support Templates are an major component of MW functionality. They should be bundled already long before now. Valuable effort is dissipated by everyone having to do templates for themselves. --Rob Kam (talk) 10:16, 14 December 2020 (UTC)[reply]
Support --Wikiourembaya (talk) 18:51, 14 December 2020 (UTC) Les critères de notoriétés ne nous facilitent pas de travailler sur les personnalités africaine, que faire ? Aidez-moi. Merci pour les évolutions pour les langues comme n'ko (nqo).[reply]
Strong support Sometimes I happen to translate an article, and the work behind the scenes is more than the actual translation... --.mau. ✉ 11:25, 18 December 2020 (UTC)
Problem: Translation tool is only WYSIWYG, it should enable users to edit source at early phases as well, or at least enable a way to for an automated move of such article to their drafts
Who would benefit: Mostly Wikipedia Editors, those who are translating content to other Wikipedia Projects.
In these countries which use a way more customized templates, or have specific formatting requirements, that usually are not met by WYSIWYG translator.
Also, it would be beneficial to users who currently use workaround by working on source in drafts.
Project overall, as this automation will accelerate progress and improve engagement of such translators.
Proposed solution:
While browsing articles in English Wikipedia, we are encouraged to create translations to languages which don't have that article yet. (E.g. in case the article for our language is not present, the language is grayed out at the languages list).
While creating articles in a different language than English, the visual editor/translator (WYSIWYG) is run by default, (the popup: "This page does not exist in polski yet. Do you want to create it?").
Popup with just one big blue button, that takes users to WYSIWYG
Solution consists of a workflow and adding of a small link beneath the big blue button. User by clicking it gets the article created in own drafts DIRECTLY, with source edit flawlessly being opened.
Other possibility, just to add source code preview at visual translator stage. I bet there exists number of users who will prefer to be able to edit code, at the incredibly early stage of article.
Now, many users must use following workaround: start a newly translated article, then they move the article to their drafts, and then edit its source there.
I think possibility to automate this behavior, introducing a small link for that under the blue button, taking user to user's drafts so they can already work on source in their drafts space, will benefit in engagement, and allow to grow drafts more.
Thank you!
Proposed solution: add DeepL among the machine translation possibilities for raw first step content translation (see Machine translation availability for already available machine translation services)
Sorry if this is a dumb question but where exactly would this be used? I understand that in Google Chrome and possibly other browsers, it's the default that pages are translated (automatically or by user request) with Google Translate, but is this part of the Wikipedia interface? If not, where would this be introduced? — Bilorv (talk) 00:19, 14 December 2020 (UTC)[reply]
Support DeepL is indeed a very useful tool and more efficient than Google. I don't know for Japanese, but it's true for all the European languages I know. --Braveheidi (talk) 20:38, 8 December 2020 (UTC)[reply]
Support DeepL is the best translator nowadays. Some languagues don't have it, but for translations from English to German/Russian/..., it's very useful. Ján Kepler (talk) 14:15, 9 December 2020 (UTC)[reply]
Comment Well, yes... but let's focus on languages that are not in the top 10... so languages that are out of DeepL. Those with most resources shouldn't be ourp priority. -Theklan (talk) 18:16, 11 December 2020 (UTC)[reply]
Support preferably: develop competitive open alternative to DeepL. it’s sad having to rely on a product and servers that you don't control, especially for private texts/non-WP applications. Reseletti (talk) 19:05, 18 December 2020 (UTC)[reply]
Problem: Many images involve text. In order to preserve the information, formats like SVG allow for elements as such instead of a simple bitmap. This is used in many images in Wikimedia projects, for example maps, infographics, charts... However, each project uses a specific language that may have local forms for a toponyms, or name. That forces to different versions of the same file in commons, such as Commons:File:Central_Erope_1572_es.svg, Commons:File:Central_Erope_1572_HU.svg and Commons:File:Central europe 1572.png.
This works but is suboptimal since:
Reusability is reduced: For example provided, graph editing skills will be needed to use the image in more languages.
Maintenance work is increased: If I find a mistake in the image in es:wiki I can correct it. But I will need to do three different corrections to ensure all wikis are updated. This may be feasible for a small population (let's say local wiki and en:, as main targets) but is not scalable to a portfolio of projects like Wikimedia with hundreds of local projects.
Some alternative options exist like Kartographer but are not widely used.
Who would benefit: translators of content between wikis, people who do commons maintenance work, small wikis that are more reliant on commons and translation tools.
Proposed solution: I wonder if a more interactive SVG can be done where a text could be linked to a Wikidata element. For example in the above-mentioned map, instead of the text "Upper Hungary" I'd like to link to Wikidata Element Q999030. This already include the version for several idioms so a local wiki can retrieve localized names. There is already work in Wikidata for using a related language when no local version exist which provides a fallback.
It will reduce the amount of files in commons, facilitate a multilingual review and update of mistakes, facilitate reuse of images (with synergies with the content translator, since currently there is no integration for image translation), reduce barriers for small wikis.
@SWilson (WMF): I didn't know that tool, thanks. For me it shows the idea is possible. However, the most valuable part, the "emerging" capability related to Wikimedia is still missing. The tool is still focused on a traditional monolingual approach from language A to language B which does not scalate very well with many languages. The tool alone means if I'm from a small/infrarepresented language I will still need to translate, review and reupload thousands of existing files in commons, requiring a huge quantity of manhours just to take advantage of existing images in Commons like this or this. It also means duplicated human work to translate the image but also to provide the same translations in Wikidata for infoboxes (let alone the article, categories, etc). I'm afraid also means by the time many of them are translated, some may already be outdated (I'm thinking of election diagrams) or forked by other reasons. Finally, it also means a weak spot for vandalism, since the new files will require new patrolling and will not benefit of the review and update of existing files (the second example I now link has 26 different versions and potentially should have one per Wikipedia). I think there is potential to further develop the tool to streamline all of this if we could use Wikidata to enhance the translation and if we can have dynamically generated images instead of multiple translated versions of the same svg.--FAR (talk) 18:52, 8 December 2020 (UTC)[reply]
"it also means a weak spot for vandalism" I was wondering about this. I see the utility of your proposal -- it basically amounts to Mark Twain's aphorism [paraphrased] "put all of one's eggs in a single basket and watch that basket" -- but based off how often I see vandalised, incorrect, or nonsensical labels on Wikidata (or would you draw from 'title', 'name', 'official name', 'name in native language' and 'nickname' statements instead of the labels/descriptions?), it would be useful to be able to specify a particular oldid of the entity in question, otherwise many files might 'inherit' the vandalism and it would be hard to track from the filepage or client wikis since the error would be transient and the pertinent history at Wikidata. That could be ameliorated in the tooling of course, but only if such [mis]use cases are kept in mind. Arlo Barnes (talk) 16:24, 9 December 2020 (UTC)[reply]
Problem: AFAIK Translator only works for whole existing pages, and if you need only a part of the content from somewhere it cannot be used if target page already exists. Also, such translator could be used in case of bugs while loading the original page, which occurs from time to time.
Who would benefit: All
Proposed solution: Implement translator functionality to enable wikitext snippet input as an alternative to page focused approach. After wikitext is copied into the translator input window, the translator should continue to function in visual mode, and the final result should be available again as a wikitext or alternatively as a page in user space.
@MusikAnimal (WMF):, @Amire80: - not necessarily. Section translation would be a big improvement, of course, but why don't just go all the way? New sentences of wikitext, for example, once inserted in the original text, would not be translatable via section translator feature, or could be, but it would be complicated. Also, there is often an example of ordinary text to be newly inserted into the article and translated, not inserted anywhere within WP before. Or if you want to translate a snippet of related page to be inserted on different target language page. I could go on and on. All of that would be easily solved with one button which would display a modal window for arbitrary wikitext insertion. Once the wikitext is inserted, switch to VE, and after the translation is done you could either save the snippet in your user space, as a new page, or (even better) copy/paste the translated wikitext into the article you are working on. For instance, I'm working on evolution related content. As such, I often have the need to pick and choose at least 10-15 snippets from English wiki article, translate them, and insert them into the Croatian wiki. Those snippets are from different sections, say 2-3 from each. If I would need to use by section translation, it would complicate my work considerably. The alternative would be to give the users the ability to translate any page in their user space to any language - I would prepare the snippets within my userspace, translate, save, and than copy to the article. I would still prefer copy/paste arbitrary wikitext approach in any case. Cheers! Imbehind04:15, 3 December 2020 (UTC)[reply]
User:Imbehind, thanks for the clarification! What do you think about Community Wishlist Survey 2021/Miscellaneous/Templates translation? See the section at the bottom, "Practical suggestion: refactor CX template adaptation". What you suggest here sounds very similar to what I suggest there: a panel that allows the translation of a template from one wiki to another. I even added mock-ups there. My suggestion there is more modest, only talking about automatic translation of the template title and parameters, and leaving the translation of parameter values to the human editor. But if this is done, it can later be easily extended to covering any wikitext and not just templates. --Amir E. Aharoni (talk) 07:43, 3 December 2020 (UTC)[reply]
@Amire80:, I'm not sure if your template request is more modest. It doesn't sound complicated but for my proposal, everything apart from a button and modal window for input and output is already there. I'm not sure the same could be said about the templates, but your proposal is also worthwile. Imbehind14:00, 3 December 2020 (UTC)[reply]
Problem: Gadgets and Userscripts are an important part of the Wikiverse. There are numerous such scripts that are used by a large number of users. Currently, those scripts are often copy-pasted from one wiki to another, to allow to translate them into the local language of the wikis. By that process lots of duplicates emerge that need to be maintained and improved independently. Further often several different scripts exist for one problem, because the script was not known outside the origin wiki, often again due to the language barrier (as well as the issue of missing findability of scripts – but this problem is currently tackled by a different WMF project).
Some scripts have translations into multiple languages integrated (mostly on Commons/Wikidata), there are issues with that. See below.
Who would benefit: All editors and some readers
Proposed solution: There should be one simple way to make the user interfaces of an userscript/gadget translatable (known as i18n). The mechanism has to full fill the following requirements:
Easy to use for tool developers. Something like mw.translate("English text") should be enough.
The translations should be saved separated to the script. Probably as a page with content model JSON.
All regular editors should have the rights to translate scripts. Which user group ("autoconfirmed", "editor", …) will be needed is up to debate but the current situation where only the script author and sysops can translate the script must be avoided.
Translating should not require technical know-how. An easy-to-use user interface is required.
point 1 is technically already possible. mw.msg() translates a message-key into a translated string (just like used in core). Gadget authors can add their own keys and translations by making a json table and importing each key with mw.messages.set(). It just lacks in terms of conventions for gadget authors on how to store the translations and to a large degree also people simply putting in the effort to consistently add internatinalization as well as a way in which more users can contributed with the translation process. —TheDJ (talk • contribs) 19:20, 21 November 2020 (UTC)[reply]
Problem: When I'm translating an article in the wikipedia translation page and I save my work and close the page before publishing, all my references get lost and the page only displays a message that says something like "the content is in another source", then when I look into the "references" section, it's all blank, so I have to errase all the citations and write them again.
Who would benefit: Translators and editors
Proposed solution: Save the references in the same format that the article is written so they don't get lost when saving before publishing. I don't know much about programming so excuse me if I don´t give a better proposal.
More comments: It's a problem that only arises if the translation is saved and the page closed before publishing. When publishing the article before saving and closing, references stay fine.
@Pginer:, I think this will interest you. Braulio, there are a lot of different issues with references in the ContentTranslation tool (see tracker in [1]). It will be helpful if you can give specific examples to identify when is still causing trouble.--FAR (talk) 11:16, 29 November 2020 (UTC)[reply]
Support A translation of the citation template (not of the text of the reference itself which has to be preserved in its original language) to the destination language would be highly appreciated. Shinkolobwe (talk) 16:44, 17 December 2020 (UTC)[reply]
Problem: There is a bug in the content translator that scrolls the screen every time something is typed. This bug makes the translation annoying and almost makes the quick translation that is promised impossible.
Who would benefit: All users using the content translator.
Proposed solution: Fix the bug, which would have the effect of not rolling the screen.
Problem: We have to switch to desktop mode to use this tools and have to zoom in and out. It's not mobile-friendly.
Who would benefit: All mobile editors.
Proposed solution: Create a simpler version for mobile that won't ask us to change into desktop mode. I'm not sure how because I'm not major in tech but would be glad if there's a tool such that.
More comments: I did translation manually because of this, I copy and pasted passages in google translate, then I copied the translated one and paste again in target page. Then I've to back to original page to copy the references. Then I got to click on the interwiki link if it exist and check what's the title in local Wikipedia. Everything was done manually except translating.
Problem: If translation contains 100% of unmodified text, ContentTranslation don't allow users to publish. However, some users may want to publish draft first and then correct it.
Who would benefit: Content translators
Proposed solution: If users want to publish draft, then the issues are regarded as resolved.
@Pginer: this may interest you. However, I personally don't think it will be a good idea. Each wiki has a different relationship with ContentTranslation, with some communities having a high success ratio with the published articles whilst others are having a worse experience. The limit of unmodified text is one of the key parameters used to tailor ContentTranslation to the needs of each project.--FAR (talk) 09:59, 29 November 2020 (UTC)[reply]
Oppose this will give room for people in a translation quizzes/competitions and non speakers to publish unproofread/uncopyedited pages just to get more article counts. Em-mustaphaUser | talk15:33, 9 December 2020 (UTC)[reply]
Oppose "Some people will want to" do all kinds of dumb things. We do not need to have the devs waste time helping them do dumb things. If you insist on making a local copy before doing any work at all on it, just make a one-character change. — SMcCandlish ☺☏¢ >ʌⱷ҅ᴥⱷʌ< 08:27, 15 December 2020 (UTC)[reply]
Support Rumpelstilzchen (talk) 16:17, 18 December 2020 (UTC)
Strong support It's about time that this thing gets done. It's. About. Time. Let's do it. --Sannita - not just another it.wiki sysop 14:57, 9 December 2020 (UTC)
Comment Well, yes... but let's focus on languages that are not in the top 10... so languages that are out of DeepL. Those with most resources shouldn't be ourp priority. -Theklan (talk) 18:16, 11 December 2020 (UTC)
Oppose this will give room for people in a translation quizzes/competitions and non speakers to publish unproofread/uncopyedited pages just to get more article counts. Em-mustapha User | talk 15:33, 9 December 2020 (UTC)
