You are viewing a plain text version of this content. The canonical link for it is here.
Posted to docs@httpd.apache.org by André Malo <nd...@perlig.de> on 2017/04/18 20:56:33 UTC
Re: svn commit: r1791807 - /httpd/httpd/trunk/docs/conf/extra/httpd-manual.conf.in
* wrowe@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).
> 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.
Please revert.
[1] if you do not specifically select a preferred language via the path
magic
Cheers,
--
Treat your password like your toothbrush. Don't let anybody else
use it, and get a new one every six months. -- Clifford Stoll
(found in ssl_engine_pphrase.c)
---------------------------------------------------------------------
To unsubscribe, e-mail: docs-unsubscribe@httpd.apache.org
For additional commands, e-mail: docs-help@httpd.apache.org
Re: svn commit: r1791807 - /httpd/httpd/trunk/docs/conf/extra/httpd-manual.conf.in
Posted by William A Rowe Jr <wr...@rowe-clan.net>.
On Tue, Apr 18, 2017 at 3:56 PM, André Malo <nd...@perlig.de> wrote:
> * wrowe@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).
Refusing to trust chrome, with the most recent conf change, from netcat I see...
HEAD /manual/tr/index.html.tr.utf8 HTTP/1.1
Host:localhost
HTTP/1.1 200 OK
Date: Tue, 18 Apr 2017 22:37:19 GMT
Server: Apache/2.4.25 (Unix) PivotalWebServer/6.2.3
OpenSSL/1.0.2j-fips mod_bmx/0.9.6
Last-Modified: Wed, 06 Apr 2016 11:34:46 GMT
ETag: "2423-52fcf59454180"
Accept-Ranges: bytes
Content-Length: 9251
Content-Type: text/html; charset=utf-8
Content-Language: tr
Re: svn commit: r1791807 - /httpd/httpd/trunk/docs/conf/extra/httpd-manual.conf.in
Posted by William A Rowe Jr <wr...@rowe-clan.net>.
On Wed, Apr 19, 2017 at 2:55 PM, André Malo <nd...@perlig.de> wrote:
> * William A Rowe Jr wrote:
>>
>> 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.
So hopefully, in re-testing you observed that the danish page was served,
the lack of listing has no effect when the language is requested by the
browser -unambiguously-.
I found one edge case reviewing your concerns again, and that was the
odd case where pt-br and da were both accepted -with equal weight-,
and because they were not in the ForceDefaultLanguage list, some other
language would be elected. That was my bug.
This is now fixed by adding back pt-br, da and ru to the list. Does this
address your remaining technical concerns? If you are observing any
other problems, could you please share the reproduction case so that
I can work out any defects in mod_mime or mod_negotiation?
Cheers,
Bill
---------------------------------------------------------------------
To unsubscribe, e-mail: docs-unsubscribe@httpd.apache.org
For additional commands, e-mail: docs-help@httpd.apache.org
Re: svn commit: r1791807 - /httpd/httpd/trunk/docs/conf/extra/httpd-manual.conf.in
Posted by William A Rowe Jr <wr...@rowe-clan.net>.
On Apr 20, 2017 15:06, "André Malo" <nd...@perlig.de> wrote:
* William A Rowe Jr wrote:
> Please re-validate your assumptions before we proceed with this
> discussion. I'll be interested in your findings.
I did. I've decided to drop out of that "discussion".
I'm sorry if I offended you, or was too assertive in my tone. I did discover
one edge case as mentioned before where a missing language (or two) even
for nearly irrelevant content would introduce an unexpected result. That is
now fixed.
I hope this resolves the veto you raised...
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.
Please revert.
I hope at this point all of your concerns are addressed? If not I'll
entirely
revert 2.4.x in anticipation of a 2.4.26 tag soon-ish.
Re: svn commit: r1791807 - /httpd/httpd/trunk/docs/conf/extra/httpd-manual.conf.in
Posted by William A Rowe Jr <wr...@rowe-clan.net>.
On Apr 20, 2017 15:06, "André Malo" <nd...@perlig.de> wrote:
* William A Rowe Jr wrote:
> Please re-validate your assumptions before we proceed with this
> discussion. I'll be interested in your findings.
I did. I've decided to drop out of that "discussion".
I'm sorry if I offended you, or was too assertive in my tone. I did discover
one edge case as mentioned before where a missing language (or two) even
for nearly irrelevant content would introduce an unexpected result. That is
now fixed.
I hope this resolves the veto you raised...
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.
Please revert.
I hope at this point all of your concerns are addressed? If not I'll
entirely
revert 2.4.x in anticipation of a 2.4.26 tag soon-ish.
Re: svn commit: r1791807 - /httpd/httpd/trunk/docs/conf/extra/httpd-manual.conf.in
Posted by André Malo <nd...@perlig.de>.
* William A Rowe Jr wrote:
> Please re-validate your assumptions before we proceed with this
> discussion. I'll be interested in your findings.
I did. I've decided to drop out of that "discussion".
Cheers,
Re: svn commit: r1791807 - /httpd/httpd/trunk/docs/conf/extra/httpd-manual.conf.in
Posted by André Malo <nd...@perlig.de>.
* William A Rowe Jr wrote:
> Please re-validate your assumptions before we proceed with this
> discussion. I'll be interested in your findings.
I did. I've decided to drop out of that "discussion".
Cheers,
---------------------------------------------------------------------
To unsubscribe, e-mail: docs-unsubscribe@httpd.apache.org
For additional commands, e-mail: docs-help@httpd.apache.org
Re: svn commit: r1791807 - /httpd/httpd/trunk/docs/conf/extra/httpd-manual.conf.in
Posted by William A Rowe Jr <wr...@rowe-clan.net>.
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.
Re: svn commit: r1791807 - /httpd/httpd/trunk/docs/conf/extra/httpd-manual.conf.in
Posted by William A Rowe Jr <wr...@rowe-clan.net>.
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.
Re: svn commit: r1791807 - /httpd/httpd/trunk/docs/conf/extra/httpd-manual.conf.in
Posted by André Malo <nd...@perlig.de>.
* William A Rowe Jr wrote:
> On Tue, Apr 18, 2017 at 3:56 PM, André Malo <nd...@perlig.de> wrote:
> > * wrowe@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/ #
---------------------------------------------------------------------
To unsubscribe, e-mail: docs-unsubscribe@httpd.apache.org
For additional commands, e-mail: docs-help@httpd.apache.org
Re: svn commit: r1791807 - /httpd/httpd/trunk/docs/conf/extra/httpd-manual.conf.in
Posted by André Malo <nd...@perlig.de>.
* William A Rowe Jr wrote:
> On Tue, Apr 18, 2017 at 3:56 PM, André Malo <nd...@perlig.de> wrote:
> > * wrowe@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/ #
Re: svn commit: r1791807 - /httpd/httpd/trunk/docs/conf/extra/httpd-manual.conf.in
Posted by William A Rowe Jr <wr...@rowe-clan.net>.
On Tue, Apr 18, 2017 at 3:56 PM, André Malo <nd...@perlig.de> wrote:
> * wrowe@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.
>> 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.
Where equal-weight is given and we have two translations other than
English to automatically fulfill, it must be the more relevant one. We
can't practically do this on a document-by-document basis, 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?
---------------------------------------------------------------------
To unsubscribe, e-mail: docs-unsubscribe@httpd.apache.org
For additional commands, e-mail: docs-help@httpd.apache.org
Re: svn commit: r1791807 - /httpd/httpd/trunk/docs/conf/extra/httpd-manual.conf.in
Posted by William A Rowe Jr <wr...@rowe-clan.net>.
On Tue, Apr 18, 2017 at 3:56 PM, André Malo <nd...@perlig.de> wrote:
> * wrowe@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).
Refusing to trust chrome, with the most recent conf change, from netcat I see...
HEAD /manual/tr/index.html.tr.utf8 HTTP/1.1
Host:localhost
HTTP/1.1 200 OK
Date: Tue, 18 Apr 2017 22:37:19 GMT
Server: Apache/2.4.25 (Unix) PivotalWebServer/6.2.3
OpenSSL/1.0.2j-fips mod_bmx/0.9.6
Last-Modified: Wed, 06 Apr 2016 11:34:46 GMT
ETag: "2423-52fcf59454180"
Accept-Ranges: bytes
Content-Length: 9251
Content-Type: text/html; charset=utf-8
Content-Language: tr
---------------------------------------------------------------------
To unsubscribe, e-mail: docs-unsubscribe@httpd.apache.org
For additional commands, e-mail: docs-help@httpd.apache.org
Re: svn commit: r1791807 - /httpd/httpd/trunk/docs/conf/extra/httpd-manual.conf.in
Posted by William A Rowe Jr <wr...@rowe-clan.net>.
On Tue, Apr 18, 2017 at 3:56 PM, André Malo <nd...@perlig.de> wrote:
> * wrowe@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.
>> 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.
Where equal-weight is given and we have two translations other than
English to automatically fulfill, it must be the more relevant one. We
can't practically do this on a document-by-document basis, 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?