You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Let's say there are some translatable strings in my-plugin/js/src/blocks.js and now we extract these somehow.
Scenario A: We use babel-plugin-makepot for string extraction. The POT and PO files will only have my-plugin/js/src/blocks.js as a file reference.
Scenario B: We use WP-CLI. All files are taken into consideration for string extraction. The POT and PO files will have both my-plugin/js/src/blocks.js and my-plugin/js/blocks.js as file references.
Scenario C: We use WP-CLI for string extraction, but we ignore the src folder. Not ideal, because this way you lose the context the original source file, but it works. The POT and PO files will have my-plugin/js/blocks.js as a file reference.
In each scenario, we run wp i18n make-json.
In WordPress, we enqueue the script my-plugin/js/blocks.js. This means WordPress looks for JSON files with the MD5 hash of js/blocks.js in the file name. This is where we run into problems.
Scenario A: WP-CLI successfully creates 1 JSON file, but uses the MD5 hash of js/src/blocks.js for creating the file name. There's obviously a mismatch because WordPress expects a different file name.
Scenario B: WP-CLI creates 2 JSON files, one for js/src/blocks.js and one for js/blocks.js. The first one doesn't work, but the second is what WordPress expects.
Scenario C: WP-CLI creates 1 JSON file with the MD5 hash of js/blocks.js. The same as WordPress expects.
How could we fix this?
Scenario A: Don't use the MD5 in the file name, but the script handle instead. This would need to be passed as an argument, obviously. However, a plugin can have lots of script handles, so this is gonna be a bit complicated. Alternatively, we'd need a way to tell WP-CLI to use js/blocks.js for the MD5 hash instead of js/src/blocks.js.
Scenario B: Add a way to tell WP-CLI to ignore certain paths when generating the JSON files.
Scenario C: Nothing to do there.
The text was updated successfully, but these errors were encountered:
I think we need to make the
make-json
command a bit smarter.Given the following folder structure:
Let's say there are some translatable strings in
my-plugin/js/src/blocks.js
and now we extract these somehow.Scenario A: We use
babel-plugin-makepot
for string extraction. The POT and PO files will only havemy-plugin/js/src/blocks.js
as a file reference.Scenario B: We use WP-CLI. All files are taken into consideration for string extraction. The POT and PO files will have both
my-plugin/js/src/blocks.js
andmy-plugin/js/blocks.js
as file references.Scenario C: We use WP-CLI for string extraction, but we ignore the
src
folder. Not ideal, because this way you lose the context the original source file, but it works. The POT and PO files will havemy-plugin/js/blocks.js
as a file reference.In each scenario, we run
wp i18n make-json
.In WordPress, we enqueue the script
my-plugin/js/blocks.js
. This means WordPress looks for JSON files with the MD5 hash ofjs/blocks.js
in the file name. This is where we run into problems.Scenario A: WP-CLI successfully creates 1 JSON file, but uses the MD5 hash of
js/src/blocks.js
for creating the file name. There's obviously a mismatch because WordPress expects a different file name.Scenario B: WP-CLI creates 2 JSON files, one for
js/src/blocks.js
and one forjs/blocks.js
. The first one doesn't work, but the second is what WordPress expects.Scenario C: WP-CLI creates 1 JSON file with the MD5 hash of
js/blocks.js
. The same as WordPress expects.How could we fix this?
Scenario A: Don't use the MD5 in the file name, but the script handle instead. This would need to be passed as an argument, obviously. However, a plugin can have lots of script handles, so this is gonna be a bit complicated. Alternatively, we'd need a way to tell WP-CLI to use
js/blocks.js
for the MD5 hash instead ofjs/src/blocks.js
.Scenario B: Add a way to tell WP-CLI to ignore certain paths when generating the JSON files.
Scenario C: Nothing to do there.
The text was updated successfully, but these errors were encountered: