Keep translation catalogs stable across code-only changes - #148
Merged
Merged
Conversation
Contributor
Test in WordPress PlaygroundTest the plugin with the code from this branch:
|
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## main #148 +/- ##
=========================================
Coverage 96.40% 96.40%
Complexity 827 827
=========================================
Files 36 36
Lines 4233 4233
=========================================
Hits 4081 4081
Misses 152 152
Flags with carried forward coverage won't be shown. Click here to find out more. 🚀 New features to boost your workflow:
|
erseco
added this pull request to stack #151
September 26, 2026 10:50
wp i18n make-pot writes #: file:line references, so any change that shifted a translatable string's line rewrote the POT and all ten PO files, and CI's check-translations required committing that churn with the code. Strip the line numbers (and repeated files) from the POT before the PO files are updated. File names stay: wp i18n make-json needs them to map JavaScript strings to their scripts, and the generated JSON is byte-for-byte unchanged. This regenerates every catalog once, without line numbers.
erseco
force-pushed
the
feature/pot-file-references
branch
from
September 26, 2026 10:50
9184b21 to
bc32141
Compare
erseco
added a commit
that referenced
this pull request
Sep 26, 2026
Register the editor and export bridges with wp_register_script(), add their configuration with wp_add_inline_script( ..., 'before' ) and print only that handle with wp_print_scripts(), so the review's 'use wp_enqueue commands' applies literally, as it already did for the editor page's CSS. The export bridge stays deferred on every supported version: WordPress 6.3+ honours wp_script_add_data( ..., 'strategy', 'defer' ); for 6.1 and 6.2 a script_loader_tag filter, scoped to that handle and removed right after the print, adds the attribute. Checked on WordPress 6.1.14 and 6.3.12. Also register the embed scripts on init instead of wp_enqueue_scripts, so the shortcode can enqueue them in contexts where that hook never fires (the /embed/ template, previews), and restore the AGENTS.md note from #148 that an earlier rebase of this branch dropped.
erseco
added a commit
that referenced
this pull request
Sep 27, 2026
…kup (#125) * fix: serve embed behavior as an enqueued script instead of inline markup WordPress.org asked that plugins stop printing <script> and <style> blocks by hand. The frontend printed three: - the block and the shortcode each emitted an inline fullscreen/poster script per embed. One delegated script, assets/js/exelearning-embed.js, replaces both; it is registered with the block's other frontend assets and enqueued only when an embed renders. - ExeLearning_Viewer_Enhancements printed a <style> and a ResizeObserver <script> to turn a percentage height into pixels. CSS aspect-ratio gives the same box without script, so the class is removed. The editor and export pages are standalone HTML documents written without a theme header, so their tags are built with wp_get_inline_script_tag() and wp_get_script_tag() (WordPress 5.7+), keeping the export bridge deferred as before, and the editor page's CSS goes through wp_add_inline_style(). * Print the standalone pages' bridge through the script queue Register the editor and export bridges with wp_register_script(), add their configuration with wp_add_inline_script( ..., 'before' ) and print only that handle with wp_print_scripts(), so the review's 'use wp_enqueue commands' applies literally, as it already did for the editor page's CSS. The export bridge stays deferred on every supported version: WordPress 6.3+ honours wp_script_add_data( ..., 'strategy', 'defer' ); for 6.1 and 6.2 a script_loader_tag filter, scoped to that handle and removed right after the print, adds the attribute. Checked on WordPress 6.1.14 and 6.3.12. Also register the embed scripts on init instead of wp_enqueue_scripts, so the shortcode can enqueue them in contexts where that hook never fires (the /embed/ template, previews), and restore the AGENTS.md note from #148 that an earlier rebase of this branch dropped. * Enqueue the standalone pages' handles and harden the pre-6.3 defer fallback Enqueue the editor and export bridges and the editor page style before printing them, so the code reads as the review asked: register, enqueue, add inline, print. The WordPress < 6.3 defer fallback matched the exact tag serialization (id='…-js'>). It now adds defer to the first <script> tag with a src in the handle's output, which skips the inline config printed in the same string, and leaves a tag that already has defer alone. A test simulates pre-6.3 core to cover it; checked again on WordPress 6.1.14 and 6.3.12. Also cover the remaining branches of exelearning-embed.js: the legacy Edge fullscreen request, a control outside any embed, and a non-element target. * Restore the WordPress version in the pre-6.3 defer test even if it fails
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
2 participants
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.
Problem
wp i18n make-potwrites#: file:linereferences. Any change that moves a translatable string to a different line rewrites the POT and all ten PO files. CI'smake check-translationsthen requires committing that churn together with the code. #124 and #125 each carry hundreds of reference-only catalog lines for this reason, although neither changes a single msgid.Change
bin/pot-strip-line-numbers.php, run bycomposer make-translationsandcheck-untranslatedright afterpot-remove-ctime. It reduces each#:line in the POT to its file names: it drops the line numbers and removes repeated files.wp i18n update-pothen carries those references into the PO files.wp i18n make-jsonuses them to map JavaScript strings to their scripts, so--no-locationwould have broken the JS translations.languages/only when a string is added, removed or moved to another file.AGENTS.mdnotes the new behaviour.Verification
composer validate-translations: OK.composer untranslated: no untranslated strings.make-translationstwice leaves no diff.