nrmnrm
commented
2 months ago Ok, I narrowed it down, it is tricky (and unfortunately its already broken in struts 1.3.x). But I think it's still a bug that would be nice to be fixed. It depends on orders. If you start the container and the resources are not filled yet in the formats hashMap inside MessageResources.class it depends if you first load a page with an actual available resource file for a locale and then afterwards load the non available local in another browser. Then this is wrongly assigned to the first filled language (in this case locale german from a first browser start in german although the fall back locale for non existent locales is english)). If you start the container and start directly with a non available locale it defaults to english as fallback locale as supposed to.
Then locales are static cached and nothing changes it again, in both cases.
This worked at least differently in struts 1.3.x:
If your default resource file is called ApplicationResources.properties (all others are called eg ApplicationResources_de.properties) it should fall back to that one in case you have a browser set to a non supported locale (eg if missing ApplicationResources_bg.properties).
In struts 1.5 it resolves to the locale from the server instead to ApplicationResources.properties, which is a strange behavior I would say.
I will try to investigate, maybe I can find out what changed that.