Page MenuHomePhabricator

Wish translation: wish page
Open, Needs TriagePublic

Description

The new Wishlist aims to increase participation among users across the globe and our projects. We can measure this by 1) diversity of submissions and 2) diversity of participation/edits by language/ip addresses.

To create a new wish, users will enter a valid form submission. The form requires fields such as" project, type (bug/new idea), title, description, and users impacted, as well as optional fields for phabricator tickets.

Goal:

  • Help anyone viewing a wish (and its related discussion) in their native language
  • Keep all conversations and edits on a single wish to one page
  • Allow anyone to edit a wish in their native language

Non-goals

  • Conversations about wishes (and wish content) are de-centralized on language-specific wish pages. We risk missing conversations, adding bloat, and changing perceptions of a wish.
  • Machine translations of wishes

Limitations of submission form:

  • The form (specifically description field) will accept wikitext, markup, and images. While we will "construct" a wish page based on the form responses, the description field is open text and a user may also write "H2: proposed solution," for example.

Event Timeline

Does it make sense for this to be the Epic ticket for the translation support for the new wishlist system?

My unserstanding is that we want to allow users to:

  • Access the intake form in their own language. Allowing them to provide the input in their own language.
  • Let anyone accessing the published wish to have access to real-time automatic translation to be able to read the wish contents in their own language.
  • Allow people to create a manual translation for the wish contents as a way to improve the automatic one.
  • Have conversations about the which in a single place where people can participate in their own language and read other people comments with real-time automatic translation when needed.

@abi_ identified some potential tasks that may help to support the above, I added some notes and possible next steps:

  1. Automatic translation of wishes in the readers' language, with redirection to the Translate interface to improve the translation.
    • Next steps: create a ticket, design how the functionality will be exposed. @GLima-WMF is familiar with some parts of the Localization infrastructure and Language selection that may be useful here, but I'm happy to provide additional context and collaborate further on this.
    • As part of the work from the Language team to build an MVP of "MinT for Wikipedia Readers" (T359072), a proof-of-concept to explore how Wikipedia contents can be translated with MinT was created (T340956) and we plan to support a translated view for articles (T359801). It would be great to coordinate efforts and reuse patterns/code when possible. @ngkountas has been working on the MVP and may have more context on the technical detals.
  2. Localisation of the wishlist intake form.
    • Next steps: create the ticket and explore how to sync the form UI messages with the Localization infrastructure.
  3. T327444: Option to redirect talk pages of translated pages to source content's talk page (Not a blocker for initial release)
  4. T295862: View translated messages in Talk pages (Not a blocker for initial release)
  5. T313748: Allow translatable templates to be shown in the user interface language (Not a blocker for initial release)

@Pginer-WMF that sounds right to me.

Access the intake form in their own language. Allowing them to provide the input in their own language.

One thing I have been wondering about… how would we (as staff and/or English reviewers) read these proposals? When we set a page up for translation, we can set the base language to the language in question, right? I guess the burden of figuring that out would fall on the translation admin. But before the translation admin steps in, what should we do? Use MinT to translate to English?

  1. Localisation of the wishlist intake form.

Task is at T361512: Wish form localization. I asked @JWheeler-WMF to untag you guys because we know how to do localization in the form, and I didn't want to burden your team with standard localization efforts. However I am going to look into using message bundles which is new to me, so we might still need some of your help after all :)

Hey @Pginer-WMF - yeah I think this makes sense to create as an Epic. I'm still not totally sure how to do that :)

I'll make sure to work with @GLima-WMF on informing users that a page is Mint-Translated, and direct them to the content translation tool.

Hey @Pginer-WMF - yeah I think this makes sense to create as an Epic. I'm still not totally sure how to do that :)

An epic task is basically a regular task where (a) related sub-tasks are added (check the "Edit related tasks..." option in the side menu) and (b) the Epic tag is included for the task. I was wondering whether the current task should become the epic or a new task should be created instead. So it is more of a question about the scope and organization in Phabricator. In any case, what I'm looking after is a link to a taks from which I can access this whole area of work with the relevant tasks about the Wishlist translation.

I'm totally happy to help with this but want to make sure tickets are organized in a way that best work for your team.

@JWheeler-WMF I created an Epic ticket (T363306: Wish translation), connected the relevant tickets as sub-tasks, and created a ne ticket about the caching support (T363308: Server-side caching for MinT) based on recent conversations. Feel free to rearrange as it best works for you.