Thank you for your review, however let me disagree. First of all, of course, all of our plugins have correct usage of __(“text”, “textdomain”). We have zero non translated strings. There are just few of them that should not be translated like names of libraries, etc.
Also, of course, you can simply search by pattern (__””) and you will see that all strings also have textdomain.
Yes, you reported this years ago but it’s not our fault that wordpress still has no good translation for third party addons for gutenberg. You can translate plugin by using next tutorial https://developer.wordpress.org/block-editor/contributors/localizing/ It’s quite complex for gutenberg and requires to use terminal, but again, it’s not our fault.
I am ready to provide you source file of one of our addon so you can see that from our side everything is correct, all strings are translated. I hope you will change rating after this
Hello, the Greenshift plugin’s Gutenberger interface fields are all compressed into the greenshift-animation-and-page-builder-blocks\build\index.js file. This compressed version destroys almost all fields that need translation.
As a paid user, I have also submitted a support ticket on your website, which you can view in the video I recorded. You can also check the official WordPress translation library to see if it includes all the fields that need translation: https://translate.wordpress.org/projects/wp-plugins/greenshift-animation-and-page-builder-blocks/
As developers, you should know that Greenshift cannot possibly have only 1175 fields that need translation! However, at https://translate.wordpress.org/projects/wp-plugins/greenshift-animation-and-page-builder-blocks/, there are actually fewer than 1200 fields to translate. This indicates that the fields in your plugin’s Gutenberger interface are rendered untranslatable by the compressed \build\index.js file, making it impossible for WordPress to recognize and provide translations!
Please don’t be presumptuous. The true truth lies in practical application. You can try translating Greenshift into other languages yourselves, and then check in the WordPress backend to see if your plugins actually support translation!
To reiterate: the issue I’m reporting here concerns the Greenshift core plugin: https://wordpress.org/plugins/greenshift-animation-and-page-builder-blocks/, not the addon plugins I reported a few years ago (I can accept that the addon plugins couldn’t be translated due to Gutenberg’s policies), but the problem of the core plugin not being translated must be resolved!
-
This reply was modified 3 weeks, 3 days ago by
cmhello.
-
This reply was modified 3 weeks, 3 days ago by cmhello.
-
This reply was modified 3 weeks, 3 days ago by cmhello.
Everyone can view this video. I chose the 100% translated Polish version as a test, but Greenshift fails to display Polish in almost 90% of the fields in the Gutenberger editor interface: https://pioneerroll.s2-tastewp.com/wp-content/uploads/2026/04/Video_2026-04-18_124455.mp4
With all respect, I recommend to study question first before blaming that we do something wrong. As I wrote, I can provide you source file and you will see that everything is correct
This is example https://cleanshot.com/share/PcDzyKjG
1175 fields – this is correct, this is how much strings are in JS files. JS translation is working not the same as PHP. It’s packed by webpack, then unpacked via i18n package and wp_set_script_translations. On plugins hosted on wp.org, i18n package is automatically unpack strings and you have them https://translate.wordpress.org/projects/wp-plugins/greenshift-animation-and-page-builder-blocks/
On Custom blocks not hosted on wp.org, you need to do this manually. This is example how to do this https://devmaverick.com/how-to-translate-a-custom-wordpress-gutenberg-block/
Why only 1175 fields? Because JS and PHP have different way to translate and different localization files. PHP strings can be translated from .pot file that is placed in lang folder (and languages folder in premium addons).
Of course, Gutenberg should have more simple translation way for JS and this was discussed for years but currently the only way is still to generate custom json via i18n. If you provide me this json file for your language I will be glad to include it in plugin
Here is another good article https://awhitepixel.com/wordpress-gutenberg-create-custom-block-part-8-translation/
@cmhello Now about polish version, each version has own editors, we don’t translate by ourself. For example, on your video you used Slider, this is source of slider, as you see, all strings are correct and localized https://drive.google.com/file/d/1VD4uX28AWcT8x1VUy_6erHPlD9A6l44t/view?usp=drive_link
the only thing which I see, that WP repository didn’t unpack file for blocks, even if it has correct registration, I will write to Gutenberg issues https://cleanshot.com/share/DYfYLrdT But this is not what we can change, it’s bug of repository
The fact is, we users cannot perform a complete translation using the WordPress translation library or Greenshift’s built-in Pot file!
https://pioneerroll.s2-tastewp.com/wp-content/uploads/2026/04/Video_2026-04-18_133154.mp4
https://pioneerroll.s2-tastewp.com/wp-content/uploads/2026/04/2026-04-18_133301.jpg
The code snippet (your source file) you provided is not included in the plugin!
I want to reiterate: the source files you used for development were not included in the Greenshift installation package! The functionality loaded in the Gutenberger editor is implemented through your compressed greenshift-animation-and-page-builder-blocks\build\index.js file! The problem lies in the fact that the code in this compressed index.js file corrupts the original structure of translation fields such as __(), _e(), etc.! This causes the translation fields to be unrecognized and untranslated! That’s the crux of the problem!
Everything I’ve said above is based on actual testing and has video evidence!
You say it supports translation, then you should translate a language yourselves and show us!!
-
This reply was modified 3 weeks, 3 days ago by cmhello.
-
This reply was modified 3 weeks, 3 days ago by cmhello.
It’s impossible to generate a POT file containing all the translated fields using any official command, because the fields are structurally corrupted in the compressed greenshift-animation-and-page-builder-blocks\build\index.js file, making it impossible to recognize and generate the fields that need translation.
If you say the WordPress translation library has bugs, then please provide a POT file with all the fields in the Greenshift plugin zip!
If you say Greenshift supports complete translations, then please translate it into one language and show it to us!
That’s all I wanted to say!
one more time. Plugin has .pot file for server side rendering
for JS translation, you need to make json file and make pot file from bundled file via terminal. If you don’t know how to use terminal, I can make it for
I know the typical path to generating JSON:
- Generate a .pot or .po file
- Translate the .po file
- Generate a .json file using the method you repeatedly mentioned.
I know how to do all of these.
The real issue is: because all the fields displayed in the Gutenberger editor by the Greenshift plugin reside in the compressed greenshift-animation-and-page-builder-blocks\build\index.js file, it has broken the original correct translation of fields like __(), _e(), etc., during the build process. This makes it impossible to fully recognize and generate a .pot file containing all fields!
It’s impossible to generate a .pot file containing all fields from the very first step! So what you need to address and solve is the problem in the first step, not keep telling me how to generate a translated JSON file!!
I just have a few questions for you:
- Have you checked whether the .pot file built into the Greenshift plugin that you uploaded to your WordPress repository actually contains all the translated fields? (I checked, and it only has 428 fields!)
- Are you actually using the command line I keep telling you to generate the .pot file in the client, then translate it, and then generate the .json file?
Please note: Do not use your locally developed Greenshift plugin directory to generate it. Instead, download and extract it from wordpress.org, and then generate it in the extracted directory!
Only you can: use your repeatedly used method to generate a .pot file containing all fields and check if it contains all fields! If you confirm that it contains all fields, please share it with me!
For core plugin – you do not need to use .pot file and json, it’s made automatically on WP translation page. For other plugins – you will need generated .pot file.
I understand that localization is complex, so I made tutorial. Also, I updated localization file for addons, so you don’t need to generate it, just copy and rename
Tutorial is here https://greenshiftwp.com/documentation/greenshift-extra/translation-of-custom-gutenberg-wordpress-plugin/
I tested for some languages and it’s working for me. I hope this helps
Thank you for the tutorial. I already know how to use WP CLI commands; that’s not my real reason for asking the question here!
You’ve consistently avoided directly answering my question:
During the generation of the compressed version of greenshift-animation-and-page-builder-blocks\build\index.js, the core plugin breaks the original __(), _e(), and other functionalities, causing the WordPress translation library and WP CLI commands like wp i18n make-pot to fail to retrieve the fields to be translated from that file.
This is why the official WordPress translation library doesn’t correctly parse the translations of the Greenshift plugin’s blocks (it’s not that the translation library has a bug, but that your plugin has a bug!).
If the plugin doesn’t have the above error, the wp i18n make-pot command should be able to retrieve all the translated fields.
You can easily test this yourself using wp i18n make-pot to see if the problem I’m pointing out actually exists.
Why do I urgently need you to provide the core plugin’s pot file? I expect you to actually test it. I’m certain you can’t possibly get a pot file containing all the translated fields because your plugin has bugs!
You’ve consistently refused to address this issue. Perhaps you believe that non-English speaking users aren’t worth your time maintaining, even paid users!
As a paid user, I’m extremely disappointed with your handling of this problem!
if it’s erasing all strings then how wordpress translation project get strings? Packed scripts can be unpacked and we use official wp scripts package for packing scripts. And can you at first try? I already wrote that all strings now merged into one .pot file, including backend and editor, you just need to generate json. Please check again tutorial, it doesn’t have step with generation of .pot file, you just need to copy it from actual version. Please try exactly how explained in tutorial and write me results
I noticed that the new version of the Greenshift core plugin includes a new .pot file, which contains almost all translatable fields!
However, this .pot file is generated in the Greenshift plugin development directory (which includes the src directory), while the plugin package downloaded from wordpress.org does not include a src directory (e.g., “source”:”src/blocks/counter/edit.js”). Therefore, users cannot generate a .pot file containing all translated fields using the downloaded plugin package.
This is because the WP CLI command cannot correctly recognize the contents of the webpack-packaged build/index.js to generate a .pot or .po file.
Therefore, the correct approach (choose one):
1. Generate the latest .pot file and include it in the plugin package with each new release.
2. Include the original files and directories in the src directory in the plugin package (this method should allow the official WordPress translation library to recognize all translated fields).
Simultaneously, the same approach should be adopted for addon plugins, and the download files in your marketplace user center should be updated.
This way, our users can translate the plugins themselves. Thank you!
as I wrote, addons also have updated unified .pot + some changes so you can use more simplified version of json file without hash (this was reason why it didn’t work for some users). I already provided you link on tutorial. Of course, we will not provide src folder for addons. First, it will increase size of package significantly. Second, it’s intellectual property. .pot file will be regenerated automatically each update
