WordPress GlotPress translate management confusing and is unscalable

Plugins and themes have translators we trust 100%, we’ve forged relationships with these translators over the years. I’m now finding myself telling my friends and colleagues “I trust you, but for some reason WordPress doesn’t trust me with my plugin”. This all stems from the confusing process that is in place now which can be easily fixed giving the plugin and theme owner direct control of their translators.

UPDATE: After speaking with team members on slack about the process, I’ve now learned that the terms used for translation have changed. These new terms are used by the polyglots team but have not been updated on the documentation, hence the confusion. First some terms to clear up…

Translator Editors != Translators – The plan is to let anyone be translators, but only editors could moderate and approve translations.

Translators != Validators – Same as above, translators can make translation recommendations, only validators can also make translations and approve translations.

The new latest process WordPress.org has in place to manage translations for themes and plugins is two fold. First there are “Translation Recommendations”, then there is “Translation Recommendations with Validations”.

Translation Recommendations

If a plugin or theme owner would like users to “recommend translations”, all the user has to do is create an account on wordpress.org. Anyone with an account on WordPress.org has permission to “recommend” translations for WordPress core, as well as any theme or plugin. I am sure this will not last long, once malicious users get their hands on this the WP.org team will be forced to chance this policy. I like the spirit of this though, but they do not make this clear in the documentation. The way it is written currently and the terms used “translator” and “translator editor” implied to me that once the user created an account they still had to be added as a “translator editor”, but that is why they’ve changed the terms.

Translation Recommendations are placed in a queue to be confirmed or marked fuzzy by translation moderators (Translation Editors or Validators). Plugin and theme developers can request specific users to be validators for specific locales.

Translation Recommendations with Validations

If a theme or plugin owner wants specific users to “translate and validate” translations in particular locales, a request must be made in this comment thread (must include the word “request” in the tag field otherwise your requests go into a black hole) and request users to be “validators” for specific locales for your plugin/theme. Specifically you need to include the following in your posting:

Your @WP.org-user-name
locale code (en or en_US) – @WP.org-User-Name – slug name of your plugin

As of current, plugin/theme owners can only request validator users and must wait for the users to be approved. There is no simple add option like that for adding committers to your project. It appears they are approving all requests, but the process is taking very long to do so. As I understand it, they are not rejecting requests, plugin and theme owners can rest assured they have control of their translations if they request it.

How Translation should be for themes and plugins

Plugin and theme owners should have control who can translate their plugin/theme, which languages can be translated, and be able to add remove translators. Plugin and theme owners should be able to add themselves as validators for any or all locales as well.

Plugin and theme owners should have the ability to decide if a translator has “full translation control” (translator and validator) or if their translations should be moderated by someone else (other valdiators). I like the idea of anyone making translation recommendations, but there should be management screen with setting in a grid view where we as plugin/theme owners can decide if  locale can or cannot be translated as well as enable/disable if translation recommendations are from anyone, or allow fur adding specific users. A grid where the columns are “locale”, “enable/disable (enabled by default”, “Allow anyone to recommend translations”, “recommend translators”, and “translation validators”. Each row would have the locale. The cells within the “recommend translators” and “translation validators” would have a textbox with an add button to add validators, as well as list the current validators with a button to remove them.

These proposed options above would allow a theme or plugin owner to add someone as a translator exclusively, they will not have to be distracted by anyone on WordPress.org making recommendations. The plugin author can also decide if a particular locale should be available or not for their plugin. Defaults though should follow what WordPress.org has in place now which encourages anyone to contribute.

The idea that plugin and theme developers cannot control the process, and that translations happen without the interaction of the theme/plugin developer in my mind violates GPL and certainly creates issues for copyrights. Luckily, this is not the case. Currently the polyglots team is changing “terms” for translation management which lies the confusion.

Why do Theme and Plugin Developers need to be moderators of their translations?

As creators of a product, albeit free and open source, there are situations where words, phrases cannot or should not be translated. For example, a website name (not the URL), plugin author should be able to decide if it remains as-is in some languages but can be translated in others. Many of these terms are copyrighted and in other cases, are technology terms that if translated, may cause more confusion. It should be up to the plugin/theme owner to have final say.

There is a way in the code to prevent some parts of strings to not be translated, but it does not control this down to the specific locales.

Another problem comes with companies who have translators on staff and can do translations. Our company has to add our employees (which can change over time) to have access to translate. What was a simple here’s the po file go to work operation has now turned into “I have to wait for WordPress.org to approve our  our employee fluent in French to be a validator for our plugin”.

Plugin and theme authors should be able to decide which languages are translated. Though I wouldn’t use such a feature, I could see a company like Facebook prevent translations for certain languages/locales until they have the language locale added to their service.

Current process does not scale

The current process at translate.wordpress.org is not going to scale to 40,000 plugins with 50+ translation possibilities each. I don’t care how many volunteers there may be helping with translations, adding a comment to a blog post it’s not going to work, we’ll see some plugins receive priority moderation (validating) over others, which will more than likely be influenced politically.

At some point a page for plugin owners wil lneed to be created that lets them pick a locale and enter a wp.org user and click ‘Add’. The faster and smoother they can make this process the less confusing it will be for all involved, and the faster new translators will start contributing.

I’m already wasted a few weeks trying to figure out how the process works, which appears is still being figured out, which also bothers me that these problems were not even discussed or thought about.

I want centralized translation to work

Do not read above and believe that I am anti WordPress or anti translation. I want this to work. To not trust the plugin / theme authors with the responsibility of controlling their translations is not only wrong, it poses the problems I describe above. This process needs to be fixed ASAP.

I would ask that you do not post comments here. Instead, I’ve opened a trac ticket requesting that this process be changed. Please comment there so WordPress translate team can read your concerns about how theme and plugin translations are currently managed. Update: My Trac ticket has been closed, feel free to comment below.

Leave a Reply

Your email address will not be published. Required fields are marked *