This thread is resolved. Here is a description of the problem and solution.
Problem: The client is experiencing issues with endpoint translations in WooCommerce Multilingual due to a mismatch in function signatures between WCML_Endpoints and WPML_Endpoints_Support. The example provided on the WPML documentation page uses a different method signature, causing incorrect language switching and missing translations. Solution: We recommend modifying the endpoint creation as follows to resolve the issue:
Additionally, ensure that you have updated to WooCommerce Multilingual & Multi-Currency 5.5.0 or later, which addresses this issue. You can update the plugin via Plugins > Add new on the "Commercial" tab by clicking on "Check for WPML Updates". Alternatively, you can download the latest version from your WPML account downloads page.
If this solution does not apply to your case, or if it seems outdated, we highly recommend checking related known issues, verifying the version of the permanent fix, and confirming that you have installed the latest versions of themes and plugins. If issues persist, please open a new support ticket.
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.
<b>Symptoms: </b>
The language gets switched to a non-existing locale, and some translations are not being displayed. This happens because the second parameter is language and not endpoint, leading to incorrect language switching when trying to register the endpoint.
<b>Questions: </b>
Is the example provided on the website incorrect?
Has backwards compatibility been broken at some point?
Languages: English (English )Spanish (Español )German (Deutsch )
Timezone: America/Lima (GMT-05:00)
Hello,
I suggest you stick with this example of the usage of this hook is:
/*
* Add this code to the functions.php file of your theme.
* This is extracted from the WCML WC Subscriptions compatibility class.
*/
add_filter('wcml_register_endpoints_query_vars', 'register_endpoint', 10, 3 );
function register_endpoint( $query_vars, $wc_vars, $obj ){
// Add the translation for the custom "view-subscription" endpoint.
$query_vars[ 'view-subscription' ] = $obj->get_endpoint_translation( 'view-subscription', isset( $wc_vars['view-subscription'] ) ? $wc_vars['view-subscription'] : 'view-subscription' );
return $query_vars;
}
I am (and other extensions are using it like this)
The issue lies in WCML (maybe a rewrite at some point) because as I already explained
$obj is an instance of WCML_Endpoints but it's signature does not match that of the example, it takes 2 arguments $endpoint and $language while another similar class takes $key, $endpoint and $language
That means that with the example provided, the $language parameter is set to 'view-subscription' which is obviously not a valid language code and was meant to be $key and $endpoint.
That means that it will lookup the string translation of the endpoint in the language 'view-subscription', which obviously doesn't exists (and spends a lot of time doing so as well by trying to load MO files to init the locale)
As such, the method `WCML_Endpoints::get_endpoint_translation` should be rewritten to this
Languages: English (English )Spanish (Español )German (Deutsch )
Timezone: America/Lima (GMT-05:00)
Could you please recreate the issue on the following sandbox? hidden link
Please use the File Manager plugin to access the server. Do not migrate your whole website to this sandbox. We only need a simple example that replicates the bug.
Leave me a comment on this ticket once you are done with this task.
It appears that I broke the sandbox and I cannot access it to fix the php file, it also had outdated WPML plugin (though this is not an issue to demonstrate the bug)
Languages: English (English )Spanish (Español )German (Deutsch )
Timezone: America/Lima (GMT-05:00)
I am not sure why you are doing this but this code is not correct:
add_filter('pre_load_textdomain', function ($null, $domain, $mofile, $locale) {
if ($locale === "view-subscription" && !isset($_GET['bypass'])) {
echo "The 'view-subscription' locale is being loaded";
die;
}
return $null;
}, 10, 4);
$locale (string|null): This is the locale being used for the translation. It is a string representing the language and regional settings (like en_US for English - United States, fr_FR for French - France, etc.). The $locale is usually set based on the language preference of the user or the site configuration.
I would suggest removing this part of the code or using it properly.
The first provided hook should be sufficient to register the endpoint and translate it with WPML String Translation.
Look, I am not here looking for feedback on a minimal reproduction.
This is a piece of code that demonstrates that YOUR example is doing something wrong. Which is using an endpoint name as a locale parameter, which obviously doesn't exist and tries to load "view-subscription" as a locale. You said it yourself, locale should be something like "en_US" or "fr_FR" not "view-subscription", so if the die does happen then there is a problem in WPML
What is not correct is either YOUR example or the WCML_Endpoints class. But this example is now widely used in other plugins. So the WCML_Endpoints class needs to be fixed.
If you don't want to implement the fix I provided which is a 2 line patch and improves the performance and reliability of WCML without breaking changes, be my guest.
Again my hook is just a DEMONSTRATION THAT WPML IS SWITCHING THE LOCALE TO 'view-subscription', it was just condensed into something that shows the issue and real usage differs, what is so hard to understand? I did not "invent" the locale parameter
Stop lecturing me about bad usage here. And actually try to understand the issue I'm reporting and if you can't then escalate the example I provided and the suggested patch to developers because they will understand.