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 topic contains 5 replies, has 2 voices.

Last updated by maleaumeT 1 month, 3 weeks ago.

Assigned support staff: Rajeeb Banstola.

Author Posts
July 31, 2019 at 4:12 pm #4316541



I'm working on a WooCommerce shop that had first been set to work in french. We are now adding an english version, using WPML (sitepress-multilingual-cms, wpml-string-translation, wpml-translation-management & wpml-media-translation) and WooCommerce Multilingual.

My problem is with urls i18n in the My Account section.

I am trying to: localize urls of the My Account section (addresses, orders, etc.)

I expected to see: urls in french on the french website (historically the first one set up), urls in english on the english website (still under development)

Instead, I got: french urls work fine but not every english url works. For example, the addresses can be viewed and edited but the recent orders listing is unavailable. It appears in the menu, there's no redirection taking place but the page returned is the default page for the My Account section. (Screenshot attached, with a debug output of WP query vars)

What can I say about this problem:

1. WPML is set up to not change historical (french) urls and use sub-directory only for other languages (/en/).
2. The "My account" page is not set to be a child of the shop page (So [this]( is not a solution).
3. The WooCommerce endpoints have first been set with french values (Screenshot attached). Everything went fine for month and still do.
4. I have nothing fancy in my setup around the My Account section except that I removed the dashboard to set the account details form as the default page.
5. Everything looks like being correctly translated from french to english when I look at the WooCommerce Multilingual urls pane (Screenshot attached)
6. The WPML String Translation page report what looks like a mess for the WP Endpoints domain: strings exist in both languages but does not seem to be recognized as translations for each other but as strings that originated from different languages. (Screenshot attached)
7. I don't have any WooCommerce Endpoints on this page (So [this]( is not a solution).
8. When I try to delete all strings in the WP Endpoints domain from the WPML String Translation page, there's no error returned but on reload, all english strings are back. (So [this]( doesn't seem to be a solution either, unless it *has* to be done outsite of WordPress.)

I did the WPML setup carefully, adding a new plugin only once I had set up the previous one. Maybe some strings had been considered translatable by the core WPML plugin and added to string translation before WooCommerce Multilingual came in the game and that results in the mess I can see today.

I'm not really trying to find an explanation on how it happened, what I'm really looking for is how I can have it fixed today. As the website is already running in production, I'll prefer a solution that doesn't ask to set the shop in maintenance mode and edit by hand a dump of the database.

August 1, 2019 at 1:44 am #4317959

Rajeeb Banstola


Thank you for contacting WPML!

This indeed appears to be very strange. I was unable to replicate this on my local environment with WPML and TwentyNineeten. Before we start debugging your issue, please make sure your server meets all the minimum requirements for running WPML:

I suggest you to increase WP Memory Limit to 256M and upgrade MySQL to 5.6 or over based on the debug information provided.

I would need to make a local copy of your site and debug the issue before I can recommend any fix. In order do so, please provide your WordPress login details.

I've marked your next reply as private so that only you and I have access to it.

August 1, 2019 at 8:41 am #4319941


Hi Rajeeb,

Sorry but I'm not very found of the idea to give you any access to a production app. No offense, I think you understand.
(As there's no sensitive informations in this post, you can turn it back to public so it may be helpful to somebody else.)

I digged a little deeper this morning and tried to understand how translations are done.

On the very first call of `WC_Query::get_query_vars()`, `WC_Query::$query_vars` contains exactly 13 items:

order-pay, order-received, orders, view-order, downloads, edit-account, edit-address, payment-methods, lost-password, customer-logout, add-payment-method, delete-payment-method, set-default-payment-method

On second call, it contains 26 items in french: all the original keys and their translation. In english, it contains only 22. As original keys are in english, the array merge done in `WCML_Endpoints::add_wc_endpoints_translations()` overwrites some of them.

That is what mess with how queries are handled in the profile section and what page should be displayed.

As soon as I change english translations to always be different than the array keys, it's fine.

If you change the arguments order in the `array_merge` call at `WCML_Endpoints::add_wc_endpoints_translations()#L184`, the problem is fixed.
Another solution would be to use array keys in Klingon…

Do you think this can be fixed in a soon to be released version of WooCommerce Multilingual?

August 1, 2019 at 11:14 pm #4325535

Rajeeb Banstola


I understand your concern. I've asked our developer team for help on this. I'll update you as soon as I have any new information.

August 2, 2019 at 8:12 pm #4332487

Rajeeb Banstola


Thank you for your patience.

I got more information from our developer team. Please delete all the endpoints from WPML - String Translation and translate again.

Let me know if this works for you.

August 19, 2019 at 6:40 am #4413699



As I said in the first message, I already tried to delete translations and translate again.

I worked around the problem, changing the english endpoints to never be the same as existing array keys. It works but the real solution sits on your side: to swap arguments in the array_merge call in `WCML_Endpoints::add_wc_endpoints_translations()#L184`.