Make it more obvious to those new to the concept of field translation that all instances of the field are translatable

@platch you are right, but for some reason it just did not register for me. Either others will make the same mistake, or I'm just weird :)

I know that if I had seen a bold sentence like: "this will make the body field in Article, Page, Event, and Press Release" translatable, I would have been alerted, if the sentence had been just below the widget rather than at the top of the box, where I'm used to just ignoring it.

Here is a patch. The following strings are changed:

example: FIELD = body, LIST = page, article, event

• users may translate this field => users may translate all instances of FIELD (LIST)
• Enable translation => Enable translation for all instances of FIELD (LIST)
• Disable translation => Disable translation and delete translations for all instances of FIELD (LIST)
• Are you sure you want to enable translation for the FIELD field? => Are you sure you want to enable translation for all instances of the FIELD field (LIST)?
• Are you sure you want to disable translation for the FIELD field? => Are you sure you want to disable translation for all instances of the FIELD field (LIST)?
• All the existing translations of this field will be deleted. => All the existing translations of this field in LIST will be deleted.

Here is one example of what this patch does. (see image)

@platch thanks, you are probably right on all counts. I'm curious to see if there is more interest in this approach. Cheers.

Hi,

Coming up with a new version of the patch has been a bit more of a challenge than I at first thought! Here is why.

Challenge #1: Fields do not have human-readable names

Field instances have human-readable names, but fields do not. Take this example

• Field field_body in Article has the name "Body"
• Field field_body in Page has the name "Main text"
• Field field_body_translatable in Press release has the name "Body"
• Field field_main in Press release has the name "Main text"

In the above example, it does not really make sense to say "All instances of field Body will be deleted".

Challenge #2: Node types are not the only entity types are can have fields

Users, and taxonomy terms, and other entity types can also have fields, so one can have a situation where:

• User accounts (entity type: user, entity: user) have the field xyz
• Taxonomy term abc (entity type: taxonomy term, entity: abc) has the field xyz
• Node type abc (entity type: node, entity: abc) does not have the field xyz
• Node type page (entity type: node, entity: page) has the field xyz

In the above scenario it would be misleading to say "All instances of xyz (user, abc, page) would be misleading because the taxonomy term abc has yxz, but not the node type abc.

Proposed solution

Because fields do not have labels, the machine name will have to be used.
Each field instance is then uniquely defined by its label, entity type and entity.

For examplpe: field machine_name (Body in node Article, Body in node Page, Bio in user User, Description in taxonomy term Tags)

I have removed the warning in disable translations, which makes the whole thing clearer, as mentioned above.

Yes, that's a lot more readable.

I removed the bundle types node and user, but I left taxonomy term; which makes sense for me.

See enclosed image for the results.

Here is a patch

Here is a better one: there were some out-of-date comments in the patch above.

related: #1953672: Make "These settings apply to the field everywhere it is used" clearer

@platch thanks for the feedback. You're probably right: there are some edge cases where the bundle type (node, taxonomy term...) could make things a bit clearer, but it's just not worth the trouble and confusion :)

So here is a patche where I dispensed with the bundle type altogether.

The result can be seen in the enclosed image

Cheers

This one is a bit cleaner. I removed some old code from previous patches in $t_args.

@platch yes that's cleaner, thanks.