Skip Navigation

[Resolved] Posts created/updated in 2nd language only visible in 2nd language

This support ticket is created 4 years, 4 months ago. There's a good chance that you are reading advice that it now obsolete.

This is the technical support forum for Toolset - a suite of plugins for developing WordPress sites without writing PHP.

Everyone can read this forum, but only Toolset clients can post in it. Toolset support works 6 days per week, 19 hours per day.

No supporters are available to work today on Toolset forum. Feel free to create tickets and we will handle it as soon as we are online. Thank you for your understanding.

Sun Mon Tue Wed Thu Fri Sat
- 10:00 – 13:00 10:00 – 13:00 10:00 – 13:00 10:00 – 13:00 10:00 – 13:00 -
- 14:00 – 18:00 14:00 – 18:00 14:00 – 18:00 14:00 – 18:00 14:00 – 18:00 -

Supporter timezone: Asia/Kolkata (GMT+05:30)

This topic contains 26 replies, has 3 voices.

Last updated by simonM-5 4 years, 3 months ago.

Assisted by: Minesh.

Author
Posts
#1438217

Hi Minesh

Just to be 100% clear before I open another ticket:

In our site, the language is default EN, just because we prefer to work and develop in English, however most of our posts are likely to come in DE, as we plan to go live in Germany first, so in effect no language should have any more "priority" over any other, although I appreciate that there has to be a default language.

1) Regarding the updates again, there is only one field that doesn't get translated in each of our Family Ads or Nanny Ads, and that is the big free text field at the end of the post. All the remaining fields are either numbers or taxonomies and these would translate fine if we the set the posts to "Translatable - only show translated items", right?

2) Regarding the WPML Settings:
For CPTs Nanny Ads and Family Ads we only set the WPML settings to "Translatable - use translation if available or fallback to default language", because we thought that was working in all languages, however if we set it to "Translatable - only show translated items", do we still have to create duplicates and triplicates?

3) So if we had updates to existing posts,
1) the updates to taxonomies and numeric fields would have to update across all the duplicates/triplicates
2) the updated text in the big free-text field at the end of each Ad would have to get copied to other language versions, but remain untranslated.

Please let me know if this scenario is supported and the recommended best practice for achieving this.

Sorry if I am asking the same question twice, I'm just returning from New Years and am a bit unclear what we discussed already in the thread. 🙂

Best regards
Simon

#1442537

Minesh
Supporter

Languages: English (English )

Timezone: Asia/Kolkata (GMT+05:30)

1) Regarding the updates again, there is only one field that doesn't get translated in each of our Family Ads or Nanny Ads, and that is the big free text field at the end of the post. All the remaining fields are either numbers or taxonomies and these would translate fine if we the set the posts to "Translatable - only show translated items", right?
====>
Which text field you are referring to:
- is it "We are looking for" available with Family Ads post type? If yes, you should set that field to "copy" from section "Custom fields" and click on the "Apply" button.
=> hidden link

- - is it "What I can offer ..." available with Native Nanny Ads post type? If yes, you should set that field to "copy" from section "Custom fields" and click on the "Apply" button.
=> hidden link

2) Regarding the WPML Settings:
For CPTs Nanny Ads and Family Ads we only set the WPML settings to "Translatable - use translation if available or fallback to default language", because we thought that was working in all languages, however if we set it to "Translatable - only show translated items", do we still have to create duplicates and triplicates?
====>
if we set it to "Translatable - only show translated items" - it will only display translated items, meaning it will display the posts if and only if the post is translated in a specific language. if they want to show the post type element everywhere and want that in every language it should be shown, then they have to duplicate it in order for it to be visible in every language.

3) So if we had updates to existing posts,
1) the updates to taxonomies and numeric fields would have to update across all the duplicates/triplicates
2) the updated text in the big free-text field at the end of each Ad would have to get copied to other language versions, but remain untranslated.
=====>
1) the updates to taxonomies and numeric fields would have to update across all the duplicates/triplicates
- from where you are looking to update those, from backend or frontend?

2) the updated text in the big free-text field at the end of each Ad would have to get copied to other language versions, but remain untranslated.
- Yes, because you chose the setting "copy", so it will copy the values, if you want to set it to Translate it, we need to save the field value manually using form's hook.

First - you need to decide, with what WPML setting you would like to go with and then decide and make a list of what fields you want to copy and what fields you want to translate.

#1446077
Screenshot 2020-01-08 at 10.38.24.png

HI Minesh

1) Yes, you are right, those are the two big freeform text fields I mean.
>>> I have set the two relevant fields to Copy under WMPL > Settings > Custom Fields Translation.
>>> This means just the should be copied, correct? The field captions should still get translated via String Translation, right?

2) I believe we should be using the setting "Translatable - only show translated items". Again, our requirement is: users should be able to create the post in their preferred language, however the posts should be searchable regardless of the language other users are using. Eg I should be able to create a Nanny Ad in German, but Family Users should be able to search and find that Ad, regardless of the language they are viewing the website in and vice versa for Job Ads being found by Nanny Users.

3) Updates to taxonomies and numeric fields should happen from the front end. The only update we will do from the backend is set the status from Pending to Published.

For example if a Nanny adds a competency to her profile (a custom taxonomy), it should be added across all language versions, regardless of the language in which she updated her Ad.

Updates to a numeric field, eg Years Experience, should get copied to all duplicate posts in the other languages.

I believe I have set all the custom fields (wpcf-*) to Copy, that don't get translated and should get copied to duplicates, as in the screenshot.

So could it be that the problem is now resolved and that we don't need any more custom code?

Thanks and regards
Simon

#1446145

Hi Minesh

Coming back to you on the updates: From your reply #1437959

What about updates to forms which have already been submitted, what would be the expected behavior in this case? Does an update count as a submission? In which case, would an update cause further triplicates to be created?
==>
Update form code should be written and tested so that if duplicates are already available, it should not makes more duplicate. You should open a new ticket and share all the required information like where you added the post edit form with access details and assign it to me.

For updates our requirements would be:

1) If duplicates already exist:
a) Updates to taxonomies: Taxonomies should be updated across all duplicates. Their translations should happen then via Taxonomies Translation.
b) Updates to numeric fields: the updated value should be replaced in the duplicates with the updated value.
c) Updates to the big freeform text custom fields (wpcf-we-are-looking-for, wpcf-nanny-what-i-can-offer). This text should remain untranslated and be copied to existing duplicates, replacing the existing content.

Kind regards
Simon

#1448585

Minesh
Supporter

Languages: English (English )

Timezone: Asia/Kolkata (GMT+05:30)

1) Yes, you are right, those are the two big freeform text fields I mean.
>>> I have set the two relevant fields to Copy under WMPL > Settings > Custom Fields Translation.
>>> This means just the should be copied, correct? The field captions should still get translated via String Translation, right?
==>
Yes, that's correct.

2) I believe we should be using the setting "Translatable - only show translated items". Again, our requirement is: users should be able to create the post in their preferred language, however, the posts should be searchable regardless of the language other users are using. Eg I should be able to create a Nanny Ad in German, but Family Users should be able to search and find that Ad, regardless of the language they are viewing the website in and vice versa for Job Ads being found by Nanny Users.
==>
I understand and thats the same thing you raised with your earlier reply:
- https://toolset.com/forums/topic/posts-created-updated-in-2nd-language-only-visible-in-2nd-language/#post-1414863
And I shared the information how it works:
- https://toolset.com/forums/topic/posts-created-updated-in-2nd-language-only-visible-in-2nd-language/#post-1416623

The only difference is at that time the setting in question was "Translatable - use translation if available or fallback to default language " and now the setting in question is"Translatable - only show translated items".

The different between duplicate post and translated post is listed here - I urge you to review that:
=> https://wpml.org/documentation/translating-your-contents/displaying-untranslated-content-on-pages-in-secondary-languages/using-content-duplication/#differentiate-between-translation-and-duplicate

3) Updates to taxonomies and numeric fields should happen from the front end. The only update we will do from the backend is set the status from Pending to Published.
==>
Ok -

For example, if a Nanny adds a competency to her profile (a custom taxonomy), it should be added across all language versions, regardless of the language in which she updated her Ad.

Updates to a numeric field, eg Years Experience, should get copied to all duplicate posts in the other languages.

I believe I have set all the custom fields (wpcf-*) to Copy, that don't get translated and should get copied to duplicates, as in the screenshot.

So could it be that the problem is now resolved and that we don't need any more custom code?
==>
as you described - the new post created/updated from the frontend only - correct? If yes:
It looks like we need to add some custom code to copy the fields but first of all, before taking next step, can you please confirm with what setting you want to go with:
- Translatable - use translation if available or fallback to default language "
- "Translatable - only show translated items"

Once you give me confirmation, I'll start to dig with the next step of copying custom fields with duplicates.

I split the ticket for the update process you shared:
=> https://toolset.com/forums/topic/posts-created-updated-in-2nd-language-only-visible-in-2nd-language/page/2/#post-1446145
- I will handle that with the split ticket.

#1449591

HI Minesh

If you're confident that our requirement is met using the setting "Translatable - only show translated items" then I'm happy for this issue to be resolved and the open (split) issue of copying custom fields with duplicates to be further worked.

Thanks and regards
Simon

#1450797

Minesh
Supporter

Languages: English (English )

Timezone: Asia/Kolkata (GMT+05:30)

If you're confident that our requirement is met using the setting "Translatable - only show translated items" then I'm happy for this issue to be resolved and the open (split) issue of copying custom fields with duplicates to be further worked.
==>
Ok. So, to run a test I've set the post type "Native Nanny Ads" setting to "Translatable - use translation if available or fallback to default language" from WPML -> Settings.

Then, I've created a post in Spanish: => hidden link
- I can see the post is successfully duplicated with all the custom fields. So, it seems no custom code needs to be added.
- so, it seems that the option "Translatable - use translation if available or fallback to default language" would work.

Can you please run a couple of tests and confirm that it works as expected.
(check all fields are copied automatically to duplicated language posts)

Once you confirm that the duplicated posts work as expected, we will sort out the query related to edit form.

#1451003

HI Minesh

We tested again and there was no difference. All posts and duplicates were created and translated successfully.

We have since decided that we are going to publish straight away and not go to status pending. You have one post in Pending still. I didn't want to touch the one you're editing currently, but you can set it to Published as well if you like.

We have set both CPTs Native Nanny Ads and Family Ads to "Translatable - use translation if available or fallback to default language".

Kind regards
Simon

#1455357

Minesh
Supporter

Languages: English (English )

Timezone: Asia/Kolkata (GMT+05:30)

Great 🙂 - really happy to see that you are now having the results as per your expectations. So, finally, if everything is sorted out here, please feel free to mark resolved this ticket 🙂

I'll ping you in the split ticket 🙂

#1455851

HI Minesh

Does this mean that all customers who want to use more than one language on their site are forced to use custom code to ensure correct translation? This seems a little strange to me.

Kind regards
Simon

#1455853

Minesh
Supporter

Languages: English (English )

Timezone: Asia/Kolkata (GMT+05:30)

Does this mean that all customers who want to use more than one language on their site are forced to use custom code to ensure correct translation? This seems a little strange to me.
==>
What do you mean exactly? Do you mean the code we added to duplicate the posts? If yes:
- To duplicate the posts automatically from the frontend (while creating a post using Toolset Form), the code we added is required.
- There is no automate the process to duplicate the posts using the Toolset Form.

#1455885

My issue is resolved now. Thank you!

This ticket is now closed. If you're a WPML client and need related help, please open a new support ticket.