I’m managing from Spain a shop based in Canada in English language and base currency CAD $ and Geolocation activated. I already have updated to last version as of November 11.
I started to test in a localhost with Xampp for translate to other languages starting with Spanish with WPML and WooCommerce Multilingual.
I started to translate some products from English to Spanish and all go ok.
Then I activate Multicurrency setting manual rates for CAD $ to EUR and CAD $ to USD and set currencies based on 'Client location'. Also I’ve activated to show currency selector on product page.
Then I’ve translated some other products from English to Spanish and translation was OK but the behaviour of prices and currencies not right. The scenario is:
1.Product A translated before activated Multicurrency Shows the right price in English and Spanish for all three currencies (CAD, USD and EUR) also if I look at product page the price (CAD $) for the English version is the same than the Spanish version.
2.Product B translated after activating Multicurrency shows the right price in English for all three currencies too but wrong prices from Spanish. Looking at product page I’ve seen that English version has the right price (CAD $) but the Spanish version has different price (CAD $) than the English version, it seems like when translating the product the value of original CAD $ was converted to a value in EUR but with currency in CAD $.
At this point if browsing product B in English language was showing right in the different currencies (CAD, USD and EUR) are showing OK and change rates to currencies applies OK too.
But if browsing product B in Spanish, the prices showed wrong. If select CAD I see the wrong value stored on Spanish version of product B that seems to be the original CAD value being applied the EUR currency rate. Then if I select EUR the value showed is the wrong CAD value converted to EUR and if I select USD the value showed is too the wrong CAD value converted to USD.
I’m doing something wrong?
Or this is the behaviour expected?
Why the price in the Spanish version of product B has been converted to EUR value but they are CAD $?
All the translations where made from an admin user that had no Billing nor Shipping address set, then the system gets the currency of this user based in Geolocation, thus in my case that means get EUR as location currency.
Then it seems that when a translation is started instead of use base currency for translate the object it uses the user currency, then the value that gets the translation in Spanish belongs to the values of real price in CAD converted to the currency of user that makes the translation but assigned to value in CAD.
I’ve tested updating the Billing and Shipping address to a Canadian address.
Then I’ve translated other product to Spanish and the prices now are OK in all languages and currencies.
Is my impression that the problem is that all the translations must take the base currency of the shop instead of the currency of the user who is making the translation.
If I’m true this behaviour must be fixed because if multiple translators on different countries with different currencies will produce a big mess on the prices for translated products.
Please tell me if that is the way, and if I can retranslate all the products using the right country (Canada in this case) as the country of translator.
Also tell me please if it’s a real bug and will be fixed in the future.
You wrote: "Is my impression that the problem is that all the translations must take the base currency of the shop instead of the currency of the user who is making the translation."
The price of a product should be the same in all languages as it is a custom field value that is synced across all different language versions of the product. So at the time of product creation/translation, there should be no consultation on the personal data of the translator.
I am referring to the price as shown in the backend - e.g. the WordPress editor view of the product.
Geolocation will kick in in the FRONTEND view of the product and this will only be activated on the checkout page.
Did you do this testing using a minimal configuration of your site? e.g. Only WPML, Woocommerce active with Storefront theme.
I would like to ask if you could please try to do the same here in this sandbox site that has the minimal configuration setup: hidden link
If you can, please let me know so I can confirm it and send it on up to development.
Hello Ivette,
You wrote: “The price of a product should be the same in all languages as it is a custom field value that is synced across all different language versions of the product. So at the time of product creation/translation, there should be no consultation on the personal data of the translator.”, and Yes I fully agree with that.
You wrote: “Geolocation will kick in in the FRONTEND view of the product and this will only be activated on the checkout page.”, if currencies are based on location the currency of the admin users are also based on location if Geolocation is not activated, the country of billing or shipping address is used to determine the currency.
I’ve not tested in my site with minimal configuration but I’ve managed to reproduce the error in the sandbox.
What I’ve made is:
Set Multicurrency select based on customer location and added US $ currency with rate 1 EUR = 1,19 USD. Also set this currency is only available in EEUU.
I activated the widgets for ‘Currency Selector’ and ‘Language Selector’ below the header.
I set in WPML Settings to use ‘WPML’s Advanced Translation Editor’.
Then if I go to shop I can see the currency in the Cart is USD.
I’ve translated the product category ‘Music’ to ‘Musica’
Go to products select category ‘Music’ and translate the product ‘Album’ that has a price of 15€.
Then select ‘+’ to add translation to Spanish and ‘voilá’, looking at the product in Spanish the price is now 17,85 € (15 € x 1,19).
If I go to shop and look for ‘Album’ with language 'Spanish' and currency USD the price is $21,24 USD (17,85 x 1,19) , if change the currency to € I see 17,25 €.
But if I select language 'English' for currency € I see 15 € and for currency USD I see 17,85 that are right prices. The problem is with the prices for 'Spanish' language.
I’ve translated too the product ‘Single’ and get the same behaviour, price was changed in the Spanish translation from 2 € to 2,38 € (2 x 1,19).
Let me know if you found this behaviour and feel free to delete the Spanish translation of these products to be able to reproduce translating again to get these results.
Many thanks in advance for your help and best regards,
When I visit the sandbox site, I am not seeing the prices that you mention.
Geolocation is only workiing when you have a MindMax key entered. I did this for you and so the sandbox site now has the "Client location" with mindmax functioning.
When I visit the shop page - I am only seeing the prices in USD as 17,85 (regardless of active language) and in EURO as 15,00 regardless of active language.
Here is the screencast: hidden link
I retranslated the product and I still get the same results. The prices you indicated are not showing.
I logged again in the sandbox and I see some changes from the last time I logged in, most of them have no influence on the results (header ‘Handmade TITAN’, currency switcher on footer and language switcher on footer).
But there was an important change related the conditions I’ve made the tests, on WPML-Settings the editor for translation was changed to ‘Use WPML’s Classic Translation Editor’.
I repeated the test using the ‘Classic Translation Editor’ and its true, the prices in the translated products are the same as the English products.
Then I switch the editor to ‘WPML’s Advanced Translation Editor’, repeat the translations and the result was that the Spanish translations shows different prices than the original English as stated before.
If you repeat the test having ‘Advanced Translation Editor’ active you will get these modified prices.
Then my feeling is that the problem happens when using the ‘Advanced Translation Editor’ and the user that is translating the products have assigned (by Geolocation or by Billing/Shipping address) a currency different than the base currency of the Shop.
Can you please confirm me that you now can see this behaviour?
Many thanks in advance for your help and best regards,
I found something strange, let me explain what I’ve do.
I’ve added Catalan language to translate the products and translated them using the Translation Dashboard and get automatic translations using Translations Tools. This way I’ve translated 60 products.
Looking for the results I’ve found that the price was wrong on 10 of these products even I have the user with billing and shipping address from Canada to avoid the bug.
I’ve deleted the translations of products with wrong prices in Catalan and tried to translate again from products page instead of Translation Dashboard, this time used the Advanced Translation Editor, getting a screen with the previous translated texts and saved it, checking for the price now the price is correct.
I thought that perhaps translations made with Translation Tools because I’ve selected several products at time can overload the server and produced these errors.
But later on when editing English version of one product to add an image to the image gallery I get on update the error ‘invalid or duplicate SKU’ , the same happens with the translations of this product. However all seems to be ok when looking from the shop.
Investigating more using the plugin free version of ‘Pimwick Plugins’ PW Bulk Edit and doing a search by SKU we get a result of 4 SKU’s instead of the 3 expected and one of them showing the wrong price get on the previous translation. I checked the product ID for these 4 SKU’s and the ones that have the price correct matches with the ID’s of each language of the product but the ID of the SKU with wrong price seems to be orphaned.
I’ve checked the same for all the products translated with pricing error and found that all of them have this problem.
At this point I don’t know if the database can be corrupted because I don’t know in deep the tables structure and his relationships.
You wrrote: "..I’ve checked the same for all the products translated with pricing error and found that all of them have this problem..."
I´ve seen this happen when translations are placed in trash but not perrmanently deleted. So the syncing is ocurring with the wrong products (the ones in the trash).
If you remove all the "orphaned" products, does this resolve the issue? Recall that a search via SKU will search ALL products in all states....not just the published ones.
However, this sounds like a different issue than the one that you originally raised which we were able to reproduce on a clean sandbox site.
For the original issue, the following message has been posted on your escalated ticket:
This has been escalated to development as a bug to be fixed. As a workaround we suggest the following steps:
Deactivate currency based on client location
OR
Go to the translator profile and change the location to other than the US and then send the product for translation to that user.
You wrote: “..I´ve seen this happen when translations are placed in trash but not permanently deleted. So the syncing is occurring with the wrong products (the ones in the trash).”
I’m very careful to empty trash every time I delete an article, and I’m sure this is not the case.
You wrote: “If you remove all the "orphaned" products, does this resolve the issue? Recall that a search via SKU will search ALL products in all states....not just the published ones.”
Yes that’s true but the state of these products isn’t showed in the standard products page, fortunately I’ve found it searching by sku using the PW Bulk Edit Free plugin, and thanks of the possibility of this plugin to select these wrong entries to open it on product editor I’m been able to send them to trash and then delete permanently, no other way I’ve found to do it in standard to do it, otherwise I’ve had to go to database and delete the records but this is a dangerous way if you don’t have details do data structure.
I thing that may be there is more under the hood of that we have found and reported to you as a bug, that is the reason I have informed you of these last issues I’ve found.
Many thanks in advance for your help and best regards,
