As soon as the locale module is activated, new nodes store their field-values in a different array location. By default the field API array is keyed with LANGUAGE_NONE, however as soon as the locale module is enabled the default language is used - as returned from field_valid_language(). It does that even if the content type is configured to have no multi-lingual support.

I think it should always write to the LANGUAGE_NONE key as long as no translation is really enabled, as
* it does not make much sense to me to store field values language specific if the entity is configured to have no multi-lingual support
* it is weird that enabling the "locale" module changes existing behaviour without any configuration changes. If the node is not translatable it should always use LANGUAGE_NONE for storing values regardless of whether the locale module is enabled.

This it is in particular weird for everyone that wants to programmatically write/update field values, as the target location changes dependent on the locale module *even* if the nodes are configured as to have
no multi-lingual support.

Related issue: #1208844: Enabling locale module changes node default language

Comments

fago’s picture

adding tag

fago’s picture

Issue tags: +Needs backport to D7
fago’s picture

#1164852: Inconsistencies in field language handling introduces a saner default for the 'translatable' option of fields: OFF. That way we'd avoid those inconsistencies with node-level language, so this issue would be solved too.

plach’s picture

Status: Active » Closed (works as designed)
Issue tags: -Needs backport to D7 +translatable fields

This is exactly how nodes behave right now (and in D6): after enabling Locale nodes without an explicit language support active get the default language instead of no language. Translatable fields behave this way to ensure their languages always match node language.

If the node behavior is changed in D8, fields should follow automagically.

fago’s picture

>Translatable fields behave this way to ensure their languages always match node language.

I'm not sure whether the fields still need to be translated once the node already is translated, but it somehow makes sense to store their values for the same value. Anyway, as #1164852: Inconsistencies in field language handling I'd consider this as fixed.

I guess the main unexpected behaviour now boils down to #1208844: Enabling locale module changes node default language