Add support for field based translation

Partially unrelated: how would you handle your use case with entity_load back in the picture (per #1002744: Use entity_load for fieldapi field handlers)?
We really need to get all this right before an alpha...

Here's what plach said about field translations:

In D6 we support CCK multiple fields allowing to specify which deltas have to be selected for display: field language should be handled the same way, if possible, allowing to select which languages retrieve. We don't need to load all languages everytime, in a common scenario in which every content is properly translated, we just need to pick up one field translation for each field (current language or LANGUAGE_NONE). This should allow to have ranged queries without too much hassle.

I'd like the concept of field based translation very much and my gut feeling tells me this will be a very common way to serve multilingual sites.

Agreed. However, my gut tells me that this can't be done right without entity_load.
The translation module has it's own logic for determining the current language, so our filtering by node language might be totally wrong, no?
If we load the "de" translation by sql, and then entity_load and translation load "en" and decide to use that one, we have a problem.

And because I hope it's usable for others or at least a seed for further development I decided to post it here.

Of course. The most useful part of it is the fact that it started this discussion. I'm grateful for both.

I worked on this tonight.

However, I'm not allowed to post patches at 3AM.
So, see you tomorrow.

Here's my patch.

One general change you'll notice is that ***CURRENT_LANGUAGE*** now gets replaced with $language_content->language, and not $language->language.
This is a D7 change. In D6, $language meant "active language". In D7, $language means "interface language" and $language_content means "content language".

The main part of this patch adds a field setting allowing you to specify the field language.
The setting is only visible and taken into account when there's a registered translation handler for the given entity, and when field is marked as "translatable".
So, if there's no project/translate (or a non-existing alternative) installed, there's no setting.

You might wonder why I went with the field setting approach.
Since language is now a per field column, adding one language filter per field would start to look ridiculous & repetitive.
On the other hand, we can't add it to Query settings, since the setting should be shown only if we are querying a fieldable entity with a registered translation handler, and views currently knows nothing about entities.

Of course, without entity_load() there's no language fallback.
Also, this only works right if all fields have the same language settings, because of our entity-building-hack. If you want to display one "en" field and another "de" field, it won't work without entity_load() or without adding a hack that clears the field_language() static cache (as mentioned in #987478: Field language is not properly handled)

subscribing

We have a fatal flaw in the patch above. This needs to be a per entity,not a per field setting.
field_language() allows you to select one language per entity for fields.
So if someone selects English for Field A and German for Field B, it won't work as expected.

I now have no idea where to put this setting...

New patch. Completely untested.

Actually, that was the old patch :D

Final, tested patch.
Also fixes a notice in views_handler_field_field::query() introduced earlier tonight.

Dereine reviewed the patch on IRC.
And I changed another comment.

Commited to the 7.x branch. Awesome.

We made a lot of progress in the last days.

Here's a small followup.
It looks like a style cleanup, but actually efq_views won't work without it (I could work around it, but this is clean)

I've included these changes in my patch at #1041340: 'Field Language' in 'Query options' missing "All languages" option.