Provide a fallback for LanguageAccept under Safari

[chivalry]

Safari on macOS doesn't provide a language-only option in the header for languages accepted. When en-US is the preferred language, Safari only provides an "Accepted Language" of en-US without any fallback to en. Therefore, if a website is offering an en language version but not an en-US version, LanguageAccept.best_match returns None.

This pull request attempts to correct that by checking if None is returned and if so, trying again with language-only accepted values.

fixes #450

[chivalry]

It appears this is a known issue? #450

It looks like there might be a better way to do this than what I came up with. I'll do a bit more research when I have time. For the time being my app is using my own function instead of best_match.

[chivalry]

After some research, I don't see a better way to handle this, but I did add some additional tests.

[chivalry]

Have the tests become more strict? Did I miss something? The tox app says there are failures in tests/test_test.py and src/werkzeug/debug/__init__.py, but my commit's version of those files is the same as in pallets:master.

[davidism]

You need to follow the style checks, in this case ensure you use Black to format the code. You can see the changes it wants to make here: https://travis-ci.org/pallets/werkzeug/jobs/524209888#L219-L262 You can install pre-commit to have this done automatically before commits.

[davidism]

There are three issues related to accept matching: #20, #450, and #458. I think the first comment in #20 may be listing the other two, but it would be good to review them.

[davidism]

This doesn't go the opposite direction, where the client accepts "en", but the server looks for "en_US". Is that intended / correct?

a = LanguageAccept((("en", 0.9),))
m = a.best_match(("en_US",))
print(m)  # None

[davidism]

Added a fallback in the other direction. The process is now:

1. Exact match
2. Accept on primary, if the client accepts "en-US", "en" matches
3. Match on primary, if the client accepts "en", "en-US" matches.

Also fixed to match 3-letter primary tags, like "aus".

Given the way the code is written, you could imagine a fourth fallback where the primary tag is considered for both the accept and match values at the same time. This doesn't make sense however, as "en-GB" would then match "en-US".