Wikimedia Meta-Wiki

Community Wishlist Survey 2022/Translation

< Community Wishlist Survey 2022
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)[reply]

Discussion

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

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)[reply]
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)[reply]
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)[reply]

Voting

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)[reply]

Discussion

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)[reply]

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)[reply]

Voting

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 (https://www.deepl.com/) 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)[reply]

Discussion

Voting

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)[reply]

Discussion

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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]

Voting

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)[reply]

Discussion

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 (talk • contribs) 13:11, 11 January 2022 (UTC)[reply]

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)[reply]
I've taken the liberty of rewording the proposal based on your comment. MusikAnimal (WMF) (talk) 23:03, 12 January 2022 (UTC)[reply]
Hi, if it helps you, related original communication 3 months ago https://www.mediawiki.org/wiki/Topic:Wilx2puo68ynsual Miroslav Ličko (talk) 20:48, 18 January 2022 (UTC)[reply]
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)[reply]

Voting

ContentTranslation for Wikivoyage

Discussion

Voting

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: https://www.mediawiki.org/wiki/Topic:Wo1y6f8y8p7hfovc
  • Proposer: Eptalon (talk) 22:03, 17 January 2022 (UTC)[reply]

Discussion

  • 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)[reply]
    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)[reply]

Voting

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)[reply]

Discussion

  • 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)[reply]
  • 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)[reply]
    I should say DeepL is the best translator in my opinion but obviously less languages are supported. 汩汩银泉 (talk) 22:22, 12 January 2022 (UTC)[reply]
    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)[reply]
  • 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)[reply]
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)[reply]

Voting

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)[reply]

Discussion

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)[reply]

@SpeckbaronDerZweite: Wir sind gespannt auf Deine Antwort. KSiebert (WMF) (talk) 11:25, 26 January 2022 (UTC)[reply]
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)[reply]

Voting

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)[reply]

Discussion

Voting

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.

Discussion

  • @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)[reply]
  • 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)[reply]
  • 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)[reply]
    • 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)[reply]

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)[reply]

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)[reply]

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)[reply]

 
personal pronoun selection in Wikimedia user settings

In https://meta.wikimedia.org/wiki/Special:Preferences 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)[reply]

@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)[reply]
@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)[reply]
@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)[reply]

Voting

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)[reply]

Discussion

  • 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.-46.127.115.197 23:43, 21 January 2022 (UTC)[reply]
  • Actually zh variant translations were already deprecated and added to blacklist, so this wish should be done at some point. —— Eric Liu（Talk） 10:06, 6 February 2022 (UTC)[reply]
  • If https://phabricator.wikimedia.org/T278639 is solved, does that address this request? Nikerabbit (talk) 17:30, 8 February 2022 (UTC)[reply]
  • Checkout Wiki Converter, this has same feature. you can identify the missing articles. -Neechalkaran (talk) 06:31, 11 January 2023 (UTC)[reply]

Voting

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)[reply]

Discussion

Voting

Make "translate" tags always render correctly

Discussion

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

  • 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)[reply]
    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)[reply]
  • 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)[reply]

Voting

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: https://www.mediawiki.org/wiki/Topic:Wo1wdedl1tn9thki
  • Proposer: Eptalon (talk) 21:47, 17 January 2022 (UTC)[reply]

Discussion

  • 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)[reply]
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)[reply]
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)[reply]

Voting

Retrieved from "https://meta.wikimedia.org/w/index.php?title=Community_Wishlist_Survey_2022/Translation&oldid=22829024"