Make admin configuration translatable to other languages?

[shrimp-gumbo-mmmhhh]

I am no php guru but it would seem all you would have to have a total foreign language ZC is this:
1) create a table with these fields

configuration_title
configuration_description
configuration_key
languages_id or
code

2) populate them with data when the language pack is installed


3) change probably one place that calls the configuration title and description and builds the admin screen so that a join between the two tables could determine what language to put in those fields?

All other functionality could be left the old way to allow other languages to be populated in those spaces?

Thoughts?

[Philibel]

I'm assuming you're referring to a ZC that's from the start in an other language.

Then the directory zc_install has to have already all the language files in it. And all the files for customer and admin. And in all available languages.

Then it would be best to make two versions of every release. An English and an international because the international will be a much bigger download with all the languages already in it. An extra menu will have to be added to select all languages you want to be installed from the start and a setting for the default language.

Translators will have be closely involved during the build of new and/or updated versions. They also will have to be committed to their task. You can't have a whole version hung till further notice because one person is in "Wait for me"-mode nor can you already publish a version and republish a sub-update just for one language. There's only 26 letters in the English alphabet.

It's "possible" but at the same time tricky as it could lead to tensions. The last thing you want is for it to lead to forking into multiple version of ZC competing. That would be the beginning of the end. It already happened and I personally find it a disadvantage. Knowledge, idea's and effort is split instead of combined.

It would need a separate set of rules about who and what. Once you say you're in, you've stay in. Working together is sometimes like that relative you're happy to see after a long time but when he/she comes to stay over, you can't wait for them to go home.

[shrimp-gumbo-mmmhhh]

I'm assuming you're referring to a ZC that's from the start in an other language.

Then the directory zc_install has to have already all the language files in it. And all the files for customer and admin. And in all available languages.

Then it would be best to make two versions of every release. An English and an international because the international will be a much bigger download with all the languages already in it. An extra menu will have to be added to select all languages you want to be installed from the start and a setting for the default language.

Translators will have be closely involved during the build of new and/or updated versions. They also will have to be committed to their task. You can't have a whole version hung till further notice because one person is in "Wait for me"-mode nor can you already publish a version and republish a sub-update just for one language. There's only 26 letters in the English alphabet.

It's "possible" but at the same time tricky as it could lead to tensions. The last thing you want is for it to lead to forking into multiple version of ZC competing. That would be the beginning of the end. It already happened and I personally find it a disadvantage. Knowledge, idea's and effort is split instead of combined.

It would need a separate set of rules about who and what. Once you say you're in, you've stay in. Working together is sometimes like that relative you're happy to see after a long time but when he/she comes to stay over, you can't wait for them to go home.

I know another way that this could be implemented. The data in the configuration table could be exported and saved and a new language data could be inserted into its place giving room for someone who does not know English to have more of ZC in their language....or to be able to switch from language to language, the only issue then would be for the payment and shipping modules.....

If somebody wanted to fork ZC off for other languages it could be done right now.... if ZC will find some simple way to make it easy for others (languages) to use it, it will find new breathe.

[lat9]

I know another way that this could be implemented. The data in the configuration table could be exported and saved and a new language data could be inserted into its place giving room for someone who does not know English to have more of ZC in their language....or to be able to switch from language to language, the only issue then would be for the payment and shipping modules.....

You need to be careful with this. It's one thing to change the description of the setting, but making changes to the actual (albeit mostly in English) configuration values will cause many, many Zen Cart things to no longer work.

[shrimp-gumbo-mmmhhh]

You need to be careful with this. It's one thing to change the description of the setting, but making changes to the actual (albeit mostly in English) configuration values will cause many, many Zen Cart things to no longer work.

My thought is these two fields would be the only ones changed:
configuration_title
configuration_description

[DrByte]

It's already possible to do very simply, directly in your own language-pack:

For example, for spanish, add to your admin/includes/languages/spanish/configuration.php
all the necessary defines, like this:

define('CFGTITLE_STORE_NAME', 'Nombre de la Tienda');
define('CFGDESC_STORE_NAME', 'El nombre de mi tienda');

The pattern is: CFG_TITLE_ followed by the default key name, and CFG_DESC_ followed by the default key name.

[shrimp-gumbo-mmmhhh]

It's already possible to do very simply, directly in your own language-pack:

For example, for spanish, add to your admin/includes/languages/spanish/configuration.php
all the necessary defines, like this:

define('CFGTITLE_STORE_NAME', 'Nombre de la Tienda');
define('CFGDESC_STORE_NAME', 'El nombre de mi tienda');

The pattern is: CFG_TITLE_ followed by the default key name, and CFG_DESC_ followed by the default key name.

Is there a way to do that with the payment and shipping modules?

Thank you!

Shrimp

[mc12345678]

Is there a way to do that with the payment and shipping modules?

Thank you!

Shrimp

To what level of detail are you asking to be able to make language dependent?

There are defines for admin/includes/languages/YOUR_LANGUAGE/modules.php which address some of the main headers, then there are the defines on the catalog side for aspects of the module(s) (shipping and payment for example) which are language dependent.

The only thing that seems to be missing is a default way to change all of the information presented to the admin when configuring the module(s). The information stored in the database for such things is generally stored in english. The data could be stored as a type/style of configuration constant like above, but it appears that additional leap hasn't been made yet in the install section of those modules and their associated language file/pack.

[Philibel]

Line #308 :       $db->Execute("insert into " . TABLE_CONFIGURATION . " (configuration_title, configuration_key, configuration_value, configuration_description, configuration_group_id, sort_order, set_function, date_added) values ('Skip Countries, use a comma separated list of the two character ISO country codes', 'MODULE_SHIPPING_ZONES_SKIPPED', '', 'Disable for the following Countries:', '6', '0', 'zen_cfg_textarea(', now())");

This is from */includes/modules/shipping/zones.php and like mc12345678 already said (and as one can see from $db->Execute("insert into ) it get set in the database.

Changing all this will:

• cost a lot of extra work without any real improvement to the functions themselves
• give a configuration title in the database like TEXT_HEAD_ZONES_SKIP which is also not readable, even English speaking users are going to doubt
• mean plugins will have to be rewritten
• need more and bigger files
• make the old database useless unless there's a good program to adjust it to the new version

All that just to understand a few lines in a module which has to be set once and maybe changed once a year?

The problems I see with that are:

• less translations because of extra work
• a lot more topics like: "my database doesn't work", "my database is a mess", "worst update ever", ...
• translations often have problems with "nuances" and run a risk of putting the user on the wrong leg

Solutions:

• the more professional part of the admin should be done by someone who knows at least basic English. The day-to-day parts are already translated. So just lock the day-to-day admins out from the deep settings.
• easier would be to provide a translated version of https://docs.zen-cart.com/user/ so the functions and settings could be explained in details in the user's language.
  I.e.: Configuration => New Listing => Display Product Image
  0= off
  1st digit Left or Right How many will type L or R?
  2nd and 3rd digit Sort Order set 01, 02, 03 and then realize there are still two more to go between 01 and 02?
  4th digit number of breaks after after what? I don't want to break anything!

It will always be to short for a new user to get it right the first time. Lucky, it's https://docs.zen-cart.com/user/templ...configuration/ to the rescue. And it has pictures! (<=not to be condescending, just sarcastic ) A picture can say more than a thousand words.
It's like the instruction manual from cars 50 years ago telling how to fix the engine. Unlike today's leaflet warning you not to drink the fluid from the battery.

[swguy]

> easier would be to provide a translated version of https://docs.zen-cart.com/user/ so the functions and settings could be explained in details in the user's language.
> I.e.: Configuration => New Listing => Display Product Image ...

Go to Admin > Configuration > New Listing in 1.5.7 Admin.
In the upper right hand corner, you see a blue "help" icon (question mark). Click it.

It takes you to a page that explains these settings.