Repository navigation
Pattern Translations: Skip locales without any translations - #790
Merged
Merged
Conversation
The translation import checked every pattern in every locale, but most locales have no pattern translations at all, so each of those lookups switched locale and queried every string only to find nothing. About two thirds of each run went to locales that cannot produce a translation. Look up once per run which locales have at least one current translation in the patterns project, and only process those. When that lookup is not possible, every locale is processed as before.
|
Note Currently processing new changes in this PR. This may take a few minutes, please wait... ⚙️ Run configuration
📒 Files selected for processing (1)
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configuration
📒 Files selected for processing (1)
Included review availability: This review used your included allowance. Your plan provides up to 2 included reviews per hour; 1 remain after this review. 📝 WalkthroughWalkthroughThe translation import cron now identifies locales with current translations in the configured GlotPress project. When this locale list is non-empty, the cron limits processing to those locales. If the list is empty, it keeps the existing locale list. ChangesTranslation locale filtering
Priority: ➖ Normal Estimated code review effort: 2 (Simple) | ~10 minutes Change: Refactor Merge Risk: ⚪ Minimal · up to No concrete regression is established. The locale filter is ready to merge after normal checks. 🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches📝 Generate docstrings
🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
Use identifier placeholders for the prefixed table names instead of interpolating them into the query.
Derive the locale of a variant translation set from its base locale and the set slug, the inverse of how the GlotPress bridge looks translations up. Looking the variant up by its own slug missed locales whose slug does not follow the set, such as Valencian Catalan, so the filter would have dropped them once they had translations.
Check for the GlotPress table prefix itself instead of the locales class, which is always loaded, and use it without a default, as the rest of the plugin does. Log when the locale list cannot be built and every locale is processed instead.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Follow-up to #789. The translation import still takes ~520s per 15-minute chunk, about half a Cavalcade worker around the clock. Most of that is spent on locales that can't produce a translation.
Each chunk processes 50 patterns × ~203 locales. For every pair,
Pattern::to_locale()switches locale and runs oneGlotPress_Translate_Bridgequery per string. The bridge caches for 6h, but each pattern only comes around every 12h, so every lookup hits the database. Of the 207 translation sets inpatterns/core, only 64 have any current translations (see https://translate.wordpress.org/api/projects/patterns/core/). The other 143 account for ~7,150 of the ~10,150 pattern/locale pairs per chunk, and every one of them ends in "No Translations exist yet."This PR looks up once per run which translation sets in the patterns project have at least one current translation of an active original (the same conditions the bridge uses), maps them to WordPress locales via
GP_Locales(variants likede/formalare locales of their own), and only processes those. If GlotPress isn't available or the lookup returns nothing, every locale is processed as before. A locale's first translation is picked up on the next chunk, since the list is rebuilt each run.Expected: chunk runtime drops by roughly two thirds, assuming per-locale cost is similar for empty and translated locales. Not profiled.
How to test the changes in this Pull Request:
wp shell --url=https://wordpress.org/patterns/and runWordPressdotorg\Pattern_Translations\Cron\get_translated_locales();. It should return ~64 WordPress locales, matching the sets withcurrent_count > 0in the API above, including variants such asde_DE_formalandnl_NL_formal.pattern_import_translations_to_directoryshould fall well below ~520s.🤖 Generated with Claude Code
Summary by CodeRabbit