Voting starts in March for the Drupal Association Board election.
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
undlanguage 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
zxxlanguage 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
undlanguage 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.