Making WordPress.org

Opened 15 months ago

Last modified 15 months ago

#7167 new feature request

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

Reported by: nilovelez's profile nilovelez Owned by:
Milestone: Priority: normal
Component: Translate Site & Plugins Keywords:
Cc:

Description

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

Change History (12)

#1 @Otto42
15 months ago

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

#2 @Otto42
15 months ago

  • Milestone Plugin Directory v3 - Future deleted

#3 @nilovelez
15 months ago

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.

#4 follow-up: @dd32
15 months ago

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

#5 follow-up: @dd32
15 months ago

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.

#6 in reply to: ↑ 5 ; follow-up: @nilovelez
15 months ago

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.

#7 in reply to: ↑ 4 @nilovelez
15 months ago

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.

#8 in reply to: ↑ 6 @dd32
15 months ago

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.

#9 @dd32
15 months ago

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.

#10 @nilovelez
15 months ago

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.

#11 @NekoJonez
15 months ago

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.

#12 @Amieiro
15 months ago

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

Note: See TracTickets for help on using tickets.