Problem/Motivation

Now after enable MULTILINGUAL modules, i.e, Content Translation, field will have its own translatable setting.
field translatable setting

After add content for a field, we get this field setting.
field translatable 2

The problem is in 'admin/config/regional/content-language', we get field translatable settings too. This could add some confusions. User may not know which UI should be used. And if user doesn't enable content type translatable here, even user has enabled a specifc field translatable in field's setting UI, its setting will be useless. That field can't be translated because the entity/bundle it attached is not translatable.

A more serious problem is, every field UI translatable setting is shared across all field instances. If you go to 'admin/structure/types/manage/article/fields/body/field-settings' and make any changes for Field translation, this setting will be synchronized at 'admin/structure/types/manage/page/fields/body/field-settings', simply because same field body is used in different content types, or field instances share same field translation setting.

See relevant issue at #1893568: Make each field instance have its own translatable property, instead of sharing translatable property with others.

Proposed resolution

Remove field's own translation setting, i.e., remove
function translation_entity_form_field_ui_field_settings_form_alter(array &$form, array &$form_state, $form_id) { }
and remove corresponding field translation page, i.e,
'admin/config/regional/translation_entity/translatable/' . $field_name,

User interface changes

Remove field's own translation setting and menu item 'admin/config/regional/translation_entity/translatable/' . $field_name,

API changes

No api changes

Related issues
#1893568: Make each field instance have its own translatable property, instead of sharing translatable property with others.
#1831608: Show or hide the "Make field translatable" checkbox on the add field form depending on translatability

Files: 

Comments

Issue tags:+Usability, +D8MI

So my understanding is that field instances need to be translatable or not, independently of whether the bundle is translatable. For example, you might have a field that needs to be the same on all translations of a node.

@smiletrl has a good point that this could lead to confusion, so there may be a usability issue here. Tagging for that and for the D8MI folks.

Issue summary:View changes

...converted all links to issues to [#...]