Early Bird Registration for DrupalCon Portland 2024 is open! Register by 23:59 PST on 31 March 2024, to get $100 off your ticket.
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.
Comment | File | Size | Author |
---|---|---|---|
#39 | test.jpg | 40.29 KB | andrea.brogi |
#27 | fix_entity_field_language-1376126-27.patch | 1.37 KB | PatchRanger |
#25 | 1376126-entity-field-language-25.patch | 744 bytes | kalabro |
#14 | 1376126-entity-field-language-14.patch | 794 bytes | amitaibu |
#8 | entity-fix-field-language-detection.patch | 870 bytes | das-peter |
Comments
Comment #1
fagoOuch. 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.
Comment #2
fagoComment #3
fagoI 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.
Comment #4
fagofixed test case assertions to correctly talk of fallbacks on the default language, not to language neutral.
Comment #5
fagoNote: 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.
Comment #6
fubhy CreditAttribution: fubhy commentedLooking 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.
Comment #7
fagoI 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.
Comment #8
das-peter CreditAttribution: das-peter commentedUnfortunately 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.Comment #9
fagouhm, so what's the default langcode when taxonomy terms are translated then? Still language-none!?
Comment #10
fagoI think we should fix this to fallback on the default language too, thus check the language code ourself.
Comment #11
das-peter CreditAttribution: das-peter commentedI 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)
insteadfield_valid_language($langcode, $default_langcode)
Comment #12
amitaibuSeems the Message module was negatively effected by this, as the wrapper doesn't properly get the correct text value.
And now the following code will get me empty result:
Comment #13
amitaibuI 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.Comment #14
amitaibuLet's see if tests still pass.
Comment #16
fagoI 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
Comment #17
amitaibuWhy is that? As the message itself isn't translatable, just the message field.
Comment #18
das-peter CreditAttribution: das-peter commentedI 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.
Comment #19
bojanz CreditAttribution: bojanz commentedNote that:
is wrong for user entities because you have a "language" column there that means "User's default language.".
Comment #20
fagoAfaik 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.
Comment #21
fagosee #1454538: Add langcode property to all entity types; for the user entity, distinguish entity language from user's language preference
Comment #22
bojanz CreditAttribution: bojanz commented$user->language does not correspond to the langcode in fields. So we need to ignore it. That's my point.
Comment #23
KarenS CreditAttribution: KarenS commentedAs 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?
Comment #24
das-peter CreditAttribution: das-peter commented+ 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)
Comment #25
kalabroIncorrect 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.
Comment #26
kalabroAlso, I found that code, which was executed by Entity API with typo:
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?Comment #27
PatchRanger CreditAttribution: PatchRanger commentedI 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.
Comment #28
PatchRanger CreditAttribution: PatchRanger commentedSince #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.
Comment #29
kscheirerMarked #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).
Comment #30
mitchell CreditAttribution: mitchell commentedCool.. 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().
Ongoing, related issues (mentioned in)
* #1282018: Improve UX of language-aware entity forms (#24)
* #1260640: Improve field language API DX (#5)
Comment #32
fagoad #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.
Comment #33
fagoad #29: Why should $entity->language be NULL? This looks like a bug somewhere else instead.
Comment #34
fagoComment #35
fagoAs 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.
Comment #36
klonosHey 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.
Comment #37
bojanz CreditAttribution: bojanz commentedWe'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.
Comment #39
andrea.brogi CreditAttribution: andrea.brogi commentedHi 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.