Expand operation capability with language code #43
Comments
mc12345678
added a commit
that referenced
this issue
Dec 17, 2017
Fixes #43 Support export with language code Export language dependent data as a field to include the language code suffix (ie. english => `en`, german => `de`, etc...), the language id suffix (ie. english => 1, german => 2, etc...), or both fields. Currently the export uses the language_id which is a number associated with the specific database as the suffix for fields that are language based (ie. category_description, product_description, etc...). Use of the language code will make data transfer/matching more universal with the existing database and other databases. Added a define value into `includes/modules/easypopulate_4_filelayout.php` to support the export of language fields to have the language code (ie. english => `en`, german => `de`, etc...) Define established is: `EASYPOPULATE_4_CONFIG_LANGUAGE_EXPORT` with expectation of at least three options: `id`, `code`, `all` where `all` will export language based fields with at least currently the language id number and the language code to where the two fields will be adjacent to each other and are expected to contain the same information on export. The file contains a define if one has not been set (expected to be set through the install/upgrade process to be in the database) to default to the "old" method of using the language id number as the suffix. Also if the setting is not `code` then the "default" will be used. If a fourth option is added to the list then this particular arrangement may need to be revisited. (ie. what if a third language field were added to the mix, then there would need to be an option to export just that third field, and three additional options to export that field combined with the other existing two and one for the existing two to be exported alone as well, though it would simply make more programming sense to either export a single field or all fields and then the additional fields removed and/or import to be controlled to allow one or the other, but shouldn't allow a combination of language characteristics unless the goal is to change the language assignment data. With the changes that have been made to the export file, having `EASYPOPULATE_4_CONFIG_LANGUAGE_EXPORT` set to any of the above three options will result in the export file containing whatever has been chosen/set or if it is not set to one of the three values to export the fields using the language id as the suffix. Added the configuration option to support "setup" and control of the export language suffix for fields that are language dependent.
mc12345678
added a commit
that referenced
this issue
Dec 17, 2017
Fixes #43 Support export with language code Export language dependent data as a field to include the language code suffix (ie. english => `en`, german => `de`, etc...), the language id suffix (ie. english => 1, german => 2, etc...), or both fields. Currently the export uses the language_id which is a number associated with the specific database as the suffix for fields that are language based (ie. category_description, product_description, etc...). Use of the language code will make data transfer/matching more universal with the existing database and other databases. Added a define value into `includes/modules/easypopulate_4_filelayout.php` to support the export of language fields to have the language code (ie. english => `en`, german => `de`, etc...) Define established is: `EASYPOPULATE_4_CONFIG_LANGUAGE_EXPORT` with expectation of at least three options: `id`, `code`, `all` where `all` will export language based fields with at least currently the language id number and the language code to where the two fields will be adjacent to each other and are expected to contain the same information on export. The file contains a define if one has not been set (expected to be set through the install/upgrade process to be in the database) to default to the "old" method of using the language id number as the suffix. Also if the setting is not `code` then the "default" will be used. If a fourth option is added to the list then this particular arrangement may need to be revisited. (ie. what if a third language field were added to the mix, then there would need to be an option to export just that third field, and three additional options to export that field combined with the other existing two and one for the existing two to be exported alone as well, though it would simply make more programming sense to either export a single field or all fields and then the additional fields removed and/or import to be controlled to allow one or the other, but shouldn't allow a combination of language characteristics unless the goal is to change the language assignment data. With the changes that have been made to the export file, having `EASYPOPULATE_4_CONFIG_LANGUAGE_EXPORT` set to any of the above three options will result in the export file containing whatever has been chosen/set or if it is not set to one of the three values to export the fields using the language id as the suffix. Added the configuration option to support "setup" and control of the export language suffix for fields that are language dependent.
mc12345678
added a commit
that referenced
this issue
Dec 18, 2017
Fixes #43 Support export with language code Export language dependent data as a field to include the language code suffix (ie. english => `en`, german => `de`, etc...), the language id suffix (ie. english => 1, german => 2, etc...), or both fields. Currently the export uses the language_id which is a number associated with the specific database as the suffix for fields that are language based (ie. category_description, product_description, etc...). Use of the language code will make data transfer/matching more universal with the existing database and other databases. Added a define value into `includes/modules/easypopulate_4_filelayout.php` to support the export of language fields to have the language code (ie. english => `en`, german => `de`, etc...) Define established is: `EASYPOPULATE_4_CONFIG_LANGUAGE_EXPORT` with expectation of at least three options: `id`, `code`, `all` where `all` will export language based fields with at least currently the language id number and the language code to where the two fields will be adjacent to each other and are expected to contain the same information on export. The file contains a define if one has not been set (expected to be set through the install/upgrade process to be in the database) to default to the "old" method of using the language id number as the suffix. Also if the setting is not `code` then the "default" will be used. If a fourth option is added to the list then this particular arrangement may need to be revisited. (ie. what if a third language field were added to the mix, then there would need to be an option to export just that third field, and three additional options to export that field combined with the other existing two and one for the existing two to be exported alone as well, though it would simply make more programming sense to either export a single field or all fields and then the additional fields removed and/or import to be controlled to allow one or the other, but shouldn't allow a combination of language characteristics unless the goal is to change the language assignment data. With the changes that have been made to the export file, having `EASYPOPULATE_4_CONFIG_LANGUAGE_EXPORT` set to any of the above three options will result in the export file containing whatever has been chosen/set or if it is not set to one of the three values to export the fields using the language id as the suffix. Added the configuration option to support "setup" and control of the export language suffix for fields that are language dependent.
mc12345678
added a commit
that referenced
this issue
Dec 18, 2017
Fixes #43 Support export with language code Export language dependent data as a field to include the language code suffix (ie. english => `en`, german => `de`, etc...), the language id suffix (ie. english => 1, german => 2, etc...), or both fields. Currently the export uses the language_id which is a number associated with the specific database as the suffix for fields that are language based (ie. category_description, product_description, etc...). Use of the language code will make data transfer/matching more universal with the existing database and other databases. Added a define value into `includes/modules/easypopulate_4_filelayout.php` to support the export of language fields to have the language code (ie. english => `en`, german => `de`, etc...) Define established is: `EASYPOPULATE_4_CONFIG_LANGUAGE_EXPORT` with expectation of at least three options: `id`, `code`, `all` where `all` will export language based fields with at least currently the language id number and the language code to where the two fields will be adjacent to each other and are expected to contain the same information on export. The file contains a define if one has not been set (expected to be set through the install/upgrade process to be in the database) to default to the "old" method of using the language id number as the suffix. Also if the setting is not `code` then the "default" will be used. If a fourth option is added to the list then this particular arrangement may need to be revisited. (ie. what if a third language field were added to the mix, then there would need to be an option to export just that third field, and three additional options to export that field combined with the other existing two and one for the existing two to be exported alone as well, though it would simply make more programming sense to either export a single field or all fields and then the additional fields removed and/or import to be controlled to allow one or the other, but shouldn't allow a combination of language characteristics unless the goal is to change the language assignment data. With the changes that have been made to the export file, having `EASYPOPULATE_4_CONFIG_LANGUAGE_EXPORT` set to any of the above three options will result in the export file containing whatever has been chosen/set or if it is not set to one of the three values to export the fields using the language id as the suffix. Added the configuration option to support "setup" and control of the export language suffix for fields that are language dependent.
mc12345678
added a commit
that referenced
this issue
Dec 18, 2017
Fixes #43 Support export with language code Export language dependent data as a field to include the language code suffix (ie. english => `en`, german => `de`, etc...), the language id suffix (ie. english => 1, german => 2, etc...), or both fields. Currently the export uses the language_id which is a number associated with the specific database as the suffix for fields that are language based (ie. category_description, product_description, etc...). Use of the language code will make data transfer/matching more universal with the existing database and other databases. Added a define value into `includes/modules/easypopulate_4_filelayout.php` to support the export of language fields to have the language code (ie. english => `en`, german => `de`, etc...) Define established is: `EASYPOPULATE_4_CONFIG_LANGUAGE_EXPORT` with expectation of at least three options: `id`, `code`, `all` where `all` will export language based fields with at least currently the language id number and the language code to where the two fields will be adjacent to each other and are expected to contain the same information on export. The file contains a define if one has not been set (expected to be set through the install/upgrade process to be in the database) to default to the "old" method of using the language id number as the suffix. Also if the setting is not `code` then the "default" will be used. If a fourth option is added to the list then this particular arrangement may need to be revisited. (ie. what if a third language field were added to the mix, then there would need to be an option to export just that third field, and three additional options to export that field combined with the other existing two and one for the existing two to be exported alone as well, though it would simply make more programming sense to either export a single field or all fields and then the additional fields removed and/or import to be controlled to allow one or the other, but shouldn't allow a combination of language characteristics unless the goal is to change the language assignment data. With the changes that have been made to the export file, having `EASYPOPULATE_4_CONFIG_LANGUAGE_EXPORT` set to any of the above three options will result in the export file containing whatever has been chosen/set or if it is not set to one of the three values to export the fields using the language id as the suffix. Added the configuration option to support "setup" and control of the export language suffix for fields that are language dependent.
mc12345678
added a commit
that referenced
this issue
Dec 19, 2017
Fixes #43 Support export with language code Export language dependent data as a field to include the language code suffix (ie. english => `en`, german => `de`, etc...), the language id suffix (ie. english => 1, german => 2, etc...), or both fields. Currently the export uses the language_id which is a number associated with the specific database as the suffix for fields that are language based (ie. category_description, product_description, etc...). Use of the language code will make data transfer/matching more universal with the existing database and other databases. Added a define value into `includes/modules/easypopulate_4_filelayout.php` to support the export of language fields to have the language code (ie. english => `en`, german => `de`, etc...) Define established is: `EASYPOPULATE_4_CONFIG_LANGUAGE_EXPORT` with expectation of at least three options: `id`, `code`, `all` where `all` will export language based fields with at least currently the language id number and the language code to where the two fields will be adjacent to each other and are expected to contain the same information on export. The file contains a define if one has not been set (expected to be set through the install/upgrade process to be in the database) to default to the "old" method of using the language id number as the suffix. Also if the setting is not `code` then the "default" will be used. If a fourth option is added to the list then this particular arrangement may need to be revisited. (ie. what if a third language field were added to the mix, then there would need to be an option to export just that third field, and three additional options to export that field combined with the other existing two and one for the existing two to be exported alone as well, though it would simply make more programming sense to either export a single field or all fields and then the additional fields removed and/or import to be controlled to allow one or the other, but shouldn't allow a combination of language characteristics unless the goal is to change the language assignment data. With the changes that have been made to the export file, having `EASYPOPULATE_4_CONFIG_LANGUAGE_EXPORT` set to any of the above three options will result in the export file containing whatever has been chosen/set or if it is not set to one of the three values to export the fields using the language id as the suffix. Added the configuration option to support "setup" and control of the export language suffix for fields that are language dependent.
mc12345678
added a commit
that referenced
this issue
Dec 19, 2017
Fixes #43 Support export with language code Export language dependent data as a field to include the language code suffix (ie. english => `en`, german => `de`, etc...), the language id suffix (ie. english => 1, german => 2, etc...), or both fields. Currently the export uses the language_id which is a number associated with the specific database as the suffix for fields that are language based (ie. category_description, product_description, etc...). Use of the language code will make data transfer/matching more universal with the existing database and other databases. Added a define value into `includes/modules/easypopulate_4_filelayout.php` to support the export of language fields to have the language code (ie. english => `en`, german => `de`, etc...) Define established is: `EASYPOPULATE_4_CONFIG_LANGUAGE_EXPORT` with expectation of at least three options: `id`, `code`, `all` where `all` will export language based fields with at least currently the language id number and the language code to where the two fields will be adjacent to each other and are expected to contain the same information on export. The file contains a define if one has not been set (expected to be set through the install/upgrade process to be in the database) to default to the "old" method of using the language id number as the suffix. Also if the setting is not `code` then the "default" will be used. If a fourth option is added to the list then this particular arrangement may need to be revisited. (ie. what if a third language field were added to the mix, then there would need to be an option to export just that third field, and three additional options to export that field combined with the other existing two and one for the existing two to be exported alone as well, though it would simply make more programming sense to either export a single field or all fields and then the additional fields removed and/or import to be controlled to allow one or the other, but shouldn't allow a combination of language characteristics unless the goal is to change the language assignment data. With the changes that have been made to the export file, having `EASYPOPULATE_4_CONFIG_LANGUAGE_EXPORT` set to any of the above three options will result in the export file containing whatever has been chosen/set or if it is not set to one of the three values to export the fields using the language id as the suffix. Added the configuration option to support "setup" and control of the export language suffix for fields that are language dependent.
|
For full product import, products and categories have been modified to support this as of version 4.0.37.8. Still working on the other sub-imports. Export appears to support providing the language associated field(s) with either or both the language_id or language_code suffix. An admin switch has been added for import that if both fields are present as to which will provide the desired data. Default is to use the language_code. By using the language_code as the default, a change to a column of data is easy to see/identify about which language it applies. Users that have adapted to using the numeric language_id in their imports may want to modify that default if they don't change their process to use the 2 letter language_code. The other import options are being worked on to fully support the use of the language_code at least for known fields. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
The original development of this plugin used the language_id (a numeric number that corresponds to a record in the database but not to a "real-world" human readable value). It means that if an export of one database is used as the import of another database that the data may not line up and in fact it may be possible that one language would overwrite another.
By using the language_code (ie. English - en, German - de, etc...) then the export of english from one store will map to the english of another store provided the language itself is installed/mapped to that letter "pairing".
The text was updated successfully, but these errors were encountered: