httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From André Malo>
Subject Re: svn commit: r1791807 - /httpd/httpd/trunk/docs/conf/extra/
Date Wed, 19 Apr 2017 19:55:34 GMT
* William A Rowe Jr wrote:

> On Tue, Apr 18, 2017 at 3:56 PM, André Malo <> wrote:
> > * wrote:
> >> Author: wrowe
> >> Date: Tue Apr 18 16:25:03 2017
> >> New Revision: 1791807
> >>
> >> URL:
> >> Log:
> >> KISS: RemoveType is a simpler fix for .tr
> >
> > I seem to remember, that removetype does not override mime.types (only
> > addtype entries). But I might be wrong (and did not check now).
> I checked this in 2.4.x-dev branch, chrome could have lied, of course.

Ok, I looked it up. It was changed in 2.3.3. :-)

> >> explain .da files; order our
> >> LanguagePriority by a first-order comparison and drop negligable
> >> translations from our ordered priority preference list entirely.
> >
> > I don't see what problem that's supposed to solve. On the contrary,
> > since the configured negotiation happens per file [1], removing
> > languages, we do provide somewhere does not make sense at all.
> I'm not able to parse your thought here... let me clarify, and then
> please clarify your objection.
> The question of language priority is strictly one of the accuracy of one
> language variant over another.
> That question is largely answered by the browser, given three languages;
> fr q=1 en q=.8 ru q=.2 it says that this guest of your website is fluent
> in French, will comprehend English reasonably well, and can stumble
> through some Russian. So if the French can be served, we will serve it,
> and as all documents exist in English, we will fall back on that.
> The question isn't answered if this is a client with no matching
> languages, if only Estonian is given as a preferred language, we would
> normally serve a list of possible documents. That's foolish so we
> force-override with some sensible choice and an option to toggle between
> languages on every page.
> Where we find et q=1 fr q=.5 es q=.5 ... they will be equally comfortable
> with either French, or Spanish, since Estonian isn't available. Now which
> do we serve? That is where my edit comes in.
> The answer is invariably English because that is the source language.

Ehm? How is the whole negotation mechanism about the source language? Why 
would it care?

> Where equal-weight is given and we have two translations other than
> English to automatically fulfill, it must be the more relevant one.

Why? if it would matter, it would be given differently by the browser. Who 
are we to decide anyway? I would probably pick the first one and it might 
even be in accordance to the RFC (would need to check).

> We can't practically do this on a document-by-document basis

See above. Luckily there's no need to.

> so what is 
> your suggestion for prioritizing the most trustworthy (on our terms)
> translation where the user-agent refuses to give one or the other a
> higher priority?

My argument is about something completely different. It's not about the 
collection of documents, it about you come to the start page, could 
theoretically automatically see the danish variant but don't because it's 
not listed at all.

That's what you just killed, I think.

For the collection as a whole we added the prefer-language variable, which 
we use to give the user a simple choice between her preferred language and 
the source language (fallback).

sub the($){+shift} sub answer (){ord q
        [* It is always 42! *]       }
           print the answer
# André Malo # #

View raw message