2

I'm currently working on a multi-country, multi-language solution using Magento 2. I'm having trouble (especially with performance and somehow with maintenance) configuring such a store.

Let's consider I want to create the following site hierarchy:

  • International website: example.com
  • United States store: example.com/us
  • Canada store: example.com/ca

Now let's say that I want the U.S. store to be available in English and Spanish. I'd have something like example.com/us/en and example.com/us/es. I would do the same thing to get the Canada store available in both English and French.

I also want to configure my products as such:

  • The whole catalog is shared across all countries and each country store enables or disables products in this catalog the way they want. It contains about 3,000 products, most of these being simple products and a few being configurable.
  • Each country defines a different, fixed price and possibly a different, fixed currency. As an example:
    • If you're living in the U.S., my awesome product costs USD 100.
    • If you're living in Canada, my awesome product costs CAD 80 (regardless of exchange rates).
    • If you're living somewhere else, you get the international price, which is EUR 150 (again, price and currency are fixed, and rates are irrelevant).

User country is determined as soon as you enter the website using IP location and CDN services.

As far as I understand, I should go with the following structure:

Website     | Store   (Catalog)         | Store view
------------+---------------------------+-------------------------
Int'l       | Int'l   (Default catalog) | English (United Kingdom)
US          | US      (Default catalog) | English (United States)
US          | US      (Default catalog) | Spanish (Mexico)
Canada      | Canada  (Default catalog) | English (Canada)
Canada      | Canada  (Default catalog) | French (Canada)

So far, so good, as we only get a total of 5 store views.

The thing is the real store I'm working on requires fixed prices for more than 20 different countries. All country stores are available in more than 10 languages. These languages are from the same set, e.g. our previous example would have all 3 stores available in English (UK), English (US), English (Canada), French (Canada) and Spanish (Mexico).

Counting from this, I would already have 200 different store views with this kind of setup. Each new store I would create afterwards would have to be immediately available in my 10+ languages. Each new language I would add afterwards would have to be immediately available on all stores.

While generating front-end views from cache may still be quite fast, (mass-)importing products and generating indices at that point is just slow and unreliable.

I also have a lot of CMS content which happens to be the exact same for every country. For example, I have a page "About us" which is translated in all my languages but has the same content wherever you live. If I create a new page, that means I have to make sure that each translated version exists in all countries. Once more, if I create a new country store, I would have to make all my CMS content immediately available on it, making the process difficult for regular back-office users.

At the moment I don't even know which way to explore to get a decent configuration.

To sum up:

  • I need to be able to define a different, fixed product price per country.
  • I need to have all my country stores available in a defined set of languages.
  • I need to be able to link CMS content to all country stores.

With my colleagues, we thought of several approaches:

- Using configurable products

Products would be set as configurable. Each variation would actually be the same product with just a different price. It gives an easy product setup through the back-office, but does not allow different currencies. It does not solve the number of views issue, as we would still have to define one website per country to be able to manage products as enabled / disabled.

- Using user groups

Creating one group per country then assigning pricing rules per group sounds great. We'd just have to make the country a required field in a registration form. However, it means we cannot handle prices for non-logged-in users (unless it is possible to assign groups to guests?).

- Splitting into continent-based magento installations

In such a case, let's say we would have something like two magento installations for Americas, two for Europe and another one for Asia. It should solve most performance issues like in North America having about 30 views (still, we're not sure it would work in Europe). It should solve maintenance issues for back-office users in the same way, considering we can create some sort of gateway to import CMS contents on all installations; the bad side being technical maintenance issues, especially to deploy security patches / bug fixes in a timely manner.

- Tweaking modules / templates to get a single store view per website

Based on answers found here (https://magento.stackexchange.com/a/19741/243) and there (https://magento.stackexchange.com/a/52937), we could tweak store views so that we would have:

Website        | Store     (Catalog)           | Store view
---------------+-------------------------------+---------------------------
Int'l          | Int'l     (Default catalog)   | Store view (10+ languages)
Country 1      | Country 1 (Default catalog)   | Store view (10+ languages)
Country 2      | Country 2 (Default catalog)   | Store view (10+ languages)
...            | ...                           | ...
Country n      | Country n (Default catalog)   | Store view (10+ languages)

It seems to be our best option but as the second linked answer suggests, going against the regular Magento workflow may be costly. It may also conflict with third-party extensions.

We've also looked for extensions but all the ones we reviewed were about having product prices defined on store views, which means we still have to define <countries * languages> combinations.

I'm open to any solution or lead, whether it requires specific development, configuration or using third-party (even paid) extensions.

Thanks.

2

I sent you an email with my contact info if you want to discuss this in more details.

We typically only see up to 3 languages per website when deployed in this manner. Are you able to reduce the # of languages per country website to just the number of officially supported languages for that country? I think that would help reduce the effective sku count on this install significantly (effective sku count = #sku * #store views * #customer groups).

Reason I ask is we have many customers that have a similar setup, but they have a # of store views per website that line up with the # of officially supported languages for that country (usually 3 or less). Once you get past about 6 websites/store views you generally need to tune your mysql.cnf - tmp_table size setting for proper indexer operation. Once you've done that you should be good to go.

We have noted some room for improvement with our indexers in the above scenario so are working on improving indexer performance in our upcoming release (2.2).

Some additional thoughts:

  • Using user groups for customer specific pricing; to support B2B use cases (customer specific pricing) we're headed this direction with our upcoming release (2.2 B2B). Prior to 2.2 though I would expect going down this path would put more load on your indexers and increase the database size as effective sku count increases.
  • Splitting into continent based installations would help reduce the data base complexity and indexer work done by each installation. PIM (product information management)/ ERPs provide a path to centralizing management of your content and then you can use APIs/import-export to synchronize data between the various installs. Alternatively, you can have admins manage content locally. We generally recommend this approach as a way to reduce database complexity for sites with large #'s of websites/store views.

Regards, Chuck

  • Thank you for your answer. At the moment, the requirement for all these languages is a spec and I'm not sure we'd be able to amend it. If we do so, I think we won't remove that many languages, as like half of the languages in our set are considered international from a marketing perspective (hence the spec) for this particular project. Anyway, we'll definitely check out our SQL config as it may help a lot and we'll get a look at PIMs / ERPs. If we manage to handle both product information and CMS contents on one such software, that could do the trick. – S2HNT Feb 16 '17 at 9:24

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.