Hi,
I tried to install a dutch language pack, but somehow all the installed modules get lost when I do so.
The admin menu is also translated to dutch directly... without me indicating that I do want to use dutch in the back-end.
Any thoughts?
There is definatally something wrong...
I installed the dutch first, switched to ducth language (nothing happens), then deleted the english language pack (now the language is switched to dutch). Also all the modules are gone.
After that I installed the english language pack again. Then I swicthed languages back to english (it still remains in dutch), I deleted the dutch language pack (now it becomes english indeed), but still the modules are gone.
Anybody any ideas on where this problem may come from?
I installed the dutch first, switched to ducth language (nothing happens), then deleted the english language pack (now the language is switched to dutch). Also all the modules are gone.
After that I installed the english language pack again. Then I swicthed languages back to english (it still remains in dutch), I deleted the dutch language pack (now it becomes english indeed), but still the modules are gone.
Anybody any ideas on where this problem may come from?
bo-oz
Nice talking to myself.... but I found the thing that is causing this problem,
The query for extensions, joins two tables:
I'll keep looing in why this value is not changed in the database.
The query for extensions, joins two tables:
- extension
- extension_description
Code: Select all
if (!$session->get('extension.search')) {
//$sql = "select e.extension_id, ed.name, ed.description, e.code, e.type, e.controller from extension e left join extension_description ed on e.extension_id = ed.extension_id where e.type = '?' and ed.language_id = '" . (int)$language->getId() . "'";
$sql = "select e.extension_id, ed.name, ed.description, e.code, e.type, e.controller from extension e left join extension_description ed on e.extension_id = ed.extension_id where e.type = '?' and ed.language_id = '1'";
}
bo-oz
when you add new language - you have to duplicate all entries in extension_description - only using new language id. Keep same record id though.
you can write sql to do it. something like:
insert into extension_description (id, language_id, name) select id, YOUR NEW LANGUAGE ID, name from extention_description
just write correct field names and replace language id in select part of the query with your new language id. That's what I did - and it worked fine.
you can write sql to do it. something like:
insert into extension_description (id, language_id, name) select id, YOUR NEW LANGUAGE ID, name from extention_description
just write correct field names and replace language id in select part of the query with your new language id. That's what I did - and it worked fine.
Last edited by gary on Wed Dec 12, 2007 11:51 pm, edited 1 time in total.
Hi Gary,
I understand that that fixes the issue, but it seems a bit strange how opencart depends on the languages with regard to configuration. With this I mean, the installed modules should be universal in my opinion (or at least, not dependent on the installed language pack), in which language they are treated is a thing that comes after that. It should be logical that when I install a new language into my already existing installation, that I do not need to execute any manual SQL to fix certain issues. Also, when it's logical from an architectural pov, then the front-end should not treat the modules as installed when they are not available in the backend (for that specific language).
I cannot remember an earlier version I've played with had the same issue. So I am now doubting to use opencart for my current project.
I understand that that fixes the issue, but it seems a bit strange how opencart depends on the languages with regard to configuration. With this I mean, the installed modules should be universal in my opinion (or at least, not dependent on the installed language pack), in which language they are treated is a thing that comes after that. It should be logical that when I install a new language into my already existing installation, that I do not need to execute any manual SQL to fix certain issues. Also, when it's logical from an architectural pov, then the front-end should not treat the modules as installed when they are not available in the backend (for that specific language).
I cannot remember an earlier version I've played with had the same issue. So I am now doubting to use opencart for my current project.
bo-oz
I've found out that by switching the language in the frontend, you can influence the standard language in the back-end. Also my earlier remark that configuration is global across languages is not valid. It seems that a localization allows its own configuration, which could be great ofcourse, but I can imagine users requiring a more portable solution that allows a complete copy of the configuration to the different languages, basically a general non language related framework that is afterwards expanded with different language packs, if for a certain product there is no information in a certain language, the default language is used. I think opencart currently is to dependent of the languages. Any thoughts?
bo-oz
Yes, I noticed that store end has trouble switching languages. So far I did not look into why it is - so have nothing really to contribute to the discussion.
I like the way language is separated in database in separate "description" tables - it is easy to find. Why modules are language specific - I don't know.
Also - for my taste - it would be better if all language strings were in one file - easier to find - although I see the point of separating them for easier modability.
I like the way language is separated in database in separate "description" tables - it is easy to find. Why modules are language specific - I don't know.
Also - for my taste - it would be better if all language strings were in one file - easier to find - although I see the point of separating them for easier modability.
Who is online
Users browsing this forum: No registered users and 1 guest
