Streamline the process of adding translation editors for a plugin

[SergeyBiryukov]

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.

[samuelsidler]

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. :)

[deconf]

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.

[pavelevap]

@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...

[netweb]

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

[ramiy]

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]

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.

[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.

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

[ramiy]

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 ).

[deconf]

Replying to ramiy:

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

Cool, your mockups are great!

[pavelevap]

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)?

[netweb]

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."

[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?

[netweb]

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

[pavelevap]

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

But it seems nobody cares :-(

[markoheijnen]

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.

[ocean90]

#1286 was marked as a duplicate.

[ocean90]

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.