Hi all, can someone tell me, where the translation for a super attributes key/value actually happens

UPWG9AYH2

Hi all,
can someone tell me, where the translation for a super attributes key/value actually happens?
I have currently two languages (en + ger) set up and therefore two entries for the abstract product in the

spy_product_abstract_localized_attributes

table. But the translation for a predefined value is defined in the attributes management section, right?
So i would suggest when i define here an attribute key “key.color” with the value “value.red” and i defined for the key for german “Farbe” and english “Color” and for the values “Rot” and “Red” that this gets displayed according to the selected language on my PDP. But it wont.

It seems that value is still the default “key.color” no matter what language selected.
When i look into the “spy_product_abstract_storage” table into the “data” fields json, i normally would suggest that here the magic already happened since this is what redis will get. But here is the key for both language entries the key “key.color” and “value.red” which should be Farbe or Color in my eyes (according to the language) …
So my question, where does the translation actually happen? Before publish? Or is there always the “technical key” published and the translation happens via translation service in Twig?
Any other suggestions?
Best regards and have a nice weekend

UKJND3A3H

I belieeeeve back in the days at least, that attribute translations happened in glossary with some naming convention (prefixed with attribute. or similar). Can’t tell if that’s still the case (and if it’s 100% right memory), but probably it’s worth a look?

UPWG9AYH2

I noticed a “spy_product_management_attribute_value” and a “spy_product_management_attribute_value_translation” table … but this part is missing for the keys … so, no “dynamic” translations for the keys here?

U01LKKBK97T

If I remember correctly, keys are translated via glossary key pattern: product.attribute.<key>.
See vendor/spryker/product-attribute/src/Spryker/Shared/ProductAttribute/ProductAttributeConfig.php::PRODUCT_ATTRIBUTE_GLOSSARY_PREFIX.

UPWG9AYH2

ah okay … but when i create some attribute via attributefacade, this happens impliicit?

UKJND3A3H

There we go, seems it’s still like that. Thanks Kay 🙂

U01LKKBK97T

Don't think that there's something happening implicitly. Pretty sure that you need to create the glossary key yourself.

UPWG9AYH2

ok, ill investigate … thanks a lot

U01LKKBK97T

Seems that a glossary key will be created implicitly, but it doesn't know what translation it should have. So yes, glossary key (spy_glossary_key) will be created, but the translation (spy_glossary_translation) is up to you.

UPWG9AYH2

Okay, the key seems to be translated, but what about the values? The value for the published product abstract in product abstract storage table is still “value.red” … it does not seem that the corresponding translation is considered from the attribute management backend. What i am missing? Best

UPWG9AYH2

As already mentioned in the product_abstract_localized_attributes table there are two entries, for each language one entry.
Should these entries already have the translated values or will the translation processed on another place?

U01LKKBK97T

They'll be published as is, so if e. g. you'd like to get search suggestions in frontend for translated attribute values, you should have them translated in db already. At least this is what's working for me.

UPWG9AYH2

But how does the mapping to the “technical” value work? So for example when you define the color as a super attribute, i dont think, that the translated value in the db can be used for make a unique variant decision … so the only possibility i can imagine is, that in “spy_product_abstract” in “attributes” column, there is a key “key.color” with value “color.red” and in the “spy_product_abstract_localized_attributes” there is the key “key.color” (translated later in glossary) and value “Red” … or for the second language “key.color” and “Rot” …

UPWG9AYH2

Sorry, the attribute stuff is more confusing to me the more i have a more detailed look

UPWG9AYH2

😄

UPWG9AYH2

I double checked and it seems that its exactly as i described … but i do wonder now what the “default” translation means for a predefined value in backends attribute management? It gets never considered since there are already the translated values in the localized table …

U01LKKBK97T

I don't know about the default either. Maybe it is meant for cases where you're querying without passing a locale, e. g. via Glue API. Don't know if that's possible at all, it could also be a legacy field that hasn't been removed yet. Just guessing, maybe somebody from Spryker can enlighten us.