MultiSite and Locale Questions

[tblanchard]

Hi, I am evaluating various Ecommerce packages for out company's planned international expansion and have some questions.

I have created two sites, the default one, with I renamed USA and gave a .com to and will use it to serve the USA, and then a second one for Canada which has the same domain in .ca.

I want the USA site to present prices in USD and the Canadian on to present prices in CAN. However, the Locales->Currency admin page does not seem to switch contexts when I switch sites. If I choose USA from the Sites tab, then go to Locales->Currency I still see both currencies enabled even though the url in the browser changes from http://localhost:8000/admin/US/jqadm/search/locale/currency?locale=en to http://localhost:8000/admin/CA/jqadm/search/locale/currency?locale=en.

I find similar issues with selecting active languages. I want CA to work in en and fr, but USA to work in en and es. I also don't see a way to associate a site with a country.

It seems, poking around the database, this is can be supported, but I'm finding the notion of locale to be kind of unusual. For instance usually a locale is a language/country pair and and there is an implied fallback hierarchy. So one would seek a resource for en_US and, failing to find it, try again for en. The country part is also used for things like date and number formats so en_US is going to operate very differently from en_GB with regard to currency, number formats, and on occasion, product description copy.

I know this seems like a lot but some clarification would be much appreciated. Maybe start with scoping localization settings to a given site and is this a bug in the admin UI I see? (I have no problem diving into the DB to sort this out).

Thanks

[aimeos]

I want the USA site to present prices in USD and the Canadian on to present prices in CAN. However, the Locales->Currency admin page does not seem to switch contexts when I switch sites. If I choose USA from the Sites tab, then go to Locales->Currency I still see both currencies enabled even though the url in the browser changes from http://localhost:8000/admin/US/jqadm/search/locale/currency?locale=en to http://localhost:8000/admin/CA/jqadm/search/locale/currency?locale=en.

Currencies and languages are available installation-wide, i.e. not limited to any site. They can be enabled or disabled only globally. Which combination of currencies and languages are allowed is configured per site in the Locale > Locale tab of the Aimeos admin backend. There, you can add the available combinations including their order in which they appear in the locale selector of the frontend.

I find similar issues with selecting active languages. I want CA to work in en and fr, but USA to work in en and es. I also don't see a way to associate a site with a country.

Aimeos has no built-in concept of a country entity because sites are a much more flexible construct. They can be used for regions, countries, states, markets or vendors. If you have two sites in Aimeos (CA and US) with different domains, add en/CAD and fr/CAD to the Canadian site resp. en/USD and es/USD to the US site.

If e.g. products should be shared between sites, the Aimeos company offers their complex B2B extension which allows you to inherit them from a common parent site.

It seems, poking around the database, this is can be supported, but I'm finding the notion of locale to be kind of unusual. For instance usually a locale is a language/country pair and and there is an implied fallback hierarchy. So one would seek a resource for en_US and, failing to find it, try again for en. The country part is also used for things like date and number formats so en_US is going to operate very differently from en_GB with regard to currency, number formats, and on occasion, product description copy.

By default, the Locale > Language list only contains non-country specific languages but you can add e.g. "en_US" and "en_GB" yourself to the list. If there are translations for "en_US" and "en_GB" available these translations will be used. For all other translations, there will be a fallback to "en" only. The PHP Intl extension and the Intl object of the browser will care about date and number formats displayed in the frontend based on the language (depending if it's "en", "en_US" or "en_GB").