Except for the choose dialog workaround FieldDefinitionKeyGenerator optimistically expects the field definition to be a part of a dialog/editor structure, i.e. relies on the presence of Form/Tab definitions in the parent hierarchy.

However, now there are cases when the field is configured not in the scope of any dialog/detail sub-app, but in completely different structures. An attempt to i18n-ize such fields would lead to RuntimeExceptions.

The proposed solution is to not make too much assumptions about the FieldDefinition's parents. We would keep the old logic of generating various dialog-ish keys, but also generate a mere all-parents-name based key in case field is defined elsewhere.