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.
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.
Share this post:
Responses (15)
-
Accepted Answer
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. -
Accepted Answer
-
Accepted Answer
-
Accepted Answer
-
Accepted Answer
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 ... -
Accepted Answer
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
- Domain 1 opens up with NOK and Norwegian. Changing content language from dropdown works, but strings loaded from language files doesn't change.
-
Accepted Answer
-
Accepted Answer
-
Accepted Answer
-
Accepted Answer
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. -
Accepted Answer
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. -
Accepted Answer
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? -
Accepted Answer
-
Accepted Answer
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. -
Accepted Answer
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
Your Reply
Please login to post a reply
You will need to be logged in to be able to post a reply. Login using the form on the right or register an account if you are new here.
Register Here »