penguinfuz has asked for the wisdom of the Perl Monks concerning the following question:

Hello fellow monks -- I seek all wisdom and advise!

I am serving a website in (2) languages, and wish to do so without requiring the visitor to make the selection. I have shifted the heavy lifting to mod_perl because visitors who have no language support for either of my translations get a nasty 406 error. Limitation of multiviews (as implemented in Apache 1.x).

So... Easy enough with mod_perl <grin>

My request for advise is this:

Which operation would be more costly, checking the contents of $r->header_in('Accept-Language') with a regexp (de and en for example) or just tacking on the default language (with a low quality rating) for all request and forget about it! The website has a considerable amount of traffic and of course I want to keep all access 'snappy'.

Obligatory code example:

...
# Everyone gets English language support added
my $lang = $r->header_in('Accept-Language');
$r->header_in('Accept-Language', $lang . ', en;q=0.20');
return OK;

[download]
Or...

...
# English language added as failsafe
my $lang = $r->header_in('Accept-Language');
if ($lang !~ /en/ || $lang !~ /de/) {
  $r->header_in('Accept-Language', $lang . ', en;q=0.20');
  return OK;
} else {
  return OK;
}

[download]

Replies are listed 'Best First'.
Re: Language Negotiation with mod_perl, Apache
by PodMaster (Abbot) on Jan 30, 2003 at 12:20 UTC
    Have you considered Apache::Language? I can't get it to build on win32 (yet), but it looks useful ;)

    MJD says you can't just make shit up and expect the computer to know what you mean, retardo!
    ** The Third rule of perl club is a statement of fact: pod is sexy.

[reply]
Re: Language Negotiation with mod_perl, Apache
by CountZero (Bishop) on Jan 30, 2003 at 20:31 UTC

    From the Apache 1.3 documentation:

    Variants with no Language

    If some of the variants for a particular resource have a language attribute, and some do not, those variants with no language are given a very low language quality factor of 0.001.

    The reason for setting this language quality factor for variant with no language to a very low value is to allow for a default variant which can be supplied if none of the other variants match the browser's language preferences. This allows you to avoid users seeing a "406" error page if their browser is set to only accept languages which you do not offer for the ressource that was requested.

    For example, consider the situation with Multiviews enabled and three variants:

    • foo.en.html, language en
    • foo.fr.html, language en
    • foo.html, no language

    The meaning of a variant with no language is that it is always acceptable to the browser. If the request is for foo and the Accept-Language header includes either en or fr (or both) one of foo.en.html or foo.fr.html will be returned. If the browser does not list either en or fr as acceptable, foo.html will be returned instead. If the client requests foo.html instead, then no negotation will occur since the exact match will be returned. To avoid this problem, it is sometimes helpful to name the "no language" variant foo.html.html to assure that Multiviews and language negotiation will come into play.

     Wouldn't that solve your problem, rather than fiddling with the headers in the request?

    CountZero

    "If you have four groups working on a compiler, you'll get a 4-pass compiler." - Conway's Law

[reply]
[d/l]
[select]
      WARNING: Comment Contains No Perl

      CountZero, I was not aware that a default 'no language' variant could be returned reliably. I say 'reliably' because my understanding (and _some_ testing) showed that when the client did not list a language that I have translations for, Apache would return the variant based on it's alphabetical order.

      Note that my test included file names such as:

      index.html.de
      index.html.en

      And then I simply request index.html and let multiviews run. As described above, if I understand correctly, I could have files like:

      index.html.de
      index.html.en
      index.html

      And simply link to the pages like <a href="index">Go Here!</a> Unfortunately I have way too many links that would need to be modified for this to work. Hence the request header fiddling! ;)
[reply]
[d/l]

        It is even a bit more involved than that: you would really like to have a file called index.html.html to avoid that someone requests index.html and does not trigger the multiview-feature.

        Of course, you could write a Perl-script that modifies your links. (There now this comment has a Perl-content ;-) )

        CountZero

        "If you have four groups working on a compiler, you'll get a 4-pass compiler." - Conway's Law

[reply]
[d/l]
[select]
Re: Language Negotiation with mod_perl, Apache
by Jaap (Curate) on Jan 30, 2003 at 12:16 UTC
    It would be really helpfull if you posted more code. Especially what you do further with the $r object. Why do you want to set header_in?
[reply]
      Jaap: It would be really helpfull if you posted more code. Especially what you do further with the $r object.

      Actually, there is not much more code to post in this example. Except the normal, use statments, and I am doing nothing more with the $r object.

      Jaap: Why do you want to set header_in?

      Because a browser that has support for only one language, lets say "zu", cannot be handled properly by Apache's multiviews directive. (The multiviews directive has been extended to address the issue in Apache2, but upgrading is not an option for me at the moment) I am intercepting the headers, and adding a default language support of "en" then passing the request on to Apache -- The web server never knows the visitor's browser does not have English language support, and multiviews can do the negotiations.
[reply]
[d/l]

Back to Seekers of Perl Wisdom