From http://groups.drupal.org/node/197848#overview:
In Drupal 7 fields have the translatable property, which has a somehow misleading meaning: a translatable field can have a different value for each language, otherwise its value will be shared among all the entity translations. This approach does not allow to fully support the language assignment functionality, since it works by assigning the field translation the
und
language code, which indicates that the content language is unspecified. This is a suboptimal solution since a "latin citation" field might be shared among all the entity translations, but still need to be assigned a language. OTOH a numeric (non-linguistic) field might hold a different value for each entity translation. This indicates that we need two distinct concepts in D8: an entity component can be linguistic or not, in which case it needs be assigned thezxx
language code (see also http://www.w3.org/International/questions/qa-no-language); at the same time a component can be shared among the entity translations or belonging to just one of them. The former is an intrinsic property of the component, while the latter needs to be configurable since its value depends on the use case being implemented. Since the main work here is on the UI side and this is not our main use case, the core behavior could be of still assigning theund
language to shared components, leaving everything else to contrib implementations. We would just need to ensure that language assignment at component level is not made impossible by our design.
Comments
Comment #1
Gábor HojtsyWe discussed this property would be better named 'multilingual'. Is that still the current plan?
Comment #2
plachYes, multilingual sounds like the right choice.
Comment #3
plachLet's wait for all conversion to the new Entity Field API before doing this: it will be way less painful.
Comment #4
plachThis is not going to happen in D8 :(
Comment #5
catchThis could happen with bc.