Hi,
I am really repeating an old problem I have found and can repeat and fix but don't really understand.
I have a DNN implementation (4.4.1) for which I don't want to use en-US but which I do want en-GB and es-ES.

I set it up as normal, add en-GB and es-ES and disable en-US on my portal.
I use apollo but I'm fairly sure that is irrelevant.

When I switch between en-GB and es-ES with my language selector, the module content changes, but the framework does not (my host language is spanish as is my locale and explorer language - the framework stays in Spanish).

If I delete the en-US entry in the locales.xml then it works just fine - this is a solution for me, but it wouldn't be if I also wanted en-US on any of my portals.

I have reported this before here

Anybody have any ideas as to what is happening here?

Thanks Vicenç,
But isn't it a hole in the DNN support of locales?  The concept of a fallback locale seems emminently sensible and the values are there in the support files, just not in the implementation - I speak from ignorance, but it doesn't sound like a major change to get it to work correctly. 

It would seem a major overhead to have to install a complete new language pack just to be able to get dates to display correctly.

But if I don't have the locale disabled the my drop down shows Spanish, English and English.

It's not a very elegant solution!!

I don't want the locale en-US I just want it as a fallback.

The documentation states:-

When a translation isn’t available in a particular resource file, we fallback onto another resource file to try to get
the translation from there.

and the bottom of the stack is the system language en-US, so unless my configuration is wrong something isn't working properly.  I'm happy to try raising it in Gemini, but I don't agree with your interpretation of the problem