On Thu, Nov 17, 2005 at 08:26:36AM -0500, glyph@divmod.com wrote: | On Thu, 17 Nov 2005 13:23:26 +0100, Aleksandar Erkalovic wrote: | >will i be forced to carry my language flag around in my data model and | >learn my loaders and renderers to get from data model what template to | >load or maybe you guys are thinking that Request object could be used | >to carry this kind of information? The acceptable languages that the _response_ is allowed to take can be found in the 'Accept-Language' header. This has the advantage of allowing more than one language choice, eighted by preference and typically auto-configured by your browser from the operating system defaults. In most browsers this setting can be changed; for example, in Firefox go to about:config and navigate to intl.accept_languages. That said, if you have an authenticated user, you might want to provide a server-side override mechanism so that people using an internet cafe' in a foreign country are given their primary language. However, this is more of a 'Avatar' property. You can use a path segment to do this I suppose; but it is not standard and is quite ugly [1]. | This is a good use case, but your language flag *should* be in your data | model. It's simply a mistake to put it in the context. For example: | user A (who speaks en_US) is browsing your site. They perform an action | which impacts user B (who speaks fr_FR). You need to generate an email | to user B. You look at the context: I guess the email should be in | english (whoops!). This is totally unrelated. Of course, if an action is going to be carried out _beyond_ the response; then the application needs to know about the users and respond appropriately. *winks* Best, Clark [1] On a related note, I use a generic PathArgs resource that "consumes" path segments that have an equal sign in them. This resource then modifies the cookies of the incoming request as if they were sent via a Cookie header. The advantage of this approach is that an arbitrary number of /key=value/ path segments can occur in the top of the URL if the browser doesn't support cookies. Then a SessionManager resource sits right below the PathArgs and looks for the 'session' cookie, etc.