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

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.

It makes sense but language detection doesn't prevent/allow the product to display

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?

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 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.

I got the login details Rune and will try to check the stores by today.

There are no changes to the files, it's a default Arastta 1.1.2 install, updated today to 1.1.3.

Can you please revert any changes done to the files so I could test how the system works by default? Thanks.

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

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 ...

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.

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.

No one else who have tested and can confirm the issues, or none issues being present, in their test?

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.