-
Notifications
You must be signed in to change notification settings - Fork 43
Translations: add script to remove 90% translations #110
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
|
This can be tested by running the command and seeing |
|
I wonder if we want to have a set baseline of translated languages? i.e. what happens when a language doesn't hit the 90% threshold after a major update and there is no longer a pack? |
|
Once there is a language pack, it'll continue to get generated, even if the translation percentage drops below the threshold ( https://github.com/WordPress/wordpress.org/blob/7bcd368b66c9e098bce1314a9f4af61d7ac067a1/wordpress.org/public_html/wp-content/plugins/wporg-gp-customizations/inc/cli/class-language-pack.php#L649 ). Once a language meets the threshold, we don't need to worry about it from the code/repo POV. On the polyglot side, we can aim to have PTE (project translation editors), which are folks who can approve a plugin's strings, so we can better ensure new and updated strings are translated. There were some conversations/proposals about not serving a pack if the percentage dropped below a number, but those weren't accepted. (e.g. https://make.wordpress.org/polyglots/2020/03/10/delete-projects-language-pack-when-below-specific-percentage/ ) It would make sense to me to try to target the languages we can with more than 1% of WordPress installs (looking at https://wordpress.org/stats/ but open to other ways to determine higher-impact languages) which current lists: Those we lack packs for: Those we do: Something I'd like to do in a follow-up is see if we can programmatically pull down the translations from translate.wordpress.org for those not at the threshold yet so those that we do have in the repo are up to date. Right now, the files we serve have already been uploaded to translate.wordpress.org and, in theory, added/improved, but users aren't seeing those improved translations until we export them back into the repo (which I haven't done thus far) |
pkevan
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Tested with composer update-translations which works as expected.
Hitting some issues with composer prepare-release - will followup separately.
When running `update_translations` we end up in a different directory (https://github.com/WordPress/secure-custom-fields/blob/c037ce16b9a110115af2289053d87430d78eec97/bin/update-translations.php#L16), this resets that to where it is expected.
Added a commit to resolve one of the issues, needs testing. |
|
@pkevan Thanks for catching that. In my iterations on the script, I ended up not needing the |
Yes, will do and report back. |
|
Looks good now @kraftbj 👍 |
Fixes #105
When preparing for a new release via
composer prepare-releaseor a newcomposer update-translations, check for language packs on WordPress.org and remove any that are at 90%.Future work would be to see if we can programmatically export the current translate.wordpress.org files for languages so any improvements made by volunteers make it to site owners.