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.

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

stockliasteroid’s picture

tedbow’s picture

Status: Active » Needs review

@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.

Status: Needs review » Needs work

The last submitted patch, language-support-entityforms-2007432-1.patch, failed testing.

briancoffelt’s picture

Issue summary: View changes
Status: Needs work » Closed (works as designed)

Issue is six months old, open if still needed.

das-peter’s picture

Title: Language Support for entityforms » Language Support for entityforms / issues with translatable fields
Version: 7.x-1.0-rc2 » 7.x-2.x-dev
Category: Feature request » Bug report
Issue summary: View changes
Status: Closed (works as designed) » Needs review
Related issues: +#2218597: Rules 'Set data value' fails when data is an entityform
FileSize
4.41 KB

Just 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.

das-peter’s picture

Issue summary: View changes

Added link to Change Record related to entity_language()

das-peter’s picture

FileSize
4.41 KB

Oh there was an copy / paste artefact entity_language('node', $entityform) doesn't make that much sense ;)

mjpa’s picture

This 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.

sergei_brill’s picture

It 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.

hugronaphor’s picture

Issue summary: View changes
hugronaphor’s picture

Status: Needs review » Reviewed & tested by the community

I'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

joelpittet’s picture

Status: Reviewed & tested by the community » Needs work
  1. +++ b/entityform.admin.inc
    @@ -332,7 +332,7 @@ function entityform_edit_form($form, &$form_state, $entityform, $mode = 'submit'
    -    field_attach_form('entityform', $entityform, $form, $form_state);
    +    field_attach_form('entityform', $entityform, $form, $form_state, entity_language('entityform', $entityform));
    

    There are more field_attach_form() calls in entityform_edit_form_validate(). Should this be done there too?

  2. +++ b/entityform.info.inc
    @@ -40,6 +40,12 @@ class EntityformMetadataController extends EntityDefaultMetadataController {
    +    $properties['language'] = array(
    +      'label' => t("Language"),
    

    Does this need an update hook to add this property for existing sites?

  3. +++ b/entityform_type.admin.inc
    @@ -523,6 +523,35 @@ function _entityform_type_settings_elements($entityform_type, $op) {
    +    $form['data']['language_set']['language_use_current'] = array(
    +      '#type' => 'checkbox',
    +      '#title' => t('Use current site language'),
    +      '#default_value' => !empty($entityform_type->data['language_use_current']),
    +    );
    

    Is this pattern being used in other modules?

Reviewing this before committing, just want to make sure everything is correct.

AlfTheCat’s picture

I'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).

postyly’s picture