zc_install doesnt recognize my 1.3.8 database during upgrade (specific languages)

I have ZC 1.3.8a installed with DB_VERSION=1.3.8 (fresh install for demo purposes)

If i run "zc_install/index.php?main_page=inspect" like for doing an upgrade, the system recognize a db_version of 1.3.0.2 only.

Seems that "zc_install\includes\classes\class.installer_version_manager.php" finds "sort_order=115" in "configuration where configuration_key='SHOW_ACCOUNT_LINKS_ON_SITE_MAP'".

This condition is also true for 1.3.8 and the system cannot differentiate them.

I can't replicate that problem on a fresh 1.3.8a install without addons.

Yes, you are right what you said, but I see the pb.
Ive checked again with my ZC (Full French 1.3.8a) and the original 1.3.8a (English version)

French 1.3.8a gives a DB_VERSION of 1.3.0.2 (false), English 1.3.8a gives 1.3.8 (correct)

Problem comes from the translation of 'zc_install\sql\mysql_zencart.sql' in French, to have an admin comprehensible for all our merchants. In 'zc_install\includes\classes\class.installer_version_manager.php', the functions 'check_version_XXX()'
were all refering to NUMBERS up to the 1302(). Then the comparison is done with 'configuration_title' (in English words)
which cannot be found in our version (French words). So it returns always false for 'check_version_XXX()' > 1302.

"configuration_title" is a field inside the database, and should not be translated.

So, what the langage packs are for if the admin cannot be translated ? Its the comparison which should not have been done against something variable and langage dependant.

Feel free to translate language files located under the /includes/languages folder.
But don't go translating the core SQL code or you're naturally going to have problems.

The Polish Language Pack (v 1.3.7 - ZenCart.pl Group) and Italian Group (http://www.zencart-italia.it/) at least are in the same case as us as they have translated 'zc_install\sql\mysql_zencart.sql'.

Some of our merchants doesnt understand English very well and have difficulties on very small problems. Thats why a full translation had been done (long work).

The issue here is compatibility between LABELS in the code and TABLES in the database.

You can call a database table anything you like (conforming of course to MySQL protocols).

Then you just need to make sure that references in the php (or other) code accurately use that table name.

But you should have no need to alter table names or code. You just need to alter the define constants for language descriptives.

I just say bad tests are done relying on langage dependant text inside TABLE_CONFIGURE to determine DB_VERSION. Nobody had been advised NOT to change English text in TABLE_CONFIGURE for localisation, and having so many options in English make merchants lost.

I think it was more simple to have the functions check_version_XXX() of 'zc_install\includes\classes\class.installer_version_manager.php' look directly in TABLE_PRODUCT_VERSION_HISTORY for the db-updates that have occured.

Making 1 or 2 checks in TABLE_CONFIGURATION does not mean
the last update has completely performed. Any SQL upgrade script can fail between its begin (update/insert into TABLE_CONFIGURATION) and
its end (upadte/insert into TABLE_PRODUCT_VERSION_HISTORY), so that you could have TABLE_CONFIGURATION up-to-date but not the others tables comming after.

Suppose a SQL failure, as it is, zc_install would find with check_version_XXX() that the last update has occured (but not completely in reality).

gob33, while I understand what you're saying, all your arguments are moot if whoever has translated the SQL code actually changed the database FIELD names.
If you want to translate descriptive text, feel free. But leave the underlying architecture alone.