Problem/Motivation
Currently the entity form submission entity defines a language column but doesn't use it.
This limits the language related functionality - see original report.
And more important it can lead to some confusing behaviour especially together with translatable fields (#2218597: Rules 'Set data value' fails when data is an entityform):
In my current case I've the issue that an translatable field was used in an entityform.
When such a field is saved it uses the current site language by default - however the submission doesn't have a language / is language neutral.
Now if you use the submission in Rules you won't be able to access the field value of the translatable field because it's value doesn't belong to the submission language.
Proposed resolution
Actually use the language property and allow to configure how the it's primed.
By default we should use LANGUAGE_NONE
as this is the closes to the current behaviour.
Further the language likely just has informational purposes and doesn't relate to "translations" (I don't assume having translations of entityform submissions is such a common case).
But we should allow to set the language property according to the current user language as well as setting a specific language.
When creating the form for an entityform submission we have to use entity_language('node', $entityform)
in field_attach_form()
- as node_form()
does. Thus we'll require Drupal >=7.15 Change Record.
Remaining tasks
Clarify if we need an update hook, and what it should do.
Reviews needed.
User interface changes
New options when configuring an entityform type.
API changes
The language property has a value which might changes/fixes behaviour.
Original report by stockliasteroid
I'm using entityform in a site where it's necessary that the submissions be flagged with the correct location based on the user submitting. This allows for localized rules to be executed, etc...
I'm pretty new to localization, so this may not be the best approach, but I thought I'd give it a try. Very small change, the schema already included a language field, though it wasn't populated.
Comments
Comment #1
stockliasteroid CreditAttribution: stockliasteroid commentedPatch...
Comment #2
tedbow@stockliasteroid seems good thought I don't do much localization work so if we could get some other eyes on it that would be good.
Comment #4
briancoffelt CreditAttribution: briancoffelt commentedIssue is six months old, open if still needed.
Comment #5
das-peter CreditAttribution: das-peter at Cando commentedJust stumbled over an issue with rules that is related to the missing language handling.
Similar to #2218597: Rules 'Set data value' fails when data is an entityform
Rewritten some parts of the patch and added configuration options for language handling.
See updated issue summary for more information.
Comment #6
das-peter CreditAttribution: das-peter at Cando commentedAdded link to Change Record related to
entity_language()
Comment #7
das-peter CreditAttribution: das-peter at Cando commentedOh there was an copy / paste artefact
entity_language('node', $entityform)
doesn't make that much sense ;)Comment #8
mjpa CreditAttribution: mjpa commentedThis appears to work fine for me. Without the patch the translated options in a List (text) field were always in the default language but with the patch (and checking the "Use current language") makes the translated options work as expected.
Comment #9
sergei_brill CreditAttribution: sergei_brill commentedIt was not possible to get value of a translatable field attached to entityform using entity metadata wrapper in my custom module. The patch solves the problem.
Comment #10
hugronaphor CreditAttribution: hugronaphor as a volunteer and at Acrosto for Dropsolid commentedComment #11
hugronaphor CreditAttribution: hugronaphor as a volunteer and at Acrosto for Dropsolid commentedI'm happy about the patch, fixes my problem as well.
After 12 months maybe it's time to push it further?
Changing the issue status
Comment #12
joelpittetThere are more field_attach_form() calls in entityform_edit_form_validate(). Should this be done there too?
Does this need an update hook to add this property for existing sites?
Is this pattern being used in other modules?
Reviewing this before committing, just want to make sure everything is correct.
Comment #13
AlfTheCat CreditAttribution: AlfTheCat commentedI've tried the patch but my rule, that checks a condition on the submission for language, does not work. I'm trying to trigger a different email for each language, but the condition always evaluates to the original language (english).
Comment #14
postyly CreditAttribution: postyly as a volunteer commentedUpdate patch for 2.0-rc5 module version.