[Feature Request] Getting an __() string in a specific language
This thread is resolved. Here is a description of the problem and solution.
Problem: The client is trying to fetch a localized string for a JavaScript file in the Gutenberg editor, but the string is not being returned in the current language of the admin screen, even after attempting to switch languages programmatically. Solution: We recommend using the
wp_set_script_translations
function to ensure that the JavaScript file recognizes the localized strings. This involves generating a .json file from the .po file and ensuring it is loaded through a WordPress hook. Here are the steps:
For more detailed guidance, refer to the WordPress documentation on how to handle internationalization in block editors: Internationalization in Gutenberg.
If this solution does not resolve your issue, or if it seems outdated or irrelevant to your specific case, we highly recommend checking related known issues at WPML Known Issues, verifying the version of the permanent fix, and confirming that you have installed the latest versions of themes and plugins. Additionally, you can open a new support ticket for further assistance at WPML Support Forum.
This is the technical support forum for WPML - the multilingual WordPress plugin.
Everyone can read, but only WPML clients can post here. WPML team is replying on the forum 6 days per week, 22 hours per day.
I am trying to fetch a string (registered like so: __("More from USAHello", "usahello") in a specific language and send that as a localized variable for a javascript file in the Gutenberg editor.
I have a filter in the enqueue_block_editor_assets WordPress hook where I'm passing variables to be available in our custom script loaded in the Gutenberg editor like so:
But, this string isn't being returned in the current language of the admin screen, if I'm viewing the Spanish translation of a post, I'm still getting the English string. I've tried switching the language before fetching the string, but that didn't work either:
global $sitepress;
$sitepress->switch_lang('es');
$default_headline = __("More from USAHello", "hello-tools");
$sitepress->switch_lang();
But that still returns the English string too and not the Spanish string. So, how can I get the string in a specific language and pass it as a localized variable?
Gutenberg Blocks are not directly getting translated with String Translation - even though we might often display their strings on WPML > String Translation.
In order to translate a Gutenberg Block with WPML you need to translate them manually on each content or you need to use the WPML Translation Editor. (only one of both methods applies)
In order for the strings of the block to show up on the WPML Translation Editor you need to create a file called wpml-config.xml and include XML markup that will register the strings for the WPML Translation Editor as explained here:
Thank you for the reply. I already have an wpml-config.xml created that defines the parts of the block that should be translated. However, I don't think that's necessary because we manually translate all of our pages instead of using WPML's ATE or CTE. It seems pretty cumbersome and unreasonable to expect that we manually translate the default value of a block every time. We have 1000s of pages that use these blocks. There's no way to do this with WPML?
I can sadly not quite follow what you expect WPML do to in this case.
If you add a Gutenberg Block to a page in English it will need to be translated into other languages with the WPML Translation Editor or manually.
Surely, you can provide language files with your plugin that are already pre-translated, but if you are looking for such default translations through language files that ship with plugins or themes, then this is not so much a WPML question, but more a developer topic.
WPML String Translation will read any language file that comes with a theme and plugin and auto-complete such default translations shipped by the author.
In case I still get you wrong about the request, I can offer a test site with WPML on which you can replicate the issue and I can have a look at it for getting abetter understanding of the issue, but please take note again, that custom code requests can not be covered by our support policy.
It seems that I am not explaining the situation well. We have been manually translating all of our posts using the Gutenberg editor instead of WPML's translation editors. The issue is that on some of our custom blocks we have a field that has a default value (e.g. an H2 that says, "More from USAHello") that 99% of the time we leave as is, but occasionally we want to change for that one instance of the block on a particular post. The field is written so that it looks in the block attributes to see if a user has provided a unique value, if there is a unique value then that value is displayed, if not, then the default value is displayed (i.e. "More from USAHello"). We have that default value set using a gettext function so it looks like this in the code:
$default_headline = __("More from USAHello", "hello-tools");
This string is picked up by WPML in the String Translation dashboard and we have it translated into all of our languages. It works completely fine on the front-end, the default headline is displayed when appropriate (i.e. a custom headline isn't entered in by a user) and it is shown in the appropriate language to match the language of the post.
The problem is that on the back-end, in the Gutenberg editor itself, the default string is NOT displayed in the appropriate language. So, if we're editing the Spanish version of a post, the headline for the block still shows the English string and not the Spanish translation. We are trying to get the translated strings to show up on the back-end because it's confusing to our team while translating posts.
Indeed, I understood the issue and I have to admit that my knowledge of Gutenberg Development is still quite basic, which means I never tried to provide default translations for a Gutenberg Block with WPML or another translation plugin yet, but I can offer to have a look into that.
I suppose you use .po-files for your translations?
@andreas-w thanks, I'm working on putting together a simple plugin that has one of our blocks in it to deploy on that sandbox site and will update this ticket when it's uploaded.
I see you already installed a plugin on the sandbox.
Anyhow, there is not any block called usahello/test-block with which I could run tests.
Please let me know, once the issue has been replicated on the sandbox.
This ticket will remain open for a maximum of 14 days and close automatically after this timeframe, in case we do not receive any further messages from you.
Okay, Andreas. I have the demo plugin uploaded and activated. I added an instance of the block to the Test Page. It is a dynamic block that simply renders a <p> that says "Share these resources". I localized that gettext string in WPML and provided translations for the two languages I added (French and Spanish). I updated the WPML settings to match what we have on our website.
I left French as a duplicate of the original English page and I chose to Translate Independently the Spanish page. What you will see is that on the front-end, the "Share these resources" string shows up in the proper language based on which page you're viewing. Even for French, which is a duplicate page, the string is displayed in French.
The issue is that in the Gutenberg editor itself that string always shows up in English no matter if the page being edited is a duplicate or an independent translation.
This string can only get translated with String Translation, as it is coming from the plugin code, and this works as expected here:
hidden link
hidden link
On the backend, it is not working, indeed. It might be due to the nature of the Gutenberg rendering - as String Translation in this case only filters on Frontend, not on Backend.
I will consult the team and our product manager about if this would be a considerable feature request for WPML.
I consulted our product manager and he does not think that this would be a feature request, may be more of an issue that I could consult internally with the team if you wish, but after it is custom work and this is not covered by our support policy.
Live rendering in the block editor
Gutenberg 2.8 added the <ServerSideRender> block which enables rendering to take place on the server using PHP rather than in JavaScript.
Server-side render is meant as a fallback; client-side rendering in JavaScript is always preferred (client rendering is faster and allows better editor manipulation).
I decided to keep digging around since the <ServerSideRender> option seemed to be highly discouraged by the WordPress team. It turns out that the process to get javascript/block translations to show up in the Gutenberg editor is a very specific process, which I finally got working following this:
This workflow is very finicky, the naming conventions, file structure, and formatting all matter quite a bit. The biggest gotchas from my experience was ensuring the you generate a .json file from the .po file which is then localized/loaded through a WordPress hook so it's available to the javascript file that defines your custom block for Gutenberg.
These functions were placed in my plugin file to facilitate the loading of the .json equivalent of the .po file for the custom block.
{"translation-revision-date":"2023-01-11 13:59-0800","generator":"WP-CLI\/2.7.1","source":"build\/index.js","domain":"messages","locale_data":{"messages":{"":{"domain":"messages","lang":"es_ES","plural-forms":"nplurals=2; plural=(n != 1);"},"Share these resources":["Comparte estos recursos"]}}}
Thank you so much for mentioning that and I am glad you found a solution. Indeed, I did not recall it straight, but going with the JSON file is the correct attempt in this case.
It is that the String Translation module from WPML is designed for Front-End and Backend, but on the Backend, it will actually only translate according to the admin language and this will not work on Gutenberg Blocks due to their design.
WPML in such a case would need to reinvent itself in order to scan JSON files for strings and make them translatable with a dedicated new interface.
Anyhow, I am forwarding this information to our project manager for taking notice of this issue.
