NAME

Apache::LangPrefCookie - Override the request's Accept-Language HTTP-Header with a preference provided by a Cookie.

SYNOPSIS

PerlInitHandler  Apache::LangPrefCookie

# optionally set a custom cookie-name, default is "prefer-language"
PerlSetVar LangPrefCookieName "mypref"

<Location /foo>
   # This also work inside container directives. But you might not get
   # what you want if you set it *both* in- and outside containers.
   PerlInitHandler  Apache::LangPrefCookie
   PerlSetVar LangPrefCookieName "foo-pref"
<Location>

DESCRIPTION

This Module looks for a cookie providing a language-code as its value. This preference is then squished into httpd's idea of the Accept-Language header as if the Client had asked for it as #1 choice. The original preferences are still present, albeit with lowered q-values. Apache::LangPrefCookie leaves the task to set/modify/delete such a cookie to you, it just consumes it :-). However, the cookie's name is configurable, as described in the Example below.

Its then up to httpd's mod_negotiation to choose the best deliverable representation.

WHY?

We are cheating on RFC-2626 with this. I have somewhat ambivalent feelings towards that, so bear with me for some words of justification:

In theory a user-agent should help its users to set a reasonable choice of language(s). In practice, the dialog is hidden in the 3rd level of some menu, maybe even misguiding the user in his selections. (See http://ppewww.ph.gla.ac.uk/~flavell/www/lang-neg.html, especially the section Language subset selections for examples.) But this is probably the wrong place to rant over this.

I dislike solutions involving virtual paths, as they lengthen some and generally increase the number of URIs for a given resource. (See http://www.w3.org/TR/2004/WD-webarch-20040705/#avoid-uri-aliases).

There might be demand to switch for a given site once (not for every single document as with explicit links to the other language variants of the page in question, which still works despite our cookie, by the way), without touching the browsers configuration. There also are scenarios where one wants to let users express a different preference just for certain realms within one site.

This approach would work with all Accept* headers. I decided against implementing a general solution for all of them, because (1) I want to keep this as focused and simple as possible and (2) I just don't see a real need for it.

The bottom-line: This Module might be useful to scratch a specific itch, if, and only if there is one ;-)

EXAMPLE COOKIE

prefer-language=x-klingon;expires=Saturday 31-Dec-05 24:00:00 GMT;path=/

Optionally, the default cookie name prefer-language can be overridden by setting the LangPrefCookieName variable:

PerlSetVar LangPrefCookieName "mypref"

mypref=x-klingon;expires=Saturday 31-Dec-05 24:00:00 GMT;path=/

BUGS

  • I haven't even looked into mod_perl2 yet, so this module might not work with it.

  • This should be a native C module for httpd.

  • Apart from these: This is first public release, so I'm not aware of any other bugs at this time.

SEE ALSO

mod_perl(3)

http://httpd.apache.org/docs/1.3/content-negotiation.html

http://httpd.apache.org/docs/1.3/mod/mod_negotiation.html

http://ppewww.ph.gla.ac.uk/~flavell/www/lang-neg.html

http://www.w3.org/TR/2004/WD-webarch-20040705/#avoid-uri-aliases

AUTHOR

Hansjoerg Pehofer, <hansjoerg.pehofer@uibk.ac.at>

COPYRIGHT AND LICENSE

Copyright (C) 2005 by Hansjoerg Pehofer

This library is free software; you can redistribute it and/or modify it under the same terms as Perl itself, either Perl version 5.8.7 or, at your option, any later version of Perl 5 you may have available.