[Resolved] Using WPML shortcodes as dropdown placeholders break search filters

[Author]

Posts

[caroleM-4]

Hello,

I am using WPML string shortcodes to translate some of my view blocks which works perfectly for search filters labels and text field placeholders.

Unfortunately it's not the case when using them as select dropdown placeholders where the shortcode breaks the preview (attached screenshot) and the search filter functionality.

The problem occurs with all selects fields no matter if it's meant to filter results based on a custom field or a taxonomy.

In fact, the string is translated correctly on the frontend and the select field seems to works normally at first sight but you can select any value and click the search button, the results won't be filtered anymore until you remove the shortcode.

Can you please have a look to see if it could be fixed ?

Thanks in advance for your help.

[Minesh Supporter Languages: English (English ) Timezone: Asia/Kolkata (GMT+05:30)]

Hello. Thank you for contacting the Toolset support.

That is not the right way to translate the view.

Please check the following doc that shows how you can translate the Toolset element:
https://toolset.com/course-lesson/translating-views-content-templates-archives-and-forms/#translating-toolset-elements-yourself

In your case its view:
https://toolset.com/course-lesson/translating-views-content-templates-archives-and-forms/#translating-views

You should not add any shortcode to your select box default text value but instead just add the text and then using Translation Editor you should translate that text.

[caroleM-4]

Thanks for the feedback and sorry for my late reply.

Actually I did choose to use WPML string shortcodes in this view block for the following reasons :

- I use this view block in a content template added to a page as a workaround to the issue described on https://toolset.com/forums/topic/pages-custom-fields-updated-for-all-pages-containing-same-view-block/

- There are only a few strings to translate in the concerned view block, most of its content being brought dynamically by custom fields

- Our customer that may want to change the translations sometimes is used to WPML string translation interface but will for sure get lost with the translation editor. He's actually managing translated pages content by editing them directly and won't be able to translate the view block strings there if I use the translation editor to translate the content template it's included in.

- I encountered many problems with a content template that I did translate using WPML translation editor and for wich the translated version did not update correctly when making other changes than textual ones on the original version such as for exemple changing font sizes or styles of a Gutenberg block included in it. The only workaround I found at the moment was to ask WPML to copy original to translation and translate again which convinced me that I needed to find another way to manage the translation of the strings I had in there.

So of course I could try to use the normal way but I really would prefer having WPML shortcodes working for search filter dropdown placeholders as they do work for other placeholders and labels or, if really not possible, at least being able to use those automatically registered by WPML for the view (attached screenshot) which actually do not work either (translation is not applied) even if, at least, they do not break the fields functionalities.

I noticed when creating a new view block that there was already a string shortcode used for the "No item found" string which suggest that those shortcodes are meant to be usable in there. Is there really no way to get them working correctly for placeholders too ?

Thanks in advance for your help and have a nice weekend.

[Minesh Supporter Languages: English (English ) Timezone: Asia/Kolkata (GMT+05:30)]

You will have to adopt to the suggested translation workflow and as of now you will have to use the translation editor to translate your view (filter) strings. With new translation workflow the use of the shortcodes are not permitted.

[caroleM-4]

Bad news for me.

Does it mean that with future versions of WPML / Toolset, WPML string shortcodes won't be working anymore in any places or is it only for view blocks filter strings that it won't be possible to use them but they will still be working correctly in places they do actually ?

And, if I have to use the translation editor instead, like it's recommended, what about Gutenberg styles that do not update correctly in translations when changed in the original version, is there a way to avoid that ?

As for the view blocks I use in content templates integrated in pages, I can eventually duplicate them to solve the problem. But I guess the same won't be possible for the content templates I use for single posts of each content types so if I have to translate them again each time they are modified, could you please at least tell me which is the correct way to delete an existing translation because I did not find any while testing.

Thanks in advance for your help and have a nice day.

[Minesh Supporter Languages: English (English ) Timezone: Asia/Kolkata (GMT+05:30)]

Does it mean that with future versions of WPML / Toolset, WPML string shortcodes won't be working anymore in any places or is it only for view blocks filter strings that it won't be possible to use them but they will still be working correctly in places they do actually ?
===>
Its within the blocks. For instance if you have legacy view and within the legacy view you added the [wpml-string] shortcode, it should work as expected without any issue.

And, if I have to use the translation editor instead, like it's recommended, what about Gutenberg styles that do not update correctly in translations when changed in the original version, is there a way to avoid that ?
===>
As per our support policy, we entertain only one question per ticket. The Gutenberg styles should be copies or set to be copied. If you found issue, please kindly report with the separate ticket will all required information and it will be handled with any of the available supporter as soon as possible.

As for the view blocks I use in content templates integrated in pages, I can eventually duplicate them to solve the problem. But I guess the same won't be possible for the content templates I use for single posts of each content types so if I have to translate them again each time they are modified, could you please at least tell me which is the correct way to delete an existing translation because I did not find any while testing.
===>
Lets say you have two languages [English and Portuguese]. You want to delete the translation for the page translated in Portuguese.

To delete the page translated in Portuguese, you can go to Dashboard->Pages and from the top admin bar change the language to Portuguese and delete the selected pages, this will delete the whole page. Then please make sure that to delete this page the trash.

In addition to that, you can also delete the specific strings as per your choice from WPML => String Translation as well.

[caroleM-4]

Ok, I'll open a new ticket if needed for the Gutenberg styles issue but I will test again first.

As for the WPML string shortcodes, I am sorry but it's still not completely clear for me. I do not use any legacy view, only view blocks / content templates, and the shortcodes are actually working perfectly for every strings inside these view blocks / content templates except for filter dropdown placeholders. So my question was : will they still be working in future versions for labels, free text in Gutenberg / Toolset blocks and other placeholders than the filter dropdown ones or should I stop using them completely in view blocks / content templates ?

And finally for the translation deletion, I was not talking about pages but about Toolset content templates for which I can't switch language to reach other languages versions. Sorry if it was not clear.

[Minesh Supporter Languages: English (English ) Timezone: Asia/Kolkata (GMT+05:30)]

As for the WPML string shortcodes, I am sorry but it's still not completely clear for me. I do not use any legacy view, only view blocks / content templates, and the shortcodes are actually working perfectly for every strings inside these view blocks / content templates except for filter dropdown placeholders. So my question was : will they still be working in future versions for labels, free text in Gutenberg / Toolset blocks and other placeholders than the filter dropdown ones or should I stop using them completely in view blocks / content templates ?
===>
[wpml-string] shortcode should be working as expected with blocks like you added(as I can see with the image you shared). There should not be any issue.

And finally for the translation deletion, I was not talking about pages but about Toolset content templates for which I can't switch language to reach other languages versions. Sorry if it was not clear.
==>
ALL strings you translate using translation editor should be registered to string translation, you should try to find the string and delete the unwanted string based on the block you added.

For instance, you have "fields and text" block added on the content template that contains the text "my content". You can translate it using the translation editor.

Now, you change your mind and remove the existing block and re-add it, when you re-add the "fields and text" block and add some content "new content" and save your content template, when you translate the content template using translation editor, it will show you the newly added block untranslated and if you visit the String translation, you will notice that new string translation entry should be added.

[caroleM-4]

So if I understand well :

- the only place in which I can not use WPML string shortcodes is parametric search dropdown placeholders in view blocks

- the only available way to translate parametric search dropdown placeholders in view blocks is to translate the pages or content templates they're integrated in using WPML translation management / editor

- Once a content template has been translated using translation editor I should be able to manage each block translation in string translations

Is that correct ?

[caroleM-4]

Sorry to post again before you found the time to reply to my previous questions but I just noticed that WPML string shortcodes are actually working perfectly when used as sorting dropdown label in view blocks which is quite the same situation, so could you please also tell me which difference is preventing them to work as filter dropdown placeholder ?

Because what's happening in the preview when using them as placeholders suggest a syntax problem with a " or ' and could probably be fixed if not happening with sorting dropdown label which would be great for me as all other mentioned solutions are getting me into big complications for just a few strings.

And by the way, could you please also help me understand what's the point of the strings automatically registered when saving the original view block (attached screenshots) if their translation is not applied ?

As for the content template translations, I think I am going to open a separate ticket because there are many things I don't catch and they are not really related to the subject of this one.

[Minesh Supporter Languages: English (English ) Timezone: Asia/Kolkata (GMT+05:30)]

Sorry to post again before you found the time to reply to my previous questions but I just noticed that WPML string shortcodes are actually working perfectly when used as sorting dropdown label in view blocks which is quite the same situation, so could you please also tell me which difference is preventing them to work as filter dropdown placeholder ?

Because what's happening in the preview when using them as placeholders suggest a syntax problem with a " or ' and could probably be fixed if not happening with sorting dropdown label which would be great for me as all other mentioned solutions are getting me into big complications for just a few strings.
==>
I'm not sure why you wont able to translate the placeholder text with your filter dropdown. Can you please share admin access details and problem URL where you added the shortcode.

And by the way, could you please also help me understand what's the point of the strings automatically registered when saving the original view block (attached screenshots) if their translation is not applied ?
==>
Its internal thing, string registered as original source of the string when you save your view and then you can translate it using translation editor.

*** Please make a FULL BACKUP of your database and website.***
I would also eventually need to request temporary access (WP-Admin and FTP) to your site. Preferably to a test site where the problem has been replicated if possible in order to be of better help and check if some configurations might need to be changed.

I have set the next reply to private which means only you and I have access to it.

[Jamal Supporter Languages: English (English ) French (Français ) Timezone: Africa/Casablanca (GMT+00:00)]

Hello Carole! This is Jamal from the Toolset support team. Minesh won't be available for a couple of days. If you don't mind, I'll continue with you on this ticket.

Honestly, I don't know why the WPML shortcodes are not working as expected when used as a placeholder for dropdowns, but I can't really escalate it or discuss it with our 2nd Tier or our developers, because we are changing the way we translate the Toolset elements(views, content template, and archive templates). You need to use the new way without investing too much time in something that will be dropped in the upcoming releases.
Basically, the WPML shortcodes, even though they still work in some places, are meant to be removed in the future.

I checked the pages that you have shared in both languages, and I don't see any issues. The filters are working for both pages, in both languages. Am I missing something? Can you add a screenshot that shows the issue, or the steps I should follow to reproduce it?

[caroleM-4]

Thanks for the feedback Jamal.

I asked Minesh if WPML string shortcodes were going to be removed in future versions but I probably misunderstood his answer, reason why I was still trying to find a solution to get them working.

As for the example website pages, Minesh removed the shortcodes in placeholders, reason why the filters were working. I added one back on page hidden link so you can see the placeholder is correctly translated but the filtering does not work anymore.

Anyway, it's not really useful to fix that if they are going to be removed. Maybe instead you could tell me if there is another solution I can use to be able to manage strings contained in content templates / views (labels, placeholders, etc.) via the string translation interface of WPML because that's what I need and the way I get there is not really important for me.

Honestly, I am not really against using translation editor for content templates / views but I am encountering issues when a view block is included in a content template (details on https://toolset.com/forums/topic/strange-behavior-of-toolset-content-templates-with-wpml/) which will often be the case on this website and, even if it gets fixed, our customer won't be able to edit the translations on his own if he also has to do it via the translation editor, which gets him lost very quickly even for content much simpler than views, and it will be the case as the secondary language content templates cannot be edited directly once translated like it's the case for pages.

That's why I thought about using WPML string shortcodes to deal with the the few strings I have in there so that he will be able to manage the translations via the string translation interface which he is used to, the previous version of his website being mostly custom code and thus relying heavily on this part of WPML.

Maybe gettext filter could be an alternative to WPML string shortcodes in this context ? If you confirm there is no WPML solution, I'll give it a try next week to see if it may solve my problem.

Understand me, I really want to use a Toolset / WPML combination for this website but I also want our customer to be confortable editing it so I need to find a way to get around that.

Thanks for your patience and have a nice week.

[Jamal Supporter Languages: English (English ) French (Français ) Timezone: Africa/Casablanca (GMT+00:00)]

Thank you for your feedback, Carole. I read your 3 tickets and I understand better your concerns. I can narrow all the use cases to the following points:
1. You would prefer to use the WPML String Translation instead of the translation editor, for strings.
2. You would like to be able to manually translate content templates, in order to have different blocks between languages.

Please correct me if I am wrong!

I'll try to elaborate on each point:

1. String Translations use for strings
I assume that you want to use the blocks editor, right! In this case, I still recommend avoiding the WPML strings at all. You will still be able to translate them. I run a test on the sandbox and I was able to translate the dropdown placeholder through String translation.
WPML shortcodes do not have much sense for the block editing experience. They are rather handy for the legacy editing experience.

These are the steps I followed to translate the string:
1. Edit the content template that contains the view, remove the WPML shortcodes from the dropdown filter placeholder, and save.
2. Search for the placeholder string in WPML->String Translations, and I removed all the strings to start from a fresh point.
3. Activate "Look for strings while pages are rendered" in "Auto register strings for translation" in WPML->String Translations.
4. Visit the page to make sure the view's strings are registered during rendering.
5. Search for the placeholder string in WPML->String Translations, and translate the occurrences that appear.
6. Check the translated page to confirm if the placeholder is translated correctly.

WPML recommends translating the content created with page builders using the translation editor. But, I still think, the translations are managed, under the hood, through WPML String Translations. That's why I was able to translate the placeholder from it.

I hope this will remove your concern about your customer's habit to use WPML String Translation!
If I missed something about it, please let me know an example you have to better understand.

2. Manual translation for content templates:
I am afraid this is not possible. I need to reach to our 2nd Tier or our developers to get more insights about it. And I'll get back to you as soon as possible.

In the meantime, I can imagine two workarounds. I did not test anyone yet. I will give them a shot tomorrow:
- Using the conditional block and check against the current language. This will need a custom function that returns the current language to be registered in Toolset->Settings->Front-end content.
- Using the wpv_filter_force_template filter to apply a different content template per language.
https://toolset.com/documentation/programmer-reference/views-filters/#wpv_filter_force_template

I'll get back to you as soon as I have any feedback about it.

[Jamal Supporter Languages: English (English ) French (Français ) Timezone: Africa/Casablanca (GMT+00:00)]

Hello again,

I run a test in a new installation and I was able to translate the content template manually. This allowed me to add a container only on the secondary language. Check this screenshot hidden link

I was able to do so, by directly translating manually, without having to duplicate the content template, then edit it independently. Check this screenshot hidden link

This being said, I would like to ask about the original question of this ticket(using WPML shortcodes within a dropdown filter placeholder). Does my previous reply answer your questions? Do you have any further questions?

Regarding manual translation for content templates, please keep its discussion in the current ticket(with Shane), or create a new ticket for any questions. Let's keep this one about the WPML shortcodes.

I'll remain at your disposal.