I'm using ET with i18n on l10n_install profile

Right now admin can configure language filter and fallback in 2 different places:
Enable language fallback in /admin/config/regional/entity_translation
Select nodes by language in /admin/config/regional/i18n/select

These configurations do not correctly fallback. For example, if the language is selected as EN and a node is not in that language the fallback system will show nodes in all other languages, including UND. It should fallback only to UND (undefined language), or give option to fallback to any languages enalbed.

Also, filtering nodes for a specific language in /admin/config/regional/entity_translation displays only nodes originally written in that languge. It does not display the translations done on ET. It has to be fixed to display that nodes translated using ET.

Members fund testing for the Drupal project. Drupal Association Learn more


plach’s picture

Component: Code » Base system
Priority: Major » Normal
heldercor’s picture

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

heldercor’s picture

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.

palamida’s picture

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


Mac_Weber’s picture

Category: feature » bug

It does not solve the issue.

There are 2 places for configuring fallback. Displaying ALL nodes is not fallback.

plach’s picture

Category: bug » feature

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.

Calystod’s picture

Category: Feature request » Bug report
Issue summary: View changes

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....

daro.pl’s picture

it's a bug.

daro.pl’s picture

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())) {

  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) {
plach’s picture

Category: Bug report » Feature request

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.

daro.pl’s picture

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).

plach’s picture

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.

james.williams’s picture

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.

plach’s picture

Status: Active » Closed (works as designed)

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

james.williams’s picture

Component: Base system » User interface
Status: Closed (works as designed) » Active

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.

plach’s picture

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

james.williams’s picture

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: Duplicate module?, 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 :-)

plach’s picture

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

plach’s picture

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

james.williams’s picture

Status: Active » Needs review
1.07 KB

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

plach’s picture

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')?

james.williams’s picture

Yes, sure, that makes sense.

  • plach committed 14e5bdc on 7.x-1.x authored by james.williams
    Issue #1172104 by james.williams, daro.pl: Improved description of the...
plach’s picture

Status: Needs review » Fixed

Commited and pushed, thanks!

plach’s picture

Title: Better language fallback system » Improve description of the language fallback option
plach’s picture

Category: Feature request » Task

Status: Fixed » Closed (fixed)

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