Allow plugin/theme autor to opt-out of translate.wordpress.org

[nilovelez]

There are some cases where projects can and shouldn't be translated in translate.wordpress.org

• Projects that are translated in an external GlotPress (i.e. Mailpoet)
• Locale-specific plugins (TypeSquare Webfonts for エックスサーバー)
• Freemium plugins that include hundreds of hidden strings from the paid version

We need a way of getting those kind of projects out of Translate, both for saving server resources and for avoid volunteers to waste time on translations that wont be used.

Proposed solutions:

• A readme.txt/style.css flag to opt-out from translation
• A way for Plugin Review Team moderators to flag projects as opted-out fron translation
• A streamlined way of removing translate.wordpress.org projects

[Otto42]

-1

The translate service is provided as a community resource for people to do translation themselves. It is not, and should not be opted-out from by plugin/theme authors.

[nilovelez]

That approach implies that the translations the users do will be usable (both by themselves and by others).

If the plugin author decides not to utilize the community translations, all the efforts made by users go to waste.

We are really short-handed on translators, and we need a way to ensure that the only projects available at translate.wordpress.org are those which will be usable.

[dd32]

If the plugin author decides not to utilize the community translations, all the efforts made by users go to waste.

A question needs to be raised as to why that's happening, as core is supposed to use the language packs from translate.w.org in preference to any included in the plugin.

It might simply be that what's needed here is a better check during the glotpress import step to validate that the plugin has the appropriate textdomain set (As that would be the simplest way to avoid the language packs applying - although core would still load the language pack..)

[dd32]

Freemium plugins that include hundreds of hidden strings from the paid version

There's also a question to be raised there, on if the plugin is arbitrarily restricting functionality behind a false plugin-as-a-service shield. If the premium functionality and strings are included in the free plugin, but inaccessible due to an API turning it off (or turning it off by not returning enough data) that's AFAIK against the plugin guidelines anyway.

[nilovelez]

Replying to dd32 :

Freemium plugins that include hundreds of hidden strings from the paid version

There's also a question to be raised there, on if the plugin is arbitrarily restricting functionality behind a false plugin-as-a-service shield. If the premium functionality and strings are included in the free plugin, but inaccessible due to an API turning it off (or turning it off by not returning enough data) that's AFAIK against the plugin guidelines anyway.

It's a common practice to include in the free plugin a PHP file with just an array of all the strings of the paid version.

We have seen that a lot of times in Elementor/Gutenberg "addon" plugins.

[nilovelez]

Replying to dd32 :

If the plugin author decides not to utilize the community translations, all the efforts made by users go to waste.

A question needs to be raised as to why that's happening, as core is supposed to use the language packs from translate.w.org in preference to any included in the plugin.

It might simply be that what's needed here is a better check during the glotpress import step to validate that the plugin has the appropriate textdomain set (As that would be the simplest way to avoid the language packs applying - although core would still load the language pack..)

This is being adressed and the Plugin Review Team is takeing steps to include i18n readines in new plugin checks, but the autor can still force to use embedded translations in any subsequent update.

[dd32]

Replying to nilovelez :

It's a common practice to include in the free plugin a PHP file with just an array of all the strings of the paid version.

That seems very.. annoying :)

That kind of behaviour shouldn't really be acceptable, and I would complain to the plugins team about the plugin including extraneous strings. Ignore for a moment that it's for the non-free version, as far as anyone is concerned here it's just extra junk data in the plugin affecting translators.

It might not be directly against a guideline as such, but I feel that falls into the category of being disingenuous to the translator community, which would fall under ​ Guideline #9 . It's offensive to me that one would expect the WordPress.org translator community to translate strings which are not actually used in the plugin being translated.

[dd32]

This is being adressed and the Plugin Review Team is takeing steps to include i18n readines in new plugin checks, but the autor can still force to use embedded translations in any subsequent update.

That's a very different thing to translate.wordpress.org, while it may seem linked, it's not exactly the same processes. We've got some other processes which take plugin updates and import them into GlotPress - including some that abort the import if certain conditions are met. Aborting because the plugin doesn't support translations due to their bad code is something we should add.

[nilovelez]

There's a lot of things we should add, for example autotranslating libraries like TMGPA which is present in hundred of themes 😅

For now, I will be happy if we just had a way to "delist" translations of projects we know that are useless to translate.

[NekoJonez]

As a translator, I feel very mixed about this ticket.
Since, how would we translate a plugin/theme then if the author opts out and doesnt provide translations for the locale of the user?

Also, why not ask the question... Why are plugins like MailPoet also using an external service? Is there a feature or support missing at translate.wp.org?

If we would do this, we also run the risk that either community translations will be splintered over various platforms... Also, there will be less consistency.

Now, if a certain project thats only for a certain country/locale ... isnt translated in other locales... I ignore it.

With all due respect, I think this shouldn't be implemented via an opt out system but asking why some plugins/themes use external platforms and such and go from there.

[Amieiro]

@fernandot arose this problem last year in a P2 ​ Translating for the user … isn’t it? and we discuss this problem in the ​ weekly meeting in Slack.