# Fixing WordPress block translations

**URL:** <https://forum.pinegrow.com/t/fixing-wordpress-block-translations/8049>\
**Category:** Pinegrow WP\
**Tags:** bug, feature-request, wordpress, blocks\
**Created:** [May 22, 2023, 6:50pm UTC](https://forum.pinegrow.com/t/fixing-wordpress-block-translations/8049 "2023-05-22T18:50:08Z")\
**Posts on this page:** 5\
**Page:** 1

<div class="post-metadata">

**Author:** ![marc\_io](https://yyz2.discourse-cdn.com/flex036/user_avatar/forum.pinegrow.com/marc_io/32/3431_2.png) [@marc\_io](https://forum.pinegrow.com/u/marc_io)\
**Post date:** [May 22, 2023, 6:50pm UTC](https://forum.pinegrow.com/t/fixing-wordpress-block-translations/8049/1 "2023-05-22T18:50:08Z")

</div>

Hi guys,

I’m currently working on a project that requires a custom block, which needs to be translated into multiple languages, both in the editor and the front-end, and I was messing around in Pinegrow to learn how to make this happen with the blocks it creates.

So I created a test plug-in with some strings and found that the translations only work with some strings entered via PHP. Translations in fields created with block attributes that use Javascript, for example, are simply not loaded when WordPress is used in another language.

 ![translations-not-loaded](https://canada1.discourse-cdn.com/flex036/uploads/pinegrow/original/2X/7/72ad9e34122aad1518ee292467189bbf562f9e3e.png)

Digging a bit into the generated block code, I found several missing pieces. Here are my findings for others interested in translating their blocks into other languages.

First, the native WordPress translation functions – for example, \_\_( ‘My string’, ‘My text domain’) – are not correctly included for block attribute strings in the JavaScript function `registerBlockType()`, usually located in `/blocks/your-block-name/your-block-name.js`. In some cases, the translation function is included, but without the text domain, which makes them ineffective.

You can manually add these functions in the correct places, but it would be nice if Pinegrow would automatically insert them for us.

 ![01-missing-translation-functions](https://canada1.discourse-cdn.com/flex036/uploads/pinegrow/original/2X/6/6ef73ab3281b9f2f93ef4e88583e24d469ea8eab.png)

Also missing are some PHP translation functions in the `/blocks/your-block-name/your-block-name-register.php` file.

Another problem is that the `wp-i18n` Javascript package is missing from the `PG_Blocks::register_block_type()` method, located in `inc/wp_pg_blocks_helpers.php`. This package needs to be added to the array that loads the WordPress dependencies for the main block script (enqueued via `enqueue_editor_script`), which we edited in the previous step. Without this, WP’s native translation functions will do nothing.

![02-missing-wp-i18n-dependency](https://canada1.discourse-cdn.com/flex036/uploads/pinegrow/original/2X/7/7b5da77aedaf14ccc74e724ede6520bace5d9bde.png)

Finally, we need to inform WordPress that our JavaScript contains translations using the `wp_set_script_translations()` function in the main PHP file (functions.php, for themes, or `plugin-name.php`, for plug-ins). You can add the snippet below to the end of the main PHP file:

```php
function my_theme_set_script_translations() {
    wp_set_script_translations( 'block-my-plugin-my-block-script', 'my_text_domain', plugin_dir_path( __FILE__ ) . 'languages' );
}
add_action( 'init', 'my_theme_set_script_translations' );

```

It is important to add the correct identifier for this to work. For Pinegrow, it follows this formula:

`block-` + `plugin-or-theme-slug` + `-` + `block-unique-id` + `-` + `script`.

 ![03-adding-the-correct-handle](https://canada1.discourse-cdn.com/flex036/uploads/pinegrow/original/2X/4/4fb11b515c576e017d03d0164376a88ceb139072.png)

With the fixes in place, you can generate the translation files (in `po`/`mo`/`json` formats) by following the [WordPress Developer official tutorial](https://developer.wordpress.org/block-editor/how-to-guides/internationalization/#create-translation-file), and place them in the `/languages/` folder in the root folder of your plugin or theme.

If you are using the LocalWP app to manage your WordPress installations, you can use the “Open site shell” link and navigate to the `languages` folder via the command line to use the necessary WP-CLI commands described in the tutorial.

Also, since we are talking about blocks, note that the `load_theme_textdomain()` and `load_plugin_textdomain()` commands included by Pinegrow for themes and plug-ins, respectively, are no longer needed.

[Since WordPress version 4.6](https://make.wordpress.org/core/2016/07/06/i18n-improvements-in-4-6/), translation files are automatically loaded on demand, freeing developers to explicitly invoke this function to load translations.

[Here is a test theme](https://dl.dropbox.com/s/cgwzw4tk4yb6kps/translatable.zip) for anyone who wants to take a look.

Again, it would be very nice if Pinegrow itself would fix these issues automatically, so that we could avoid a lot of manual work with every change in the block. What do you think @matjaz and @Emmanuel?

---

<div class="post-metadata">

**Author:** ![madjedo](https://avatars.discourse-cdn.com/v4/letter/m/cc9497/32.png) [@madjedo](https://forum.pinegrow.com/u/madjedo)\
**Post date:** [June 16, 2023, 6:39pm UTC](https://forum.pinegrow.com/t/fixing-wordpress-block-translations/8049/2 "2023-06-16T18:39:04Z")

</div>

I had some issues translating a website with WPML with some strange behaviour. Some blocks would translate correctly and other blocks would have parts of it that could not get translated. I had to manually register them for translation.

I am getting a bit weary calling Pinegrow blocks multi language compatible. They should take another look into why we are having issues translating Gutenberg blocks. I have a staging site I can demonstrante some examples if they are interested of some of the issues.

---

<div class="post-metadata">

**Author:** ![adamslowe](https://yyz2.discourse-cdn.com/flex036/user_avatar/forum.pinegrow.com/adamslowe/32/4590_2.png) [@adamslowe](https://forum.pinegrow.com/u/adamslowe)\
**Post date:** [June 19, 2023, 5:26pm UTC](https://forum.pinegrow.com/t/fixing-wordpress-block-translations/8049/3 "2023-06-19T17:26:45Z")

</div>

I’d love to see some examples, especially since I have a few more multi-language projects on the horizon. So far, I haven’t run into any major issues with TranslatePress but it’s always helpful to know of any issues/limitations before I run into them personally.

---

<div class="post-metadata">

**Author:** ![matjaz](https://yyz2.discourse-cdn.com/flex036/user_avatar/forum.pinegrow.com/matjaz/32/5_2.png) [@matjaz](https://forum.pinegrow.com/u/matjaz)\
**Post date:** [June 25, 2023, 6:03am UTC](https://forum.pinegrow.com/t/fixing-wordpress-block-translations/8049/4 "2023-06-25T06:03:16Z")

</div>

@marc_io thanks for providing detailed info on what I missing to support translations. We have this on the to-do list with high priority.

---

<div class="post-metadata">

**Author:** ![madjedo](https://avatars.discourse-cdn.com/v4/letter/m/cc9497/32.png) [@madjedo](https://forum.pinegrow.com/u/madjedo)\
**Post date:** [June 29, 2023, 11:40am UTC](https://forum.pinegrow.com/t/fixing-wordpress-block-translations/8049/5 "2023-06-29T11:40:07Z")

</div>

So I dont use translatepress. But for WPML i noticed blocks that were also containing some embed media like a youtube video or a block with a inner content block had some issues.WPML would detect strings and I could translate in the back-end, but nothing gets translated on the front-end.

Then I had just random issues with other blocks were certain headlines or paragraphs just did not get translated. And these are not complex blocks. Just paragraphs, headlines and images. Actually the more advanced blocks seems to be working better.

Did some quick testing using the new hybrid blocks. In summary: nothing works at all with them for me.

I don’t understand much of what the topic starter wrote down, but they sure seem to have forgotten to include some things that would make Wordpress understand or recognize certain strings for some block types and is probably why I’m also having same issues.

And I don’t think any of this got addressed on the latest release?
