Use individual shortcodes and/or custom Gutenberg blocks depending on the selected language and hope there's another way besides using the WordPress-Editor or writing my own workaround
Long: Okay.
Hi! 🙂 I'm the webmaster/builder/admin of hidden link - a page constantly changing somehow. For several years the page ran on Polylang, but since more languages are about to be added the Executive decision was made to switch to WPML instead, because it's Advanced translation interface and similar features.
Aaaand now I'm the guy who has to make it all work. 😀 So right now I'm doing so on our Dev-Server.
Transferring the Contents from Polylang worked fine and I am quite happy with the plugin too. BUT...
The reason for my superiors to use WPML now instead of Polylang was, as I said, the Advanced Translation interface.
... which, I just learned, can't be used to give an individual shortcode for each language (for example for a text slider). Or for Custom Gutenberg Blocks that need translated tests too, of course. Or the plugin "SOGO Add Script Header Footer" that we Use to load individual CSS Files and .js files on each page... It seems that WPML ignores those all - even when I tell it to use a WPML duplicate of the page as translation.
Now - I have already googled around to see if, perhaps, I have missed some option, but it doesn't seem that way. Please tell me I'm wrong! 🙂
Also: I do have a few ideas for workarounds for pretty much all of the problems - and I believe they'll work... But they need additional work I hope to avoid:
1. The plugin for the header/footer script used for CSS and Java Files on each page can, I'm sure, be replaced with Advanced Custom Fields (also in use on the page) - I'd just need to slightly modify the page template files for that to work. If I understand right, then THOSE should then be manageable through WPML and also will be copied in a Duplicate of the page, correct? Which would mean I need to open every single page (including a whole bunch of custom post type stuff) and copy-paste the content from the plugin-fields to the ACF Fields instead.
2. It should be possible to modify the custom Gutenberg-Blocks to have each field in all languages and then output only the version with the selected language. That'll also require me then to manually adjust all the pages that have those in use...
3. The shortcode problem can be fixed in the same fashion using a new, custom, Gutenberg-Block that has all the different shortcodes and also only will output the correct one.
From what I've seen these workarounds sure SHOULD work. Whether the "Deciders" like the fact that I'll need a bunch more time to write them and implement the changes needed on each page or post I can't say now, I'll have to wait until tomorrow for that. Buuuut maybe a workaround isn't required, because I have missed something...
> Is there any documentation that you are following?
Oh, I HOPE there is one and I'm just not finding it! But it seems there isn't...
> Is there a similar example that we can see?
hidden link - Scroll to the bottom of the page, there's four pictures with Text and button. Each of them is a custom Gutenberg-Block, because they're used all over the place and with the custom block it's easier for the authors to set them up without my (admin) help. The block comes with fields for the image, text, Link URL, Link text, Button colour and height.
A whole bunch of other blocks like these is in use too... Then several pages have sliders, added with shortcode, that need to be different depending on language. And since basically every second page gets new elements by the designers that would create one HUGE Css file if I had them all in one file each page or sometimes group of pages has it's own css and sometimes Javascript files that also need to be handled.
> What is the link to your site?
See above. ^^
Let's see if you can help me. If not, then I'll have to see whether the Execs will sanction doing all the needed workaround work. If not then we'll probably have to stick with Polylang after all...
Thank you for contacting WPML support, I'd be happy to help you with this issue.
If you want to use the WPML Advanced Translation Editor, that means you should translate content on the page: texts, images, URLs ... and not the layout or HTML structure. WPML attempts to translate content on the page as much as possible. If you are using a custom block, you can follow the documentation below to register it for translation https://wpml.org/documentation/support/language-configuration-files/#gutenberg-blocks
With the custom block from Lazy Blocks, it is compatible with WPML hidden link
For the CSS and JS code, you can create the code for a specific page and use the selector html[lang="de-DE"] to select the element in the second language.
YOu are right - Lazy blocks actually have a Button for wpml translations now, I didn't see that before!
Buuuuuuut even so I still have problems with fields not turning up:
I have one block "landingpagesinfoblock" that has, amongst others, a field for a link, a text field for the link text and a wysiwyg field (running the classic editor) for the rest of the copy. Those three fields are set to be translateable, but in the advanced translator only the "button-text"-Field shows up, the URL Field and the WYSIWYG fields don't show.
(I haven't even started to check all the other Blocks in use - I hope that, when we get this one fixed I then can do the rest following the example).
I JUST have noticed: When I misstype the URL to say https//google.de (without the ":") then suddenly the field shows up for translation!
The WYSIWYG Field still keeps NoShow, though.
If you want I can give you access to the DEV page for you to have a look around?
Regarding the WYSIWYG field, can you please help me to replicate the issue on a clean installation? It could be a compatibility issue when only this field value is not available in ATE. You can login directly to the admin area with this link hidden link
Okay - I installed Lazy Blocks, did a basic WPML configuration and copied the Lazy Blocks from our page, so you indeed get 100% the same blocks.
And - indeed - the error also appears on the test page, as you can see. The Classic Editor WYSIWYG Field "Copy" isn't offered for translation. Actually now even the buttontext isn't in there - and I can't find the URL now searching for https (that worked before, when I tried).
Something is really effed up here, but it's good to see it's not because of all the other plugins on the page, apparently
When editing the Lazy Block, you can enable the option "WPML translation" for each block in the tab Content Controls. Then the field value is available in Advanced Translation Editor to translate. Please check screenshots below.
Hello there. Yes, I know this switch, it didn't work for the fields in that Lazy Block, just as you saw on the demo page.
But I found the apparent problem now on our DEV Server:
<p><?php echo $attributes['copy']; ?></p> <- That's how the field was output in the Block's template, and apparently WPML doesn't like html code with too many tags in it?
When I replaced the <p> with <span> instead it works. I'll now check all the other elements in use...
Maybe there is an issue with the output PHP code on your site. On the sandbox site, I see you use the <p> tag and it works properly.
Also, I'm focusing on the translatable of the field, not how it's displayed. If you see all fields are translatable and available in ATE, that means the issue is resolved.
Well, it now works for that one block. And yes, this was all about the translatability of fields, not the way they're displayed.
I guess I won't bother you with the other problems I have with blocks then and think of something else. I mean... You asked me to replicate the problem, I did so and then next you tell me I have to activate the translation for fields... AFTER it should've been quite clear that this was about fields not showing up for translation even though that switch was flipped.
And yes, it works now with the P -tag on the sandbox, apparently, but looking at the Lazy Block you tried some weird stuff there with now two fields called "copy" - one WYSIWYG and one textfield. I tried that too on our DEV server and there it doesn't work.
But it's fine... I'm going to replace the blocks in question with pure html code now, that will make a whole lot more work for me, but at least it then will work.
I will mark this ticket as Resolved. Feel free to create a new ticket if you have any questions.
Thanks and have a good day.
Manage Cookie Consent
We use cookies to optimize our website and services. Your consent allows us to process data such as browsing behavior. Not consenting may affect some features.
Functional
Always active
Required for our website to operate and communicate correctly.
Preferences
The technical storage or access is necessary for the legitimate purpose of storing preferences that are not requested by the subscriber or user.
Statistics
We use these to analyze the statistics of our site. Collected information is completely anonymous.The technical storage or access that is used exclusively for anonymous statistical purposes. Without a subpoena, voluntary compliance on the part of your Internet Service Provider, or additional records from a third party, information stored or retrieved for this purpose alone cannot usually be used to identify you.
Marketing
These cookies track your browsing to provide ads relevant to you.
![Advanced Translation Editor - WPML [Staging] 2023-11-14 08-40-47.png](https://cdn.wpml.org/wp-content/uploads/2023/11/14793119-Advanced_Translation_Editor_WPML_Staging_2023_11_14_08_40_47.png "14793119-Advanced_Translation_Editor_WPML_Staging_2023_11_14_08_40_47.png")