Improve description of the language fallback option

My original language is PT and when viewing in EN I get the content in FR which is the next available one.

Doesn't make sense, I would rather fallback to the original language (in my case, PT).

drupal core: 7.21
entity_translation: 7.x-1.0-beta2

Forget my comment. I solved it by changing the order of my languages in admin/config/regional/language.

Decided to leave it here in case others are looking for the same thing.

thanks,
this solved my problem

I had a similar situation:
- using Entity translation
- Language fallback was checked
- default language was set to ENGLISH
- on the Entity translation settings page the default language for the node was set to ENGLISH
- content was in ENGLISH and CROATIAN

when looking the ITALIAN page I get the CROATIAN content insted of ENGLISH

even using the Language Fallback module didn't solve the issue, but reordering the list of languages as you said did the job
I don't know, maybe I overlooked this note somewhere but it took me few hours until I find your solution

thanks,
regards
Marko

One of the places to configure fallback is provided by a submodule of i18n that is not compatible with ET and this is clearly stated in the documentation.

Additionally the OP does not provide any bug report, just a request for a behavior change without explaining what's wrong with the current one.

I really cannot understand what's the goal of this issue, but certainly this is not a bug report atm.

I confirm the problem and this problem have generated many bugs on our website. We have 4 languages: English, Japanese, Chinese and Korean.

For a question of presentation, the customer asked us to sort language in the switcher like this: Japanese, Korean, Chinese and English. We done.

When they have begun the translation in japanese, they had no problem. But, presently, they translate the site in chinese and have many problems:

• Taxonomy is display in japanese and not in english.
• When vocabulary isn't translated in japanese yet, terms are empty in the content
• When we validate the chinese translation with TMGMT in chinese, the english title becomes japanese.

English is configured as the fallback language in admin/config/regional/entity_translation for all nodes, vocabularies and panels.

After have read this issue, I have changed the order of languages for have english in first and all bugs are corrected....

It's a very frustrating bug....

+1
it's a bug.

I write some code to workaround this issue

/**
 * Implements hook_field_language_alter().
 */
function tweaks_field_language_alter(&$display_language, $context) {
  if (path_is_admin(current_path())) {
    return;
  }

  if (variable_get('locale_field_language_fallback', TRUE) && entity_translation_enabled($context['entity_type'])) {
    $entity = $context['entity'];
    $entity_type = $context['entity_type'];
    $handler = entity_translation_get_handler($entity_type, $entity);
    $translations = $handler->getTranslations();

    if (!empty($translations->data)) {
      list(, , $bundle) = entity_extract_ids($entity_type, $entity);
      $instances = field_info_instances($entity_type, $bundle);

      foreach ($translations->data as $langcode => $translation) {
        if ($langcode != $context['language'] && $langcode != $translations->original) {
          foreach ($instances as $instance) {
            unset($entity->{$instance['field_name']}[$langcode]);
          }
        }
      }
    }
  }
}

It's not a bug, it's meant to work exactly this way. By default fallback is determined by language weight, there is a hook exactly to let you implement whichever logic suits your use case.

You are probably facing a Title module bug instead.

Maybe it's Drupal logic here (because field languages are supported by the core), but it can't be accepted that Drupal displays German field values translations on English site, for example. Translations shouldn't complement each other. Original node values should be able to do it only.
Entity translation should provide some option to fix it (allow users to adjust it).

I agree the behavior suggested above makes sense and is probably a more sensible default behavior, but this is new functionality not a fix. If #9 becomes a patch that also adds an option to enable/disable this alternative fallback logic I'm happy to commit it.

We also need an update function disabling this, so that existing sites keep working as before.

Try using either of https://www.drupal.org/project/language_hierarchy or https://www.drupal.org/project/language_fallback to cover what you want to do. ET doesn't give control over fallbacks, it just allows them, without restricting what fallbacks can be set, unlike these other two projects.

Good point, let's make other modules cope with this.

Good point, let's make other modules cope with this.

In that case, it needs indicating/documenting, since ET provides the options in its UI that reference fallbacks that are confusing users. Users don't know that ET isn't going to do the 'whole' job, and the option implies that it might. Either the options should be relabelled / amended, or documentation needs adding somewhere clear that other modules exist to implement the functionality.

Can you suggest which amendments to the UI you would make?

See the attached patch :-)

It would be even more helpful to provide direction for users to find modules that actually do the work of controlling which languages are available as fallbacks (e.g. Language Hierarchy -- which I openly confess to being a maintainer of!). I don't know if you would want to do that, but it would make the job much easier for users? It's very common for users to find Drupal's default fallback behaviour frustrating, as it does usually seem 'wrong' for a completely unrelated language's translation to show up on another language's page.

If you did want to link to another project, Language Hierarchy & Language Fallback are the two examples (we're not aware of any other working D7 modules at all in fact), and since #2552663-8: Consider deprecating language_fallback in favor of entity_language_fallback, the maintainer of Language Fallback has said their project could be phased out in favour of Language Hierarchy, so if you just want a single simple link to another project, one could be added for Language Hierarchy? Though as a maintainer of the project, I'm obviously biased! I'll leave that suggestion up to you / anyone else without a vested interest to decide :-)

I'm fine with mentioning/linking Language Hierarchy in the comment instead of a general hint to contrib modules, thanks :)

Actually a link opening in a new tab pointing to the LH page would be great :)

Okay great, here's a revised patch then :-) Thanks!

Can we change the last sentence to say something like Otherwise, existing translations will be chosen based on their <a href="!url">language weight</a>. (where !url would point to url('admin/config/regional/language')?

Yes, sure, that makes sense.

Commited and pushed, thanks!