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 the zxx 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 the und 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

We discussed this property would be better named 'multilingual'. Is that still the current plan?

Yes, multilingual sounds like the right choice.

Status:Active» Postponed

Let's wait for all conversion to the new Entity Field API before doing this: it will be way less painful.

Version:8.x-dev» 9.x-dev
Status:Postponed» Active
Issue tags:-D8MI, -language-content

This is not going to happen in D8 :(