Crunchy should forward Accept-Language HTTP header

[GoogleCodeExporter]

Some websites use the HTTP header Accept-Language to display their content
in the preferred language of the user.

An example is the toolbar of a MoinMoin wiki: links like "edit" are
translated in the language of the user.

Because crunchy doesn't send this header when it get remote pages, they may
not be in the expected language.

Crunchy should send the same Accept-Language that it receive from the
browser who asked the page to crunchy.

Original issue reported on code.google.com by florian....@gmail.com on 25 Jun 2008 at 3:39

[GoogleCodeExporter]

Good usability suggestion.

If doing so, we should add a new configuration choices used by Crunchy so that 
this
can be overriden (for example, for testing purpose).

Changing labels...

Original comment by andre.ro...@gmail.com on 25 Jun 2008 at 7:59

• Added labels: Type-Enhancement, Usability
• Removed labels: Type-Defect

[GoogleCodeExporter]

Original comment by florian....@gmail.com on 27 Jun 2008 at 12:35

• Changed state: Started

[GoogleCodeExporter]

I've added (in my branch) the forward of Accept-Language (in
plugins/handle_remote.py), but for the moment without configuration choice 
(I'll add
it). It works, tested with a MoinMoin wiki and some sites like
http://www.mozilla-europe.org/ which use Accept-Language to choice the content 
to
display.

However, this is done only if there is no preprocessor used: they have their 
own way
to retrieve remote data. Of course, it's possible to put the same code in
preprocessor plugins, but it could be interesting to have a central way to get 
remote
content, before send it to preprocessor, isn't it?

Original comment by florian....@gmail.com on 27 Jun 2008 at 12:59

[GoogleCodeExporter]

I'm not sure I understand.  I thought if Crunchy sent the Accept-Language info, 
it
would get back a page (if available) in the preferred language; from that point 
on,
it would process the page as usual and display it.

To put it in concrete terms, the way I thought this worked:

From a normal browser (no Crunchy involved):
1. I set my preferred language(s) in my browser option.
2. I type in a url (or click on a link) for a website that works with multiple 
languages.
3. My browser sends in the Accept-Language info as part of the header.
4. The website sends back the appropriate page based on my language choice.

Now, using Crunchy.
1. is unchanged.
1.a) I *may* want to set up Crunchy so that it also gives feedback in the same 
language.
2. Unchanged, except that the request first goes to Crunchy.
3. Crunchy, and not the browser, forwards the request to the web site.
4. The website sends back TO Crunchy the appropriate page based on the language 
choice.
4a.) Crunchy processes the page as usual and displays the content.

What am I missing?

Original comment by andre.ro...@gmail.com on 27 Jun 2008 at 2:00

[GoogleCodeExporter]

Your are missing that currently, handle_remote.py work like that:

3a.) The page doesn't need to be parsed by a preprocessor (the choice is made 
with
the extension of the url)
3a1.) Crunchy, and not the browser, forwards the request to the web site.
3a2.) The website sends back TO Crunchy the appropriate page based on the 
language
choice.
3b.) The page need to be parsed by a preprocessor (like for rst files)
3b1.) The preprocessor get the url, and do it's job (getting the file and 
convert it)
4.) Crunchy processes the *html* page as usual and displays the content.

So it's the preprocessor plugin which get the file (local or remote). It should 
have
more sense to get the file before, and next send it to the preprocessor, or - at
least - to have a common function to get (local or remote) files for all
preprocessors plugins, that they could use or not.

I'm writing the configuration code. I think this should be enabled by default, 
since
the user expect the same content in the website that outside crunchy. Any 
though?

Original comment by florian....@gmail.com on 27 Jun 2008 at 2:12

[GoogleCodeExporter]

ok, I get it.  It all sounds good.

It would be useful to write a simple html page with links to websites, like
http://www.mozilla-europe.org/, that are known to deliver pages based on user's
preferences as a test.  This page could contain a brief description of how to 
set
this language choice in Firefox  (I have done so once before I *think* ... but 
most
people would only do that once and forget how to do it --- just did it again:
outils/options/contenu/langue ... I guess it would be 
tools/options/content/language).

Eventually, we could have also our own internal tests with a few pages that 
would be
part of the Crunchy distribution and would be available in different 
languages...

Original comment by andre.ro...@gmail.com on 27 Jun 2008 at 2:36

[GoogleCodeExporter]

I've committed the configuration stuff. Tests are still needed. For 
handle_remote.py,
tests are currently done with a local file, which isn't possible to test HTTP 
headers...

For preprocessors, I'll fill another issue.

Original comment by florian....@gmail.com on 27 Jun 2008 at 3:40

[GoogleCodeExporter]

I've also written the html page. I guess /server_root/functional_tests/ is the 
best
place to put it.

Original comment by florian....@gmail.com on 27 Jun 2008 at 4:15

[GoogleCodeExporter]

Thanks for this (writing the html page).  The location you suggest is the right 
one.
 I intend to incorporate it in the trunk as soon as I can.

Original comment by andre.ro...@gmail.com on 27 Jun 2008 at 4:20

[GoogleCodeExporter]

Incorporated in the trunk.  Considered fixed.

Original comment by andre.ro...@gmail.com on 27 Jun 2008 at 9:51

• Changed state: Fixed