2. Also where are we at with getting issues like the translate link targets not working etc. ? This one is still a real pain point as it mean manually translating all the links.
Languages: English (English )Spanish (Español )Italian (Italiano )
Timezone: Europe/Rome (GMT+02:00)
You have a problem with links not translating correctly.
I'd like to know if you could point me to a product or a place that is not translating correctly and walk me through the process.
- I had asked your developers and if you say had a link that was "site.com/product1" and then you migrated the site to dev1.site.com and translated it there, the link would only translate if the link was changed to dev1.site.com/product1
- From what i see, all the links are in native WordPress fields, right? if the links are in ACF fields or fields coming from plugins or any other place, then that's important to mention since they would pass through different mechanisms.
Could you give me an example in your site that i can test?
But to clarify it is when translating a page mainly. I create the page the link maybe in ACF block in WYSWYG field or in a standard WP Guttenburg block. Some links on the page will be translated ok, but mostly not.
When I refer to translated links I mean internal links going to the correct language version, but they are not mostly they are still pointing to the original base language version as before translating said page. So for example:
Original: hidden link
Should be for example: hidden link
But actually stays hidden link
Or might even do a combination of the 2 hidden link
But it is intermittent and random to which links it will and wont translate. I have tried translating in different orders, making sure the linked pages are translated before translating the main page etc. I have tried sticky links (this is why implemented in 1st place), I have tried using the ATE and translation manager, I have tried using the "Translate Link Targets" in WPML Settings (which literally does nothing for us, it scans and says it has but actually nothing).
As I said this was reported about a year ago with little to no progress on it and then other stuff has taken priory, specifically with WPML 1 issue at a time policy this got put to the back as we had translated what we wanted at the time and I manually did all the links. But now we are starting to work on adding new content which needs translating or editing existing content.
So I have just tested this on a dev site which only has Litespeed (with ESJ and redis off) and WCML only.
I created a new page and added 4 links to pages which are already translated. I translated using the Translation Manager as per my normal work flow. hidden link
I have used the translate link targets as in settings and it reports "All posts have been processed. 26 links were changed to point to the translated content." please see screenshots. And this worked so I enabled ACF + ACFML + WCML + String translation and translated a 2nd page with just a few basic links.
hidden link
And these seem to work automatically without having to run translate link targets.
I have added the language footer for swapping languages and as you can see it is using the standard Twenty Twenty-Four Theme.
So I will continue to investigate this further and see if I can narrow down the conflict / cause. But as I said before it is intermittent and random so like with all these issues may not be reproducible easily.
Languages: English (English )Spanish (Español )Italian (Italiano )
Timezone: Europe/Rome (GMT+02:00)
Ok!
I can tell you the following in hopes it will help you:
- We've been improving this part of our code for all the 4.6.X updates and we are working on doing the same for Advanced Custom Fields Multilingual and page builders like muffin builder, elementor, divi, etc. (Which do not seem to apply to you, wih gutenberg it should work).
- You shouldn't even need to use any plugin for this (like sticky links), Especially if you use any of the default themes from WordPress / WooCommerce.
- If the links are not absolute but relative (/product instead of hidden link) then those might not be translated, however they should appear in the translation editor, in the translated segment, if you use our latest layout, or hidden but searchable if you use the old editor layout.
- Translate Link target usually works better when you use page builders. gutenberg is considered one so it might help there as well.
I have done some additional work since my last reply. Importing the ACF block into the standard Storefront template and the links have not translated on this at all.
It seems it is something when ACF / ACF blocks is being used that is preventing it from translating the links.
Original hidden link
Translated but link still EN even after running Link scan. hidden link
Maybe the issue on standard gutterburg block was where I was using the "Classic Block". As I tested this also on the page and the link that was just a standard Guttenburg Paragraph block translated but the Classic Block and ACF blocks did not
I can confirm we have tried both local and full URLs.
This is tested on
WP 6.6.2
WPML 4.6.13
String Translation 3.2.12
WCML 5.3.6
ACF 6.3.6
ACFML 2.1.3
I also found other tickets with same issue and a errate which Laura sent me this code about a year ago which I dont think worked and she couldn't answer what it did at the time.
Anyways I added it to the XML Config in WPML settings on this site, deleted and re-translated 1 of the pages (Dutch version) and is still the same.
I have also tried updating the XML further to add the id of the field in the ACF block but it wont let me edit the XML further no errors etc. I am trying to add the below which is the actual ACF field but the XML file will not let me edit it. Which is one of the things I raised with Laura before and there was no resolution to it. I will look to see if I can work out how to edit the XML file manually.
I even tried manually updating the wpml-config.xml in sitepress plugin file but that made no difference. And before this I added the wpml-config.xml using the template from the support docs into the theme root folder. But still with the same results. And running the Link scan afterwards. Also deleting completely the translated versions before retranslating to make sure it updates.
Languages: English (English )Spanish (Español )Italian (Italiano )
Timezone: Europe/Rome (GMT+02:00)
Hello,
I checked again after you mentioned ACF, because there is a known issue with this and that will be fixed in Advanced Custom Fields Multilingual 2.1.5, which is the next Big release.
The issue happens mainly when you're on a nested field, a flexible field or a repeater, by the way, it doesn't really matter if it's a textarea, WYSIWYG or any other field, as long as it's in one of the scenarios mentioned above.
Is the field in a simple WYSIWYG but inside a block (not nested or in a repeater or flexible field?? that way i can try to test it and see if the problem happens on a clean environment.
The XML code won't do anything in here, since the links are translated no matter what, it doesn't matter if the field is set to copy or translate (That's the correct behavior up until now).
---------
With the classic block, it could also be a problem, mainly when the classic editor block is inherited from the actual old layout (And not when added manually) and I'll test with that as well (this one is tricky because it all depends how Gutenberg handled the migration from classic editor to Gutenberg block using the classic editor).
----------
I'll check with the project's developer since the WYSIWYG issue was fixed a long time ago, indeed and this might be a similar issue but not exactly the same.
So the Classic Block is a freshly created one so should be whatever the latest version is and a simple a tag was added which did not translate / update.
The ACF block has a WYSWYG Editor within the block. See screenshot. It is not within a repeater etc.
So it seems to me it is a more a general handling of a tags within HTML.
Languages: English (English )Spanish (Español )Italian (Italiano )
Timezone: Europe/Rome (GMT+02:00)
I have recreated the problem with the classic block. however with ACF WYSIWYG, our devs told me that the expected behavior is for it to be translated on the fly on the front-end but that it will show as untranslated in the back-end.
It basically goes through this filter that is run when you click the "Translate Link Target" feature.
I'm escalating the case to our devs to see how it can be solved. I know that classic block in general is not super compatible because it's kind of legacy code but i think it should still be fixed with at least a workaround.
