Once added to a project or to the server instance as a whole, languages cannot be removed. This is inconvenient if you've added the wrong locale, etc.
Luke Brooker commented:
I would say it was implemented this way as removing a language that is currently in use would be difficult. But, in most cases, deleting a language would be required directly after it was entered incorrectly.
In the future, we are looking at making all known languages available to the instance by default and you would only need to enter custom languages.
So in that case, deleting custom languages would be a requirement and other languages should just be disabled.
I'd say we should probably make this interface similar to the new project/version language settings where disabled and active languages are 2 separate lists and mass activating/disabling in bulk is much easier.
Would the above solution solve your instance language configuration problems?
Steve Kowalik commented:
We are certainly not looking for the requirement of removing a language that is in use – this would be to clean up if it was entered incorrectly, as you say.
I'd agree that the global languages interface should be similar the project languages interface – which does have the ability disable languages. If your plan gives us that ability, as well as mass activation/disabling that sounds like a win.
Languages can already be disabled (as of 3.7):
navigate to the locale via the Languages heading
open the settings tab
uncheck "Enable language"
Disabled languages are only visible to admin users.
The quick fix for disabled languages cluttering the admin language list view is to add a filter selector to the languages list (e.g. a dropdown) with the following options
This selector would only be visible to admin users.