Sylius: RFC - Translatable atribute values behavior

[gabiudrescu]

Let's say we have a Sylius instance that operates in two languages:

• en_US
• fr_FR

And this shop is selling tShirts, that have 3 mandatory attributes:

• fabric
• max. degrees for washing
• collar type

Fabric is a select attribute, that allows the following options:

• cotton
• linen
• polyester

Max. degrees for washing is an integer attribute, while Collar type is a string attribute.

---

The current implementation for selectable attributes in Sylius allows the following configuration for selectable attributes:

As a business owner,
I am not able to define in this screen the french translation of cotton or linen.

The only way I can do that with the current format is put all values, no matter what's the locale and select the translation on product level. Example:

English attribute value for product:

French attribute value for product:

This solution is cumbersome and does not scale very well when you have more than 2 locales or attributes with more than 10 options for each locale.

---

Another issue discovered with the current implementation is with integer or percentage attributes. Those attributes do not require a translation, as do string attributes.

Based on my initial example:

While it makes sense to add different translatable values on product for string attributes, for integer and percentage, it doesn't. See above that, as a content editor, you enter the value 100 twice. This is not a thing you want to do when you have like... 6 locales.

or 4-5 integer attributes on a 6 locales shop.

---

My proposal is to define attribute values as translatable or not translatable. The followings must be translatable:

• select
• text
• textarea

While the followings do not make any sense to be translatable:

• checkbox
• integer
• percentage
• date
• datetime

Also, in my opinion, the select attribute values must be translatable, not the assignment on the product. Our custom implementation is like this:
Selectable attribute on product (en_US):

Same selectable attribute on product (ro_RO):

And for en_US.

The attribute options are configured in a screen like this:

While for string attributes it looks like this:

And for integer attributes like this:

---

My proposal with this RFC is to rework some of the current behavior in attributes until Sylius gets stable. I understood from @pjedrzejewski this implies BC Break and we should consult first, before any decision.

Looking forward to hearing your opinions.

[sweoggy]

While it makes sense to add different translatable values on product for string attributes, for integer and percentage, it doesn't. See above that, as a content editor, you enter the value 100 twice. This is not a thing you want to do when you have like... 6 locales.

Definitely agree: because of this we disabled the translation of attributes all together, it was that much of a frustration for the shop employees.

[psihius]

I agree, this does need a proper review and probably an update.
It's not that easy to fill a big catalog in numerous languages. Some of the attributes might be text only, but major part usually is limited to a subset and can be done via selecting a value once and not for each language.

[Lowlo]

It's a good idea !
For the select attribute I opened a PR some days ago in order to test the translation implementation https://github.com/Sylius/Sylius/pull/8206. Some fixes are mandatory to finalize the PR. Feel free to use it.

[pjedrzejewski]

I agree, perhaps we just add a translatable (true/false) field to Attribute entity? That's what Akeneo does IIRC. And then based on this decide whether to generate translatable attribute values or always fallback to the default locale. Thoughts?

[psihius]

I think completely removing translations is not the best choice here. If you have a multi-language store - you don't really want to start messing in the translation files, and also you might want to use the translated attribute name when doing searching backend with elastic to support full text search capabilities.

So in essence I think this might be a hybrid between a select field and a freeform text field. Make it a widget that you not only can "just" select a value (probably searchable dropdown), but also an option to add a new value right on the spot with translations (so you don't have to predefine _everything_ upfront, as it's not always possible and having to go to attribute page, open it and edit it is not the best UX).
The difference between this and just using a dropdown field is that dropdown fields is an array of values and is stored differently in the database (it's a JSON string).

And leave an option for it to be a fully free-form translation like it's now.

My 0.02$

[pamil]

As for any kind of select field, the current implementation is buggy:

• we don't handle a scenario when one of its value gets removed
• we reference values by the key generated from the value, so every time the value changes, we end up with outdated references

I think we should address these issues first before making it translatable and therefore more complicated :)

[gabiudrescu]

@pjedrzejewski if we get inspired from Akeneo, then Attributes should also know about Channels, not only locales. but I think this makes it even more complicated.

based on our experience at BestValue, following the rule that some type of the attributes are translatable and some are not, solved the problem of having to put the same information twice.

in the end, whoever wants a percentage attribute to have different values for different locales, can use the string type, which should be default translatable. yes, there might be some mumbo-jumbo required on the display or filtering part, but I think we're talking about custom requirements, not general requirements.

@pamil good catch. I haven't bumped into this so far. I've opened a separated issue for this: #8308

[psihius]

Well, this is tagged for 1.0.0 and the big question is - is this going to make it?
Right now I have a huge need to be able to do translatable dropdowns (basically all attributes are gonna be dropdowns) and I have to know if I have to do a workaround for my problem or this is going to make it into the master soon and I can wait for it.

[pjedrzejewski]

@psihius We will give it a try next week but can't promise it will happen for 1.0. It is a risk to introduce feature so late but maybe we find a safe & simple way to add it.

[psihius]

@pjedrzejewski thanks. Probably a workaround for me for now then anyway.

[psihius]

Also, as a thought - before there were Archetypes - a kind of a attribute and option template or something, but it was quite confusing :)

But the idea itself was not a bad one and I actually implement a variation of that for current client - as we have a catalog of 3000+ products, creating new once is quite cumbersome, so for the old system they had a preset system.

A preset is a named entity that has a list of attributes selected and their values filled in. When they add a new product - they can either manually fill it in, or select a preset and it adds all the attributes and pre-fills all their values in all languages. Just attributes. It might be a good idea to also add something like this to the core, as that will ease the management a lot.

[gabiudrescu]

@psihius that's what Archetypes were doing in 0.19. I can share with you an account and take a look on our implementation, if you want.

@pjedrzejewski fingers crossed for having this solved in 1.0, because I find it a key feature for eCommerce shops with more than a couple of hundred products.

[pjedrzejewski]

I investigated and unfortunately too risky before 1.0. :) But I see ways to introduce it safely without BC breaks in 1.1 while giving it time to "mature".

[GSadee]

To be up-to-date: For now, we won't implement in Attribute the field (true/false) if it is a translatable or not. However, I checked the behaviour of attributes and there is a fallback locale that works. We don't have to fill values of attributes in every locale, just fill in the base locale. So if the value in a specific locale is not filled, then the value in a base locale should be displayed in shop. The only problem that I discovered was associated with channels and its default locale, but I guess that I've fixed it here: #8775