Add text domain option while scaffolding the block in create-block

[vampdroid]

What?

Fixes #54980

Why?

• This PR adds a new option prompt in the create-block command to add text domain option in the scaffolding block's block.json metadata

How?

• As per the flow of the command goes:
• If the user calls npx @wordpress/create-block --no-plugin it adds 'textdomain' prompts where the user can specify the text domain for that block.
• Created a new prompt in the prompts.js for textdomain and added it to scaffold.js and in the plugin template for --no-plugin option. This way it will be shown both with the plugin and no plugin option.

Testing Instructions

• Open the code editor and terminal
• Create a folder inside wp-content/plugins
• Run npx ../gutenberg/packages/create-block --no-plugin. (Make sure you already have the Gutenberg plugin installed and updated with this branch code in plugins folder already)
• You will see an option The text domain used to internationalize text in the block: after selecting a category where you can specify your text-domain.
• After the block scaffolding is done, you will be able to see your specified text-domain in block.json of your block folder

Testing Instructions for Keyboard

None

Screenshots or screencast

[github-actions]

👋 Thanks for your first Pull Request and for helping build the future of Gutenberg and WordPress, @vampdroid! In case you missed it, we'd love to have you join us in our Slack community, where we hold regularly weekly meetings open to anyone to coordinate with each other.

If you want to learn more about WordPress development in general, check out the Core Handbook full of helpful information.

[ryanwelcher]

@vampdroid thanks for putting this together! Would you be able to address the merge conflicts and update the branch with the latest from trunk?

[github-actions]

The following accounts have interacted with this PR and/or linked issues. I will continue to update these lists as activity occurs. You can also manually ask me to refresh this list by adding the props-bot label.

If you're merging code through a pull request on GitHub, copy and paste the following into the bottom of the merge commit message.

Co-authored-by: vampdroid <[email protected]>
Co-authored-by: gziolo <[email protected]>
Co-authored-by: ryanwelcher <[email protected]>

To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook.

[ryanwelcher]

I may be mistaken, but it looks like this only covers interactive mode. It would be great to also have a --text-domain flag that can be used to pass the text-domain when in quick mode.

[gziolo]

I added the [Status] Stale label to the PR. I am happy to remove it as soon as the branch is refreshed with the latest changes in trunk.

[vampdroid]

Sure @gziolo, I will be updating the PR as soon as possible.

[gziolo]

I added the changelog entry in dccf1d1 as preparations for landing this PR.

[gziolo]

I checked the documentation for plugins: https://developer.wordpress.org/plugins/internationalization/how-to-internationalize-your-plugin/#text-domains

Since WordPress 4.6 the Text Domain header is optional because it must be the same as the plugin slug. There is no harm in including it, but it is not required.

We still need this option for the case when scaffolding the block without the plugin because the slug is going to be different than the textdomain. How we can handle it?

[ryanwelcher]

One Idea I've been toying with is accessing block.json for other values.

In the case of adding another block to an existing plugin, it may be possible scan the src directory (or whatever folder it's using) for a block.json and take the textdomain value from here.

There's a lot of edge cases here based on where files are located but it might be worth a look?

[gziolo]

In the case of adding another block to an existing plugin, it may be possible scan the src directory (or whatever folder it's using) for a block.json and take the textdomain value from here.

I like the direction in which your thoughts are going. Based on my previous comment, it feels like detecting in some magic way the slug of the theme or the plugin would also solve the issue.

As for this PR, is there anything left to do? @ryanwelcher, does it work for you as expected?

[gziolo]

It worked correctly in my testing.

@vampdroid, thank you for contributing this new option.

[gziolo]

@ryanwelcher, I landed it so I can rebase the Inquirer.js usage together with #67877. If you have some ideas how to iterate on it, I'm happy to help with follow-up PRs.

I may be mistaken, but it looks like this only covers interactive mode. It would be great to also have a --text-domain flag that can be used to pass the text-domain when in quick mode.

I was thinking about it a bit. Based on my comment #57197 (comment), my understanding is that when scaffolding a full plugin, --text-domin should be equal to the slug. This functionality would be mostly useful together with --no-plugin opton.