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.

This thread is resolved. Here is a description of the problem and solution.

Problem:

Links in custom fields that are displayed on posts that are set to 'Translatable - use translation if available or fallback to default language' (AKA 'Display as translated') are not pointing to the translated link.

Solution:

Here is what you need to do. In the following example, I'm using 'link_field' as the field's meta name.
1. Go to WPML -> Settings -> Custom XML Configuration (tab).
2. Add this code:

<wpml-config>
    <custom-fields>
        <custom-field action="ignore" translate_link_target="1">link_field</custom-field>
    </custom-fields>
</wpml-config>

3. Update the original post or page where you have the custom field.

4. Check the 'Display as translated' version of the post or page.

Now the link in the custom field should also point to the translated post or page.

Please, note that the translated post or page needs to be translated with WPML's Translation Editor.

Relevant Documentation:

https://wpml.org/documentation/support/language-configuration-files/

https://wpml.org/documentation/getting-started-guide/translating-custom-fields/

This topic contains 11 replies, has 2 voices.

Last updated by Itamar 2 months ago.

Assigned support staff: Itamar.

Author Posts
August 8, 2019 at 11:55 am #4362381

Pieter

This is the 2nd BUG I am filing regarding virtual content duplication (earlier this week: https://wpml.org/forums/topic/bug-wp_list_pages-not-functioning-for-virtual-duplication/)

This time I have discovered that when adding a link to another page in the content it only works consistently when those links are added to the regular body of the page.

Once links are added to custom fields (that are set to translate), I cannot get it to work (consistently). In most cases the link added to the custom field does not get the language-code in the URL.

How to replicate:
- set page post type to "Translatable - use translation if available or fallback to default language"
- make a custom WYSIWYG-field with ACF and add this to the `page.php` template
- make a page
- on the page include a few links in the body as well as in the custom field.
- publish

- View page
- switch to secondary language and you will see that the links in the body receive the language code of the secondary language in the link, but the links in the WYSIWYG field are pointing to the default language.

Please advise.

August 8, 2019 at 1:16 pm #4363185

Itamar
Supporter

Languages: English (English ) Hebrew (עברית )

Timezone: Asia/Jerusalem (GMT+03:00)

Hi, and thanks for reporting this issue.

Nevertheless, it is not a bug, IMHO. WPML knows how to handle internal links that are added to the body of the post/page. So if there is a translation for this internal link then on the translated post/page the link will be to the internal translated link. With custom fields, the behavior is different. It depends on the field translation option. If it is set to 'Copy', then the link is being copied as it is. And if it is set as 'Translate' then, of course, you need to translate it, and WPML will not take any action further than your translation.

Please let me know if this makes sense to you r you have any other questions.

If you want to suggest a new feature regarding this issue, please fill out the form at the following link, and our developers will review that.
https://wpml.org/suggest-a-new-feature-for-wpml/

Regards,
Itamar.

August 8, 2019 at 1:56 pm #4363533

Pieter

Hi Itamar,
Thanks for getting back to me.
Although what you say makes a little bit sense, your suggested workaround of setting the fields to "copy" instead does not work.

If I'm understanding correctly what you imply is that links in custom fields can never be used then, because when the general content is set to "Translatable - use translation if available or fallback to default language" and

- field is set to translate: you say nothing happens because the field needs to be translated, which obviously is not happening with a virtual duplication

- field is set to copy: you say the link is copied, which is correct: the default language link is copied and does not get the language code added in on the virtual duplicate.

August 11, 2019 at 6:39 pm #4377255

Itamar
Supporter

Languages: English (English ) Hebrew (עברית )

Timezone: Asia/Jerusalem (GMT+03:00)

Hi.

I'm sorry if I was not clear enough, but I didn't mean that setting the field to 'Copy' is a workaround. Basically what I'm saying is that the WPML mechanism that works for links on the body section of the page does not work on custom fields. I think that it is not a bug. I'm currently consulting our second tier supporters about to get advanced with this issue. I'll get back to you here what I have an answer from them.

August 11, 2019 at 7:19 pm #4377331

Pieter

Hi Itamar,

Thanks for getting back on this and for consulting with second tier.

If it is not a bug and it is "by design", then I think it should be made clear on the documentation.

I will wait until you have more information regarding this.

Many thanks,
Pieter

August 11, 2019 at 7:21 pm #4377333

Itamar
Supporter

Languages: English (English ) Hebrew (עברית )

Timezone: Asia/Jerusalem (GMT+03:00)

Hi, Pieter.

While I wait for our second tier supporter answer, could you please tell me which part of our documentation do you find missing or confusing information?

Thanks,
Itamar.

August 11, 2019 at 7:33 pm #4377345

Pieter

Hi Itamar,
What I meant is that I think this page (https://wpml.org/documentation/translating-your-contents/displaying-untranslated-content-on-pages-in-secondary-languages/) should contain a warning or a note at the very least, explaining that links in the body and excerpt are included in the virtual duplication and therewith will point to the new language, links in other parts, for example custom fields, are excluded.

Hope that clarifies my earlier comment.

Thanks,
Pieter

August 13, 2019 at 6:33 pm #4390307

Itamar
Supporter

Languages: English (English ) Hebrew (עברית )

Timezone: Asia/Jerusalem (GMT+03:00)

Hi.

I'm discussing this issue with our third-tier supporter and our ACFML developer. I was told that processing links in custom fields might cause a significant performance hit. So that might be the reason why the links in custom fields are not being processed as fields in the body section.
I was advised by my superiors to check a certain workaround for this issue. If it does not work I'll escalate this issue.

Since I'll be on vacation from today including the weekend, I'll be able to return to you about this issue early next week.

Thank you for your patience.
Itamar.

August 14, 2019 at 7:13 am #4392823

Pieter

Thanks for the update Itamar, much appreciated.

I have also been thinking of a workaround. Of course one alternative is to actually physically duplicate the page and then change the link, but that completely takes away the advantages of virtual duplication.

Wish you a great vacation and talk next week then!

Pieter

August 18, 2019 at 4:00 pm #4412473

Itamar
Supporter

Languages: English (English ) Hebrew (עברית )

Timezone: Asia/Jerusalem (GMT+03:00)

Hi, Pieter.

I've tested the suggested workaround, and it works for me on a clean WordPress installation.
Here is what you need to do. In the following example, I'm using 'link_field' as the field's meta name.
1. Go to WPML -> Settings -> Custom XML Configuration (tab).
2. Add this code:

<wpml-config>
    <custom-fields>
        <custom-field action="ignore" translate_link_target="1">link_field</custom-field>
    </custom-fields>
</wpml-config>

3. Update the original post or page where you have the custom field.
4. Check the 'Display as translated' version of the post or page.
Now the link in the custom field should also point to the translated post or page.
Please, note that the translated post or page needs to be translated with WPML's Translation Editor, which I think that anyhow is the case on your site.
More about WPML configurations files at the following link.
https://wpml.org/documentation/support/language-configuration-files/
Please let me know if this information is helpful to you.

Regards,
Itamar.

August 18, 2019 at 6:04 pm #4412597

Pieter

Hi Itamar,

Hope you had a nice holiday and thank you for getting back to me on this.

I think your solution might indeed work on custom fields that are exclusively used as a link, but it does not work for custom fields that can contain a link.

In this case the original issue manifests itself with a link being added (as a shortcode) in an ACF wysiwyg custom field.

The only alternative is to physically duplicate the pages where this happens or by adding the links in a different way.

Anyways, it was worth a try and I realise that at best this is an edge case. After all Custom fields have their own translations settings that do not necessarily correspond with the translation settings of the post-types.

I think you can close this issue and I again want to thank you for your input!

August 19, 2019 at 3:17 pm #4417069

Itamar
Supporter

Languages: English (English ) Hebrew (עברית )

Timezone: Asia/Jerusalem (GMT+03:00)

Thank you for your input, Pieter.

About the suggested workaround, for your information, it worked for me even when I tried it with a WYSIWYG field.

Best Regards,
Itamar.