Malte - I don't see any other reason why an administrator would want to _force_ the navigation of a subsite to be in another language than the one selected by the user, other than to somehow deal with the problem that you describe in this document:
http://www.sussdorff-roy.com/resources/internationalization (Summary: character encoding of the navigation is not displayable in the character encoding of the content, thus the character encoding of the navigation must be changed.). Although in the solution you describe, the language is altered automatically by the system when needed, not by the admin, so maybe you had something else in mind.
I would agree though that the default language - the fallback in case the language preference of a user could not be determined - should be configurable on a subsite level, not site-wide as I suggested above.
The solution of the problem that's described in that document - character encoding clash between navigation and content - by switching the navigation to english because it's displayable in all character encodings is very cool. For a general openacs solution though I would want the server to alternatively be able to return the page in unicode if the client supports it, especially because the availability of unicode browsers is propably increasing, and because users who manage to navigate to a page that contains different languages are more likely to have a unicode enabled browser installed.
