Support for other field types like Link or Table fields

Interesting. I don't think we should add direct support for various field types names provided by other contrib modules, but instead do something more generic, such as provide a hook or plugin type of approach that could add support for such so that module users could plug this into new field types.

The problem might be to know beforehand what kind of field processing would be needed in processElement to enable this kind of pluggable solution. But do you get my idea? Would it be something that you could work on? The plugin approach could be better in a sense that this module could already include plugins for various field types. Or, if it is possible to write the code so that it already supports many kind of fields automatically, then a hook to alter the list of supported field types would suffice. Allowing to add the button for just type of field widget would probably be a bit risky?

jhuhta, thanks for the suggestions. Could you take a look at the changes in the issue fork? Is it close to what you had in mind?

I haven't had time to actually test it and check it properly. What I'd like to avoid though, is hardcoding contrib provided field types there - maybe either have it as an extendable structure or then get rid of of the thing completely and instead try to recognize if this or that field could have the feature enabled. The form mode config form shouldn't add the third party settings to every single existing field though.

jhuhta, I'm not sure if I understood your point correct or not, but your problem is with these plugins only: `ExtLinkBlockListTranslatePlugin` and `TableFieldTranslatePlugin` ? or you mean specifically the field names defined in those plugins ? or even something else entirely?

There is another complexity. Adding the Header widget when using heading module, is not enough to make the translation button work. The reason is that the actual text element is in a sub element called container when we want to access and update the text field through form and formState. I'll add this updated patch as a support for Header widget.
Not sure how we can reflect this in the Fork Issue as the general solution.