geocode not working on multilanguage site

Subscribe.

Ok tested and confirmed the issue. The suggested fix/patch works but id like to know why we dont just ALWAYS pull the language from the $field key or even just use 'und' constant?

I have enabled both content translation AND entity translation but my $field associative key is ALWAYS 'und' regardless of the active locale and the content translation state of the node.. Anyone mind shedding a little light on what im missing here and why all this language logic is needed?

This patch seemingly has already been applied to the code?

function geocoder_widget_validate_walkthrough(&$field, $form_state, $parent = NULL) {
  if (is_array($field)) {
    // Set the language based on the form state.
    $lang = isset($form_state['values']['language']) ? $form_state['values']['language'] : LANGUAGE_NONE;

    // If default language is set but content isnt translatable it is still 'und' on the fields. 
    if (!isset($field[$lang])) $lang = LANGUAGE_NONE;

However, that doesn't fix the issue in my case. Because source field has a language, while the geocoder field has LANGUAGE_NONE. Why that is I have yet to figure out. This however breaks the modules functionality in just the same way as above.

Unless I'm hitting a core bug here, this issue is not fully resolved yet.

Further research indicates that
1) Not all fields need to be translatable, which causes my problem.
2) Old versions of core created _all_ fields as translatable, while newer core does not. See #1164852: Inconsistencies in field language handling.
3) The version of this issue that I've hit, is only likely to occur when you have an old core install, and continue creating new fields after upgrading core. But clearly it's possible to have some fields translatable and some not, this is currently not properly supported.

Since "split language fields" this is likely a low priority issue, my suggestion is
1) Add "All fields on an entity must be in the same language" note to a KNOWN ISSUES.txt file
2) Close this issue fixed
3) Open a new feature request for "proper" field language handling.

Got an issue with different language fields. Translation done using Entity translation module.
And there are three points I has when did this patch:
1. Translation form in entity_translation module has no 'language' value
2. Submission field items in submission form always have language
3. There is the only one language on field item in form

It is possible that I'm wrong with the second point, but seems not.

This patch works for me for both edit and translation forms.

I *think* this is fixed in the latest refactoring. Can you review and report back?

Okay, I'm sure enough this has been fixed to actually mark it as such. Although if it turns out this is not the case of please re-open.