Community Wishlist Survey 2022/Translation

15 proposals, 199 contributors, 304 support votes
The survey has closed. Thanks for your participation :)

Section translation of the article (desktop version)

  • Problem: Translation of a part of an article and continuation of translation by other users is provided in some languages and on the Wikipedia mobile application, but this feature is not available in the desktop version of Wikipedia; Adding such a feature to all languages and the desktop version will increase the translation speed and it is not necessary for one person to translate an article completely alone.
  • Proposed solution:
  • Who would benefit: All Wikipedia users, especially translators, will benefit.
  • More comments: This is actually a suggestion to complete and improve the translation in line with this project.
  • Phabricator tickets: phab:T234323
  • Proposer: ‍‍Mohammad ebz (talk) 15:55, 11 January 2022 (UTC)


UOzurumba (WMF), I believe Language may be the right team to respond to that :) SGrabarczuk (WMF) (talk) 02:53, 12 January 2022 (UTC)

Thank you SGrabarczuk (WMF) for highlighting this. This wish has been noted. Also, the phab ticket is open.
UOzurumba (WMF) (talk) 12:01, 12 January 2022 (UTC)
I think the translation part is like ok. Section translation is smaller than full-article translation and we could collaborate with each other. Thingofme (talk) 01:56, 22 January 2022 (UTC)
Supporting the expansion of articles by translating a section is part of the Language team plans. The initial focus of Section Translation has been on mobile, where the experience was completely new and users didn't had support for translation.
We plan for both Content and Section Translation to converge over time. For this to happen we'd have to work on the following:
  • Adapt the desktop translation editor to edit and publish one section at a time when translating sections (while preserving the current behaviour when working on a new article).
  • Unify the Section and Content Translation dashboards. The Section Translation dashboard will become the default for both desktop and mobile, allowing to both create new articles or expand them with sections. The work on the mobile experience of Section Translation is getting the dashboard closer to feature parity.
  • Although the experience to select a section was designed to work on a responsive way, small adjustments may still be needed for it to fit well larger screens.
Pginer-WMF (talk) 15:15, 25 January 2022 (UTC)


Translator for existing pages

  • Problem: Translator tool do not allow to translate existing pages
  • Proposed solution: Translator tool should load existing translated page content in the tool so that translator can pick-and-choose the content and paste it against existing source.
  • Who would benefit: Translators
  • More comments: This will be beneficial for expanding the pages
  • Phabricator tickets:
  • Proposer: Vikrantkorde (talk) 16:40, 18 January 2022 (UTC)


I discussed with the team today, and I will again point out the items that I think are relevant:

  • With the current user inteface, the translation tool is to be used to "translate" form one language to another. This can be done section by section, but once the translation is "published" the task of the translation tool is done. It is currently not possible to translate "3 of the 5 sections", and come back later to translate the other two.
  • Even listing the translations that have been done will take you to the published page in the respective Wiki (or it will produce an error if that page does nor exist).

My idea (non-technical) would be the following:

  • When looking at translations that you have done using the tool, you have the option:
    1. Jump to to the published page (status quo); integrate a check that the page actually exists.
    2. Load a version into the translation tool; this version would take the version published (or the most current one of the published article), and compare it to the source version (or the most current one) in the source language (User-settable options). The user can then re-translate, or change existing settings, and publish the article again. The Wiki is probably smart enough to work out the difference.
  • In the Wiki, the fact that they were translated, as well as the source language (+article) is stored. Subject to privileges and page protection, every eligible editor gets a button to "contune the translation". This would then bring up a translation view similar to the one above.

Other things to keep track of:

  • At the time of publication, the user might not have the permissions required to publish the page (under that name); we might give the user the opion to publish the page under a different name
  • If I am translating a source page, and when I come back, the source page has noticeably changed, this may need to be reflected in the tool. Luxury option: be able to cycle between revisions of the page (done after the user started the translation)
  • When the user clicks on translations, and this takes him/her to the translated page on-wiki, we might need to check that the page hasn't been deleted since, or that it moved somewhere else (e.g. disambiguation page)
  • When continuing a translation" we need to give good thoughts as to what versions of the source and target page to show to the user.
  • Supposing more than one user is translating a page, and one of the translators publishes, sohuld the other translators be notified? - If so, in what way?

I know it is probably a major piece of work, and it would likely be done in stages.I discussed with a few people of the community wishlist team, and they sounded interested. Hope that this helps. -Eptalon (talk) 21:13, 19 January 2022 (UTC)

Honestly, this proposal just sounds a lot like the section-divided translation tool already proposed above (#2) Xn00bit (talk) 19:13, 28 January 2022 (UTC)


Add DeepL as a machine translation option in ContentTranslation

  • Problem: Content translation allows pre-filling the text using machine translation provided by either Google Translate or Yandex Translate. This is better than nothing, but the quality of their translations is poor.
  • Proposed solution: Add DeepL ( as a machine translation option. In my experience their output is much better than the other two, although they only support 24 languages. Probably make it the default for the supported languages, too. Human review is still required, but I think this will reduce the effort spent on fixing boring things, e.g. correcting the pronouns in languages with gendered nouns.
  • Who would benefit: Translators to/from 24 languages
  • More comments: (I've mostly used it when translating English to Polish, also occasionally for various languages to English, and their result was the best almost every time I tried comparing with the other websites.)
  • Phabricator tickets: phab:T301561
  • Proposer: Matma Rex (talk) 03:39, 22 January 2022 (UTC)


  • 100% agree! I came here to propose the same. In my experience DeepL is really better than Google T. Javiermes (talk) 11:58, 22 January 2022 (UTC)
  • How does licensing work for this? I know there was a special arrangement worked out for Google Translate. czar 23:59, 29 January 2022 (UTC)
    @Czar I researched it out of curiosity. The terms of use for DeepL's paid services [1] state that "DeepL does not assume any copyrights to the translations made by Customer using the Products", so there is probably no licensing problem. (Also, I found this page about our Google Translate arrangement with a bit more detail than the page you linked.) Matma Rex (talk) 00:33, 30 January 2022 (UTC)
  • Would have supported if I had known voting ended at 18 UTC. ~~~~
    User:1234qwer1234qwer4 (talk)
    22:32, 11 February 2022 (UTC)


  •   Support Javiermes (talk) 19:23, 28 January 2022 (UTC)
  •   Support It's the highest-quality machine translation out there. Would be great. Femke (talk) 19:37, 28 January 2022 (UTC)
  •   Support Lahmenfurst (talk) 21:01, 28 January 2022 (UTC)
  •   Support Nad.roz (talk) 22:43, 28 January 2022 (UTC)
  •   Support Izno (talk) 00:02, 29 January 2022 (UTC)
  •   Support Edigodiuss (talk) 02:26, 29 January 2022 (UTC)
  •   Support Shizhao (talk) 04:02, 29 January 2022 (UTC)
  •   Support Ottawajin (talk) 06:08, 29 January 2022 (UTC)
  •   Support 𝑇𝑚𝑣 (𝑡𝑎𝑙𝑘) 07:19, 29 January 2022 (UTC)
  •   Support Curios7ty (talk) 08:55, 29 January 2022 (UTC)
  •   Support +1 Afernand74 (talk) 08:59, 29 January 2022 (UTC)
  •   Support Sajbadina (talk) 10:20, 29 January 2022 (UTC)
  •   Oppose risk of multiplication of automatic translation (even good) without human review too hight Triton (talk) 11:23, 29 January 2022 (UTC)
  •   Support Terber (talk) 11:45, 29 January 2022 (UTC)
  •   Support Nardog (talk) 14:32, 29 January 2022 (UTC)
  •   Support Aca (talk) 15:09, 29 January 2022 (UTC)
  •   Support Likibp (talk) 15:37, 29 January 2022 (UTC)
  •   Support — Omnilaika02 (talk) 19:44, 29 January 2022 (UTC)
  •   Support Vincent Simar (talk) 21:24, 29 January 2022 (UTC)
  •   Support It's my preferred translator for bulk text, requiring minimal corrections during review. DeepL's quality is noticeable. I'm very pleased using it to translate text from English to Lithuanian (my native language) compared to Google Translator, which often comes short. Kunigas Michailas (talk) 22:54, 29 January 2022 (UTC)
  •   Support Added a question above czar 23:59, 29 January 2022 (UTC)
  •   Support Tgr (talk) 00:27, 30 January 2022 (UTC)
  •   Support Ali Imran Awan (talk) 07:18, 30 January 2022 (UTC)
  •   Support Lectrician1 (talk) 07:33, 30 January 2022 (UTC)
  •   Support TheInternetGnome (talk) 08:28, 30 January 2022 (UTC)
  •   Support Ameisenigel (talk) 09:20, 30 January 2022 (UTC)
  •   SupportBilorv (talk) 20:45, 30 January 2022 (UTC)
  •   Support Hkoala (talk) 06:37, 31 January 2022 (UTC)
  •   Support Yes it seems quite good. Gam3 (talk) 07:50, 31 January 2022 (UTC)
  •   Support Elenaib (talk) 12:34, 31 January 2022 (UTC)
  •   Support -- big, big +1 Trizek from FR 13:47, 31 January 2022 (UTC)
  •   Support the wub "?!" 15:02, 31 January 2022 (UTC)
  •   Support Djiboun (talk) 15:05, 31 January 2022 (UTC)
  •   Support Matma Rex (talk) 16:32, 31 January 2022 (UTC)
  •   Support Bencemac (talk) 18:12, 31 January 2022 (UTC)
  •   Support Zapipedia (talk) 19:19, 31 January 2022 (UTC)
  •   Support PatriHorrillo (talk) 19:53, 31 January 2022 (UTC)
  •   Support Lalviarez (talk) 20:54, 31 January 2022 (UTC)
  •   Support MONUMENTA (talk) 23:59, 31 January 2022 (UTC)
  •   Support Kazkaskazkasako (talk) 09:08, 1 February 2022 (UTC)
  •   Support Havang(nl) (talk) 09:49, 1 February 2022 (UTC)
  •   Support Eduardo.noeda (talk) 12:00, 1 February 2022 (UTC)
  •   Support Szymonel (talk) 13:30, 1 February 2022 (UTC)
  •   Support Absolutely agree! RaquelFlorez (talk) 14:00, 1 February 2022 (UTC)
  •   Support Worrida (talk) 14:41, 1 February 2022 (UTC)
  •   Support Thibaut (talk) 16:15, 1 February 2022 (UTC)
  •   Support XavierItzm (talk) 20:14, 1 February 2022 (UTC)
  •   Support Thingofme (talk) 02:39, 2 February 2022 (UTC)
  •   Support Geert Van Pamel (WMBE) (talk) 16:38, 2 February 2022 (UTC)
  •   Support Sargento - A sus órdenes 17:41, 2 February 2022 (UTC)
  •   Support Aimwin66166 (talk) 06:17, 3 February 2022 (UTC)
  •   Support I came to say propose the same thing. Rotavdrag (talk) 11:30, 3 February 2022 (UTC)
  •   Support In my opinion DeepL is the best CAT in the web. Giacomo Alessandroni let's talk!   14:32, 3 February 2022 (UTC)
  •   Support Paucabot (talk) 15:51, 3 February 2022 (UTC)
  •   Support Pintakuda (talk) 09:46, 4 February 2022 (UTC)
  •   Support Dsalerno (talk) 00:58, 5 February 2022 (UTC)
  •   Support - Darwin Ahoy! 02:10, 5 February 2022 (UTC)
  •   Support Rdr3141 (talk) 09:03, 5 February 2022 (UTC)
  •   Support Kpjas (talk) 12:52, 5 February 2022 (UTC)
  •   Support Exilexi (talk) 17:59, 5 February 2022 (UTC)
  •   Oppose --Ciao • Bestoernesto 03:46, 6 February 2022 (UTC)
  •   Support Fehufanga (talk) 07:50, 6 February 2022 (UTC)
  •   Support One of the best machine translation service on the net--Vulp❯❯❯here! 09:01, 6 February 2022 (UTC)
  •   Support —— Eric LiuTalk 10:00, 6 February 2022 (UTC)
  •   SupportThanks for the fish! talkcontrib (he/him) 17:12, 6 February 2022 (UTC)
  •   Support Ayumu Ozaki (talk) 02:21, 7 February 2022 (UTC)
  •   Support DesPsyCHo (talk) 09:35, 7 February 2022 (UTC)
  •   Support Ryse93 (talk) 12:46, 7 February 2022 (UTC)
  •   Support Serg!o (talk) 13:00, 7 February 2022 (UTC)
  •   Support Tom Ja (talk) 17:48, 7 February 2022 (UTC)
  •   Support Readers need a warning, "this page is machine translated from [source page]", sort of like webpage links framed as "ad-supported article." Otherwise readers may be confused by bits of garbage in the machine result. Gpwitteveen (talk) 21:38, 7 February 2022 (UTC)
    Publishing purely machine-translated text is not the point of mw:Content translation (and would be not quite in line with the standards on the various wikis); this proposal only aims to extend the range of available machine translation tools used to aid manual translation. ~~~~
    User:1234qwer1234qwer4 (talk)
    22:30, 11 February 2022 (UTC)
  •   Support ~Cybularny Speak? 23:39, 9 February 2022 (UTC)
  •   Support Quiddity (talk) 08:48, 10 February 2022 (UTC)
  •   Support DeepL should be prefered for the languages it supports, and then google, and in the last Yandex, and in the absolute worst case scenario opt for Bing. Pauloroboto (talk) 10:13, 10 February 2022 (UTC)
  •   Support Wikiusuarios (talk) 20:23, 10 February 2022 (UTC)
  •   Support Marcok (talk) 12:52, 11 February 2022 (UTC)
  •   Support AngryBiceps (talk) 16:07, 11 February 2022 (UTC)

Wiki translate machine

  • Problem: When translating an entry from another language edition of wikipedia, publication is often not permitted. I agree not to publish in the ns0 but if you want to publish in a user sandbox it should not be forbidden as it works better in a sandbox than the translator screen.
  • Proposed solution:
  • Who would benefit:
  • More comments:
  • Phabricator tickets:
  • Proposer: Burgundo (talk) 10:29, 12 January 2022 (UTC)


Content Translation has a a system for quality control that prevents from publishing translations when too much unmodified content is detected. There are different elements in this system and we identified different possible improvements (phab:T251887). Avoiding limits to be applied when publishing in the user namespace is one of them, but it wold be useful to know more details about the issues experienced to identify the underlying problem (preventing the publication of good translations) rather than providing just a workaround. --Pginer-WMF (talk) 15:00, 12 January 2022 (UTC)
For example, some templates or tables are just simply difficult to translate in the Content Translation interface, so as things like source code editing or editing reference lists. In addition, sometimes some machine translation result of some paragraph are so bad due to failure of machine translation engines, that it is more preferable to take the original text and translating them by hand subsequently in draft space. Sometimes translation would also need to adjust paragraph and section layout and that's easier to be done in user namespace than inside Content Translation interface. Sometimes the Content Translation simply bugged out and cannot properly store an article so it would be better to first export what have been done to user namespace or draft namespace first instead of having to dump the entire thing into trash bin and redo the entire thing. C933103 (talk) 22:09, 15 January 2022 (UTC)
Yes, when we can't translate as efficiently most people want to publish the draft in a user draft page, or in Draft: namespace. Howewer, CT has a lot of problem, when we can't edit in source code and a lot of template must be used in source code. Thingofme (talk) 02:36, 22 January 2022 (UTC)
Hello Burgundo, thank you for this proposal. Could you write more about when exactly you experience this? I mean in what situation you find it's forbidden? It may be helpful for you to read the comments above. SGrabarczuk (WMF) (talk) 22:56, 18 January 2022 (UTC)
My experiences are of a different kind. The system does not accept HTML errors that are not easy to find in the tables, or the translation of a paragraph is good and therefore it was not necessary to change the translation. In these cases I am forced to make unnecessary corrections that the program deems sufficient to unlock the translation. This means that it is then necessary to sandbox what has been modified to get published. I still maintain that it would be very useful to be able to publish the raw translation in a user sandbox anyway where you still have to work to fix the notes, wikify and insert the templates that have not been translated. In any case I will continue to make do as I have so far as I have done more than 2000 translations and I am a responsible person as I have also been an administrator on it: wiki for 15 years.--Burgundo (talk) 07:52, 19 January 2022 (UTC)
Would have supported if I had known voting ended at 18 UTC. There are also some bugs related to the calculation of unmodified text, which should ideally be fixed. ~~~~
User:1234qwer1234qwer4 (talk)
20:46, 11 February 2022 (UTC)


  •   Support Izno (talk) 00:01, 29 January 2022 (UTC)
  •   Support Aca (talk) 15:12, 29 January 2022 (UTC)
  •   Support MONUMENTA (talk) 00:00, 1 February 2022 (UTC)
  •   Support, however there would be concerns about machine-translations as it's easy to move into ns0 afterwards Thingofme (talk) 02:49, 2 February 2022 (UTC)
  •   Support I also have this issue - I like using the translation tool for templates, categories, etc., but want to do the actual translation work in my sandbox due to preferring the native tools on Wikipedia. Exilexi (talk) 18:01, 5 February 2022 (UTC)
  •   Support --Ciao • Bestoernesto 03:43, 6 February 2022 (UTC)
  •   Support Ayumu Ozaki (talk) 01:36, 7 February 2022 (UTC)
  •   Support Ryse93 (talk) 12:48, 7 February 2022 (UTC)
  •   Strong support Alhassan Mohammed Awal (talk) 03:33, 8 February 2022 (UTC)
  •   Support Kaicarver (talk) 08:44, 11 February 2022 (UTC)
  •   Support Marcok (talk) 12:57, 11 February 2022 (UTC)

Preserve templates when returning to an in-progress translation

  • Problem: In Content Translation, some markup and templates like Latex code can disappear. For example, when translating articles with math codes (surrounded by <math> tags), if you saved it and come back to the translation page the other day, sometimes all the math syntax disappears.
  • Proposed solution:
  • Who would benefit: Translators
  • More comments:
  • Phabricator tickets: phab:T278323
  • Proposer: Z423x5c6 (talk) 02:25, 11 January 2022 (UTC)


This sounds like a bugreport that should be filed in the bug tracking system phab:phabricator, together with examples (maybe screenshots) of where and when this occured. —TheDJ (talkcontribs) 13:11, 11 January 2022 (UTC)

By the description, the main issue may be a known problem to preserve templates when returning to an in-progress translation (phab:T278323). So this seems more general than just affecting math content. There is also a specific report about math formulas disappearing when publishing the translation (phab:T137803) among other math-related issues captured as sub-tickets of the general issue of supporting specific types of content (phab:T191389). Pginer-WMF (talk) 09:55, 12 January 2022 (UTC)
I've taken the liberty of rewording the proposal based on your comment. MusikAnimal (WMF) (talk) 23:03, 12 January 2022 (UTC)
Hi, if it helps you, related original communication 3 months ago Miroslav Ličko (talk) 20:48, 18 January 2022 (UTC)
Sometimes, a math issue may prevent some good translations, but some copy-pasting can be an idea. However, translating pages is hard and in Extension:Translate, we can't change manually in non-translatable parts. Thingofme (talk) 01:54, 22 January 2022 (UTC)


  •   Support highly welcomed. Can you please consider keep the ongoing translation list – offer posibility open given article in new tab? Thank you. Miroslav Ličko (talk) 20:09, 28 January 2022 (UTC)
  •   Support Libcub (talk) 23:41, 30 January 2022 (UTC)
  •   Support It sounds like the tool could be more helpful to translators Gam3 (talk) 07:43, 31 January 2022 (UTC)
  •   Support Thingofme (talk) 02:41, 2 February 2022 (UTC)
  •   Support KingAntenor (talk) 07:02, 2 February 2022 (UTC)
  •   Support Aimwin66166 (talk) 06:18, 3 February 2022 (UTC)
  •   Support - Darwin Ahoy! 20:59, 4 February 2022 (UTC)
  •   Support --Ciao • Bestoernesto 03:48, 6 February 2022 (UTC)
  •   Support Ayumu Ozaki (talk) 03:30, 7 February 2022 (UTC)

ContentTranslation for Wikivoyage

  • Problem: Currently, it is not possible to use ContentTranslation in Wikivoyage projects.
  • Proposed solution: Make ContentTranslation compatible for Wikivoyage
  • Who would benefit: The entire Wikivoyage community, new users and editors interested in translating articles from other sister projects.
  • More comments: 2020 wish
  • Phabricator tickets: T106469, T105171
  • Proposer: Hispano76 (talk) 00:24, 15 January 2022 (UTC)


  • Also for Wikibooks, as we can translate books. Thingofme (talk) 11:38, 22 January 2022 (UTC)
  • And for Incubator, while we are at it. - Xbspiro (talk) 03:28, 23 January 2022 (UTC)
  • I wonder why (both this and last year) the proposal was so restricted to a single project. This is an equally good idea for Wikibooks, Wikiversity, and Wikinews. ~~~~
    User:1234qwer1234qwer4 (talk)
    21:47, 11 February 2022 (UTC)


Add some basic statistics about article/section/paragraph being translated

  • Problem: When talking about people who learn a language as an additional language, readabililty of a text or section is a big issue. While there are different ways to calculate the readability of a text, most rely on specific word lists ('controlled vocabulary'). Something that would help make a translation understandable is to improve these scores. For this reason, it might make sense to calculate different scores for a text, or a section of text, most notably word length, and sentence length. It might also make sense to highlight sentences that are much longer than the average sentence length; if there's something like a word list, might also make sense to highlgt words that are not part of this list (optional). If there are several such word lists, the user must be able to choose one among those available (optional). The sipmle counting and comparing of word length/sentence length for a given section would already be helpful.
  • Proposed solution: Add word-length/sentence length, for the whole translated text, section being translated, or selection of text. Of course, this should be done for both the source text and the translation.
  • Who would benefit: Translators who want to make sure their translation is easy to understand for a target audience.
  • More comments:
  • Phabricator tickets:
  • Proposer: Eptalon (talk) 22:03, 17 January 2022 (UTC)


  • What about some of the attitude of the readers? Sometimes, we have to translate advance knowledge, which can be hard to implement. Thingofme (talk) 02:37, 22 January 2022 (UTC)
    Even if you are talking about advanced scientific concepts making shorter sentences will make the aticle easier to understand. Also note, that this is just a number (or a set of numbers) that editors can throw around. At least at the start, the success of Reader's digest wasthat they summarized' and shortened other publications. Calculating and publishing these numbers won't keep anyone from doingg anything, but it might help those who at least try to writie in simpler/easier to understand language. -Eptalon (talk) 16:46, 22 January 2022 (UTC)


Add Bing translation

  • Problem: Bing provides Cantonese translation, but Google does not provide it, resulting in having to manually translate it into Cantonese with Mandarin every time after Google translates. Please make an analogy to any language translated into French and then translated into Italian.
  • Proposed solution: Contact and add Bing APIs
  • Who would benefit: Cantonese people
  • More comments:
  • Phabricator tickets: phab:T90207
  • Proposer: 汩汩银泉 (talk) 13:40, 11 January 2022 (UTC)


  • I'm sorry to hear that. I would support adding that option to the translation service.我好抱歉聽到呢個消息。 我支持將該選項添加到翻譯服務中。 This message was translated by Bing into Cantonese from English. 此消息由Bing由英文翻譯成粵語。Dunutubble (talk) 15:36, 11 January 2022 (UTC)
  • Adding a Bing translation engine not only covers more languages for translation, but also comparing multiple translations of a section will increase the accuracy of the translation, and the best translation can be chosen from among them (sometimes Bing translation performance is better than others). Mohammad ebz (talk) 09:10, 12 January 2022 (UTC)
    I should say DeepL is the best translator in my opinion but obviously less languages are supported. 汩汩银泉 (talk) 22:22, 12 January 2022 (UTC)
    About the Cantonese, it's unknown whether Cantonese is a language or a dialect of Mandarin language, with the number of languages is increasing (Chinese has a lot of Yue dialects). Some not-so-popular language is not used a lot. Thingofme (talk) 01:58, 22 January 2022 (UTC)
  • In the case of the Bengali language, Bing Translator translates comparatively more fluently. Besides, Bing Translator has the Assamese language, but Google Translator does not. So adding Bing Translator will greatly benefit Assamese Wikipedians. ≈ MS Sakib  «TalK» 14:53, 12 January 2022 (UTC)
I think that it is necessary to start with the fundamental possibility of using external tools. These external tools should not be used to generate or modify project data, but should only be easily viewable. And the ability to supplement browsing pages with these tools should be enabled or disabled at will through the personal settings.
As examples: 1. 我好抱歉聽到呢個消息。 ( ) & 2. 我好抱歉聽到呢個消息。 ( )
And here's the next step - for automatic translation tools, to provide a customizable and expandable list of external tools. Let's say Google-translator, Yandex-translator, Bing-translator etc. We can expect other alternatives to appear in the near future - this industry is now developing rapidly.
Anticipe pardonu aŭtomatan tradukilon, se ĝia angla lingvo estas ne tre kvalita ( )

Va (🖋️) 10:55, 14 January 2022 (UTC)

  •   Comment license? --Liuxinyu970226 (talk) 03:46, 20 January 2022 (UTC)
  •   Comment I see a lot of Bengali Wikipedians supporting this proposal as there was a discussion previously to add Bing Translator to the Translation Tool for Bengali. I think this proposal will boost up the process. — Meghmollar2017Talk • 12:08, 29 January 2022 (UTC)


Articles that urgently need to be written

  • Problem: So far there is no tool to show fast and easy which articles urgently should to be written.
  • Proposed solution: Under discussion ideas for a possible tool have been exchanged. The tool could bring together internationally most-clicked articles (with many Interwikis) that don't exist in your own language. Alternatively also with sorting options in different categories.
  • Who would benefit: Everyone that writes articles (I am one of them :D) and wants to help to make Wikipedia more connected and complete
  • More comments: Happily at the moment there is this project: "Frauen in Rot" – which is great, but it would be fantastic if one could do the same additionally for other categories, as mentioned, also for internationally known articles
  • Phabricator tickets:
  • Proposer: SpeckbaronDerZweite (talk) 09:23, 11 January 2022 (UTC)


Könntest du weiter beschreiben wie dieses Tool funktionieren würde? Findet es automatisch Artikel, deren Übersetzung fehlt? Oder geben Editoren Artikelwünsche ab? Diese Infos können uns helfen, um herauszufinden, ob sich dieser Wunsch umsetzen lässt. KSiebert (WMF) (talk) 10:44, 26 January 2022 (UTC)

@SpeckbaronDerZweite: Wir sind gespannt auf Deine Antwort. KSiebert (WMF) (talk) 11:25, 26 January 2022 (UTC)
Hallo @KSiebert (WMF),
vielen Dank für euer Interesse. Genau, ich stelle mir das wie eine nach Relevanzkriterien sortierte Rangliste vor und zusätzlich dazu bestimmte Bereiche wie zum Beispiel das "Frauen in Rot". Relevanzkriterien könnten zum Beispiel durchschnittliche Artikelgröße, Klick- und Editierrate oder Anzahl der Interwikis sein. Artikel, für die es keine deutschsprachigen Artikel braucht, weil sich die Inhalte bereits in entsprechenden Hauptartikeln wiederfinden, könnten aus dieser Liste herausgefischt werden (kleiner Redundanzvermerk, kleines Ausrufungszeichen oder dergleichen durch die Nutzer) – auch diese Artikel sind dann aber nicht unwichtig, man könnte damit dann auch explizit schauen, ob es nicht vielleicht doch sinnig ist, da beim ein oder anderen Artikel der internationalen Mehrheit zu folgen und zum Beispiel zwei Artikel draus zu machen. Toll wäre, wenn es für die Rangliste eine Art Filter gäbe: das können dieselben Kriterien sein wie oben genannt, nur dass sie dann eben nicht in Form eines 'Relevanz'-Kriteriums zusammengeführt sind. Es könnte dann auch als Filteroption möglich sein, besagte, eventuell redundante Artikel, die bereits als solche markiert sind, herauszufiltern, sodass man sicher sein kann: das was ich hier vor mir sehe, das wird wirklich gebraucht, um die Wikipedia vollständiger zu machen, ich kann gleich starten und loslegen mit dem ersten bzw. obersten Artikel in der Liste. (Um das zu unterstützen könnte es dazu auch eine einfache Upvote-Funktion geben. Nutzer könnten sich durch die Liste klicken und Artikeln, die sie gerne geschrieben sehen würden, mit einem Upvote nach oben in die Liste klicken und damit den Relevanz-Algorithmus füttern.
Und wenn du mich fragst, dürfte das liebend gerne auf der Starseite als so ein Mitmach/Get started/Losleg-Button zur Verfügung stehen und Leute motivieren, etwas Wichtiges zu tun.
Liebe Grüße
--SpeckbaronDerZweite (talk) 13:01, 26 January 2022 (UTC)


  •   Support Agreed Xn00bit (talk) 19:22, 28 January 2022 (UTC)
  •   Support Lulucmy (talk) 20:39, 28 January 2022 (UTC)
  •   Support Izno (talk) 00:03, 29 January 2022 (UTC)
  •   Support War (talk) 04:30, 29 January 2022 (UTC)
  •   Support Ottawajin (talk) 06:10, 29 January 2022 (UTC)
  •   Support Perüton (talk) 09:35, 29 January 2022 (UTC)
  •   Support Aca (talk) 15:09, 29 January 2022 (UTC)
  •   Support Tgr (talk) 00:23, 30 January 2022 (UTC)
  •   Support Agus Damanik (talk) 01:54, 30 January 2022 (UTC)
  •   Support TheInternetGnome (talk) 08:30, 30 January 2022 (UTC)
  •   Oppose: it seems that volunteers could write such a tool already, and our few wishes in the Wishlist are better suited to WMF-only projects. — Bilorv (talk) 20:32, 30 January 2022 (UTC)
  •   Support A very good idea BihacVet (talk) 21:47, 30 January 2022 (UTC)
  •   Support daSupremo   21:53, 30 January 2022 (UTC)
  •   Support Kcomerfo (talk) 14:45, 31 January 2022 (UTC)
  •   Support Luc Patin (talk) 16:09, 31 January 2022 (UTC)
  •   Support Thingofme (talk) 02:46, 2 February 2022 (UTC)
  •   Oppose KingAntenor (talk) 07:04, 2 February 2022 (UTC)
  •   Oppose What "should" be written is entirely subjective. WMF projects are contributed to by volunteers based on their interests and (hopefully) subject matter expertise. So, write about what interests you and what you're knowledgeable about. Silver hr (talk) 19:20, 2 February 2022 (UTC)
  •   Oppose This doesn't seem like a good idea. I support the previous comment that this is volunteering. Users translate pages based on their interests, so I consider this proposal incompatible with the rules. --MarieVirtuElle (talk) 02:12, 3 February 2022 (UTC)
  •   Support Aimwin66166 (talk) 06:16, 3 February 2022 (UTC)
  •   Support Prof.Flip (talk) 13:56, 3 February 2022 (UTC)
  •   Oppose per others. Daniel Case (talk) 21:01, 4 February 2022 (UTC)
  •   Support --Ciao • Bestoernesto 03:50, 6 February 2022 (UTC)
  •   Support Пан Хаунд (talk) 14:03, 6 February 2022 (UTC)
  •   Support Ayumu Ozaki (talk) 01:40, 7 February 2022 (UTC)
  •   Support Umar-askira (talk) 08:44, 7 February 2022 (UTC)
  •   Support I think this can help motivate people to translate and write more articles —TheDJ (talkcontribs) 16:19, 7 February 2022 (UTC)
  •   Support paul2520 (talk) 18:40, 7 February 2022 (UTC)
  •   Support value-added to this proposal: languages like Uyghur or ones in Myanmar spoken by communities under pressures of major languages or genocide should be given special support to grow the wikipages in those languages. Gpwitteveen (talk) 21:41, 7 February 2022 (UTC)
  •   Oppose Subjective and upto individual projects to decide their priorities — DaxServer (t · c) 14:32, 9 February 2022 (UTC)

Add field about the number of hits for an article when suggesting a translation

  • Problem: The time people have to translate is limited, therefore it might be feasible to dispaly the number of "hits" an article gets in the source language. Articles that get many hits may be more feasiblefor translation
  • Proposed solution: When displaying proposals/suggestions for translations, also display the number of pageviews, and perhaps make the list sortable by this field. The idea is that articles that get many hits in the source language, might also get many hits in the target language.
  • Who would benefit: Translators with limited time
  • More comments:
  • Phabricator tickets:
  • Proposer: Eptalon (talk) 22:18, 17 January 2022 (UTC)


  • I think it's like popular page for translation. Some people like to translate some of the particular subject. Thingofme (talk) 02:38, 22 January 2022 (UTC)
  • I think page view statistics are only available for existing pages? Internal page links might be the better solution, as used in the missingtopics (?) tool. ~~~~
    User:1234qwer1234qwer4 (talk)
    22:11, 11 February 2022 (UTC)


  •   Support Meditating (talk) 19:05, 28 January 2022 (UTC)
  •   Support Ottawajin (talk) 06:09, 29 January 2022 (UTC)
  •   Support Kcomerfo (talk) 14:46, 31 January 2022 (UTC)
  •   Support Thingofme (talk) 02:45, 2 February 2022 (UTC)
  •   Support Aimwin66166 (talk) 06:16, 3 February 2022 (UTC)
  •   Support --Ciao • Bestoernesto 03:34, 6 February 2022 (UTC)
  •   Support Ayumu Ozaki (talk) 01:41, 7 February 2022 (UTC)
  •   Support Tom Ja (talk) 17:47, 7 February 2022 (UTC)
  •   Support paul2520 (talk) 18:39, 7 February 2022 (UTC)
  •   Support The principle of "low hanging fruit" or better "Pareto Principle" makes sense here: put limited time/energy into high volume pages. In some cases, though, low-use but high-value subjects still must be translated as priority. Gpwitteveen (talk) 21:34, 7 February 2022 (UTC)

Male-female and pro-gender variants of the site

  • Problem: Some people may prefer texts that are in their language in the male-female variant and others in the pro-gender variant. Today's Wikipedia does not allow you to switch between these options in your settings.
  • Proposed solution:
  • Who would benefit:
    • Display the content of the page as the user wants.
    • Reduction of tension between these groups.
  • More comments:
Examples of variants
Variant Text
Man Woman She is 5 years old and played with her toys.
Pro-gender They are is 5 years old and played with their toys.


  • @Dušan Kreheľ: Thanks for your proposal. I've machine-translated it into English in preparation for it being translated to other languages. This is a bit tricky because it's not as easy to express gendered nouns in English, but hopefully people will understand what's being proposed here. Also, there's a slightly similar proposal in the Wikisource category, for dynamically replacing archaic spellings (I mention it only because there might be some common way of marking up variants for replacement; I haven't looked into it greatly yet). (Strojový preklad: Ďakujeme za váš návrh. Strojovo som ho preložil do angličtiny v rámci prípravy na preklad do iných jazykov. Je to trochu zložitejšie, pretože v angličtine nie je také ľahké vyjadriť rodové podstatné mená, ale dúfajme, že ľudia pochopia, čo sa tu navrhuje. Tiež je tu trochu podobný návrh v kategórii Wikisource na dynamické nahrádzanie archaických pravopisov (spomínam to len preto, že by mohol existovať nejaký bežný spôsob označenia variantov na nahradenie; zatiaľ som sa tým veľmi nezaoberal).)SWilson (WMF) (talk) 02:53, 26 January 2022 (UTC)
  • Ok. Community Wishlist Survey 2022/Wikisource/Export of modernised texts is useful to read if someone wants to implement it. ✍️ Dušan Kreheľ (talk) 17:33, 27 January 2022 (UTC)
  • LONG-TERM PRACTICALITY?  : What happens if this gender-solution in English changes again? In the past half century, there have been various suggestions and changes. "Ms." has stuck – but using "their" for he-or-she-or-they risks impractical long-term usage. Bottom line: how will Wikipedia revert in the future, after making problem hundreds of thousands if not millions of changes to gender pronouns? --Aboudaqn (talk) 20:29, 28 January 2022 (UTC)
    • I live in the present or in the near future. Not in the distant future. These belong to others. The next generation. They solve and adjust (manually or with robots). And we certainly don't know what the future will be like.
    • The world is not just English. In other languages, changes may not occur as often.
    • Variations can be enriched, closer to certain people.
    • The solution should be complementary.
    • We will have the Movement Charter. It will probably be pro-gender ([2], the question number 108). For man-woman man will be a little less understandable.
    • ✍️ Dušan Kreheľ (talk) 21:04, 28 January 2022 (UTC)

This is only the draft as the idea. The implementation would be after discussions in the community. Implementation should be optional - whoever wants will use this option. If not, then everything will be the same. These are not automatic adjustments. A literal translation does not seem to be correct (when I translate, for example, she → they) . It is also necessary to know the context. In content with many people, translation can be challenging. this problem is suitable for cooking sites for T–V distinction. This implementation would be good wherever the languages are different in a few words. Wikipedia may be less attractive to a group of people if it is not directly in "their" language. I don't know that wiki setting in user settings would be acces via some API in the templates / Lua, except language variable.

@Eptalon, InterstateFive, Joedeshon, Modest Genius, and Silver hr: Response. ✍️ Dušan Kreheľ (talk) 12:59, 6 February 2022 (UTC)

Also, if I want another group to have their own language style (ex. the non-binary people) they should also be allowed to do so.

@Dronebogus: How have the way the non-binary people now? ✍️ Dušan Kreheľ (talk) 14:36, 6 February 2022 (UTC)

Another, the gender language is not only about the he/she and they. More read Language and gender. ✍️ Dušan Kreheľ (talk) 17:18, 6 February 2022 (UTC)

personal pronoun selection in Wikimedia user settings

In there is already a user preference setting as shown in the screenshot here. What more should we do? Bluerasberry (talk) 02:24, 10 February 2022 (UTC)

@Bluerasberry I don't know read this key+value setting from template or Wikifunctions. Another, that setting is a "vocativ" for the user. Missed T–V distinction. Dušan Kreheľ (talk) 09:02, 10 February 2022 (UTC), ✍️ Dušan Kreheľ (talk) 09:05, 10 February 2022 (UTC)
@Dušan Kreheľ: I think that I understand now. The situation is that the Wikimedia interface only has gender options for pronouns. This is because English language gets the most attention. The system works only when another language uses gender pronouns like English. However, this system does not work for other languages which have other ways of communicating gender.
You want gender support for more language systems, including those that use gender in vocative case or this T-V distinction.
Is that correct? Bluerasberry (talk) 13:34, 11 February 2022 (UTC)
@Bluerasberry I wanna the support for more language systems – the User interface or the content of pages (when the little changes the originals). Dušan Kreheľ (talk) 14:12, 11 February 2022 (UTC)


  •   OpposeMr Grey (talk) 11:30, 29 January 2022 (UTC)
  •   SupportJustinGanimard (talk) 21:29, 28 January 2022 (UTC)
  •   Support THainaut (talk) 11:05, 29 January 2022 (UTC)
  •   OpposeElioPrrl (talk) 11:30, 29 January 2022 (UTC)
  •   Oppose --SSneg (talk) 21:20, 29 January 2022 (UTC)
  •   Strong oppose it seems like a bad joke. Wostr (talk) 00:49, 30 January 2022 (UTC)
  •   Support OwenBlacker (Talk) 11:26, 30 January 2022 (UTC)
  •   Strong oppose - Languages other than English have concepts like a grammatical gender(In English: People say that .. -> they, In French: Les personnes disent... -> Elles (they, feminie plural, since personne in French is feminine). In addition, there are languages that have the concept of a dual (special mode to refer to two people), or other modes for groups of people; probably special rules apply when you use these modes. Writing in inclusive language may be modern, cool, and easy, in English, I don't know to what extent it is present in other languages (esp. those with strong patriarchic ideas about society). I don't speak Arabic, Persian, Pashto, Chinese, Japanese, or any of the languages of Pakistan/India/Bangladesh. I don't know how much want there is for a gender-inclusive text in those languages (don't forget homosexuals, transgender,...). Translation is difficult, and needs a lot of knowledge on the culture involved. So, writing a gender-neutral text is something that has to be done manually, and that likely cannot be automated.-Eptalon (talk) 19:39, 30 January 2022 (UTC)
    In addition, each time a text is edited, we either need meta-information to generate the proposals form, or we need to hard-code the proposals. In addition, there may be an issue with the age or background of the reader. Older readers of English might prefer "he or she" over "they" (because in their view "they" is clearly wrong; younger readers may have less of a problem with "they". Also, there may be cutural differences: The Spanish and Portuguese in South America are noticably different from the languages in Europe. As to English: who thought about Belize, South Africa, India, Hong-Kong or Macao. English is an official language in all of them, yet there will be small differences in language use; which might come to light in such cases. Same probably for Dutch in Europe, vs. Afrikaans in South Africa? - So while it would certainly be a nice thing to have, I don't see it can be done easily, esp. if you want to automate it, and be available in several languages. Eptalon (talk) 19:50, 30 January 2022 (UTC)
  •   Support Libcub (talk) 23:44, 30 January 2022 (UTC)
  •   Strong oppose The correct gendered vs non-gendered terminology varies by context and can be complicated. The appropriate treatment should be handled by the local wiki style guide, not set in software preferences. Modest Genius (talk) 20:55, 31 January 2022 (UTC)
  •   Strong oppose Some languages are strongly gender-SPECIFIC and native users are comfortable with that. Other languages are strongly gender-NEUTRAL and native users are comfortable with THAT. Adding such a feature could impose a constraint where it isn't culturally accepted and would risk offending as many people as it satisfied. Joedeshon (talk) 13:27, 1 February 2022 (UTC)
  •   Oppose --Havang(nl) (talk) 09:53, 1 February 2022 (UTC)
  •   Oppose XavierItzm (talk) 20:12, 1 February 2022 (UTC)
  •   Oppose Seboloidus (talk) 00:09, 2 February 2022 (UTC)
  •   Oppose It depends in languages. Thingofme (talk) 02:43, 2 February 2022 (UTC)
  •   Oppose KingAntenor (talk) 07:01, 2 February 2022 (UTC)
  •   Oppose A.S. Universal (talk) 08:02, 2 February 2022 (UTC)
  •   Oppose --Hampcky (talk) 15:48, 2 February 2022 (UTC)
  •   Oppose This proposal makes no sense whatsoever. Silver hr (talk) 19:10, 2 February 2022 (UTC)
  •   Support Gene (talk) 01:25, 3 February 2022 (UTC)
  •   Oppose --MarieVirtuElle (talk) 02:13, 3 February 2022 (UTC)
  •   Oppose Kpjas (talk) 12:57, 5 February 2022 (UTC)
  •   Oppose You can already do this, can't you? --InterstateFive (talk) 02:10, 6 February 2022 (UTC)
  •   Support --Ciao • Bestoernesto 03:36, 6 February 2022 (UTC)
  •   Oppose--Vulp❯❯❯here! 09:07, 6 February 2022 (UTC)
  •   Oppose there are ways to include non-binary people, this isn’t one of them. Dronebogus (talk) 14:14, 6 February 2022 (UTC)
  •   Oppose There are a number of issues with changing all singular references to plural as in the example above. --Dcheney (talk) 16:09, 6 February 2022 (UTC)
  •   Oppose I do not understand the scope of the proposal, and the example given appears to have been scrambled in translation. Significant development and clarification is needed before it could be seriously considered.Zfish118 (talk) 22:44, 6 February 2022 (UTC)
  •   Oppose Ayumu Ozaki (talk) 02:16, 7 February 2022 (UTC)
  •   Oppose i don't see this as a workable suggestion in its current form. I can't how it would work. —TheDJ (talkcontribs) 16:17, 7 February 2022 (UTC)
    • ”I can’t how it would work” perfectly sums up this proposal. Dronebogus (talk) 21:25, 7 February 2022 (UTC)
  •   Oppose Not the place to right great wrongs in the society — DaxServer (t · c) 14:54, 9 February 2022 (UTC)
  •   Strong oppose Clearly not a good idea. Prawdziwy Mikołajek (talk) 17:44, 9 February 2022 (UTC)
  •   Oppose Not necessary at all. --Ján Kepler (talk) 19:15, 9 February 2022 (UTC)
  •   Oppose ~Cybularny Speak? 23:41, 9 February 2022 (UTC)
  •   Support Obviously there are issues to address here and we need more clarity in the proposal, but I support the development of this idea if anyone can more clearly describe an actionable solution. I think more discussion would be useful. Bluerasberry (talk) 02:27, 10 February 2022 (UTC)
  •   Oppose קליאו (talk) 15:35, 10 February 2022 (UTC)

Translatable pages and language converter

  • Problem: Readers using languages that have variants find it inconvenient to read translatable pages (in meta, MediaWiki, wikidata, commons, etc.). The link Special:MyLanguage redirects to the translated page with the users system language. However, take an example of Chinese, the system language of users (defined in Special:Preferences) is often one of the variants of Chinese, for example, Mainland China Simplified Chinese (zh-cn), Taiwan Traditional Chinese (zh-tw), Singapore Simplified Chinese (zh-sg) etc. Translatable pages may have "/zh" subpage, but no "/zh-cn", "/zh-tw", "/zh-sg" subpages, so Special:MyLanguage redirects to the original English page. Page "/zh" may exist (which supports language converter), however Special:MyLanguage does not redirect to it, unless the user's system language is exactly "zh" instead of "zh-cn", "zh-tw", "zh-sg". In case our system language is exactly "zh", the Special:MyLanguage can redirect to "/zh", but not the converted version. Actually, users using Chinese prefer to read Chinese pages converted to their variant, instead of the "unconverted" original Chinese.
    Btw, in this page, the button content that uses {{zh other}} and {{dynamite}} to display my language is also unconverted, as the page lang of this page is not "zh". I hope it can fix too.
  • Proposed solution: For example, if my system language is "zh-cn", the Special:MyLanguage should redirect to the "/zh" translation of page with parameter "?variant=zh-cn".
  • Who would benefit: Users using languages that support language variants.
  • More comments: This issue has been talked about many times in Phab, yet with few solution. I hope the issue can fix through this wishlist survey.
  • Phabricator tickets:
  • Proposer: SolidBlock (talk) 10:00, 12 January 2022 (UTC)


  • First of all, I didn't take part in any of these discussions, but I basically see the following osutions:
    1. Like there's a language setting for the GUI, there should be a language-variant setting, for applicable languages: Example: Serbian exists with Latin Script, and With Cyrillic script. So If a user has set it to say Latin script, and he/she is reading the Serbian Wikipedia, he should get the Lain script version
    2. The other way would be to display a drop-down on a section on the side, listing the differebnt options; that wa it would be easy to switch. The drop-down should be hovering, or it should be in a non-scrolling section. obviously, it should be hidden, for languages where it doesn't apply. Displaying the dropdown mifgt also be a user-settable option.- 23:43, 21 January 2022 (UTC)
  • Actually zh variant translations were already deprecated and added to blacklist, so this wish should be done at some point. —— Eric LiuTalk 10:06, 6 February 2022 (UTC)
  • If is solved, does that address this request? Nikerabbit (talk) 17:30, 8 February 2022 (UTC)


  •   SupportSHEIKH (Talk) 10:38, 29 January 2022 (UTC)
  •   Support In fact /zh translation pages already have LC support, but it looks like the supports work really bad, I thought that there's a Phabricator task mentioned this? IIRC that task was created by Cwlin0416 but I ignored the Phabricator task number for years. --Liuxinyu970226 (talk) 11:37, 29 January 2022 (UTC)
  •   Support Մելանի (talk) 11:40, 29 January 2022 (UTC)
  •   Support Aca (talk) 15:08, 29 January 2022 (UTC)
  •   Support: let's be honest, this is a bugfix, not a new feature. But it needs to be fixed. It's critical to avoid excluding or marginalising certain language speakers from centralised Wikimedia projects (Commons, Wikidata) and discussions that concern the whole community (meta, MediaWiki). — Bilorv (talk) 20:52, 30 January 2022 (UTC)
  •   Support daSupremo   22:05, 30 January 2022 (UTC)
  •   Support Libcub (talk) 23:31, 30 January 2022 (UTC)
  •   Support Trey314159 (talk) 00:19, 1 February 2022 (UTC)
  •   Support A Chinese user (talk) 09:46, 1 February 2022 (UTC)
  •   Support Stefan.Groote (talk) 12:49, 1 February 2022 (UTC)
  •   Support Pavel200071 (talk) 20:33, 1 February 2022 (UTC)
  •   Support Thingofme (talk) 02:46, 2 February 2022 (UTC)
  •   Support So that's why I always land in /zh... 魔琴 (talk) 16:05, 2 February 2022 (UTC)
  •   Support Tangchina236215 (talk) 13:37, 5 February 2022 (UTC)
  •   Support CanadianPeninsula (talk) 15:49, 5 February 2022 (UTC)
  •   Support —— Eric LiuTalk 10:04, 6 February 2022 (UTC)
  •   Support Ayumu Ozaki (talk) 01:37, 7 February 2022 (UTC)
  •   Support I like how change pronunciation and spelling in different languages Ryou14 (talk) 20:51, 8 February 2022 (UTC)

Imporve language converter systems (eg. between simplified and traditional Chinese)

  • Problem: LanguageConverter is usually not used in system messages and translatable pages. For example, editing a MediaWiki-namespaced page "xxx/zh" does not affect "xxx/zh-cn", "xxx/zh-tw", "xxx/zh-sg" etc, which means, readers whose interface language is "zh-sg" sees the original content that is defined by the software, instead of the converted version of "xxx/zh". In Chinese wikipedia, bots are used to automatically convert and create "xxx/zh-cn", "xxx/zh-tw", "xxx/zh-sg" ... pages according to the content of "xxx" or "xxx/zh"
  • Proposed solution: Convert contents automatically when displaying system messages, without the need of creating subpages for each language variant.
  • Who would benefit: Users using language-converter system, for instance, users speaking Chinese
  • More comments:
  • Phabricator tickets:
  • Proposer: SolidBlock (talk) 09:38, 12 January 2022 (UTC)


  • I agree with you, the current method is silly while there is LanguageConverter. --Kcx36 (talk) 10:56, 12 January 2022 (UTC)
  • Where's the scope of this proposal? Does it mean all user interface messages in MediaWiki should be handled by LC? If so, I'm afraid I won't support this. This add extra complexity to the software.--Tranve (talk) 03:49, 21 January 2022 (UTC)
    As I've said before, the LanguageConverter doesn't have many benefits when it's used to handle large sets of short messages, because we have to add a number of extra conversion rules to every message. Tranve (talk) 03:54, 21 January 2022 (UTC)
    A lot of things come by converter rules, like Chinese or number-digits. I don't even know what LanguageConverter means. Thingofme (talk) 11:37, 22 January 2022 (UTC)
    @Tranve: Converted texts may be caches as soon as the pages are created, which works like some bots or gadgets in WP, which creates specific subpages that stores converted text. The LC is used for message pages created, or messages that override default messages. That would not be too much burden for the server. And @Thingofme: you may refer to mw:Special:MyLanguage/LanguageConverter. --SolidBlock (talk) 14:14, 22 January 2022 (UTC)
    I see. Thank you for you clarification. Tranve (talk) 03:54, 24 January 2022 (UTC)


  •   Support James3141592 talk 18:03, 28 January 2022 (UTC)
  •   Support translation system, followed by mandatory review by converter – because robotic translation has real problems, plus issue of citations – and need to see which images can come along with text from original language Aboudaqn (talk) 20:27, 28 January 2022 (UTC)
  •   Support Shizhao (talk) 04:03, 29 January 2022 (UTC)
  •   Support Libcub (talk) 23:42, 30 January 2022 (UTC)
  •   Support Raos10 (talk) 02:19, 31 January 2022 (UTC)
  •   Support Pratodellaspiaggia (talk) 17:32, 1 February 2022 (UTC)
  •   Support Thingofme (talk) 02:39, 2 February 2022 (UTC)
  •   Support SD hehua (talk) 15:24, 5 February 2022 (UTC)
  •   Support CanadianPeninsula (talk) 15:47, 5 February 2022 (UTC)
  •   Support Artem Vynohradov (talk) 15:55, 5 February 2022 (UTC)
  •   Support --Ciao • Bestoernesto 03:33, 6 February 2022 (UTC)
  •   Support Fehufanga (talk) 07:51, 6 February 2022 (UTC)
  •   Support —— Eric LiuTalk 10:08, 6 February 2022 (UTC)
  •   Support Ayumu Ozaki (talk) 01:39, 7 February 2022 (UTC)

Make "translate" tags always render correctly


GeoffreyT2000 (talk) 04:27, 28 January 2022 (UTC)

  • Congratulations for marking all of the affected proposals' "/Proposal" subpages for translation! Now, none of the above seven proposals are affected anymore. But the problem could still affect proposals created in future surveys. GeoffreyT2000 (talk) 05:40, 28 January 2022 (UTC)
    Hehe, as you know by the time voting starts there should be no proposals left for you to use as an example. But thank you for keeping track of this for us! :) There is a more permanent example at User:MusikAnimal (WMF)/Translate example (so long as no one marks the subpage for translation). I'm not that familiar with mw:Extension:Translate internals, but it's possible this is an unavoidable bug. For a moment I thought there was a workaround we could build into our templates, but I see that even transcluding the page directly (and not a /en or /mylanguage subpage as is done with {{dynamite}}), the parser is not recognizing the <translate>...</translate> tags. The thing is, when you view the subpage directly, they are not visible. So this is unique to transclusions. One of the many translationadmins here on Meta may be able to explain this. MusikAnimal (WMF) (talk) 05:41, 28 January 2022 (UTC) MusikAnimal (WMF) (talk) 05:42, 28 January 2022 (UTC)
  • This opt-in behavior of transclusion is intentional to avoid breaking existing templates that rely on the previous behavior. It's possible though that this might change when Translate extension is updated to support Parsoid. Nikerabbit (talk) 18:25, 8 February 2022 (UTC)


Improve translation tool: Fixed (editable) per language mapping of section titles

  • Problem: When tranlating from one language to another, the section titles often either get translated, or they remain untranslated. Many Wikis have style guides what an article sholud look like, including specific section titles. In Simple English, we expect that the 'External Links' be called 'Other websites', or that 'Related pages' be called 'See also'. Similar requirements exist in other languages.
  • Proposed solution: Add a 'dictionary'/'mapping' containing these sections, when translating from one language to another. So, when translating, the tool automatically proposed 'Other Websites' instead of 'External links'. The question remains if there's one 'dictionary', and at the first translation the translator gets a copy he/she can adapt, or have one dictionary per language pair that specific users (based on a privilege) can edit.
  • Who would benefit: Translators
  • More comments:
  • Phabricator tickets:
  • Proposer: Eptalon (talk) 21:47, 17 January 2022 (UTC)


  • Sounds like a good idea. I can see this being very beneficial to translators who are new to ContentTranslation. However, I'd say the specific implementation should be just as a ContentTranslation warning (like the ones we often see in the right sidebar if something goes wrong) suggesting the most common/agreed-upon translation.

    It should also give lots of lee-way; a section title in one topic can be ambiguous if translated the same way in another topic, even if the literal/exact translation doesn't necessarily differ. Maybe just provide a list of viable translations, or use the categories to find where exactly in the semantic field a term used in an article is in. Xn00bit (talk) 19:04, 28 January 2022 (UTC)
Right; I just reread your proposal and realized that you specified specific section titles mentioned in style guides, not free-form section titles. In that case, I agree unequivocally. I'm starting to think that it can even be implemented like a template, so when the community decides to change something, it changes the entire wiki instead of having to do it manually. Xn00bit (talk) 19:09, 28 January 2022 (UTC)
Doesn't seem quite feasible after literally millions of instances of specific section headings exist on the biggest wikis. ~~~~
User:1234qwer1234qwer4 (talk)
22:05, 11 February 2022 (UTC)


  •   Support Libcub (talk) 23:32, 30 January 2022 (UTC)
  •   Support Raos10 (talk) 02:26, 31 January 2022 (UTC)
  •   Support Thingofme (talk) 02:50, 2 February 2022 (UTC)
  •   Support As someone who has to rename "The References" to "Notes and references" in every single translation :) Exilexi (talk) 18:01, 5 February 2022 (UTC)
  •   Support --Ciao • Bestoernesto 03:48, 6 February 2022 (UTC)
  •   Support InterstateFive (talk) 20:39, 6 February 2022 (UTC)
  •   Support Ayumu Ozaki (talk) 03:33, 7 February 2022 (UTC)
  •   SupportTheDJ (talkcontribs) 16:24, 7 February 2022 (UTC)
  •   Support β16 - (talk) 09:07, 9 February 2022 (UTC)