1. Enable locale
2. Set multilingual support (see image)
3. Set body field to be translatable

$field = field_info_field('body');
$field['translatable'] = TRUE;
field_update_field($field);

4. Create a node in "English" and write in the body "old value".
5. Execute code

$wrapper = entity_metadata_wrapper('node', 1);
$wrapper->body->value->set('This will replace value');
$wrapper->save();

you will notice it didn't replace the correct value. With patch, it replaces the correct value in the field.

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

fago’s picture

Priority: Normal » Major
Issue tags: +D7 stable release blocker

Ouch. I was able to reproduce it. Looks like LANGUAGE_NONE is passed instead of NULL. We need to figure out why and ensure it's consistent with getters.

fago’s picture

Issue tags: +Needs tests
fago’s picture

Title: Set correct language for translatable field » Fix language handling for translatable fields
Issue tags: -Needs tests
FileSize
6.91 KB

I got hit by this too, while working on #1422996: localization and i18n integration. In addition to the described problem, currently the field-getters make use of field_language(). Thus, they default to the current content language, however they should default to the entity default language.

I've overhauled language handling based upon the insights I got in #1277776: Add generic field/property getters/setters (with optional language support) for entities, what fixes both problems. We already had a test-case for that, but it was broken too since it tested multi-lingual fields in a not-multilingual field environment. I fixed that test-case, so we've test coverage too.

Patch attached.

fago’s picture

fixed test case assertions to correctly talk of fallbacks on the default language, not to language neutral.

fago’s picture

Note: We can overhaul this to make use of entity_language() or of the introduced helpers once #1260640: Improve field language API DX has been fixed.

fubhy’s picture

Status: Needs review » Reviewed & tested by the community

Looking good... Do we want to wait for that issue that you linked? Setting it to RTBC for now. We can probably set it back to "active" once this 'unfinished' version is commited.

fago’s picture

Status: Reviewed & tested by the community » Fixed

I don't think we need to wait, in particular as it can take quite a while until a possible fix ships... Once, it has shipped we can improve our code though. Committed.

das-peter’s picture

Status: Fixed » Needs review
FileSize
870 bytes

Unfortunately I've to reopen this issue.
After the update the title module was broken.
I use it to translate taxonomy terms but since those don't have a language property the current approach returns always LANGUAGE_NONE.
Thus I decided to remove the first condition and only check if a field is translatable. Furthermore I've changed the usage of field_valid_language() because the second parameter should be a boolean value.

fago’s picture

uhm, so what's the default langcode when taxonomy terms are translated then? Still language-none!?

fago’s picture

Status: Needs review » Needs work
+++ b/modules/callbacks.inc
@@ -498,8 +498,8 @@ function entity_metadata_field_get_language($entity_type, $entity, $field, $lang
+    $langcode = ($langcode != LANGUAGE_NONE) ? field_valid_language($langcode, TRUE) : $default_langcode;

I think we should fix this to fallback on the default language too, thus check the language code ourself.

das-peter’s picture

I investigated further and discovered a whole complex of an issue. Thus I've created this issue #1456186: Interaction of entity, entity_translation & title on entities without a language property.
If the new issue is solved the issue I mentioned here should be fixed too.
However, we should change the code to use field_valid_language($langcode, TRUE) instead field_valid_language($langcode, $default_langcode)

amitaibu’s picture

Seems the Message module was negatively effected by this, as the wrapper doesn't properly get the correct text value.

$property = MESSAGE_FIELD_MESSAGE_TEXT;
$message_type = message_type_create('foo');
$message_type->{$property} = array(
  'en' => array(
    0 => array('value' => 'foo'),
  ),
  'es' => array(
    0 => array('value' => 'bar'),
  ),
);
$message_type->save();

And now the following code will get me empty result:

$wrapper = entity_metadata_wrapper('message_type', $message_type);
dpm($wrapper->language('en')->{MESSAGE_FIELD_MESSAGE_TEXT}->value());
amitaibu’s picture

I think the problem is in if ($default_langcode != LANGUAGE_NONE && field_is_translatable($entity_type, $field)) {
It should be an OR

if ($default_langcode != LANGUAGE_NONE || field_is_translatable($entity_type, $field)) { as for example the Message entity doesn't have an $entity->language property, but the field is still translatable.

amitaibu’s picture

Status: Needs work » Needs review
FileSize
794 bytes

Let's see if tests still pass.

Status: Needs review » Needs work

The last submitted patch, 1376126-entity-field-language-14.patch, failed testing.

fago’s picture

I don't think an OR is right, as there may be only language specific values if the field is translatable. However, I think the first hunk could be removed. When looking at the patch over at http://drupal.org/node/1260640#comment-5004098, it's not in there and I presume taxonomy terms being translated via fields still have the language NONE (to be verified).

That should fix the problem with message too, although I think we should store a default language there too.

@tests: Unfortunately, the test bot is currently broken for unknown reasons: #1450686: automated tests fail

amitaibu’s picture

although I think we should store a default language there too.

Why is that? As the message itself isn't translatable, just the message field.

das-peter’s picture

I would really appreciate feedback here #1456186: Interaction of entity, entity_translation & title on entities without a language property.
There I tried to show why this actually is happen - at least as far as I understand the whole issue.

bojanz’s picture

Note that:

 $default_langcode = isset($entity->language) ? $entity->language : LANGUAGE_NONE;

is wrong for user entities because you have a "language" column there that means "User's default language.".

fago’s picture

is wrong for user entities because you have a "language" column there that means "User's default language.".

Afaik we don't have a distinction between "language" and "user preferred language" for user accounts in d7 yet? In d8 we have, but by default it's the same too.

bojanz’s picture

$user->language does not correspond to the langcode in fields. So we need to ignore it. That's my point.

KarenS’s picture

As noted above, the fix that was committed is wrong for users. I'm wondering if #1495648: Introduce entity language support would fix this issue as a substitute for the code that was originally committed? If so, maybe we can pile on that issue and try to get it into core?

das-peter’s picture

+ 1 for #1495648: Introduce entity language support because the new language aware entity edit form also relies on it (#1282018: Improve UX of language-aware entity forms)

kalabro’s picture

Incorrect parameter passing in entity_metadata_field_get_language()

I think there is a small typo that makes some problems. I found it while I tried to save both untranslatable and translatable fields of translatable node (node with language set) with Entity API.

After testing I see that this patch fixes problems from this issue summary too, so I'm posting it here.

kalabro’s picture

Status: Needs work » Needs review

Also, I found that code, which was executed by Entity API with typo:

field_is_translatable('node', 'node'); // TRUE, but why?

returns TRUE. But the second parameter should be an array and field_is_translatable() should return error or FALSE. May it be the core issue?

PatchRanger’s picture

I confirm that #25 fixed issue for non-translatable fields.
For translatable fields there should be one more change, see attached patch.
It works because $entity->language property is set but empty. That is why isset is setting $default_langcode to just "".
Please review the patch.

PatchRanger’s picture

Since #1703146: Use !empty() instead of isset() to check for entity language was commited the patch from #27 is no more actual.
Consider the patch from #25 as actual instead.

kscheirer’s picture

Status: Needs review » Reviewed & tested by the community

Marked #1829156: Incorrect parameter passing in entity_metadata_field_get_language() as a dupe of this issue, but the patch there came to the same conclusion. Is #25 the only problem we're trying to solve here now? The original bug report for this issue looks solved (I ran through the directions and the behavior was as expected).

mitchell’s picture

Status: Reviewed & tested by the community » Fixed

The original bug report for this issue looks solved

Cool.. So, altering approach in #29 to make one change per issue.

Summary

#7 fixed 'language handling for translatable fields' but required a followup change.

#8-#28 are about the followup change, to be done in #1829156: Incorrect parameter passing in entity_metadata_field_get_language().

the patch there came to the same conclusion [as #25].

Ongoing, related issues (mentioned in)

* #1282018: Improve UX of language-aware entity forms (#24)
* #1260640: Improve field language API DX (#5)

Status: Fixed » Closed (fixed)

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

fago’s picture

Status: Closed (fixed) » Needs work

ad #30: But this one is marked as stable release blocker, the other one not. Also, I think there is still the issue with user language left. I guess we should start using entity_language() here and bump the required core version.

fago’s picture

ad #29: Why should $entity->language be NULL? This looks like a bug somewhere else instead.

fago’s picture

Status: Needs work » Fixed
fago’s picture

As we have entity_language() since 7.15, I just made use of this one if it's there. This should fix the remaining issues with e.g. user entities. I'll document the recommended drupal version of drupal >= 7.15.

klonos’s picture

Hey Wolfgang, I can keep an eye on http://drupal.org/project/usage/drupal and let you know when the number of installations < 7.15 becomes really small. Then I guess we can change the 7.15 from a suggested to the required minimum version.

Currently, it seems that there are 220k out of the total of 545k reported D7 installations using 7.14 or lower. This means ~40% which is still pretty high.

bojanz’s picture

We've made 7.15 a requirement for both Commerce and Inline Entity Form.
Since there have been security updates since 7.15, I don't consider old versions an acceptable excuse.

Status: Fixed » Closed (fixed)

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

andrea.brogi’s picture

FileSize
40.29 KB

Hi Guys,
I reopen this discussion because I have a problem with translated version of e-commerce site.
The problem occurs when I update the Enty API from RC1 to RC2 and looking inside Release Note I've seen that this post and this one http://drupal.org/node/1356978 have worked to translation. So I have put this messagge also inside the other Isuue.

One yers ago I have developd an e-commerce site using Commerce Drupal.
The products have some "Term Reference" fields connected with a "Localized Vocabulary" (Not Translated).
All the products are translated and they show the correct terms when we shitch Language.
A group of Products is connected to a "View Node" using "Product Reference" field so we can have "Variation of products" showed inside the "Node View" with some "Select List".
Using the entity API version RC1 evrything was working correctly. When switch the lanuage the terms inside the select list was correctly translated.

If I update to RC2 instead the terms inside the "Select Field" are not translated. I have checked the product and the terms inside translation page but nothing is changed, the terms are correctly translated. Also in the Node View If I show the referenced terms like link the terms are translated. Only Inside "Select Field" the terms are wrong.

Someone of the guy have make this isuue can understand was it happen and help me to solve this problem?

You can test live this sistuation here
http://www.m2r2-comunicazione.it/en/node/26

This is a clear installation with the latest version of Drupal-Commerce-EntityApi.
If I come back to the RC1 of entityApi the system work correcly.