Problem/Motivation
Now after enable MULTILINGUAL modules, i.e, Content Translation, field will have its own translatable setting.
After add content for a field, we get this field setting.
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 →