Make each field instance have its own translatable property, instead of sharing translatable property with others. [#1893568]

Problem/Motivation

Currently, field translatable property is set in table field_config, which means all field instanses for a specific field share the same 'translatable' perporty. This could lead to settings conflict.

For example, the most commonly used field 'body' is attached to several content types. Let's say it's used in both content types page and article. Now I want to make the body in page translatable and in article non-translatable. This simple requirement could not be done in current design, because translatable property applies to all field instances. I must create two different 'body' fields for content type 'page' and 'article', and assign different translatable property to either 'body'.

Steps to reproduce

Install drupal8 with English and stardard profile;
Enable Language, content translation, and Interface Translation modules;
Go to 'admin/config/regional/content-language', check 'Content', and make Article and Basic page translatable;
Leave Body for Article unchecked and Body for Basic page checked. Click save.
Now Body for Article is also checked in this page, even it's not checked before save.

Proposed resolution

Move the field translatable property from table field_config to table field_config_instance. In this way, each field instanse will have it's own translatable property, and no conflicts.
This could involve many aspects of field settings, like field's own translation setting, but I seriously think is it really necessary to enable field's own translation setting.

User interface changes

No UI changes

API changes

I suppose no api changes.

Comments

Comment #1

smiletrl CreditAttribution: smiletrl commented 20 January 2013 at 14:32

This could be a big design issue. berdir doesn't think it's possible to do this. Anyway, leave it open.

Comment #2

smiletrl CreditAttribution: smiletrl commented 21 January 2013 at 01:16

Title:

Move field 'translatable' property from table field_config to table field_config_instance

» Make each field instance has it's own translatable property, instead of sharing translatable property with others.

Comment #3

YesCT CreditAttribution: YesCT commented 21 January 2013 at 02:03

thanks for opening this issue. It will be nice to at least have written down some explanation of why translatability needs to stay a global field setting on shared fields.

Comment #4

plach

he/him

Italian

Venezia

CreditAttribution: plach commented 23 January 2013 at 11:56

Issue tags:

-translatable fields

I'm not sure I see what concern @Berdir has wrt making fields translatable per-instance: since the Entity Field API supports per-bundle settings, altough it does not supports cross-entity-type field definitions, we should be able to proceed here. I'd start by making field_is_translatable() and field_available_languages() accept a field instance instead of a field.

Probably there might be some tricky case where we have no bundle available, here we may want to check all the defined bundles for the given entity type and consider the field translatable if at least one of its instances is.

Probably the migration code to make a field translatable will need to be adapted, hence we might want to wait for the Field API to be fully converted to the Entity Field API.

Edit: Also field_entity_field_info() and the DatabaseStorageController will need to be adjusted. Actually this is a pretty advanced task :)