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.
Comment | File | Size | Author |
---|---|---|---|
#3 | 1531002-content_interface_language.patch | 5.33 KB | Jose Reyero |
Comments
Comment #1
salvisI 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.
Comment #2
Jose Reyero CreditAttribution: Jose Reyero commentedRight, we should use content language instead of others for:
- Any manipulation related to field values.
- Query rewriting for nodes.
Comment #3
Jose Reyero CreditAttribution: Jose Reyero commentedUsing 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.
Comment #4
Jose Reyero CreditAttribution: Jose Reyero commentedReviewing 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).
Comment #5
Jose Reyero CreditAttribution: Jose Reyero commentedRelated: #1601834: Use context language to select the right values for node/term forms.
Comment #6
Kristen PolRelated - 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
Comment #7
Jose Reyero CreditAttribution: Jose Reyero commentedFixed (in latest dev) using 'context language' for newly created terms.