Looks like the field language conditions vanished as of #1089876: Move field_language to display settings.

The mentioned issue moved the field language settings from the query to the display plugin. Unfortunately the field module wasn't adjusted accordingly. There you'll still find:

 if (field_is_translatable($entity_type, $field) && !empty($this->query->options['field_language_add_to_query'])) {

dereine already created a patch to fix this: http://paste.pocoo.org/show/550380/

I've just added another part to the patch to allow empty field values.

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

das-peter’s picture

I just thought about the locale_field_language_fallback setting.
If the setting is enabled locale_field_language_alter() uses locale_field_language_fallback() to find the most appropriate language for the field content.
This is done by iterating over the language list returned by language_fallback_get_candidates() which returns the first matching value.

Currently I just assume that SQL will also return the value of the first matching language in the fallback list - if this correct, the patch could look like this: http://drupalbin.com/20809

dawehner’s picture

If sql doesn't behave like that we are doomed anyway.

The patch in the pastebin looks fine.

das-peter’s picture

Here we go that's the patch for the pastebin code.

dawehner’s picture

Status: Needs review » Fixed

This changes are fine as written above. Committed to 7.x-3.x, let's see whether everything is broken :)
Thanks for writing the patch!

3rdLOF’s picture

Is this issue in any way connected to this: http://drupal.org/node/1450268 ?

Fatal error: Call to undefined function language_fallback_get_candidates() in modules/views/modules/field/views_handler_field_field.inc on line 210

Getting this after turning aggregation on.

Status: Fixed » Closed (fixed)

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