addressfield_set_target $field['und'] should be something like $field[$entity->language]

Comments

rszrama’s picture

Issue tags: +Feeds

Tagging. A patch would've been more helpful, as it wasn't immediately clear what code you were even referencing.

rszrama’s picture

Title: addressfield_set_target $field['und'] » addressfield_set_target() an .fields.inc shouldn't use 'und' as a hard-coded language code
Version: 7.x-1.0-beta2 » 7.x-1.x-dev

At the very least we should be using LANGUAGE_NONE instead of 'und'. I'd love to be able to use entity_language(), but it's not very clear to me how we can determine the entity type of the given $entity in addressfield_set_target(). I'll keep looking, but pointers would be helpful.

rszrama’s picture

Status: Active » Fixed

Alrighty, I found a way to determine the language code from a method on an entity processor called entityType. We can load the processor based on the $source config array, so during the set target phase, I load the plugin, check for the method, and if found try to fetch an entity type for it. If we can find one, we run it through entity_language, added as of Drupal 7.15, and if we get a result from that, we use it! If any of those conditions fail, we revert to LANGUAGE_NONE.

I also added some comments and made variable names a little clearer in this commit.

Commit: http://drupalcode.org/project/addressfield.git/commitdiff/681dd6e

johnv’s picture

Not sure if this is a good idea. Havent come across any translatable addresses lately. On a field-translatable entity, all untranslated fields are language-none, unless you set the 'translatable' field property. If this is not verified , the address may not be shown on every language. For D6-type translated nodes/copies it may be different.

rszrama’s picture

Title: addressfield_set_target() an .fields.inc shouldn't use 'und' as a hard-coded language code » Detect if an address field value should be language specific on import via Feeds
Category: bug » feature
Status: Fixed » Postponed
StatusFileSize
new1.25 KB

Alrighty, I ran a few tests to confirm, and honestly it's confusing me. If I set the $entity->langage to 'en' so that both the imported node and its field value are entered for English, it doesn't save the field value even though the node gets saved correctly. I don't know all the ins and outs of field translation, unfortunately, but I just couldn't get this thing to work.

I'm going to revert this patch and repurpose this issue. There may be some multilingual integration for us to take into consideration at a future time, but for now I'm just going to make everything use LANGUAGE_NONE. I'll attach the patch here so it can be reverse applied if we ever need to base work off it again. So much for the time spent on it yesterday. : P