Naoko Takano 3:16 pm on May 27, 2016

Cross-Locale PTE Trial

As I briefly mentioned in the last weekly chat, I want to discuss the way we handle importing translations of multiple localesLocale Locale = language version, often a combination of a language code and a region code, for instance es_MX denotes Spanish as it’s used in Mexico. A list of all locales supported by WordPress in https://make.wordpress.org/polyglots/teams/. For the sake of simplicity , I’m only referring to plugins here but this applies to themes as well.

The question is this:

What is the best way for an organization/business with a team of in-house (or hired, third-party) translators to import their PluginPlugin A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party translations into translate.wordpress.orgtranslate.wordpress.org The platform for contributing to the translation of WordPress core, themes and plugins.?

There was an in-depth discussion on this on SlackSlack Slack is a Collaborative Group Chat Platform https://slack.com/. The WordPress community has its own Slack Channel at https://make.wordpress.org/chat/., in which @matt suggested testing a small number of cross-localeLocale Locale = language version, often a combination of a language code and a region code, for instance es_MX denotes Spanish as it’s used in Mexico. A list of all locales supported by WordPress in https://make.wordpress.org/polyglots/teams/ PTEProject Translation Editor A Project Translation Editor (often referred to as PTE) is a person, who has access to validate strings on a specific project (for example BuddyPress, WooCommerce or Twenty Fourteen) for one specific locale. A project translation editor can approve strings that are added by translation contributors. Per project translation, editors are appointed by a general translation editor after a request by the project author or by the contributors themselves. accounts.

Current situation:

Only individuals with ability to fluently speak the language can become a PTE
Plugin authors can’t import PO/MO filesMO files MO, or Machine Object is a binary data file that contains object data referenced by a program. It is typically used to translate program code, and may be loaded or imported into the GNU gettext program. This is the format used in a WordPress install. These files are normally located inside .../wp-content/languages/ translated by someone else

Proposal:

Conduct a trial: allow the account associated with a Plugin author to become PTEs for multiple Locales, which can then import languages files translated and reviewed outside of translate.wordpress.org.

The goal for this trial is to see if it’s possible to streamline the translation process for plugins with a team of their own translators while maintaining the quality.

Criteria for the trial plugins (some ideas):

Provide links to the style guides and glossaries the translators are using
Disclose the sources of translation (e.g. translation vendor) and reviewers (.org username)
List steps for .org community volunteers to get involved in the review process
Have a separate .org account just to do the cross-locale imports, and fill in the profile page with contact information
PingPing The act of sending a very small amount of data to an end point. Ping is used in computer science to illicit a response from a target server to test it’s connection. Ping is also a term used by Slack users to @ someone or send them a direct message (DM). Users might say something along the lines of “Ping me when the meeting starts.” GTEs after imports (at least during the trial period, if the GTEs want to be notified)

From a GTEGeneral Translation Editor A General Translation Editor (often referred to as GTE) is a person, who has global access to validate strings on all projects for a specific locale.’s point of view – it’s impossible for our team of 6 Japanese GTEs to review tens of thousands of plugins on our own. I’m happy to have more PTEs (including cross-locale ones) handle translation if they are willing to work together and improve the quality.

And as someone whose job is to help internal team translate their software projects, I would love to see us forge closer collaboration between business organizations & the community that will help make WordPress plugins available in more languages.

Torsten Landsiedel 3:09 pm on May 29, 2016

I’m really interested to hear the opinion from @samuelsidler here. As a translator and GTEGeneral Translation Editor A General Translation Editor (often referred to as GTE) is a person, who has global access to validate strings on all projects for a specific locale. I am more than happy if professional translations for large plugins (Jetpack, Yoast, etc.) come in. But in the past we followed the path from #metaMeta Meta is a term that refers to the inside workings of a group. For us, this is the team that works on internal WordPress sites like WordCamp Central and Make WordPress.-i18nInternationalization Internationalization (sometimes shortened to I18N , meaning “I - eighteen letters -N”) is the process of planning and implementing products and services so that they can easily be adapted to specific local languages and cultures, a process called localization. This is the process of making software translatable. Information about Internationalization for developers can be found in the Developer’s handbooks. to just allow single people speaking the language fluently. In the end it is a matter of trust: Do we trust them to provide good translations although we aren’t involved in the process anymore (because it is handled externally). For companies like Automattic, Yoast, etc. this will be easy. But what to do with all the other? Do we trust them or not? This is the overall question.

And if we trust them, what can go wrong? Translation propagation is critical here, I think.
- Mattias Tengblad 10:47 pm on May 30, 2016
  
  Translation propagation is critical here, I think.
  
  I agree. If translation propagation “breaks” because of this, it will probably discourage community translators.
Alvaro Gois dos Santos 11:34 am on May 30, 2016

I’m not sure even companies with relevant (and premium) plugins can control the quality of professional translations. I have too many examples in Portuguese pt_PT that they do not – and I mean BIG. Therefore, as this can be a good way to accelerate translation import, there’s also a huge slip hazard.
Dominik Schilling (ocean90) 1:09 pm on May 30, 2016

I agree that this all about the right amount of criteria.
The list mentioned by @Nao is a good start. Some other ideas are a random review process and imports by “Cross-LocaleLocale Locale = language version, often a combination of a language code and a region code, for instance es_MX denotes Spanish as it’s used in Mexico. A list of all locales supported by WordPress in https://make.wordpress.org/polyglots/teams/ PTEProject Translation Editor A Project Translation Editor (often referred to as PTE) is a person, who has access to validate strings on a specific project (for example BuddyPress, WooCommerce or Twenty Fourteen) for one specific locale. A project translation editor can approve strings that are added by translation contributors. Per project translation, editors are appointed by a general translation editor after a request by the project author or by the contributors themselves.” should be publicly logged (like in #polyglots-warnings).
An open question might be whether a “Cross-Locale PTE” is allowed to override existing translations which were suggested/approved by another translator/GTEGeneral Translation Editor A General Translation Editor (often referred to as GTE) is a person, who has global access to validate strings on all projects for a specific locale./PTE.

Pinging @niallkennedy since he requested the same for Twitter. @niallkennedy: I’d like to know your thoughts on this as well.
Petya Raykovska 4:53 pm on May 30, 2016
Мost of us know why we handle PTEProject Translation Editor A Project Translation Editor (often referred to as PTE) is a person, who has access to validate strings on a specific project (for example BuddyPress, WooCommerce or Twenty Fourteen) for one specific locale. A project translation editor can approve strings that are added by translation contributors. Per project translation, editors are appointed by a general translation editor after a request by the project author or by the contributors themselves. and plugins / theme translations the way we currently do, but let’s drop what we know from experience for a second and think about possible ways we can solve the problem with professional translations before we dismiss all of them due to a few mistakes in the past and potential mistakes in the future.

As this is clearly pushed as the way forward, I’d like to focus on discussing ways to potentially execute it that will also ensure:
- Keeping/Improving the quality and consistency of pluginPlugin A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party and theme translations
- Maintaining a healthy relationship with all plugin authors
- Maintaining the growth and the motivation of the translation community we’ve witnessed in the past 24 months
I think there are four main things to address:

General translations quality and consistency

In regards of the quality and consistency of translations, if a plugin author makes sure their professional translators follow a localeLocale Locale = language version, often a combination of a language code and a region code, for instance es_MX denotes Spanish as it’s used in Mexico. A list of all locales supported by WordPress in https://make.wordpress.org/polyglots/teams/’s guidelines and glossary, that will eliminate the high risk of inconsistencies. We can make that a requirement and a failure to comply will result in eliminating their access to import translations.

If a locale does not have a Glossary or a Style Guide, which is the case for a lot of plugins, there might be a case to be made around the professional translators being asked to create one based on current WordPress translations and the terms they’re using. That will also benefit localesLocale Locale = language version, often a combination of a language code and a region code, for instance es_MX denotes Spanish as it’s used in Mexico. A list of all locales supported by WordPress in https://make.wordpress.org/polyglots/teams/ that are running a bit behind on documentation and can be one way for the whole community to benefit from having professional translators involved.

Problem: Potential inconsistency between plugin/theme translations and WordPress CoreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. translations
Solution: Require that professional translators follow the community created guidelines for a specific locale

Eliminating the risk of mistakes

The main issue here is that access to import stringsString A string is a translatable part of the software. A translation consists of a multitude of localized strings. currently means access to approve strings as well.

I think in the case of professional translations and access to upload to all locales, we need to make a clear distinction between users with that access being able to import vs being able to approve translations.

Importing professional translations for languages you don’t speak is one thing – you have the guarantee of your provider that what you’re getting is quality and the right thing. Bulk approving suggestions by the community without speaking the language should not be allowed for anyone. Currently PTEs and GTEs can both import and approve. We need a technical solution – a new user role maybe, that only allows importing strings.

Problem: Approval of community suggested strings by people who do not speak the language
Solution: Access to import vs access to approve strings – requires development

Translating in context – plugin/theme translations QA

When experienced translators or users translate an interface, they do it with a clear knowledge of the context the stringString A string is a translatable part of the software. A translation consists of a multitude of localized strings. is used in – that means they either text translations before shipping them (as we do with all language versions), or being users, they are very clear on where the string will be used and how to test it. As professional translators are often not users, a requirement would be for their translations to be tested in a real environment. There are several ways that can happen:

Problem: Gramatically correct translations breaking the UIUI UI is an acronym for User Interface - the layout of the page the user interacts with. Think ‘how are they doing that’ and less about what they are doing. because they’re not used right in a particular context
Possible solutions:
- The plugin author can ask users for the locale for feedback after importing
- The plugin author/whoever has the access, can ask the GTEs for a specific locale to test with no expectation of immediate response or reaction
Overwriting existing translations

If an import is made by a cross-locale PTE for an existing string translations, submitted/approved by the community, those should not be overwritten. The process goes the other way around: the translations need to be coordinated with the locale glossary and style guide and if there’s a conflict somewhere, it’s the cross-locale PTE’s job to clarify the issue between their professional translators and the General Translation EditorsTranslation Editor Translation editors can approve translations for projects. The GTE (General Translation Editor) and LM (Locale Manager) roles can add new users with the "Project Translation Editor" role that can approve translations for specific projects. There are two different Translation Editor roles:
General Translation Editor and Project Translation Editor for a locale

Problem: Contributions submitted in accordance to community guidelines getting overwritten by imports
Solution: Imports from cross-project PTEs should not be able to overwrite existing translations

Technical implementation of the cross-locale PTEs

Problem: Currently, adding PTEs happens through the backend of each RosettaRosetta The code name of the theme for the local WordPress sites (eg. bg.wordpress.org is a “Rosetta” site). All locale specific WordPress sites are referred to as “Rosetta sites.” The name was inspired from the ancient Rosetta Stone, which contained more or less the same text in three different languages. site associated with a locale. To add cross-locale PTEs, we would need to go to 100+ separate websites. That is not going to scale as only three people active in the Polyglots teamPolyglots Team Polyglots Team is a group of multilingual translators who work on translating plugins, themes, documentation, and front-facing marketing copy. https://make.wordpress.org/polyglots/teams/. have access to all Rosetta sites (myself, Dominik and Sam).

Solution: We need a separate UI for this, maybe tied to a user’s .org profile as opposed to their profile in a Rosetta site. Maybe @ocean90 can suggest the right approach here.

The issues listed above are not the only ones that need to be addressed, but discussing them would be a good start.

Something I’d like to hear from active GTEs about would be:
- What do you think a good trial period should be?
- How do you think we should check about consistency?
- What would the process be if someone fails their trial – would they be granted a second chance?
I like the criteria Nao suggested about qualifying for a trial. What can we add to that?

Please get involved. This is an important discussion. Looking forward to hearing from active Polyglots members – @chantalc @tacoverdo @deconf @casiepa @pixolin @fxbenard @wolly @alvarogois @coachbirgit @luisrull as well as all the rest of the General Translation Editors.
- Chantal Coolsma 5:03 pm on May 30, 2016
  
  In my opinion we should start with some bigger developers. I remember we had a request by Twitter in the past. That would be a good start. Give some of those some room to do their thing and let GTEs monitor how it is going. For example: do translations match the current coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. translation for their localeLocale Locale = language version, often a combination of a language code and a region code, for instance es_MX denotes Spanish as it’s used in Mexico. A list of all locales supported by WordPress in https://make.wordpress.org/polyglots/teams/, etc etc. After everything is going ok, we can let more and more cross localesLocale Locale = language version, often a combination of a language code and a region code, for instance es_MX denotes Spanish as it’s used in Mexico. A list of all locales supported by WordPress in https://make.wordpress.org/polyglots/teams/ PTEs do multiple languages.
- Wolly aka Paolo Valenti 5:07 pm on May 30, 2016
  
  I think that we can ask to follow lines guide and glossary, but anything more.
  
  i think that this trial is an external project, not part o the community.
  
  GTEs, IMVHO, cannot spend theire time to check professional tranlations.
  
  Professional translators are not part of the community, they don’t live in te localeLocale Locale = language version, often a combination of a language code and a region code, for instance es_MX denotes Spanish as it’s used in Mexico. A list of all locales supported by WordPress in https://make.wordpress.org/polyglots/teams/ communities, they are external.
  
  Giving theme full access to all localesLocale Locale = language version, often a combination of a language code and a region code, for instance es_MX denotes Spanish as it’s used in Mexico. A list of all locales supported by WordPress in https://make.wordpress.org/polyglots/teams/, about their projects mean that we accept that translations will be not only community based.
  
  It’s good? It’s bad?
  I don’t know, but external translations will foolow a different path.
  
  Those are my 2 cents,
  - Mattias Tengblad 10:39 pm on May 30, 2016
    
    GTEs, IMVHO, cannot spend theire time to check professional tranlations.
    
    +1
    
    I think it’s important to recognize that there are small Polyglot teams too, we can’t expect GTEs to take on this type of growing work load.
- Wolly aka Paolo Valenti 5:28 pm on May 30, 2016
  
  Two minutes ago I deleted a DM in Twitter.
  
  The modal window translation was really bad, wrong and confusing.
  
  In my opinion the professional italian translation of twitter is not made by italian mother tongue.
  
  Professional translations are not better translations, are, maybe, faster translations.
- Alvaro Gois dos Santos 5:46 pm on May 30, 2016
  
  I believe @petya‘ suggestions are the minimum reasonable conditions for having cross-localeLocale Locale = language version, often a combination of a language code and a region code, for instance es_MX denotes Spanish as it’s used in Mexico. A list of all locales supported by WordPress in https://make.wordpress.org/polyglots/teams/ PTEs.
  
  On the other hand, the problem of non-native translators is real, like @wolly remembers. From my experience, there’s not a lot of web focused professional translators, let alone WordPress focused.
  
  Is there a way to have GTEGeneral Translation Editor A General Translation Editor (often referred to as GTE) is a person, who has global access to validate strings on all projects for a specific locale. pre-approve translations before being imported? As an option or, at least, dependent on a previous contact between the pluginPlugin A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party/theme author and GTEs?
  
  I sometimes suggest people to be PTEProject Translation Editor A Project Translation Editor (often referred to as PTE) is a person, who has access to validate strings on a specific project (for example BuddyPress, WooCommerce or Twenty Fourteen) for one specific locale. A project translation editor can approve strings that are added by translation contributors. Per project translation, editors are appointed by a general translation editor after a request by the project author or by the contributors themselves. for a specific plugin, because I know that person is able to assess the context in which the plugin is used or is likely to already use it or a similar plugin, and, therefore, is more qualified than average to validate translations.
  
  This would somehow take the community in consideration and what is being achieved.
- Alin Marcu 6:06 am on May 31, 2016
  
  I do agree with all the above. In addition, eliminating the risk of mistakes will be quite a challenge. Bulk importing without speaking the language can also result in importing a translation, the wrong one, into a different localeLocale Locale = language version, often a combination of a language code and a region code, for instance es_MX denotes Spanish as it’s used in Mexico. A list of all locales supported by WordPress in https://make.wordpress.org/polyglots/teams/.
  
  I’ve always wondered: If you’re hiring professionals to translate your pluginPlugin A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party/theme, is it so hard to make a requirement for them to contribute as other community members do? I mean, each professional translator will have his own w.org account and will be PTEProject Translation Editor A Project Translation Editor (often referred to as PTE) is a person, who has access to validate strings on a specific project (for example BuddyPress, WooCommerce or Twenty Fourteen) for one specific locale. A project translation editor can approve strings that are added by translation contributors. Per project translation, editors are appointed by a general translation editor after a request by the project author or by the contributors themselves. for one locale. By doing so, as a plugin/theme author you’re eliminating some of the risks mentioned above and you’re allowing the community to easily review, spot and correct possible translation errors or consistency issues.
Pascal Casier 7:10 am on May 31, 2016

@alvarogois: The “pre-approve” is exactly what should not be done, otherwise we all become even more bottle necks in the process.
@petya: The UIUI UI is an acronym for User Interface - the layout of the page the user interacts with. Think ‘how are they doing that’ and less about what they are doing. for adding those PTEProject Translation Editor A Project Translation Editor (often referred to as PTE) is a person, who has access to validate strings on a specific project (for example BuddyPress, WooCommerce or Twenty Fourteen) for one specific locale. A project translation editor can approve strings that are added by translation contributors. Per project translation, editors are appointed by a general translation editor after a request by the project author or by the contributors themselves. should not be a priority when going in a pilot phase. As the number of cross-localeLocale Locale = language version, often a combination of a language code and a region code, for instance es_MX denotes Spanish as it’s used in Mexico. A list of all locales supported by WordPress in https://make.wordpress.org/polyglots/teams/ users will be limited, it’s sufficient to find e.g. a correct update query in the central database to add that user or if not possible a mix of asking all GTEGeneral Translation Editor A General Translation Editor (often referred to as GTE) is a person, who has global access to validate strings on all projects for a specific locale. to add that specific user and then manually going over the remaining ones not done.
I agree with @ocean90 that to get to the “trust but verify”, there should be a clear way of getting notified in one or the other slackSlack Slack is a Collaborative Group Chat Platform https://slack.com/. The WordPress community has its own Slack Channel at https://make.wordpress.org/chat/. channel when an import has happened, easily identifiable.

So my first remarks:
1. GTE should be allowed to overwrite the stringsString A string is a translatable part of the software. A translation consists of a multitude of localized strings. and get the priority over the imported strings. The locale GTE/PTE are supposed to know the local language and style guides, so they have the final word on the strings.
2. Add (trusted) PTE next to the cross-locale accounts so they can help and correct where needed.
3. We need to work on the import for the cross-locale. In a first phase we could grant them PTE rights as that’s the only thing we have, but a different way for ‘importing without overwriting’ should be found
4. We need to continue our effort into style guides and glossaries as those are our bibles for doing the work we do and where we refer to in case of doubts
5. A notification system for those accounts needs to be setup so GTE get notified when an import happened
6. An ‘import-but-not-overwrite’ option should be given to these cross-locale PTE (this might be used later for all contributors)

My main worry in all of this is that currently an import will overwrite whatever a GTE has adapted before, so an endless fight could start in having the correct stringString A string is a translatable part of the software. A translation consists of a multitude of localized strings. translation. So having an import that cannot overwrite validated strings seems to me the priority to avoid loss of quality/reputation.

So it’s clear that development will be needed next to adapting our way of working. But like @petya indicated and probably all of you agree, we might find more agile and innovative ways of working, but we should not lower the high quality standards we have reached so far.
- Alvaro Gois dos Santos 8:27 am on May 31, 2016
  
  Yes, @casiepa, I agree that a “pre-approve” is just not possible and GTEs shouldn’t be a barrier. However, a way of notifying GTEs prior to an import would be important, if not essential. You have to have a way to include this translations in the community workflow, or it’ll be like a whole separate thing. I mean, @deconf is right: “Bulk importing without speaking the language can also result in importing a translation, the wrong one, into a different localeLocale Locale = language version, often a combination of a language code and a region code, for instance es_MX denotes Spanish as it’s used in Mexico. A list of all locales supported by WordPress in https://make.wordpress.org/polyglots/teams/.”
- Bego Mario Garde 7:19 am on June 1, 2016
  
  GTEGeneral Translation Editor A General Translation Editor (often referred to as GTE) is a person, who has global access to validate strings on all projects for a specific locale. should be allowed to overwrite the stringsString A string is a translatable part of the software. A translation consists of a multitude of localized strings. and get the priority over the imported strings.
  
  While I certainly agree that we want to keep sort of control over translations to ensure an overall good user experience, I would imagine that developers who hired a professional translator would feel upset if the work they paid for was edited by a Translation editorTranslation Editor Translation editors can approve translations for projects. The GTE (General Translation Editor) and LM (Locale Manager) roles can add new users with the "Project Translation Editor" role that can approve translations for specific projects. There are two different Translation Editor roles:
  General Translation Editor and Project Translation Editor (who in worst case even might not see the source of the translation and consider their effort as a benefit for the overall user experience). As a result, the quality of work of translation editorsTranslation Editor Translation editors can approve translations for projects. The GTE (General Translation Editor) and LM (Locale Manager) roles can add new users with the "Project Translation Editor" role that can approve translations for specific projects. There are two different Translation Editor roles:
  General Translation Editor and Project Translation Editor could be questioned and compared with the work of professional translators, who by definition should deliver a better work.
Wolly aka Paolo Valenti 10:17 am on June 1, 2016
With regards to the cross-localeLocale Locale = language version, often a combination of a language code and a region code, for instance es_MX denotes Spanish as it’s used in Mexico. A list of all locales supported by WordPress in https://make.wordpress.org/polyglots/teams/ PTEProject Translation Editor A Project Translation Editor (often referred to as PTE) is a person, who has access to validate strings on a specific project (for example BuddyPress, WooCommerce or Twenty Fourteen) for one specific locale. A project translation editor can approve strings that are added by translation contributors. Per project translation, editors are appointed by a general translation editor after a request by the project author or by the contributors themselves. issue, the Italian Community in yesterday’s meeting has agreed to the following
- we do not oppose the initiative of cross-locale PTEs
- we are neutral with regards to the trial, willing to help if it should be a go, but ok even to just go without it
- we feel Devs should be free to decide whether or not to translate directly or to pass through the Community. Both have advantages and disadvantages
- we think that the Community, though, should cater to those who decide not to proceed with their own translation and therefore should not be asked/required to work (voluntarily) on projects that are being translated by paid professionals. For this reason we encourage the development of a specific team that could supervise this work. This solution would free up resources in the Community and at the same time allow for Devs the opportunity/freedom to make whatever choice they deem in their best interest
- we think that the translations should be “signed” in some way as being “proudly provided by the Community” or provided by Dev/whomever. This will induce a clearer view as to the quality of the work (and also gratify the work of the Polyglots”
- obviously style guides, glossary and indications will be freely shared and Devs encouraged in asking their translators to follow them
- the “pro-*TE” team could also randomly test and verify translations periodically to assure quality standards are kept high
- this way, we feel, we could allow both the freedom for the Developers and the standards of the platform, giving value to the work of the Community and of all parts in the process
Naoko Takano 8:46 am on June 2, 2016
Thanks everyone for participating in the conversation, both in this thread and the meeting yesterday. This is not a simple change, but I’m happy to see many polyglots are diving in deep to figure things out together.

To use as a base for the discussion on the criteria, I added this section on the “Roles and Capabilities” page.

Cross-Locale Project Translation EditorCross-locale Project Translation Editor A Cross-Locale Project Translation Editor is an account owned by a plugin or theme author (or the authoring organization), which uses professional translators to localize their product. The cross-locale project translation editor can import/validate strings on a specific project for more than one locale. This role has the same capabilities as a Project Translation Editor over multiple locales instead of one. Cross-Locale Project Translation Editors need to meet a set of criteria before being appointed by General Translation Editors. (Title/Details Pending)
This section is still being discussed (more info).

A Cross-LocaleLocale Locale = language version, often a combination of a language code and a region code, for instance es_MX denotes Spanish as it’s used in Mexico. A list of all locales supported by WordPress in https://make.wordpress.org/polyglots/teams/ Project Translation Editor is an account owned by a pluginPlugin A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party or theme author (or the authoring organization), which has can validate stringsString A string is a translatable part of the software. A translation consists of a multitude of localized strings. on a specific project for more than one locale. This role has the same capabilities as a Project Translation EditorProject Translation Editor A Project Translation Editor (often referred to as PTE) is a person, who has access to validate strings on a specific project (for example BuddyPress, WooCommerce or Twenty Fourteen) for one specific locale. A project translation editor can approve strings that are added by translation contributors. Per project translation, editors are appointed by a general translation editor after a request by the project author or by the contributors themselves. over multiple localesLocale Locale = language version, often a combination of a language code and a region code, for instance es_MX denotes Spanish as it’s used in Mexico. A list of all locales supported by WordPress in https://make.wordpress.org/polyglots/teams/ instead of one. Cross-Locale Project Translation EditorsTranslation Editor Translation editors can approve translations for projects. The GTE (General Translation Editor) and LM (Locale Manager) roles can add new users with the "Project Translation Editor" role that can approve translations for specific projects. There are two different Translation Editor roles:
General Translation Editor and Project Translation Editor need to meet a set of criteria before being appointed by General Translation Editors.

And this on the “Translating Themes & Plugins” page.
Criteria for a Cross-Locale Project Translation Editor (Pending information)
This section is still being discussed (more info).
1. Use the community style guides and glossaries, or create ones based on them and provide public links.
2. Disclose the sources of translation (e.g. translation vendor) and reviewers (.org username)
3. List steps for other .org community volunteers to get involved in the review process
4. Create a new accont for this role rather than using a personal one, and fill in the profile page with contact information
5. Have a SlackSlack Slack is a Collaborative Group Chat Platform https://slack.com/. The WordPress community has its own Slack Channel at https://make.wordpress.org/chat/. account and pingPing The act of sending a very small amount of data to an end point. Ping is used in computer science to illicit a response from a target server to test it’s connection. Ping is also a term used by Slack users to @ someone or send them a direct message (DM). Users might say something along the lines of “Ping me when the meeting starts.” GTEs (TBD – unless auto-notification is possible) after imports
None of these are set in stone, just some examples of how we would document it if the trial goes well. Let’s talk about what need to be changed, clarified, or added in the next meeting.
- Petya Raykovska 11:28 am on June 9, 2016
  
  Hey @nao, just seeing this now, sorry I didn’t reactReact React is a JavaScript library that makes it easy to reason about, construct, and maintain stateless and stateful user interfaces. https://reactjs.org/. earlier.
  
  Let’s please not add anything to the handbook before we have a final agreement on what we’re doing.
  
  These things are still under discussion and can be misleading in our documentation right now.
  
  These updates also don’t make it clear that this is a trial role that does not apply to every pluginPlugin A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party or theme author that wishes to have an account like that.
  
  If we’re going to add anything to the documentation pages, it should be information that these trial projects will start running soon. But as it is now, the role seems a valid one for each author to request.
  - Naoko Takano 12:53 pm on June 9, 2016
    
    Ok, removed them from both pages – at the meeting “draft on the handbook” was requested but probably not meant to be *on* there — yet.
    
    The exact information is in my comment above.
Alvaro Gois dos Santos 7:53 pm on June 8, 2016

I am skeptical about the hypothesis of a Cross-Locale Project Translation EditorCross-locale Project Translation Editor A Cross-Locale Project Translation Editor is an account owned by a plugin or theme author (or the authoring organization), which uses professional translators to localize their product. The cross-locale project translation editor can import/validate strings on a specific project for more than one locale. This role has the same capabilities as a Project Translation Editor over multiple locales instead of one. Cross-Locale Project Translation Editors need to meet a set of criteria before being appointed by General Translation Editors. replace a translation already made by the community when importing a full translation. I suppose one of the criteria, in addition to a prior contact with localeLocale Locale = language version, often a combination of a language code and a region code, for instance es_MX denotes Spanish as it’s used in Mexico. A list of all locales supported by WordPress in https://make.wordpress.org/polyglots/teams/ GTEs, could be the percentage of stringsString A string is a translatable part of the software. A translation consists of a multitude of localized strings. already translated in the project. In a project with a low percentage of translated strings, import will not do major damage. But what about projects where there is already a translation by an established community?

Chating on the #polyglots slackSlack Slack is a Collaborative Group Chat Platform https://slack.com/. The WordPress community has its own Slack Channel at https://make.wordpress.org/chat/. channel I remembered the example of WooCommerce: the Portuguese (pt_PT) community has a very active translation team working with WooCommerce, the devs could hardly find better translators – not because they’re professional translators but because they’re community members, WordPress professionals and know a lot about e-commerce. What would happen if the WooCommerce Cross-Locale Project Translation Editor just imported a new translation and overide the current one?

I’m using this as an example, I’m sure they wouldn’t do that because there’s already local PTEs that would be contacted, I imagine.
- Naoko Takano 1:26 pm on June 9, 2016
  
  I commented on SlackSlack Slack is a Collaborative Group Chat Platform https://slack.com/. The WordPress community has its own Slack Channel at https://make.wordpress.org/chat/. too but will leave a reply here for everyone to see. Heres’ what I said
  
  If there is a situation like what you describe for any other pluginPlugin A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party/localeLocale Locale = language version, often a combination of a language code and a region code, for instance es_MX denotes Spanish as it’s used in Mexico. A list of all locales supported by WordPress in https://make.wordpress.org/polyglots/teams/ combination, I think it’s ideal for a few of active translators to become reviewers (if they have time to do so), so that they can review the professional translations and correct anything out of context, etc.
  Otherwise, PTEs and GTEs can make corrections after imports are done. The downside of this latter method is that their correction may not go into the professional translator’s translation memory (TM) so they will not correct the mistake at the source. Also, the translators (non-*TEs too) can contact the cross-locale PTEProject Translation Editor A Project Translation Editor (often referred to as PTE) is a person, who has access to validate strings on a specific project (for example BuddyPress, WooCommerce or Twenty Fourteen) for one specific locale. A project translation editor can approve strings that are added by translation contributors. Per project translation, editors are appointed by a general translation editor after a request by the project author or by the contributors themselves. to point out things like misuse of a term.
  
  Also, I agree the GTEGeneral Translation Editor A General Translation Editor (often referred to as GTE) is a person, who has global access to validate strings on all projects for a specific locale./PTE translations should NOT be overridden by Cross Locale PTEs.
- Naoko Takano 2:38 pm on June 9, 2016
  
  Added a new issue to the GlotPressGlotPress GlotPress is the translation management software that powers Translate.WordPress.org. More information is available at glotpress.org. pluginPlugin A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party: “Import: Avoid overwriting current translations“
Claudio Sanches 4:24 pm on June 15, 2016

> Conduct a trial: allow the account associated with a PluginPlugin A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party author to become PTEs for multiple LocalesLocale Locale = language version, often a combination of a language code and a region code, for instance es_MX denotes Spanish as it’s used in Mexico. A list of all locales supported by WordPress in https://make.wordpress.org/polyglots/teams/, which can then import languages files translated and reviewed outside of translate.wordpress.orgtranslate.wordpress.org The platform for contributing to the translation of WordPress core, themes and plugins..

I understand that many people are pushing for something like this to happen… But I see this as something necessary or good, the way we’re doing things are going very well.
And most importantly, since the launch everyone knew that plugins/themes were not required to use the translate.wordpress.org. If people want professional translation, they still can using other translations system for they own plugins/themes and they can also hire professionals today to translate in translate.wordpress.org as any user who can go there and translate.
I don’t see why this need to have “special permissions”, seems like give plugin/theme authors the capacity to able to edit/delete topics and reviews from the forum, I see a lot of people wanting it, but the authors also are not required to use the forum too 🙂
Charles E. Frees-Melvin 11:36 pm on June 16, 2016

I think perhaps opening up the import option to anyone is the solution here, and if the are not a PTEProject Translation Editor A Project Translation Editor (often referred to as PTE) is a person, who has access to validate strings on a specific project (for example BuddyPress, WooCommerce or Twenty Fourteen) for one specific locale. A project translation editor can approve strings that are added by translation contributors. Per project translation, editors are appointed by a general translation editor after a request by the project author or by the contributors themselves. or GTEGeneral Translation Editor A General Translation Editor (often referred to as GTE) is a person, who has global access to validate strings on all projects for a specific locale. then it goes to moderation just like the one by one. If the translations are good make them a PTE. It would be nice if there was a button next to the name in GlotPressGlotPress GlotPress is the translation management software that powers Translate.WordPress.org. More information is available at glotpress.org. to make someone a PTE rather then going to rosettaRosetta The code name of the theme for the local WordPress sites (eg. bg.wordpress.org is a “Rosetta” site). All locale specific WordPress sites are referred to as “Rosetta sites.” The name was inspired from the ancient Rosetta Stone, which contained more or less the same text in three different languages. and finding the user and project.
Pascal Casier 6:51 am on June 22, 2016

Hi all, I have started to draft some scenarios. Global comments can go here, specific comments can be added to the document: https://docs.google.com/document/d/112jTcnuIgpGqsGaTwJpW91pitKFlETTKdFFYJvF27iY/edit?usp=sharing
Thanks, Pascal.
- Petya Raykovska 5:47 pm on July 15, 2016
  
  Hi, Pascal, let’s get these on the P2p2 "p2" is the name of the theme that blogs at make.wordpress.org use (and o2 is the accompanying plugin). When asked to post something "on the p2" by a member of the Polyglots team, that usually means you're asked to post on the team blog https://make.wordpress.org/polyglots/., please. Working in closed Google Docs prevents some people from participating in the discussion.
Marcus 3:23 pm on June 30, 2016

This would be a welcome step.

From a pluginPlugin A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party developer’s point of view (who speaks 4 languages fluently), maybe I’m missing something but one thing confuses me with the current setup… there’s this big issue of “trust” being mentioned here, yet ultimately the big trust factor is in the fact that the author is creating good quality code. Translations become irrelevant if the software sucks in whichever way, so there is already an establishment of trust there, why not let the plugin author have more control over translations?

I wouldn’t be opposed to an po file import not overwriting current translations, that could be left to consideration of others or the author could just approve them one by one after.

One frustration is there’s times for example where we find a typo, correcting that fuzzies translations which spell it correctly, would love to be able to just approve those myself and keep those 100% plugins at 100%.

Slightly off topic but touched on here too, why not give plugins the option to externally host projects, as in the ‘translate’ link on wp plugin page points somewhere? Those hosting projects externally now are confusing, since the translate.wp.org link is still there. Then, instead of shipping language files in the plugin, we have a languages folder as we do assets and languages are updated that way. We put a lot of work building our own GP environment, it allows us to have closer ties to translators, the .org way doesn’t.

Cheers,
Marcus
- Petya Raykovska 5:55 pm on July 15, 2016
  
  Hey, Marcus, it’s awesome to get a pluginPlugin A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party author join the discussion.
  
  The issues the translation community has are mostly related to plugin authors using Google Translate in the past, resulting in unusable software (some big, well-respected plugin authors have done it). It is in the best interest of a plugin author to have quality translations, however, and in this case, we’re discussing mostly big companies who translate their plugins using professional translation services.
  
  As much as I understand a plugin author’s desire to speed up the process, there’s a long term goal here that a lot of people overlook: we’re trying to take steps that will ultimately grow the translation community, bringing existing translators of plugins to translate.wordpress.orgtranslate.wordpress.org The platform for contributing to the translation of WordPress core, themes and plugins. rather than keeping them at a distance. The more translators brought in as Project Translation EditorsTranslation Editor Translation editors can approve translations for projects. The GTE (General Translation Editor) and LM (Locale Manager) roles can add new users with the "Project Translation Editor" role that can approve translations for specific projects. There are two different Translation Editor roles:
  General Translation Editor and Project Translation Editor, the better the chance is that those people will stick around to translate other projects as well, as well as the coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. project.
  
  That’s why the encouraged and number 1 preferred method to bring translations to your plugins on translate.w.org will stay as it currently is: we ask plugin authors to bring their existing translators to the platform.
  
  Importing for everyone, given the team gets the right tools that will allow the current GTEs to be able to reactReact React is a JavaScript library that makes it easy to reason about, construct, and maintain stateless and stateful user interfaces. https://reactjs.org/. easier to potential problems, can be a step in the future.

Translate WordPress

Weekly Meetings

Posting here

Cross-Locale PTE Trial

Current situation:

Proposal:

Criteria for the trial plugins (some ideas):

Translate WordPress

Weekly Meetings

Posting here

Current situation:

Proposal:

Criteria for the trial plugins (some ideas):

Share this: