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.
| Sun | Mon | Tue | Wed | Thu | Fri | Sat |
|---|---|---|---|---|---|---|
| - | 7:00 – 14:00 | 7:00 – 14:00 | 7:00 – 14:00 | 7:00 – 14:00 | 7:00 – 14:00 | - |
| - | 15:00 – 16:00 | 15:00 – 16:00 | 15:00 – 16:00 | 15:00 – 16:00 | 15:00 – 16:00 | - |
Supporter timezone: Europe/London (GMT+00:00)
This topic contains 18 replies, has 2 voices.
Last updated by 5 years, 12 months ago.
Assisted by: Nigel.
No problem 🙂
Ok so yes, that is my situation. I followed your suggestion and translated back the view term in the shortcode to the default one, on the translated page. Still, I see mixed content.
If one CPT doesn't have the equivalent in French, the English one is shown, with mixed results (see screenshot).
Also, the following crazy thing happens:
EnglishPost --> FrenchPost
EnglishNewPost --> No French translation
Now in the screenshot, EnglishNewPost is displayed on my French side but, when I click on it, the url is the one with /fr/ at the beginning! So I am viewing a non translated English post, on my French side, with the French url! Is this correct?? Because sounds very weird.
also, since it was the main thing, any chance to change the behavior of the RFG in the future to be more multilingual friendly?
I think we are nearly there.
I don't know where your get_wpml_language_code_value shortcode comes from, I guess you wrote a custom shortcode to get the language details of the current post?
I did something similar, registering the following shortcode ("post-language"):
add_shortcode('post-language', function () {
$language = apply_filters('wpml_post_language_details');
// Return just the language code
return $language['language_code'];
});
Now, in the loop output section of my View I simply insert that shortcode so that I can see what language WPML/Views think the posts are in.
If you look in the screenshot at the results of a View in the secondary language which is including English results where there is no Spanish version of a post, WPML knows that the post is English, it doesn't think it is Spanish.
In fact, the array returned by that WPML filter is really helpful in this case, because it includes a flag for whether the language of the post is the same as the current language for the page.
I'm looking at the Spanish version of the page, and the Spanish posts in the View loop output return this:
[08-Feb-2019 11:16:10 UTC] language: Array
(
[language_code] => es
[locale] => es_ES
[text_direction] =>
[display_name] => Español
[native_name] => Español
[different_language] =>
)
But the English posts that are included because of the translation setting return this:
[08-Feb-2019 11:16:10 UTC] language: Array
(
[language_code] => en
[locale] => en_US
[text_direction] =>
[display_name] => Inglés
[native_name] => English
[different_language] => 1
)
So all we need for our shortcode to use in the wpv-conditional test is to return the different_language element and compare it to 1:
add_shortcode('different-language', function () {
$language = apply_filters('wpml_post_language_details', null, null);
return $language['different_language'];
});
which we use like this:
<wpv-loop>
[wpv-conditional if="( '[different-language]' eq '1' )" evaluate="false"]
<h3>[wpv-post-link]</h3>
<p>[wpv-post-taxonomy type="location" format="name"]</p>
[/wpv-conditional]
</wpv-loop>
That successfully only outputs anything for the posts in the intended language.
I wasn't looking at your RFG workaround here, but it's no problem using nested wpv-conditional shortcodes, so you should be able to work your solution inside this.
