tboronczyk / localization-middleware Goto Github PK

I really like the idea of this implementation, but I'm struggling a bit with incorporating it into my system. What I'd like to be able to do with it is:

• Set the locale very early in the middleware queue based on cookie or header
• Override that locale selection using a per-user setting, but this must be done later in the queue after authentication has been done
• Set the cookie only in the case of a per-user setting, not when the locale is chosen based on the header
• Unset the cookie as the queue unwinds, if the user logged out

As far as I can tell, this can only be accomplished with a combination of:

• two separately-configured copies of the middleware inserted at different places in the queue
• changing the logic to allow for a default not to be set (can be done now in the locale callback)
• allowing for the locale callback to return an indication that the cookie should not be set (I guess I could do this by throwing an exception in my callback, and wrapping the call to the middleware in a function that catches and ignores this exception, but that just really feels kludgy)

So, my question is, is there a clean way to do what I'm thinking of already and I'm just missing it? If not, does some of this sound generally useful if I were to do a PR?

This middleware currently requires Slim 3 because concrete type are used. The Slim types should be replaced with their PSR-7 interfaces to allow the middleware to be used with other frameworks.

An error occurs when there is locale set (via params, cookies, etc.) and no Accept-Language header present. The expected behavior in this case is the default locale is returned.

The method LocalizationMiddleware::__invoke() uses MessageInterface::withHeader() method and overrides the http headers set before. Probably MessageInterface::withAddedHeader() should be considered to use instead?