When building a multi-store, there is option for using separated domains, and different languages and currencies per store.

However it doesn't seem to have any affect, the selected defaults doesn't change between the stores/domains, it's always using the defaults from the 'main store'.

Has anyone else tested this, and/or have any clue where I should start looking to get this fixed?

Testing English and Norwegian, with EUR and NOK, on a .com and .no domain in Arastta version 1.1.2 running PHP 5.5.29

Note! I have also noticed that changing language on admin login doesn't help, it's always using the standard anyway - in case it's related ...

Side note! An option for linking languages and and currencies would probably be useful for many anyway.

Btw! I've also noticed that when changing language from the selection in header of frontend, only the content language changes, not the language file strings.
Thursday, October 08 2015, 02:30 PM
Share this post:
Responses (15)
  • Accepted Answer

    Thursday, October 08 2015, 11:15 PM - #Permalink
    OK, still testing - and found something interesting after doing a fresh install.

    If installing in English, the sites default language is English.
    Then installing t.ex. Norwegian, keeping English as default, the language changing works fine in both frontend and backend.
    But then, changing Norwegian to default breaks everything ...

    Continued digging and found a generated file: system/modification/system/library/language.php
    Opened it and found some en-GB values, which I changed into nb-NO, saved it - and language changing works again.

    But then I go into Modifications and do a Refresh, and it's broken again, since the file is rebuilt with en-GB ...

    Something fishy going on here it seems ... ;)

    Btw! The problem is the same if Norwegian is used when installing, and then adding English after.
    - And for the site/domain association, it doesn't work anyway.
    The reply is currently minimized Show
  • Accepted Answer

    Thursday, October 15 2015, 11:12 PM - #Permalink
    No one else who have tested and can confirm the issues, or none issues being present, in their test?
    The reply is currently minimized Show
  • Accepted Answer

    Sunday, October 18 2015, 12:52 PM - #Permalink
    No sorry, was ill last week and have now a few urgent customer projetcs > X-Mas is coming and now they checked that fact and everybody wants to have a new shop..
    Guess further testing could be done only after X-Mas.
    The reply is currently minimized Show
  • Accepted Answer

    Monday, October 19 2015, 11:23 AM - #Permalink
    Have you tried this in Private window? It may be related with the browser cache. Upgrading to 1.1.3 may also help. I can check it further if you could send me an admin account via PM.
    The reply is currently minimized Show
  • Accepted Answer

    Monday, October 19 2015, 12:04 PM - #Permalink
    No, it's not related to the browser cache as several are tested. Also the info already posted indicates it's a system issue, related to caching in Arastta for modifications (possibly caused by the language fallback feature).

    Demo site:
    Domain 1 - Should open up with language Norwegian and currency NOK: http://demo.arastta.no/
    Domain 2 - Should open up with language English and currency EUR: http://demo2.arastta.no/

    Edit! Some changes discovered in 1.1.3. Seems like domain changing works now, but not language change from dropdown. Will do more testing on it ...
    The reply is currently minimized Show
  • Accepted Answer

    Monday, October 19 2015, 01:09 PM - #Permalink
    OK, so after more testing in different browsers with cache cleared between domain change I'm quite sure this is the behaviour (some improvements in latest version):


    • Domain 1 opens up with NOK and Norwegian. Changing content language from dropdown works, but strings loaded from language files doesn't change.
    • - Issue: Changing language strings doesn't work.
    • Domain 2 opens up with EUR and Norwegian (should be English). Changing both content language and language strings from dropdown works.
    • - Issue: Wrong language opened up at first visit.
    • Admin is only working with Norwegian when it's default, selecting English has no effect.
    • - Issue: Only default admin language works, when other than English.


    General issue: It seems like the browser is overriding the store settings for language per store/domain, so you might get English by default on both, instead of me getting Norwegian. In my opinion the browser should not override stores default language in a setup like this, else it doesn't make any sense including it as a store setting ...

    I'll send you an admin user, but as mentioned the language select for admin doesn't work when Norwegian is the default, so I changed it to English in setting so you can find your way. ;)

    PS! Going to the admin login on Domain 2 outputs a notice:
    Notice: Undefined index: value in /system/library/utility.php on line 69
    The reply is currently minimized Show
  • Accepted Answer

    Monday, October 19 2015, 05:42 PM - #Permalink
    Can you please revert any changes done to the files so I could test how the system works by default? Thanks.
    The reply is currently minimized Show
  • Accepted Answer

    Monday, October 19 2015, 08:43 PM - #Permalink
    There are no changes to the files, it's a default Arastta 1.1.2 install, updated today to 1.1.3.
    The reply is currently minimized Show
  • Accepted Answer

    Friday, October 23 2015, 03:41 PM - #Permalink
    I got the login details Rune and will try to check the stores by today.
    The reply is currently minimized Show
  • Accepted Answer

    Tuesday, October 27 2015, 11:24 AM - #Permalink
    The English language issue has been fixed here https://github.com/arastta/arastta/issues/235

    As for browser language detection, that is a feature not bug. The default option in settings is used in case the browser language is not available in your store.
    The reply is currently minimized Show
  • Accepted Answer

    Tuesday, October 27 2015, 11:32 AM - #Permalink
    I agree with Denis that we should keep browser language detection feature. Because let's say:

    - You have English language installed on your site
    - You have Norwegian language installed on your site

    If someone visits your store from an English-set browser, then English will be used. And once Norwegian visits, Norwegian will be used.

    What if someone from other countries/languages visits? Then Arastta uses the default language so we need to keep default language setting, too.
    The reply is currently minimized Show
  • Accepted Answer

    Tuesday, October 27 2015, 04:58 PM - #Permalink
    Great, thanks for the fix.

    While I agree the auto detect is useful for a normal multi-lingual shop, it's not always the case for a multi-domain shop.
    In some other systems this can also be an option, to use the autodetect or not. Some also has a option to load currency from the loaded language, currency to language.

    Let's say we use a .no domain, and a .eu domain.
    The .no domain is aimed at the Norwegian market only, products here are not translated or intended for other markets. They are to be sold to Norwegian market in Norwegian Kroner (NOK) only. The .eu domain has some other products, and maybe a few translated shared with .no, aimed for other Nordic countries/EU

    In this case the store owner only want to display Norwegian and NOK for .no, as it makes no sense to display a lot of untranslated products to someone only reading English.

    Does it make sense? :)
    The reply is currently minimized Show
  • Accepted Answer

    Saturday, October 31 2015, 11:50 PM - #Permalink
    It makes sense but language detection doesn't prevent/allow the product to display :)
    The reply is currently minimized Show
  • Accepted Answer

    Sunday, November 01 2015, 12:08 AM - #Permalink
    Well, I didn't say that, but actually it should. Btw! Following this path, only fields for the main language should be required, other should fallback to it if not filled. Anyhow, that's a different story, and quite big rewrite. :)

    But the point is (even if it might be unclear) that there is no need to have English language for the .no store if there is no products or content published in/for English in it, those are in the .com store only... So yes, if someone visit it now they do see some content in English (from language files), but the rest is all in Norwegian, which make it look quite bad - unserious ...

    In this case the store owner only want to display Norwegian and NOK for .no, as it makes no sense to display a lot of untranslated products to someone only reading English.


    .no = "Norwegian products", not translated. Store owner only wants this to display Norwegian, and don't open up in English because of browser detect. No currency or language select displayed neither. Products assigned by multi-store feature to the .no store.

    .com = "English products", not translated to Norwegian or shared and translated. Store owner only want this to display English, and don't open up in Norwegian because of browser detect. No currency or language select displayed neither. Products assigned by multi-store feature to the .com store.

    Not sure if I can make it any clearer, but if still unclear I will try. :)
    The reply is currently minimized Show
  • Accepted Answer

    Sunday, November 08 2015, 06:20 AM - #Permalink
    I'm playing around with the code trying to make a new setting for forcing use of default language and currency per domain, and I can get it work using HTTP_SERVER, but would like to improve and propose a patch or mod for it. Though I found something weird going on in my searching and tests ...

    T.ex. this line https://github.com/arastta/arastta/blob/master/system/library/utility.php#l61 is always returning the default store id, and not the actual store id according to domain/URL. Same for language, where this line is always returning default language code: https://github.com/arastta/arastta/blob/master/system/library/utility.php#l44

    Is this how it's supposed to work, or what is it I'm missing here? Or said in another way, how can we get those values according to visited domain/URL?

    Here's my quick and dirty VQMod hack used at the moment:

    <modification>
    <id><![CDATA[Use Default Language]]></id>
    <version><![CDATA[1.0.1]]></version>
    <vqmver><![CDATA[2.4]]></vqmver>
    <author><![CDATA[SYNTAX ERROR - Rune Rasmussen]]></author>
    <file name="system/library/currency.php">
    <operation error="log">
    <search position="after"><![CDATA[$this->set($this->request->cookie['currency']);]]></search>
    <add><![CDATA[
    }
    elseif ($_SERVER['HTTP_HOST'] == 'mydomain.no') {
    $this->set('NOK');
    }
    elseif ($_SERVER['HTTP_HOST'] == 'mydomain.com') {
    $this->set('EUR');
    ]]></add>
    </operation>
    </file>
    <file name="system/library/utility.php">
    <operation error="log">
    <search position="after"><![CDATA[$code = $this->request->cookie[$prefix.'language'];]]></search>
    <add><![CDATA[
    }
    elseif ($_SERVER['HTTP_HOST'] == 'mydomain.no') {
    $code = 'no';
    }
    elseif ($_SERVER['HTTP_HOST'] == 'mydomain.com') {
    $code = 'en';
    ]]></add>
    </operation>
    </file>
    </modification>


    What I would like to do for t.ex. the language is something like:

    <file name="system/library/utility.php">
    <operation error="log">
    <search position="after"><![CDATA[$code = $this->request->cookie[$prefix.'language'];]]></search>
    <add><![CDATA[
    }
    elseif ($force_default_language) {
    $code = Client::isAdmin() ? $this->config->get('config_admin_language') : $this->config->get('config_language');
    }
    ]]></add>
    </operation>
    </file>


    Edit: Updated with improved code in vqmod
    The reply is currently minimized Show
Your Reply