0
There has always been one area in osCommerce Online Merchant that was not able to be translated into different languages, which has been the configuration parameters. The title and descriptions are hardcoded in english in the database osc_configuration table. Not only that, a hack was introduced to see and set the values dynamically on a per configuration parameter level - which had an ugly implementation that was also hardcoded in the database table.
I just pushed out a proof of concept to finally fix this for v3.0 to a new cfg branch on my github repo:
https://github.com/haraldpdl/oscommerce/tree/cfg
This introduces the concept of Configuration Modules where each configuration parameter is a module, where one common module is used by slightly over half of the configuration parameters to set its value via a normal text input field. Each module has its own language definition file where the title and description are defined, and also additional definitions for unique parameter values.
The modules are named in CamelCase style of the parameter key, for example the module for STORE_COUNTRY is found in:
osCommerce/OM/Core/Site/Admin/Module/Configuration/StoreCountry.php osCommerce/OM/Core/Site/Admin/languages/en/US/modules/Configuration/StoreCountry.php
The language definitions are defined as:
cfg_store_country_title cfg_store_country_description
Simple configuration parameters do not need their own module, they can use the standard common module but must have their own language definition file containing the title and description of the parameter.
There are two methods to retrieve the configuration parameter value:
$Config->get() // returns a formated value, eg United States of America (by default it returns the getRaw() value) $Config->getRaw() // returns the real value, eg 223 (the country ID for USA)
The configuration table can be optimized from:
configuration_id configuration_title configuration_key configuration_value configuration_description configuration_group_id sort_order last_modified date_added datetime use_function set_function
to:
configuration_id configuration_key configuration_value configuration_group_id sort_order
(A field could be added to define the module name, but this can be generated automatically from the configuration key)
Although it will be a lot of work to create the initial configuration parameters, it brings in much more flexibility on how configuration parameters can present their input fields and also allow for the parameters to be translated into different languages.
What are your thoughts? Is this a good implementation to work on?
Kind regards,
