Opened 6 months ago
Last modified 6 months ago
#7614 new feature request
Add an option to remove the --ignore-domain parameter in wp i18n make-pot
Reported by: | mhkuu | Owned by: | |
---|---|---|---|
Milestone: | Priority: | normal | |
Component: | Translate Site & Plugins | Keywords: | |
Cc: |
Description
Whenever plugins or themes are updated, wp i18n make-pot
is run to upload the translations to translate.wordpress.org (see https://meta.trac.wordpress.org/ticket/3748).
This command uses the parameter ignore-domain
(see https://github.com/WordPress/wordpress.org/blob/trunk/wordpress.org/public_html/wp-content/plugins/plugin-directory/cli/i18n/class-code-import.php#L52-L58 for plugins), so any translation is being uploaded, regardless of the text domain. Five years ago this parameter was apparently added for backwards compatibility when transferring from makepot.php
(https://meta.trac.wordpress.org/ticket/3748#comment:8).
We would like to consider a configuration setting in the plugin/theme that would remove this parameter (e.g., in the readme.txt
file). That would prevent translations from a different text domain (on purpose or by accident) to be uploaded to translate.wordpress.org.
In https://meta.trac.wordpress.org/ticket/7167 there are some use cases laid out of why someone would choose a different text domain on purpose, mostly hinging around the inclusion of Premium strings in a Free plugin. Our use case is quite similar: at Yoast SEO, we have a general JavaScript text analysis library (yoastseo
, see https://github.com/Yoast/wordpress-seo/tree/trunk/packages/yoastseo), that's used on platforms outside of WordPress as well (TYPO3, Shopify, Drupal, etc.), but some specific language data that powers some of the so-called assessments is only available for Yoast SEO Premium customers. We feel the translation strings pertaining to these assessments should therefore not be translated through translate.wordpress.org, and we have consequently assigned them a different text domain (cf. https://github.com/Yoast/wordpress-seo/blob/trunk/packages/yoastseo/src/scoring/assessments/readability/WordComplexityAssessment.js).
Moreover, if the text domain is set wrongly by accident, the string not being uploaded to translate.wordpress.org would in my opinion be a clearer indication that something is wrong in the plugin/theme code (see also https://meta.trac.wordpress.org/ticket/5358).
Change History (3)
#2
@
6 months ago
Thanks @dd32. You're right, tree-shaking unused JavaScript is the other route we are currently investigating for our specific use case, I failed to mention that in the original message, sorry for that!
I agree; The code related to this should however not be within the distributed free plugin, such as that the strings are not present.