Your concept is a bit weird therefore I have some recommendations for you. I use direct in many projects and most them had the need for localization and rather complex AC-Managements.
- Your app should not have the need to resolve or load something before it even starts.
- Language & localization should be provided the time the main application view get loaded
- Your frontend should never resolve any access control. You can (for most situations) perfectly achieve this with the direct API
- reduce the API to these actions where the user have access (this also happens when the application main view get prepared)
That make your app faster and your life easier.
Update
The time the user login or just request the mainview you should have plenty information like the supported browser language or at least when the user selects a language. With that knowledge you just need to prepare the view.
A acl within a frontend is not secure and need to be rechecked at serverside it should therefore be avoided or simple. The simplest way with direct is to provide a API matching the user access and check for this within the frontend. That is a sort of implicit access control. How to implement this depends on the on the UI, but there are many ways
Update 2
Why don't you provide one build per language? I don't see any reason against it. Or split the framework from your application & classes which allows you to update while the clients can still use the cached framework lib.
The API can be easily checked for controller (backend) access and method (backend) access. Where the controller may be your tab and the actions your menu elements. Cause the API is global available you just need to check if the objects or properties exists. Let's pretend we have a backend-controller named Car
and Method called Drive
we can check for this like
if (Car) {
// has controller access
if (Car.Dirve) {
// has access to the 'drive' action
}
}