To reproduce:

(1) enable entity_translation on a drupal 7 site
(2) admin/config/regional/language/add: add two languages
(3) set one of them as default
(4) uncheck the enabled checkbox in the english language.
(5) go to admin/structure/types/manage/article, and set Publishing options > Multilingual support to Enabled with field translation
(6) Create a new article,
(7) now click on the translate tab for the newly-created article, and we are seeing english even though it is disabled (I would expect not to see it).

A typical scenario for this bug would occur in a site which is in French and Spanish, but not in English. It is impossible to delete english, so we disable it. Editors should not see "English", then.

Cheers,

Albert.

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

alberto56’s picture

Status: Active » Needs review
FileSize
2.38 KB

For those who do not want disabled langues to be available in the language list, you can try one of these two approaches:

(1) set the entity_translation_languages_enabled variable to TRUE on your environment, like this:

drush vset entity_translation_languages_enabled 1

(2) try applying the enclosed patch.

I can't think of a use case where where one would want disabled languages to appear in the list, so I would propose applying the enclosed patch. The logic which uses a variable is still in place, but I have set the default value to TRUE rather than FALSE. That way, if this patch is applied, you can still revert to showing all languages in the language list by setting the entity_translation_languages_enabled variable to FALSE.

alberto56’s picture

Here is a better version of the patch:

(1) expand test coverage to test disabling of english as well as disabling of add-on languages.
(2) in function entity_translation_languages(), if i18n_node exists and we are dealing with a node, the existing module ignores the entity_translation_languages_enabled variable

function entity_translation_languages($entity_type = NULL, $entity = NULL) {
  if (isset($entity) && $entity_type == 'node' && module_exists('i18n_node')) {
    // @todo Inherit i18n language settings.
  }
  elseif (variable_get('entity_translation_languages_enabled', FALSE)) {
    $languages = language_list('enabled');
    return $languages[1];
  }
  return language_list();
}

In the patched version we are using if instead of elseif (in addition to using TRUE as the default value), so the entity_translation_languages_enabled variable is taken into account whether or not we are using i18n_node:

function entity_translation_languages($entity_type = NULL, $entity = NULL) {
  if (isset($entity) && $entity_type == 'node' && module_exists('i18n_node')) {
    // @todo Inherit i18n language settings.
  }
  if (variable_get('entity_translation_languages_enabled', TRUE)) {
    $languages = language_list('enabled');
    return $languages[1];
  }
  return language_list();
}
B-Prod’s picture

@alberto56: the issue #2497991: Allow translation of disabled languages gives an answer to your question in #1.

Dealing with disabled language may be really important in some circumstances. But I also agree that the configuration of such thing should be better explained.

GaëlG’s picture

In case i18n_node exists, we should use i18n settings (from admin/config/regional/i18n), as the @todo mentions.
Here's the right function, I think:

function entity_translation_languages($entity_type = NULL, $entity = NULL) {
  if (isset($entity) && $entity_type == 'node' && module_exists('i18n_node')) {
    // Inherit i18n language settings.
    if (variable_get('i18n_language_list', I18N_LANGUAGE_ENABLED) == I18N_LANGUAGE_ENABLED) {
      $languages = language_list('enabled');
      return $languages[1];
    }
  }
  elseif (variable_get('entity_translation_languages_enabled', TRUE)) {
    $languages = language_list('enabled');
    return $languages[1];
  }
  return language_list();
}
taote’s picture

Yes, this is what I was looking for. When is it going to be implemented in the module?

hgoto’s picture

candelas’s picture

Thanks @alberto56 Patch #2 works width last dev.
I don't have i18n_node enabled.

joseph.olstad’s picture

re-upload same patch to trigger testbot

stefanos.petrakis@gmail.com’s picture

Status: Needs review » Closed (duplicate)

First of all, an answer to the question:

a use case where one would want disabled languages to appear in the list

The answer comes from the closely related issue (thanks @hgoto for linking) #1175170: Optionally enable disabled languages for entity translation., you can read the following in the issue's description:

In some cases it might be useful being able to translate content to disabled languages before enabling it, thus it makes sense to have an option to turn that behavior on.

Here are the various different at hand regarding this issue:

  1. What should be the default behavior for showing disabled languages, a.k.a. default value for the entity_translation_languages_enabled variable?
    As there exist arguments for both sides, I would leave the option as it is. Allowing to control/modify this variable using the admin interface should solve the original issue reported here, this is being handled by #1175170: Optionally enable disabled languages for entity translation..
  2. Inheriting the i18n language settings; as mentioned in #2339495-4: English language appears in list even if it is disabled there is a @todo in the code. I moved this into a new issue #2872194: entity_translation_languages() should inherit i18n language settings.

So, I would close this as a duplicate and point the action to #1175170: Optionally enable disabled languages for entity translation., moving some/all of the tests provided in the patch there as well, in case they are of use.