Create configuration provider

[CumpsD]

We need a provider to configure all theme settings

• default page
• supported languages
• 404 page name
• 403 state name
• login page name
• login state name
• translate url template
• token endpoint
• ...

Then we can pull a lot of app.config stuff to gnap.config

[CumpsD]

We also need a basePath variable to use for addPart and localeLocationPattern, which we can configure in the generator, because the base path differs on how you deploy the template

[CumpsD]

We will also need some kind of versioning hook in the gnap code to have the generator work on

[vincentsels]

When locales are being moved to config of provider, also consider using actual locales (nl-BE) instead of just languages (nl) - is there any particular reason these were not used ? Also, consider adding an $http interceptor which uses the current locale (from localeService) as Accept-Language header. Lastly, the API could then set its current thread to this locale (like here, however, mind this). Or should I create a new issue / pull request for all this... :)

[CumpsD]

A new issue to deal with all things localisation would be nice, a PR even more :)

There was a plan to provide an endpoint to figure out the locale of the user, since it's not accessible from JS.

There is no particular reason nl is used instead of nl-BE, although semantically one could argue nl is the fallback culture (at least that's how it is in .NET). Do I think we need to build something this advanced in the UI? To start with, not really ;)

The $http interceptor would be a nice addition, indeed!

[vincentsels]

to provide an endpoint to figure out the locale of the user, since it's not accessible from JS.

How's that ? The localeService tries to get whatever was set in the local storage by the localeSelector directive, and otherwise falls back to whatever's set in the browser (in languageNegotiationService.detectLanguage()) - isn't that sufficient ?

[CumpsD]

If I remember correctly, neither of this actually returns the language the user prefers:

return ((
                nav.language ||
                    nav.browserLanguage ||
                    nav.systemLanguage ||
                    nav.userLanguage
            ) || '');

These variables only contain the language of the browser installation. For example, you can have an English IE, but actually prefer es as a language because you're Spanish.

This information is only available in the HTTP Headers when the browser sends them out, and not accessible with JS. So we would need to have an endpoint which does nothing more than take the HTTP Header and return it as a JSON object so we can parse it on the client and deal with it.

[vincentsels]

Ok, I see, thanks :)