WordPress.org

Making WordPress.org

Opened 3 years ago

Closed 3 years ago

#1237 closed enhancement (fixed)

Streamline the process of adding translation editors for a plugin

Reported by: SergeyBiryukov Owned by: ocean90
Milestone: Priority: high
Component: Translate Site & Plugins Keywords:
Cc:

Description

Currently, the process of assigning translation editors for a particular plugin looks like this:

  1. Plugin author submits a request on Polyglots (example)
  2. I have to invite the translation editor to https://ru.wordpress.org/.
  3. I have to wait until they accept the invitation (periodically checking the dashboard and/or the Polyglots blog).
  4. Once they accept, I have to go back to dashboard, find the user, remember the plugin name, find it in the list, and finally assign them as a translation editor.

This could easily become time-consuming if there is more than one request per day.

We should either eliminate steps 2 and 3 or allow plugins authors to assign translation editors for their plugin themselves.

Attachments (4)

plugin-admin.png (41.9 KB) - added by ramiy 3 years ago.
plugin-admin-translators.png (62.8 KB) - added by ramiy 3 years ago.
plugin-admin-translators-tab.png (37.6 KB) - added by ramiy 3 years ago.
plugin-admin-translators-tab-status.png (41.8 KB) - added by ramiy 3 years ago.

Download all attachments as: .zip

Change History (28)

#1 @netweb
3 years ago

  • Cc stephen@… added

#2 @samuelsidler
3 years ago

Agreed. We need to make this easier.

Dion thinks that Editors should be able to invite any user and set them up with the per-project TE role. However they'd still have to accept the invite before being confirmed. That would remove most of the friction here. Essentially, for Editors, the process would become...

  1. Add a new user to the site and at the same time assign them a TE role for a specific project.
  2. User shows as "unconfirmed" or "invited" or something until they confirm the email.
  3. Once the email is confirmed, the TE can go about like normal.

For plugin authors, this becomes a one-step process (request on make/polyglots). For Editors, this becomes a one-step process (add the user). For TEs, this becomes a one-step process (accept the invite). That's what I call a win-win-win!

Ultimately, this is just expanding the role drop down to add TE and require a project be selected (All Projects is an option, obviously).

It might also be advantageous to allow Editors to add current users (that is, users who already exist on the site) through the same method, so they don't have to scroll through the list of users and update their role if the TE is expands to more than one project. But that's probably another ticket. :)

#3 @samuelsidler
3 years ago

  • Priority changed from normal to high

#4 @deconf
3 years ago

  • Cc admin@… added

This ticket was mentioned in Slack in #meta-i18n by deconf. View the logs.


3 years ago

#6 @pavelevap
3 years ago

  • Cc pavelevap@… added

#7 @deconf
3 years ago

I think it would be awesome to have something like this at some point:

  1. A plugin author adds a TE for a locale from his plugin administration screen (on wordpress.org).
  2. A request is generated for GTEs of the corresponding locale (available in Rosetta in a dedicated screen) and at the same time an invitation is sent to the TE.
  3. After a GTE confirms the request in Rosetta and the TE confirms his invitation, the user is automatically added to the plugin's project as a TE on the specified locale.
  4. The plugin author will also be able to check the status of its requests and manage confirmed TEs using its administration screen.

This will basically eliminate the need of a request on Polyglots/P2.

Last edited 3 years ago by deconf (previous) (diff)

This ticket was mentioned in Slack in #meta-i18n by deconf. View the logs.


3 years ago

#9 @pavelevap
3 years ago

@deconf: Yes, it would be fine, but:

I added translator requested by plugin author, but this translation is not very good and sometimes misleading. And together with other "features" (project cross matching), those people can also "damage" some other projects. And I am not mentioning that they can use tools like Google Translator to achieve 100 % limit needed for language packs. Polyglots should have some kind of control, I guess...

#10 @netweb
3 years ago

Related: #1242 Per locale @mention that emails all translation editors

#11 @ramiy
3 years ago

Another approach:

Currently, each plugin owner can add committers to his plugin using the plugin admin panel:

https://wordpress.org/plugins/xxxx/admin/

The process is very simple.

We can create a similar mechanism to add translators in the plugin admin panel. It will have a select box for the language field and an input for the user name.

This way, the entire process is made by the plugin author. One step controlled by the plugin author.

@ramiy
3 years ago

#12 @ramiy
3 years ago

Also, we can create another tab in the plugin page for translators.

The general public will see only the users list (like credits page), and the plugin admin will be able to add/remove/invite new translators.

#13 follow-ups: @deconf
3 years ago

@pavelevap - IMHO you shouldn't add a TE to a plugin if he's not meeting the expectations! At step 3. the user will become a TE only for that specific plugin.

@ramly - We need the GTEs approval in the process. IMHO keeping consistency among translations for the same locales is mandatory!

Last edited 3 years ago by deconf (previous) (diff)

#14 in reply to: ↑ 13 ; follow-up: @ramiy
3 years ago

Replying to deconf:

@ramly - We need the GTEs approval in the process. IMHO keeping consistency among translations for the same locales is mandatory!

No problem, we can add the request status ( unconfirmed / invited / pending GTE approval ).

#15 in reply to: ↑ 14 @deconf
3 years ago

Replying to ramiy:

No problem, we can add the request status ( unconfirmed / invited / pending GTE approval ).

Cool, your mockups are great!

#16 in reply to: ↑ 13 ; follow-up: @pavelevap
3 years ago

Replying to deconf:

@pavelevap - IMHO you shouldn't add a TE to a plugin if he's not meeting the expectations! At step 3. the user will become a TE only for that specific plugin.

Yes, I know, but it is very hard to refuse somebody (translator and plugin author can be disappointed). I can go through translation and reject some strings, but it is not sustainable to check them all when there will be many plugins and themes.

When some user adds new translation and has rights only for specific plugin, then this translation will not be propagated throughout all other projects (cross matching project)?

#17 in reply to: ↑ 16 @netweb
3 years ago

Replying to pavelevap:

When some user adds new translation and has rights only for specific plugin, then this translation will not be propagated throughout all other projects (cross matching project)?

No, I believe this indeed does happen at the moment, this is what I believe currently happens:

"If a translation is approved it propagates to all sub projects in that parent project, (e.g. a plugin translation will get propagated to all plugins but *not* themes) regardless of the fact of if the user is only an approved translator for a single plugin and not all plugins which will result in all plugins now having this translation string approved."

#18 follow-up: @pavelevap
3 years ago

@netweb: OK, thank you! But it is serious problem, I guess, because every plugin has another context. Simple example, in one plugin is "Name" used in the sense of name of living people, but in another plugin it is "Name" in the sense of some kind of title. In our language are these words strictly different for living and non-living things. I used this simple example, but there are many similar issues. By approving this string we are making automatically mistake in many plugins?

Also, when somebody (not very experienced translator) adds any wrong translation for any theme, it will be propagated throughout all other themes? How can I bulk repair it for all themes?

#19 in reply to: ↑ 18 @netweb
3 years ago

Replying to pavelevap:

@netweb: OK, thank you! But it is serious problem, I guess, because every plugin has another context. Simple example, in one plugin is "Name" used in the sense of name of living people, but in another plugin it is "Name" in the sense of some kind of title. In our language are these words strictly different for living and non-living things. I used this simple example, but there are many similar issues. By approving this string we are making automatically mistake in many plugins?

Also, when somebody (not very experienced translator) adds any wrong translation for any theme, it will be propagated throughout all other themes? How can I bulk repair it for all themes?

I agree, we should look into and discuss this in a new ticket

#20 @pavelevap
3 years ago

I commented several weeks ago directly here: https://glotpress.trac.wordpress.org/ticket/327

But it seems nobody cares :-(

#21 @markoheijnen
3 years ago

I have been busy the last weeks to build up my own company so hadn't had much time to volunteer back to GlotPress. I do care about how stable GlotPress is and I have replied to the ticket with the suggestion to disable it for now. Which is a hard decision to be made but I feel it's needed for now.

This ticket was mentioned in Slack in #meta-i18n by sam. View the logs.


3 years ago

#23 @ocean90
3 years ago

#1286 was marked as a duplicate.

#24 @ocean90
3 years ago

  • Owner set to ocean90
  • Resolution set to fixed
  • Status changed from new to closed

In 1942:

Rosetta: Allow to make users a Translation Editor even if they aren't a member of the site yet.

If a user isn't a member of the site add them as a subscriber.

Fixes #1237.

Note: See TracTickets for help on using tickets.