Add a customer-facing label to ProductAttribute

I support this idea.

Could this not be remedied by just outputting the machine name in both the attributes table and product variation attribute checkboxes?

Just like product type 'admin/commerce/config/product-types'

Since you can't add two 'colour' options without changing the machine name anyhow and the case for two of the same attribute 'titles' is likely fairly low, this would seem like a pretty easy solution without changing attributes schema.

Adding screenshot for reference

Created PR for the above: https://github.com/drupalcommerce/commerce/pull/621

That's a great idea but would not it be better to display on attributes' overview page attribute value names instead of machine names. Moreover the machine names you could see on this page when hovering over attributes' Edit button.

when administrating their attributes at admin/commerce/product-attributes they would see 'colour' as the title for many attributes, causing confusion, because that's the word we want the customer to see on the product and having that as the 'title' is the only way to do this.

Not quite sure what you mean by this because you don't need to assign customer usable labels on the attribute manage page. Instead you could do this individually for each reference field on each variation type. The same attribute field may have different labels on different variation types and at the same its own label on an attribute edit field itself.

As for the machine name on a variation type edit page it's a useful thing. The only deficiency is that italic style text for an attribute label and machine name is a bit redundant. It will be enough for a label but machine name could be leaved as is. Also, the parentheses make it inconvenient to select machine name which you could need as a developer. Remember the checkbox label is an active element and you could check/uncheck box by clicking on it so to avoid this you need to start selection from left to right but on this path you'd stumble on a parenthesis.

Please, use the diff on this comment because the diff on #6 was slightly modified.

I agree the label thing is kind of a moot point since you can just set it on the entity reference field that gets created for the attribute (as you pointed out here, but I'm not sure I like the idea of spitting out every attribute value into the table.

Consider an attribute that contains sentences, or one that has maybe a couple hundred non-single word values. That screen gets unreadable real quick, especially on smaller screens.

Outputting the machine name let's you determine which one you are looking at as they are always unique, single values, and if you want to view the values you can just hit edit. That also covers the case that someone does label them the same during setup but only changes the machine name.

Attached patch with both machine name in table and checkbox labeling as you've suggested.

I agree that machine names might be required for some use cases but the summary of attributes' names is also pretty useful, so why not to concatenate machine names with labels moving them one line down to spare space at the right.

Look at the first name of Animals Attribute. This is actually African Forest Elephant and it is trimmed to 7 characters + 3 ellipsis = 10. Also, the Exponential Attribute has 110 names but only 100 are displayed. That way we will never get more than (10 + coma + space) x 100 + 20 (possible **more** hint) = 1220 characters on an attribute. I don't think that this amount of a text can render a screen unreadable, would be it desktop or mobile device.

Let's get this back on track.

The default attribute label is currently both admin-facing and customer-facing.
Config entity labels are in general admin-facing (which makes sense since they match the machine name, and often need to be more specific when used as a reference).
So we need to add a customer-facing label. This could be worked around by editing the title of the generated field, but that's not super user-friendly.

We can call this new property $elementLabel, to match $elementType and the existing label().
Like $elementType, this new property would be used by ProductVariationAttributesWidget::getAttributeInfo(), instead of the field label. If empty, we'd fall back to the main attribute label (and the element label in ProductAttributeForm should have a #description that explains this).

Question: What label should the generated fields (that are shown on the product add/edit screen) use? Do we keep the admin label there?
A common use case is to have "Color" as the attribute label and "Select color" as the element label, which probably doesn't make sense on the admin form.

elementLabel should be anything non-Drupal administrative related. So when adding and editing products you'd see "Color". When displaying in Views (as additional example) or the Add to Cart form you'd render elementLabel

I thing that one more label might introduce just more mess up.

For now we have admin facing attribute label which is the same everywhere it referenced and that's is good. If the label is changed on an attribute edit page then it also will be changed everywhere. Look at the Animals Variation attributes. They display admin facing labels which I expect to see here. Then clicking on Manage fields tab I see user facing labels which I've modified specifically for this variation type. As for me that is enough labels.

If an admin is unsure what particular Admin Label => machine_name mean they could use clickable machine name which leads to the attribute edit/overview page.

@drugan
I said in #11 that fields should keep the admin facing label.
The point of adding the customer facing label is that people should not be editing the field label for this purpose.

UPD: please, use the patch on #16 comment.

Well, now I agree with #11 approach and think that additional customer facing label might be useful in some cases. For example, when you want all the references of an attribute field have the same customer label (global) keeping at the same time admin facing label untouched.

The priority of labels is the following:

When user adds new or edit existing attribute they can add customer facing label for this attribute. If the label is set up, then by default it will be assigned to any reference field of the attribute on a variation type. If not, then the admin label will be assigned. After saving the attribute reference on a variation type no any further changes on a global customer facing label will have an effect on this reference field label. It need to be changed individually for each attribute reference if desired. On a variation type edit form you have direct links to access an attribute reference edit page at the left and attribute edit page at the right. Note that the label at the left reflects the customer facing label which is currently in effect on the given variation type.

Minor changes made on to which label to display on a variation type edit form.

The #16 patch does not apply any more.

Instead use the latest diff from new PR:

https://patch-diff.githubusercontent.com/raw/drupalcommerce/commerce/pul...

@smartparty

I've cleanly applied the patch against the rc-1 version and for me all works as expected. Additionally, just to be sure, I've rebased the patch above the latest 8.x-2.x commit.

Please, explain more verbosely what the issue you have with the patch.

This feature is now included into Commerce Extended Attributes module.

Please, do the module review if you find it as a useful one.

Let's get back to this for 2.18.

elementLabel should be displayLabel, to match how we're calling this field elsewhere (from checkout panes to promotions).

+1 for this, but already 2.21 ...

+1 from me. Especially with translated sites it's very difficult and unstable to differentiate between attributes programatically with only a label. This is also in contrast to almost everything else in Drupal where you can have machine names for everything and thus quite counter-intuitive. Really surprising that you cannot have a proper machine name.

I've looked at commerce_xattributes, but first it doesn't seem to properly install with Composer under Drupal 9 because of outdated dependencies, then it relies on a second README module, which I don't want or need and for fixing basic stuff there is another submodule which also has to be enabled. Don't get me wrong, I definitively appreciate the effort with the module(s), but it looks quite complicated for sth. that really ought to work out of the box IMHO.