gustavG-2
|
I'm sorry to say that I still seem to have problems with the blocks that I use on pages.
I have commented out the code you wrote about in global.php.
When I log in as a Swedish user, I go to a page and add a new block, for example, coworkers. It is in English (The block is originally written in Swedish and then translated into English using string translation).
When I then go back to my code in global.php and uncomment what was previously commented out, and then reload the page, I, of course, get it in Swedish as it was originally, and then when I comment it out again, it displays correctly in Swedish.
But if I want to add a new block, it doesn't work. It will then be in English.
|
Bruno Kos
WPML Supporter since 12/2018
Languages:
English (English )
German (Deutsch )
French (Français )
Timezone:
Europe/Zagreb (GMT+02:00)
|
Can you show us this on hidden link and record a video using tool such as hidden link, so a scenario which happens after you revert the code thing?
|
gustavG-2
|
hidden link
Here you have 2 videos.
Everyting works fine if you just not add new blocks to the page. In company information the block works perfect.
|
Bruno Kos
WPML Supporter since 12/2018
Languages:
English (English )
German (Deutsch )
French (Français )
Timezone:
Europe/Zagreb (GMT+02:00)
|
Escalated to 2nd Tier
|
Bruno Kos
WPML Supporter since 12/2018
Languages:
English (English )
German (Deutsch )
French (Français )
Timezone:
Europe/Zagreb (GMT+02:00)
|
About this:
"Option page string": This feature ensures that the language displayed on the option page is taken directly from the user's profile, rather than relying solely on the default behavior of WPML in WordPress.
"Blocks in editor": With this feature, the language displayed in the editor is determined by the language of the page itself, rather than relying solely on the default WP behavior through WPML.
Additionally, when certain code sections are commented out, it allows WPML to function seamlessly. In such cases, the translation of the page string defaults to English.
Can you clarify a bit more what is expected here and whether this is the same issue as with Options page?
|
gustavG-2
|
The option page works as expected.
The page that contains Gutenberg blocks do not work as expected. When a new block is created its field labels are in the language that the page is, not the language that the user is. The labels of the ACF fields is expected to follow the users language and not the current page language.
|
Bruno Kos
WPML Supporter since 12/2018
Languages:
English (English )
German (Deutsch )
French (Français )
Timezone:
Europe/Zagreb (GMT+02:00)
|
We don't think that would be a proper way for the language display. Let's say you are creating a page in Spanish, while the user profile language is English. The content should be entered in Spanish, not in English.
|
gustavG-2
|
Yes, the content should be entered in Spanish, but the block title and labels, I think, should be in English, not in Spanish. Maybe I am thinking wrong.
|
Bruno Kos
WPML Supporter since 12/2018
Languages:
English (English )
German (Deutsch )
French (Français )
Timezone:
Europe/Zagreb (GMT+02:00)
|
We think it makes sense these to follow the profile language of the user, as that is the main purpose of translating labels in the backend.
https://wpml.org/documentation/related-projects/translate-sites-built-with-acf/translating-acf-field-labels-with-wpml/
|
gustavG-2
|
Ok let me just get this right!
When my user, whose profile is set to English (image 1), visits a backend page in Swedish (image 2), they should see the title of the ACF block and the labels for the fields (all backend only) in English.
The user should only see the old ACF blocks in English, but if they add a new block to the page in Swedish, it should be in Swedish. This is because the page is in Swedish.
Is this incorrect?
|
Bruno Kos
WPML Supporter since 12/2018
Languages:
English (English )
German (Deutsch )
French (Français )
Timezone:
Europe/Zagreb (GMT+02:00)
|
Can you create a new ticket for this mixed languages issue? As that thing with blocks seems to be a different issue than reported here (as per our 2nd tier, given that this theme options issue was found to be caused when the values are stored in an acf-json folder).
|
