Add domainpath support to block.json metadata for custom translation paths

[iamadisingh]

When registering blocks from PHP using register_block_type() or wp_register_block_types_from_metadata_collection(), the underlying register_block_type_from_metadata() function attempts to load translations from the plugin root directory. This is problematic because it's a common practice (and WordPress standard) to store translation files in a /languages subfolder.

Currently, there's no way to specify a custom domain path for block metadata translations, forcing developers to either:

1. Place translation files in the plugin root (not best practice)
2. Use workarounds that bypass the automatic translation loading

Step-by-step reproduction instructions:

1. Create a WordPress plugin with custom blocks
2. Register blocks using register_block_type() with a block.json file
3. Add translations for block.json metadata (title, description, etc.)
4. Place translation files in /languages folder (WordPress standard location)
5. Use Query Monitor plugin to observe translation loading attempts
6. Notice translations are only attempted from plugin root, not /languages folder

Block metadata translations should support a configurable domain path, similar to how WordPress core handles plugin translations. The block.json should accept an optional domainpath property:

{
    "textdomain": "my-plugin",
    "domainpath": "/languages",
    "title": "My Block Title",
    "description": "My block description"
}

Related Issue:
Referenced from discussion in issue ​https://github.com/wordpress/gutenberg/issues/70357

[swissspidy]

Hi there,

Thanks for your report and welcome to Trac!

We‘re already tracking this in #54797