WordPress Translate System Feedback

I tried to reply with my latest feedback on WordPress.org handling of Translations but sadly my comment was not approved. I’ve tried to have conversations with developers on WordPress’s slack system but instead of considering the problems I raised I quickly got responsive answers.

Here’s my reply so hopefully someone will read it who develops for wordpress.org and will possibly consider some of the ideas I have for fixing the complicated mess that exists today with plugin (and theme) translations on WordPress.org.

A reply to thread Hello Polyglots, First I would like to say

First I want to make this clear, though I am very critical (I am by nature, i am a developer), I support the translation efforts. I know the reaction when someone criticizes the way things are done is perceived as anti WordPress, that is not the case with me. I will call out BS, but again I’m a developer it is in my DNA. I can tell you as a project supervisor, the way this is setup currently will never scale to the 40,000+ plugins, let alone the themes.

I am glad to see for once a thread not get deleted and actually being replied to that points out some of the problems with the way things are working now. Is there now an official way how we can post these issues or is it hit or miss if they get deleted or replied to? I’ve tried to discuss them on here (they get deleted), also on slack I was given answers (that technically did not answer my concerns) rather than have someone listen to my concerns and let me know my concerns would be considered for discussion (responsive vs considerate support).

These are my thoughts as a plugin developer who is not on the WordPress.org core team. Please take my thoughts and ideas into consideration. I think ideas and critical thought from outside WordPress core is necessary from time to time, like any project or application.

* Plugin developers should be trusted with their translations. This would solve a lot of problems. Yes there will be plugin developers who just use Babelfish or Google Translate, but I have an answer for that at the bottom of this reply.

Note: It is common for a company to pay someone to do translation work. In this example, even though I do not speak French, I may have the translations for French that my company paid for to put into my plugin. The current procedure prevents me from doing this translation when I ask for such access simply because the polyglots moderator says I do not speak French. (who owns the plugin and its’ translations?)
* Let plugin developers determine if a translation can happen or not regardless of percentage completed. I know if the developer doesn’t speak that locale language the translations may not be “correct”, but that is how it works today when not using translate.wordpress.org. After all we want to provide some translation rather than none. None is way worse than 50% translated.
* Provide a simple way for plugin developers to add/remove WordPress.org users as translator editors. It should be in the same place we add additional committers to our projects. Then the current method of posting a comment in a particularly specific way can end which is very frustrating. The latest example how to post requesting translators I saw wants you to praise the team in your introduction, this seems rather self-serving to me, almost as if to reinforce the system in place now is a good one.
* Translate editors should be strict. Meaning if I don’t add translator editors to my project, no one I don’t know is approving translations for my plugin without my knowledge. Yes I know the idea is to allow global translation editors can approve translations for whatever plugin, but this brings up legal issues (see my GPL comment below). Perfect world, the plugin author could simply check a box to say “my translator editors only” or “global translators allowed” next to each locale.
REST OF MY ITEMS ARE ADVANCED ISSUES
*Let plugin developers decide if a translation can even happen. There are situations where I may not want anyone to create a translation into a particular locale. For example, lets say we were going to launch a service in England in April, we may not want a version allowed to be translated until that release.
* Let the plugin developer have the ultimate say about translations. I may have my companies lawyer tell me the translation of a word we use as a trademark in the US cannot be used in France. That that point I as the plugin author need to be able to change that translation (not the translator editor I picked) Ocean90 pointed out some code I can add in PHP to do this but it did not quite answer this specific case, only how i can target locales.
* Ultimately, the translation is part of the plugin and thus the management should be in the control of the plugin developer. Not allowing the plugin developer to have this control means that derived works are technically branches or forks owned by someone else (other than the plugin developer). This brings up legal questions, is a translation where the plugin developer cannot modify or control the translation still part of the original plugin or is it a derived work (where other parts regarding trademarks and copyright need to be modified). With everything falling under GPL here at WordPress.org, it would mean that the inaccessible by the plugin developer translated plugin technically should use a different name and modify the copyright, and give credit to the original plugin developer to make sure not to imply the derived work was his/hers. This problem is solved simply by allowing plugin developers complete control of who can and cannot translate their plugin including themselves (see my first item above).
I believe the scale-able solution is to allow Global Translation Editors the ability to grade translations that have been approved by non global translator editors. This would be viewed as some sort of star rating or grade percentage next to the translation that then the user can decide if it is good or not. That would solve the issue about quality of the translators in a community driven organic way. Also solves the problem if only 90% of the translation is completed, automatically the grade would be at most 90%.
This is what I would like to have access to as a plugin developer. A place in the plugin’s admin page that would list all of the locales in a table form with options:
locale | translator editors | translation allowed by | translation grade | actions
en-us | user1 x, user2 x, … | () global translators () plugin translator editors () plugin author only | 85% of translations accepted by global editors | add translator editor
| – separates columns in table
() – radio button (defaults to global translators)
x – next to user name to remove translator editor
I’ve already had folks reply telling me this cannot be done for random reasons. I beg of the team to instead respond with reasons why it cannot be done, please consider discussing these ideas first.

Leave a Reply

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