make-pot: scan any theme.json file in any level

[swissspidy]

• scan any theme.json file in any level, for any type of project
• only scan style variations in a top-level /styles folder if it is a theme (this restriction is new)

Fixes #423

[swissspidy]

@oandregal @ocean90 would appreciate your feedback on this.

[oandregal]

I've looked at the command used to extract core strings. It creates a few different files:

• wordpress-continents-cities.pot: no strings coming from theme.json are related to this.
• wordpress.pot: this looks like the strings for the front-end? No strings coming from theme.json need to be displayed in the front-end.
• hello-dolly.pot: no strings coming from theme.json are related to the hello-dolly plugin.
• wordpress-admin.pot: strings to load on the admin. The strings coming from theme.json need to be available in all block editors. If this is the file we load for that, they need to be loaded here.
• wordpress-admin-network.pot : this sounds like the admin network screen. No strings coming from theme.json here.

I suppose we should exclude wp-content from all those contexts, apart for some minor tweaks (include dolly, etc.). This would suffice to prevent theme-defined strings (be in PHP like patterns or functions.php, or any of the theme.json (main or style variations) from being picked for the core pot.

With the limited context I have about how the extraction works, I believe the i18n-command should never skip a path. It's the consumer responsibility to configure the command properly and they can already --exclude-* paths and --skip-* types of files (PHP, JSON, etc.).

[oandregal]

This direction sounds good to me, thanks for the quick fix.

I've shared an edge case that we may want to address before merging.

[swissspidy]

Thanks @oandregal for your help and thinking of all possible edge cases here 🦸 🚀

@wp-cli/committers if someone could give this a quick review & approval, that would be greatly appreciated!