fix: parse accept-language prefixes

[strangedev]

This is a work-in-progress for fixing #63.

We also have some questions concerning the order of precedence when parsing the accept language.
This test seems to imply in its description that when both en-GB and en are both offered by the server and accepted by the client, en-GB should always be chosen, as it is more specific than en. Are we missing something here?

@dotKuro and I plan on refactoring and testing this tomorrow.

[devinivy]

Hey, thanks for the help! My interpretation is the same as yours: I believe that we have two bugs here. I have a couple thoughts:

1. It looks like we have 100% coverage, but it would still be great to get a failing test for the original bug.
2. I wonder if it would be a fruitful approach to expand preferences when it is normalized into lowers. For example, preferences such as ['de-DE', 'en-CA', 'fr'] would be normalized into a map with keys de-de, de, en-ca, en, fr. The goal would be to minimize exceptions throughout the code for accept-language and minimize the computation involved in matching. Does that seem like a workable approach?

[strangedev]

Hey @devinivy 👋
Thank you for the quick response! We're pretty pleased with how this has been handled so far ☺️

We liked your idea of normalizing the preferences into the map and refactored the code to use this approach. With the new approach, we've only introduced two new conditionals in total and only one of those is specific to accept-language 😊

We've also added a test for the fix.

Hopefully the code is up to standard. If there's anything we should improve, please let us know!

[devinivy]

@dotKuro @strangedev many thanks for this contribution. I see that you weighed-in on #65 and support that approach and behavior, which was important feedback to ensure the bug you raised was addressed. It seems like that is the direction we should go (I realize just how similar the implementations are!) so I'm closing this, but again your work and review is appreciated.