Currently a Node reference will always be node/nodes, but a Commerce Product has the option to be variation/variations. Why not just make the language (singular/plural) be completely configurable as a field settings?

Seems like it could only be a good thing.

Will try to get a patch put together.

CommentFileSizeAuthor
#2 inline_entity_form-1962022-02-custom-labels.patch4.24 KBjamsilver
#1 custom_language-1962022-1.patch2.92 KBdeciphered

Comments

deciphered’s picture

deciphered
Primary language English
Location Ballarat, Victoria, Australia
commented
Status: Active » Needs review
StatusFileSize
new custom_language-1962022-1.patch2.92 KB

Super simple patch.

jamsilver’s picture

jamsilver commented
StatusFileSize
new inline_entity_form-1962022-02-custom-labels.patch4.24 KB

Ooh lovely - rerolling the patch adding this functionality on to the regular (node, term etc) occurrences of inline entity form too - not just commerce!

deciphered’s picture

deciphered
Primary language English
Location Ballarat, Victoria, Australia
commented

@jamsilver,

This functionality should already have been on all the other ones, it just needed to be specifically declared for commerce... although I may be wrong, I'll re-test.

Also, can you possibly add a interdiff so I can see exactly what you changed?
http://drupal.org/documentation/git/interdiff
http://xjm.drupalgardens.com/blog/interdiffs-how-make-them-and-why-they-...

rerooting’s picture

rerooting commented

Hmm... interesting... have you seen this issue that bojanz was working on? It seems these are interrelated?
#1658458: Support Entity API-provided labels
Possibly even a duplicate?

deciphered’s picture

deciphered
Primary language English
Location Ballarat, Victoria, Australia
commented

@rerooting,

Based on a quick read through, the main difference is that this is about custom labels, and that's about entity labels. While a Node is a node, an end user may not know nor need to know what a node is, as that node might be a Product (wrapper) or an event or an address, it could be anything.

Not discounting that patch, it definitely make sense, but it doesn't make this patch make any less sense or required any less.

rerooting’s picture

rerooting commented

Indeed, I think its providing the entity-api provided label from the bundle, not the label itself...

In my opinion, that would be the most sensible default functionality, then what you are working on would be the other setting. It's nice to have the field work a certain way in default, then you only need to change the field settings if you must. I imagine an option list wherein the default entity bundle label (say product) is what comes through, then you can choose 'provide a custom label' and a field conditionally appears wherein you can add a label, providing entity token support.

rerooting’s picture

rerooting commented

The other thing your patch will need to take into account is formatting for plurals, which the entity api provided bundle labels would provide by default.

deciphered’s picture

deciphered
Primary language English
Location Ballarat, Victoria, Australia
commented

@rerroting,

This patch already handles plurals.

Otherwise, I'm happy enough with what you say, the bundle based patch should go in first as it'll probably resolve this issue for 80% of people, and then this patch should go in for those who want more control. As far as I'm currently concerned, this patch does what my client currently needs and I'm not authorised to spend any more of their time on the issue for the moment, however I will check in on it from time to time as it is functionality I know I will be needing again on future work.

I still have not reviewed the changes made by jamsilver, but I will try to do so sometime in the next 24 hours.

ianthomas_uk’s picture

ianthomas_uk
he/him
Primary language English
Location Brighton, UK
commented

@Deciphered jamsilver's patch just makes the same change to includes/node.inline_entity_form.inc and includes/taxonomy_term.inline_entity_form.inc that your patch makes to includes/entity.inline_entity_form.inc

bojanz’s picture

bojanz commented
Status: Needs review » Needs work

This setting can't live in IEF settings because IEF can support multiple bundles at the same time, in which case the setting makes no sense.
In addition to that, the UX of the new settings is pretty bad, I had no idea what it would do for me (from a user perspective).

Not "won't fixing" for now, we might be able to just get away with providing settings for each allowed bundle, but it certainly needs more thinking and exploring.

Sinan Erdem’s picture

Sinan Erdem commented

The patch jamsilver posted on comment #2 works for me and it is the functionality I need. Thanks for the patch.

dww’s picture

dww
we/he/they
commented

#1795162: Add Per Bundle Labels for Nodes is a related issue that's a really important UI improvement. However, even if we can't figure out a perfect solution for all the buttons and internal labels in a purely general way for all entities and bundles, can we at least preserve the field label wrapping the whole inline form?

Once I enabled this module on a test site, the UI got rather confusing. I've got a couple of entity ref fields in a row on a given entity form. Once I click the "Add Existing Node" button the existing field label I've configured goes away completely and all I see is "ADD EXISTING NODE". That's a wonky label for the field container (and button) for two reasons: a) I want to reference an existing node, not add one and b) "WTF is a 'Node'? I was trying to reference an author". If I open a couple of my entity reference fields at the same time, I no longer have any idea which one is which -- I just get a 'Node' autocomplete box with no idea what to type. Even if I just open one, I have to remember what it was. And if I have two fields next to each other referencing the same entity/bundle, I still can't see. Why do we replace the configured widget label? I don't understand how that improves the UI at all.

Once #1881616: Move the inline forms (add, edit, remove, reference existing) to modals is happening, we still need to re-use the field label as the title of the modal or something.

Can we at least make it configurable whether the ajax/model destroy or preserve the widget label I configured for this field? This seems like the best issue to raise this in, but if not, please point me to a better place.

Thanks!
-Derek

bojanz’s picture

bojanz commented

Decided to go ahead with this one after all. Rerolling soon.

rerooting’s picture

rerooting commented

Oh great! I was working on a blog post that covers this among other things, so I'll hold off until this upcoming commit.

bojanz’s picture

bojanz commented
Title: Allow custom language/labels. » Allow labels to be overriden
Issue summary: View changes
Status: Needs work » Fixed

Committed:
http://drupalcode.org/project/inline_entity_form.git/commitdiff/333d8c5?...

And opened a followup: #2164511: Allow overriden labels to be translated

Thanks for the patience, everyone.

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.