i18n_node_node_prepare() initializes the language property of the node object to the current interface language (through i18n_langcode()). This gives issues when another module, for example admin_language, changes the interface language object $GLOBALS['language'] to show all the string in English. This results in only having the admin_language language to choose on the node add form when you restrict the language.

However $GLOBALS[LANGUAGE_TYPE_CONTENT] remains untouched and is also more correct to choose the language of the node. This way the interface can be in English and the language content selection can still work correctly.

To reproduce:

  • Activate the options from the Basic page content type: "Set current language as default for new content.", " Lock language (Cannot be changed)."
    Enable the admin_menu module.
  • When creating a node and having the site in another language as English only English can be chosen for the node language.
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

salvis’s picture

I agree completely. Anyone with reasonable English language skills will prefer the English interface, but it's completely wrong to force the language of the content to be English because of that.

Jose Reyero’s picture

Title: i18n_node_node_prepare should use content language instead of interface language to set node language » Use content language instead of interface language (i18n_node_node_prepare should use...)
Category: bug » task

Right, we should use content language instead of others for:

- Any manipulation related to field values.
- Query rewriting for nodes.

Jose Reyero’s picture

Using content language for node prepare + clean up content / interface language usage. This is the first patch committed, though I think this may need some more work.

Patch committed, letting this open.

Jose Reyero’s picture

Title: Use content language instead of interface language (i18n_node_node_prepare should use...) » Use proper content/interface/context language everywhere.
Issue tags: +Needs change record

Reviewing the code (again) I've noticed these two (content and interface languages) are not used very consistently all around the modules.

In order to clean this up (first step):
- Obsoleted i18n_language(), replace with i18n_language_content/interface/context (created all these new functions).
- Renamed i18n_context_language() to i18n_language_context() for consistency. See where we can use it.
- Removed i18n_menu_language(), i18n_node_language() as these are meaningless, not really reusable (each of the modules needs content or context language depending on the place).

Jose Reyero’s picture

Kristen Pol’s picture

Related - taxonomy example that shows how to reproduce (marked duplicate of this issue): #1479498: Taxonomy Translation "translate" option and freetagging not compatible with Administration Language module

Jose Reyero’s picture

Status: Active » Fixed

Fixed (in latest dev) using 'context language' for newly created terms.

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