Opened 6 years ago

Last modified 3 years ago

#3423 new task (blessed)

Add new functionality for editor/locale requests

Reported by: danieltj's profile danieltj Owned by:
Milestone: Priority: normal
Component: Translate Site & Plugins Keywords: 2nd-opinion


There has been quite a lot of discussion within the Polyglots team about changing how we manage editor requests. Currently, the Make/Polyglots site is used to manage these requests but it's become clear that it simply isn't manageable as requests get lost, people forget etc. It's been proposed that we find a new way to handle these types of requests and reserve the P2 for the Global Team for other things instead.

Current list of proposed ideas (not exhaustive at all):

  • Add new functionality into Translate.WordPress for users to click a button to 'request PTE' status.
  • Add a new forum to the support forums where people can post a new thread to request things.
  • Add a new UI to somewhere, perhaps a Rosetta site where people can request PTE status.
  • Add a new Trac instance so people can create a ticket for a request.

Lots of ideas, some better than others but also some are more difficult to implement too.

We need something to integrate into the current PTE workflow that'll let GTEs add new PTEs easily as the current workflow doesn't work very effectively.

Please discuss and share ideas on how best to approach this.

Attachments (1)

new-pte-workflow-idea.png (48.3 KB) - added by Nao 6 years ago.
Ideas for new PTE workflow

Download all attachments as: .zip

Change History (23)

#2 @casiepa
6 years ago

Thanks Daniel for starting this.

There are 3 use cases for PTE requests that should be considered and find a place somewhere:

  1. A plugin author that indicates usernames of people that have translated and agreed to become PTE
  2. Any user can request to become a PTE for a certain plugin/theme
  3. Cross-locale PTE requests from companies that have paid translations

Some ideas:

  • Maybe on on the contributors page ( ?
  • Depending if you are the author (can that be detected there?) or not, you get different questions? Like if you are author 'enter locale and username', if you want to become PTE yourself only 'enter locale'.
  • CL PTE could in fact also start from here but might need a different process.
  • For the GTE that need to validate there could be 1) A page on with the list of requests per locale or 2) a list on the local Rosetta sites. Of course a notification needs to be sent, but as these are sites, standard notification rules could apply probibly easily.

#3 @ChantalC
6 years ago

All solutions where there is custom work involved in changing meta sites, isn't desirable I think. Therefore a trac system like for example would have my preference. Most flexible solution.

Then there could placed a link on the plugin/theme pages to instantly create a new trac ticket (when logged in with your .org account).

This ticket was mentioned in Slack in #polyglots by nao. View the logs.

6 years ago

This ticket was mentioned in Slack in #polyglots by petya. View the logs.

6 years ago

#6 @wolly
6 years ago

I think, IMVHO, that a backend page, in Rosetta, with the list of request, could be very interesting.

A dev, could ask for PTEs, in the plugin or theme page, a user colud request to become pte on the plugin/theme page and/or on translate.

Maybe, an automatic post on meke polyglots

#7 @Mte90
6 years ago

Maybe use the nickname of author of the plugin as PTE or an interface to simplify this part.
As I know very often the author want to be also a PTE.

#8 @ocean90
6 years ago

#1643 was marked as a duplicate.

6 years ago

Ideas for new PTE workflow

#9 follow-up: @Nao
6 years ago

To summarize, the steps will be:

  1. Initiate a PTE Request: Either on Rosetta or Need to send username and project name.
  2. Create a public post: On a new Make P2, Trac, or forum section.
  3. GTEs receive the request: On Rosetta or (if new admin backend is to be created). For now, this may have to be an aggregated view of the system used in step 2 + notification system using a specific keyword.
  4. GTEs approve request or decline with reasons: The resolution is posted back to the system used in step 2.

Here are my thoughts on each step.

Step 1:
I think is most suitable because starting the workflow from there feels more natural & less confusing. Translators are already translating on it, and plugin/theme authors are looking at the list of contributors to determine who should be a PTE.

Step 2:
Creating a new Make P2 sounds good to me. GTEs are most familiar with the format - some of GTEs may not be used to using Trac. Forums currently don't have a way to show all unresolved with a certain tag, so that may require more customization.

Step 3:
Even if we don't have the resource to get a new system for this step, it's still an improvement to get other steps more streamlined.

Last edited 6 years ago by Nao (previous) (diff)

This ticket was mentioned in Slack in #polyglots by ocean90. View the logs.

6 years ago

#11 in reply to: ↑ 9 @danieltj
6 years ago

Thanks for your thoughts on this @Nao. I also agree that is the best place for this as it is essentially the start of the workflow. If people are not familiar with it, then you can argue that they need to be to translate efficiently. I think the next step is getting some kind of proof of concept setup for the meta team to have a look at possibly.

I'd like to try and get started on something but I'll need to get VVV or something working first for the meta environment. I see people requesting PTE status first, and then the manual GTE assignment process afterwards because in theory you should start as a PTE first, then be upgraded to a GTE (that's just my opinion anyway).

I'll put this into Slack again to refresh the ticket and see if anyone else has more thoughts on this.

This ticket was mentioned in Slack in #polyglots by danieltj. View the logs.

6 years ago

#13 @Nao
6 years ago

Another idea.

GTEs for certain locales (fr_FR, es_ES, and it_IT) follow up with the same/similar message after a PTE request is posted on make. polyglots. They have a public guideline about becoming a PTE and sometimes direct the requester or would-be PTE to their local Slack. (example)

It would be easier for those GTEs if such guidelines are automatically posted after step 2 (PTE request post generation).

#14 @wolly
6 years ago

@Nao, thanx, great idea!

This ticket was mentioned in Slack in #polyglots by nao. View the logs.

6 years ago

This ticket was mentioned in Slack in #polyglots by tobifjellner. View the logs.

5 years ago

#17 @maximejobin
5 years ago

Shouldn't a plugin/theme author be able to edit any language they want for their plugin/theme without having to ask ?

That would save time.

#18 @wolly
5 years ago

The problem is not saving time, is having good translations. Most of the plugin developer translation are of a very bad quality, g translated and often wrong. We spend so much time to correct bad translations, that's the big problem. We made mentoring to new contributore, before giving them PTE power

Last edited 5 years ago by wolly (previous) (diff)

#19 @maximejobin
5 years ago

@wolly I get your point and it's valid.

I did not face that situation.

#21 @Nao
4 years ago

Just getting around to post the update on this ticket (from 2 months ago, which I forgot to link it up here):

Other suggestions not reflected in the thread:

Setting a threshold for making a translation request

1) 100% of all strings if the # of total strings is < 50
2) At least 50 strings if the total # is > 50

Auto-populating the form

Check and/or display the most recently translated projects – if that makes sense in terms of the load to the system.

Warning review
After the “Request a review” button is clicked, show a message to ask the translator to review any warnings (if there's any).

Updated flowchart is here:

People who gave feedback were in general agreement to proceed.
As the next step, we need a Translation Review Request form which creates a P2 post when submitted.

#22 @ocean90
3 years ago

In 10628:

WP I18N Teams: Split main plugin class out into separate include files.

See #3423.

Note: See TracTickets for help on using tickets.