The override system doesn't support looking up "dynamic" language keys that do not already exist in the filesystem. I don't know how the fields stuff is stored, but my gut feeling is this would result in pretty expensive lookups within the database to try and support this which might not be practical.

Can it be checked how the issue can be solved?
Either there has to be a language key created on each field creation. Or the table where the Fields are stored has to be included in the search.

The override search has always been based on the existing filesystem. The fields feature might expose this "weakness" a little bit more, but it has never been a search of the source code or the database to find language keys (for example you can't use the override UI to create new plural forms of language strings that support pluralization unless you know the key structure already).

This is not a new issue related to fields and IMO this isn't something that has a simple fix slapped on it.

Since you define the language keys yourself when you define the field, there is no way that the override system can find them. It only exists as a label text in the database.
But then, you already know the key (you just wrote it yourself in the field), why do you want to look it up? Just create the override manually. It's faster anyway ?

That's not something which can be looked up, thus I'm closing this issue.

Ok... well i think that it´s not always the usecase that the person that created the fields want to change the language. And it will be not always like that that there are only 5 fields but maybe 200 But i understand your explanation why it´s not working.

The user can use the search in the override list to find the existing override.