Compatibility with Google Merchant Center Feed

Hi @raymond621,

Let me try to answer your questions.

No matter how prices are switched using a plugin, merchant center bots will always crawl the language and currency woocommerce was set as default. Is this the same case with this plugin?

WCML has two modes for multi-currencies: “by language” or “by country location”.

The site visitor will have a preset currency based on his preferred language or current location. There’s no specific treatment for search engine, so it will depend on the above parameters.

Moreover, the visitor’s currency is defined in his session (there’s no URL argument). So there’s no way for a search engine to crawl product pages in different currencies.

Is there a demo site where I can inspect how these functions are operated?

We do not have this to offer right now.

The plugin supports different url structure for different language and currency? Or does it use query string to change language and currency?

There’s a unique URL for each language, but not for currencies which are in the visitor session. For the language, you can select between 3 different URL formats: “Different languages in directories”, “Different domain per language”, “Language name as a parameter”. You can find more details here.

So what other plugins do I also need to install for changing language and currency? This plugin itself doesn’t switch language and currency by itself? Description: You will also need WPML, together with the String Translation and the Translation Management modules, which are part of the Multilingual CMS package. So what do I have to install in total to get this to work?

WooCommerce Multilingual currently requires the Multilingual CMS package (WPML Core, WPML String Translation, WPML Translation Management).

You can find the details here.

Note that we have a 30 days money-back guarantee. So you can purchase the Multilingual CMS package, test it with WooCommerce Multilingual and make sure it fits your needs.

Thanks,
Pierre

• This reply was modified 3 years, 5 months ago by Pierre Sylvestre.
• This reply was modified 3 years, 5 months ago by Pierre Sylvestre.

I will like to clarify why this has been a concern for me. Under google merchant center, I have specifically created different ad to target different countries. Each targeted countries will have a different feed structure if the language or currency is different. For example, ads targeting to France will always show French as language and Euro as currency on my landing page. Ads targeting to United States will show English as language and USD as currency.

According to Google Merchant Center policy, I cannot use auto detect user IP for displaying languages and currencies because it is a violation. If a customer is located in United States and happens to click into an ad that was targeting to France with default language French and Eruo, auto IP detection will most likely display Engilsh and USD on my landing page which is a policy violation. Is it possible to turn off auto ip detection for language and currency change? Display languages and currencies based on URL structure. Customers who clicked into this link eg. https://www.abc.com/fr/ will always display language in French regardless where they are located at.And for currency, I assume it will display what ever default currency is set under wpml settings for France.

But what if I have the following scenario:
Targeting countries: United States & Spain
Language: United States speaks English & Spanish and Spain only speaks Spanish
Currency: United States currency is USD and Spain will show Euro as currency

People from United States are speaking both English and Spanish. The default Currency is USD. People from Spain will only speak Spanish and currency is set to Euro. How do I go about displaying these languages in different URL structure. I have seen from other webstores where a customer is allowed to choose a displayed currency and language under two different fields. Thus the URL structure will look similar to the following:

English, USD: https://www.abc.com/EN-USD/
English, Euro: https://www.abc.com/EN-EUR/
Spanish, Euro: https://www.abc.com/ES-EUR/ where ES stands for Spanish language

Without two different fields to choose from, won’t it look a little odd with only a single field dropdown to choose language and currency. It might look like the following under language/currency dropdown box with redundant information. eg. English USD, English EURO, Spanish Euro

Any advise on how to make this behave better?

I will like to add: What I mean by having two different fields for language and currency:

What it might look like under my landing page header:
Choose Language:(English, Spanish) / Choose Currency: (USD, Euro)
Two separate fields to select from before the page reloads the correct language and currency.

Just curious, if IP detection is enabled, what will the landing page url look like? eg. URL will always look like https://www.abc.com despite what language is used or currency?

Hi @raymond621,

Currently, the WCML currency depends on the visitor session and we do not have any way to “force” it through the URL. It could be a possibility in the future though.

To sum up, you will have URLs with the language information https://domain.tld/es/my-product/ (or https://es.domain.tld/my-product/ or https://domain.tld/my-product/?lang=es), but the currency will be an implicit information.

If the multi-currency configuration allows, the visitor will see a currency switcher on the page. If he selects a different currency, an AJAX request will the sent to the server to change it in his session and then refresh the page fragments.

I you didn’t check before, I recommend to have a look at the WCML multi-currency documentation. It will probably help to clear some of your doubts.

Note that we have 2 modes for the multi-currency feature:
1. By language: you can define which currencies are available for each language. This was the first mode for the feature.
2. By country: for each currency, you can define in which country it’s available. This of course requires geolocation.

Thanks,
Pierre