Hi. I was talking about this with @roland-d about this on Saturday night. Could you please explain all the type of checks you would like to see and the benefit of each.

What I am thinking about is a list with all the overrides (constants) with the value of the override and the current value of the variable (original text).
It is more or less the same as the view as it is now, without the filter and showing also the text from the original developer (Joomla or Extension builder).
It must give the option to delete the override (if I notice it is the same as original text now, or the original constant does not exist anymore)
It must give me the option to edit the override (while I also see the text of the original constant).
This way I can remove overrides which don't exist anymore or edit/delete overrides which are changed in time.
if someone has more ideas....

Not really the most practical thing to pull off. For templates, it's a relatively easier check to make (you can check modification timestamps, file checksums, assume source file paths based on the override file path, etc.), but because of the way Joomla "lazy" loads each language file you couldn't sanely do a post-update check of every constant in your override INI to check for changes (two immediate issues include that some strings take advantage of the fact that loading a file after another one can overwrite a constant, a quirk used in components to override certain strings from the <lang>.ini or <lang>.lib_joomla.ini files; and the override INI files have no information about what constant they're overriding so you'd need to add requirements for that file to put comments above each constant specifying the source if you wanted a verifiable reference).

I spent quite a bit of thinking time today on this and like @mbabker I can't think of a sensible way to achieve this

I also thought about it and agree with @mbabker and @brianteeman for reasons which @mbabker explained above.

A couple of years ago I was toying with the idea of having a plugin that caches a compiled Joomla\CMS\Language\Language instance which eliminates the need to read all of the language files on each request if the files are already in the cache. The plugin conceptually works, but it ultimately runs into the same problem with the load order of files and constants being overwritten as a result that made me basically give up on that idea. So even if you were able to shove constant metadata into the override file as comments on each thing (source file at a bare minimum), you still ultimately end up running into the overwrite issue at some point without doing a raw filesystem diff and avoiding use of the Language API to pull in everything to a monolithic Language instance.

Maybe some of the work George and I did on the Framework's Language package (specifically the bits about extracting the message catalogue from the Language class to its own class (with a notion of fallback catalogues instead of a single catalogue that gets overwritten, perfect for the "my site is in German but English files are still loaded as the default language" scenario) and extracting the file parser API from the Language class) could help someone put something together. But ultimately without a source file to compare against it's going to blow up pretty badly thanks to the lazy loading and overwriting that happens now.

I don't think you understand what I want. I don't want an automated check.
I don't think there are much language overrides in a site. It is not as important als template overrides, which can disturbe your site.
I would be glad if the present information is changed:

The filter must contain 'Show all', which shows all the language overrides (all ectensions and all languages).
Below the 'Text' of the Override I would like to see the present text of the language variable. This way I can manualy delete a override if it is equal to the origin and edit it when the origin is changed.
If I edit the override variable I want to see the present variable.
Again: No automated check!

Ah - we misunderstood

This sounds similar to #22259

Both of which seems a good idea to me although the comments from @infograf768 on that issue state that it is not possible

Below the 'Text' of the Override I would like to see the present text of the language variable. This way I can manualy delete a override if it is equal to the origin and edit it when the origin is changed.

That bit runs into the problems with the load order of files and constants. It is hardcoded into the Language class that the overrides file be loaded when it is instantiated and it is loaded into a separate array from the main message catalogue, then when a language file is loaded basically the new file is merged over the message catalogue then the overrides merged back in on top of that. So there is not a way using the API to show both the text of an override AND its original text (again the original text bit requires that the system knows where the original came from and that is information that is not stored anywhere at present), the closest practical solution as far as code goes to dealing with that is using the extracted API logic from the Framework package since using the catalogue and parsers standalone from the main Language class will let you assemble a message catalogue with the source information without it being "polluted" by the hardcoded override logic.

Some aspects could be done for the list, after a full refactoring of the overrides.
Please read #22259 (comment)

If that refactoring is done, we "could" get new ways of filtering to display in the list all overrides with a "Show All" and filter separately or not by Language, Client and even Constant.

But that would not solve your expected result, i.e. get a Warning if the original language string is removed or changed. as @mbabker rightfully explains.

Also the same constant may have different values depending from which component they are loaded. Example JLIB_RULES_SETTING_NOTES
Let's not forget also that we may have NO original value for a constant which string is created in the override file as some constant may be for example the Title of a custom field, or other similar situations.

Closing this due to not receiving required information to determine if this is a bug or not. If you feel this still needs review, please open a new tracker entry with as much information as possible to ensure it can be reviewed properly

This was not a bug report - it was a feature request

@brianteeman if this is a feature request from this far back and was tagged as "information Needed". Then something was missing at some point. Maybe it isnt the right status now, but no follow up as been completed and if it needs a different state then someone who felt it was a viable feature could have changed it to "confirmed" so someone can start a PR.

I have experience of something like this with a custom component and multiple languages. For the request here I think the solution needs a couple of tables, one for the joomla strings and one for the overrides, both with last update dates. Should this be a third party extension rather than a core feature? And is it a site specific solution - something to run after an update? Something for an Ideas page (do we have one)?

I would like to see a more robust language override system where I can track that the original strings were changed but also which ones are even still in use and also track changes between the languages. For example, if I have 7 languages and I change the overrides from 3 of them to have a check to change the other 4 languages as well.

This needs more discussion and definition what we want to achive and what can be done. Moving it to dicussion.