httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From William A Rowe Jr <wr...@rowe-clan.net>
Subject Re: svn commit: r1791807 - /httpd/httpd/trunk/docs/conf/extra/httpd-manual.conf.in
Date Wed, 19 Apr 2017 20:47:32 GMT
On Wed, Apr 19, 2017 at 2:55 PM, André Malo <nd@perlig.de> wrote:
> * William A Rowe Jr wrote:
>
>> >> 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?

First, you should be aware, this change did *not* affect browser-hinted
or explicit selection of languages. Again, this change only affects those
equal-weight or no-matching language scenarios. The ONLY purpose
for the ForceLanguagePriority directive is to direct the mime handshake
to suggest one document over another based on the accuracy or the
timeliness of the material, something only we, the authors, are aware of.

The English document is the primary source. All other translations are
either entirely up-to-date with respect to the English source document
or have fallen out of date by one or more edits to that document.

>> 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).

Exactly, if the browser (user) has a preference it was expressed by the
accept languages list, and we serve what the user requests.

When the user requests only languages we cannot provide, then the
ForceLanguagePriority kicks in. The alternative is to serve a list of the
available documents.

>> We can't practically do this on a document-by-document basis
>
> See above. Luckily there's no need to.

Yes, there is.

>> 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.

Nope. the patch didn't kill it. Screencaps below. Not only will 'da' be
selected, but not all translations were listed in the previous priority
list, they never needed to be. Whatever the browser requests which
we can honor, we still honor. This is a fallback and a default when the
browser hasn't told us enough information to make the decision for us,
or provided conflicting instructions without weighting the preferences.

Please re-validate your assumptions before we proceed with this
discussion. I'll be interested in your findings.

> 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).

You seem to be under the mis-impression that this change eliminated the
less-than-comprehensively covered languages. It did no such thing.

Mime
View raw message