0

In following the steps outlined in this question I am unable to get it to work with the setup that I have. Essentially I have all my custom blocks within a structure like so:

enter image description here

They are loaded in functions.php like this:

function custom_theme_block_init()
{
    $blocks = array(
        'accordion',
        'brand-animation',
        'brand-family',
        'brand-listing',
        'button-hoc',
        'custom-icons',
        'editor-experience',
        'grid-layout',
        'stories',
        'testimonial-showcase',
        'variations',
    );

    foreach ($blocks as $dir) {
        register_block_type(__DIR__ . '/blocks/build/' . $dir);
    }
}
add_action('init', 'custom_theme_block_init');

My issue is the JSON files that make-json generates do not load. I've tried all the solutions presented in the aforementioned question I linked to above.

The block.json for the custom block highlighted in my screenshot (stories) is as follows:

{
    "$schema": "https://schemas.wp.org/trunk/block.json",
    "apiVersion": 2,
    "name": "mativ/stories",
    "version": "1.1.7",
    "title": "Stories",
    "category": "mativ",
    "description": "Filterable content view of the Stories post type",
    "supports": {
        "html": false,
        "align": true
    },
    "attributes": {
        "postType": {
            "type": "string",
            "default": "post"
        },
        "postTaxonomies": {
            "type": "array",
            "default": []
        },
        "numPosts": {
            "type": "integer",
            "default": 4
        },
        "enablePagination": {
            "type": "boolean",
            "default": true
        }
    },
    "textdomain": "mativ",
    "editorScript": "file:./index.js",
    "editorStyle": "file:./index.css",
    "style": "file:./style-index.css",
    "render": "file:./render.php",
    "viewScript": "file:./view.js"
}

An example of my usage is as follows: __("Remove filter", metadata.textdomain)

10
  • aside from the PHP block in your question there's no other code, can you show where it's being used on the javascript side? As well as where you're expecting to see the translated strings? As well as the theme.json you're using for one of the blocks that has the issue
    – Tom J Nowell
    Commented Nov 15, 2023 at 14:55
  • Thanks @TomJNowell - I've updated my initial question with some additional information. Let me know if there is anything else you'd like me to provide. Commented Nov 17, 2023 at 1:05
  • this issue might have nothing to do with gutenberg and everything to do with the use of a dynamic variable being used for the textdomain, language tools can't parse those variables because they can't load a browser and start WordPress, execute the add new post page, go to that page, load the editor, insert your block, then read what the second value passed to __ was. It has to be a static string, it cannot be a variable unless you plan to write out your localisation files by hand manually
    – Tom J Nowell
    Commented Nov 17, 2023 at 12:37
  • e.g. I strongly suspect if you change __("Remove filter", metadata.textdomain) to __("Remove filter", 'mativ') then you'll end up with a localised JSON file that has a single entry for Remove filter
    – Tom J Nowell
    Commented Nov 17, 2023 at 12:38
  • @TomJNowell I don't believe that'll fix the issue as ultimately when the files are compiled to the build folder they will get resolved correctly to the value of contained within metadata.textdomain (which so happens to be 'mativ'). Commented Nov 18, 2023 at 16:32

0

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Browse other questions tagged or ask your own question.