How to configure and adapt Aimeos based shops as developer
Forum rules: Always add your Aimeos and PHP version as well as your environment (Linux/Mac/Win)
#4710 by Bfr
05 Oct 2017, 09:09

I want to import products from my other database, I have a lot of product to import and these products all have different options categories, each containing a lot of options.
I suppose I have to create "attribute type" for each category but the problem is the translation because attribute type translation are stored in files based on the "code". Is there an other way to do it? Or should I add texts in "attribute type"?

Thanks in advance for your help,

#4718 by aimeos
05 Oct 2017, 17:57
The only way to translate the attribute types are the i18n translations - either in the config or in a Gettext po/mo file. How many attribute type (not attributes) do you have and are they highly dynamic or stay they for a longer time. Can you tell us what these attribute types are for?

We've thought about adding a mshop_attribute_type_i18n table which can contain translations for types in highly dynamic environments but nobody has required this up to now.
#4722 by Bfr
06 Oct 2017, 09:36
We have 5000 products and a lot of them have different "att type", for example a pen will have :
- color of the clip
- color of the barrel
- color of part1
- color of ink
a t-shirt will have
- color of collar
- color of body
- color of sleeve
- size
- material

And each product have their own types. I don't know if the po/mo file will have good performance if it contains 5000 key maybe you can tell me. I will also have to create new products and types and update existing everyday from my other database It wont be easy to update only the modified one with po/mo files.
#4724 by aimeos
06 Oct 2017, 11:00
Performance of Gettext mo files isn't a problem because they can be cached in APC if you enable that. But in your case it makes sense to use a translation table to for the attribute types if those values change more or less every day.

Are you interested in creating a patch to implement that? We would help you and tell you what should be done to get this working.
#4738 by Bfr
08 Oct 2017, 10:36
Yes I’m interested, how can I proceed? Should I do it in aimeos-core project ?
#4739 by aimeos
08 Oct 2017, 15:44
Yes, aimeos-core in an own branch would be the best place.

At first, we need to add the required table in I would suggest that layout:
Code: Select all      'mshop_attribute_type_i18n' => function ( \Doctrine\DBAL\Schema\Schema $schema ) {

         $table = $schema->createTable( 'mshop_attribute_type_i18n' );

         $table->addColumn( 'parentid', 'integer', [] );
         $table->addColumn( 'langid', 'string', ['length' => 5] );
         $table->addColumn( 'label', 'string', ['length' => 255] );

         $table->addUniqueIndex( ['parentid', 'langid'], 'unq_msatttyin_pid_langid' );

         return $schema;

We could join this table in the SQL statement used in searchItems() of the attribute type manager. In the attribute manager, we can use it to populate the "attribute.typename" property of the item. For management, we would need two more SQL statements in the attribute type manager to delete and insert langid/name pairs. The type item would need a getNames() and setNames( array $pairs ) method.

What do you think?