Make Entity Extra Fields translatable

Most of the other types beside "Token" don't seem to be that important to be translatable, but it also wouldn't do any harm, I think.

Maybe using translatable schema types is a good first step to give it a try. Additionaly we'll then have to add the *.config_translation.yml for the UI?
https://github.com/erpushpinderrana/config_translations_example/blob/mai...

@Grevil could you give it a try? I'll show you an example where it affects us.

@anybody, I think that I might be misunderstanding what you want from this issue. Do you want the extra fields to be translatable within their config (on the “Manage extra fields”) page, or within a content entity form (when editing a content entity with extra fields)? As far as the second one goes, I don't think that there is a universal option for doing this with every entity, because this requires the entity to be translatable as well. Also, I'm a bit confused since you appear to want the second solution, but your talk about a config_translation.yml seems to lean toward the first solution.

TL;DR: Could you clarify what you want to be translatable specifically?

@lrwebks: The first one!

... to be translatable within their config (on the “Manage extra fields”) page, or within a content entity form (when editing a content entity with extra fields)?

Extra fields are not even editable on the content level, AFAIK. They are "static" fields, if I'm not totally mistaken.

I've run into a bit of a problem just now:

Usually, when trying to translate standalone config entities (not attached to any other entity or something similar), all edit forms of that entity will have the same route name (e.g., entity.my_config_entitiy.edit). You can then use that route in the config_translation.yml and the work is done.

This module however (and I think that this is custom coded) modifies the route names of the extra field entities to signify what entity they are attached to (e.g., entitiy.some_base_entity.entity_extra_fields.edit). That makes translation impossible (in a simple fashion) as far as I know. Why? Because the config translation system is build upon the former of the two approaches and expects static route names (no wild cards) in the translation routes within config_translation.yml.

It might still be possible to solve using code and not YAML, but I was unable to find any suitable approach online and via AI, and for that matter, any approach at all.

@anybody: What shall we do now?

Thanks @lrwebks I think it should be similar to how translation of field formatters and field widgets work?

At least the schema structure looks similar:

entity_extra_field.extra_field.*.*.*:

But I have to admit that I also don't know how to implement that correctly, yet. Let's see if someone know the answer!

config changes already look good!