* William A Rowe Jr wrote:
> On Tue, Apr 18, 2017 at 3:56 PM, André Malo <n...@perlig.de> wrote:
> > * wr...@apache.org wrote:
> >> Author: wrowe
> >> Date: Tue Apr 18 16:25:03 2017
> >> New Revision: 1791807
> >>
> >> URL: http://svn.apache.org/viewvc?rev=1791807&view=rev
> >> 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.
Hmm.
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).
Cheers,
--
sub the($){+shift} sub answer (){ord q
[* It is always 42! *] }
print the answer
# André Malo # http://pub.perlig.de/ #
