You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This bundle features a sophisticated sticky locale implementation, and the sticky locale is applied on routes for which "translation" (i18n) is disabled; see #229 .
It would be great if this functionality could be more configurable. Sometimes I won't want to have cookies being set (see also #210 ), for example. But the thing I'd most like to be able to configure is whether or not Accept-Language request headers are used. They are used in the current implementation, but there are situations in which I'd prefer to use the configured default language rather than rely on the (notoriously unreliable) Accept-Language header.
The text was updated successfully, but these errors were encountered:
gitcerizead
changed the title
Make the "sticky locale" functionality more configurable
Make the "sticky locale" functionality be more configurable
Nov 30, 2018
gitcerizead
changed the title
Make the "sticky locale" functionality be more configurable
Make the "sticky locale" functionality more configurable
Nov 30, 2018
On the other hand, the "stickiness" is achieved solely through the use of a cookie called 'hl', which may be being set in error (i.e. the stickiness feature may be a bug rather than a feature!). See #210 . But even it's decided to remove the stickiness feature, it would still be good to be able to configure how the default locale is determined for a route for which "translation" (i18n) is disabled, as per the description in this ticket.
Feature request
This bundle features a sophisticated sticky locale implementation, and the sticky locale is applied on routes for which "translation" (i18n) is disabled; see #229 .
It would be great if this functionality could be more configurable. Sometimes I won't want to have cookies being set (see also #210 ), for example. But the thing I'd most like to be able to configure is whether or not Accept-Language request headers are used. They are used in the current implementation, but there are situations in which I'd prefer to use the configured default language rather than rely on the (notoriously unreliable) Accept-Language header.
The text was updated successfully, but these errors were encountered: