Agree - we should never have KEYS with the same name in different language files

You mean same value I guess.
But some maybe necessary to let customise depending on languages.
In this case there is no customisation possible (or even desired).

We could for example use
<option value="safehtml">COM_FIELDS_PARAMS_FILTER_SAFEHTML</option>
instead of
<option value="safehtml">PLG_FIELDS_EDITOR_PARAMS_FILTER_SAFEHTML</option>

oops sorry - was reading on my phone i thought these had the same key

In this case I guess its ok to use a generic string but its something to be careful with for others as they might be translated differently depending on the context - although they wont be here

That's why I wrote

In this case there is no customisation possible (or even desired).

I don't think com_fields.ini is the right place to add it. You would have to load com_fields language files when editing the plugin parameters.
You may add it to the en-GB.ini or the lib one (if that one is loaded at that place always). For the filter options, this may make sense as they basically are referring to a library class method.

But there is something wrong for sure as https://github.com/joomla/joomla-cms/blob/staging/plugins/fields/editor/params/editor.xml#L41-L57 is using the language strings from the "text" field, not the "editor" ones. Looks like a copy-paste error ?
Will do the PR for that.

@Bakual
As far as I could see with debug language, com_fields.ini is always loaded when custom fields are edited. xx-XX.ini is always loaded as well as xx.XX.lib.joomla

**Loaded** : JROOT/administrator/language/en-GB/en-GB.ini
**Loaded** : JROOT/administrator/language/en-GB/en-GB.lib_joomla.ini
**Loaded** : JROOT/administrator/language/en-GB/en-GB.plg_system_updatenotification.ini
**Loaded** : JROOT/administrator/language/en-GB/en-GB.plg_system_fields.ini
**Loaded** : JROOT/administrator/language/en-GB/en-GB.plg_system_logout.ini
**Loaded** : JROOT/administrator/language/en-GB/en-GB.tpl_isis.ini
**Loaded** : JROOT/administrator/language/en-GB/en-GB.com_fields.ini
etc.

I would prefer to use com_fields ini as we have other strings in the same case. for example these with the value "Use From Plugin", 9 of them...

en-GB.plg_fields_editor.ini:23: PLG_FIELDS_EDITOR_PARAMS_USE_GLOBAL="Use From Plugin"
en-GB.plg_fields_imagelist.ini:14: PLG_FIELDS_IMAGELIST_PARAMS_USE_GLOBAL="Use From Plugin"
en-GB.plg_fields_integer.ini:16: PLG_FIELDS_INTEGER_PARAMS_USE_GLOBAL="Use From Plugin"
en-GB.plg_fields_media.ini:16: PLG_FIELDS_MEDIA_PARAMS_USE_GLOBAL="Use From Plugin"
en-GB.plg_fields_sql.ini:12: PLG_FIELDS_SQL_PARAMS_USE_GLOBAL="Use From Plugin"
en-GB.plg_fields_text.ini:17: PLG_FIELDS_TEXT_PARAMS_USE_GLOBAL="Use From Plugin"
en-GB.plg_fields_textarea.ini:21: PLG_FIELDS_TEXTAREA_PARAMS_USE_GLOBAL="Use From Plugin"
en-GB.plg_fields_url.ini:12: PLG_FIELDS_URL_PARAMS_USE_GLOBAL="Use From Plugin"
en-GB.plg_fields_usergrouplist.ini:10: PLG_FIELDS_USERGROUPLIST_PARAMS_USE_GLOBAL="Use From Plugin"

As for editor, yep, I really wondered why telephone (to take only one example) was a filter for editor... ;)
I guess we need there: No, Use From Plugin, text, safehtml, raw

In another PR, we should add separately the possibility to choose the editor and syntax

Therefore, if you agree, I will make the patch using com_fields.ini

Or
we could add the "Use from Plugin" in com_fields.ini as it is specific to custom fields
and the others in lib rather than xx-XX.ini as lib is loaded both in front and backend and indeed could be used in the future for other stuff.

If used in lib we would have:

JLIB_FILTER_PARAMS_RAW="Raw"
JLIB_FILTER_PARAMS_SAFEHTML="Safe HTML"
JLIB_FILTER_PARAMS_TEXT="Text"
JLIB_FILTER_PARAMS_ALNUM="Alpha Numeric"
JLIB_FILTER_PARAMS_INTEGER="Integer"
JLIB_FILTER_PARAMS_FLOAT="Float"
JLIB_FILTER_PARAMS_TEL="Telephone"

What wonders me more is why is the com_fields language file loaded when editing a plugin?

@infograf768 the JLIB strings do make sense IMO. Would go that way.

What wonders me more is why is the com_fields language file loaded when editing a plugin?

Well, happily it does as we already have global strings there:
Example

COM_FIELDS_FIELD_DEFAULT_VALUE_LABEL="Default Value"
COM_FIELDS_FIELD_DESCRIPTION_DESC="A description of the field that will be displayed in the label tooltip."

These strings should only be used when editing a field, but not the plugin.

Indeed, that's why the params above have to go into the lib to be sure they are loaded.
The global strings are not used for the plugins.
Therefore those with "Use from Plugin" can be safely change to a global one in com_fields.ini

Doing patch today

@infograf768 You can't use com_fields because those strings are used in two places. Once when you create/edit a field (here com_fields is loaded). The other place is in the plugin options itself and there com_fields has no business at all. Thus it would fail.
That's what @laoneo and me meant ?

Closed as we have a patch: #14683

That's what @laoneo and me meant

Yep, I understood. That's why I just added one string to com_fields. ?