Enable field name translations to use "Custom translations"

[rijkvanzanten]

Discussed in #19226

^{Originally posted by ruihildt July 24, 2023}

Summary

Custom translations are useful because you can centralize all translations in the same place.

Basic Example

No response

Motivation

Unfortunately, field name translations can't use the Custom translations.
So sometimes you will have to duplicate translations, and not every translations will be centralized in the same place.

Detailed Design

Next to the "Create new" button (or instead), add the translation icon to make it possible to select an existing custom translation

Requirements List

Must Have:

• easy pick from the Custom translations

Drawbacks

No drawbacks. :)

Alternatives

Don't do anything and keep the issue unsolved.

Adoption Strategy

If you already have translation, I guess it would be nice to offer to add them to the Custom translations.
Ideally this could be automated.

We could imagine to auto-migrate all existing Field name translations, and use as the translation key the field key, and if there's already something with that key, add a simple increment (so field_1, field_2, etc.).

Unresolved Questions

No response

[Nitwel]

How would we approach this database whise as right now we store field translations in JSON. Changing that to string sounds like the optimal solution but would screw up existing implementations. Adding a new colum to fields sounds overly complicated. 🤔

[rijkvanzanten]

Adding a new colum to fields sounds overly complicated. 🤔

I think we should do this! Just have a single "display name" column that's either a regular string, or one of those $t: strings that uses the custom translation naming.