the entity wrapper always write to LANGUAGE_NONE if no certain language is given. However the current behaviour in core is different, see core issue #1208856: Enabling locale module changes field default language.

Defaulting to the language as returned from field_valid_language() should fix it.

CommentFileSizeAuthor
#9 entity_set_lang.patch1.51 KBfago
#7 1208862-7.patch965 bytesderhasi
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

fago’s picture

fago’s picture

Component: Core integration » Entity property wrapper

from discussion with plach in IRC I think we need an entity_language() to fix this. Also I guess the wrapper's language() method should default to that language, not language none.

plach’s picture

fago’s picture

fago’s picture

adding tag

derhasi’s picture

I found out of a similar problem, when using auto_nodetitle. There tokens are not provided for node creation, but for node updates.

As I recognized this occurs because in entity_metadata_field_property_get() the $langcode is retrieved as 'und', but the node form provided its fields as (in my case) 'de' (for German).

So I have an entity with

$entity->field_xy = array(
  'de' => array(
    0 => array('nid' => 3)
  ),
);

but the due to the $langcode it wants to look for 'und'.

Btw. $options['language'] is set to NULL, as $this->getPropertyLanguage() returns NULL, in EntityStructureWrapper::getPropertyValue(), where entity_metadata_field_property_get() is called.

derhasi’s picture

Status: Active » Needs review
FileSize
965 bytes

By further investigation, I guess I fell into a core bug that leeds to some wrong field language associations: #1238042: Field display languages are cached before locale has changed field language.. i recognized that after testing to patch the entity wrapper with some defaultLanguage behaviour.
The patch for that is attached here.

Looking into core, the only entity to providing a language property seems to be 'node'. I guess simply looking for $data->language would not fit to other entity approaches, but therefore I'm not enough into the entity api, to provide a more generic patch. Hope this patch might help anyway.

plach’s picture

fago’s picture

FileSize
1.51 KB

Looks like, we are going to need that entity_language() stuff to be able to fix this. Once this is settled in core we can think about improving the wrappers.

For now, we could just use $entity->language if it's there. See patch attached.

fago’s picture

Status: Needs review » Fixed

ok, I've committed this as interim workaround until an entity_language() function arrives in core.

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