Report distinction between default and non-default languages #12
Conversation
For a webserver, where new translation languages may appear after the initial release, it will be handy not to stick users to their non-default best match.
|
Maybe it would be more useful for other users of the crate to return the qualification? So instead of this patch: pub fn parse_verify_default(raw_languages: &str) -> Vec<(String, bool)>
pub fn intersection_verify_default(raw_languages: &str, supported_languages: &[&str]) -> Vec<(String, bool)> I could re-write it to: pub fn parse_with_qualification(raw_languages: &str) -> Vec<(String, f32)>
pub fn intersection_with_qualification(raw_languages: &str, supported_languages: &[&str]) -> Vec<(String, f32)> Although that makes the optimized one (not present yet) even longer: pub fn parse_ordered_with_qualification(raw_languages: &str) -> Vec<(String, f32)>
pub fn intersection_ordered_with_qualification(raw_languages: &str, supported_languages: &[&str]) -> Vec<(String, f32)> Any other suggestions? |
|
@peter-scholtens Your potential change makes sense to me. Returning the quality is more flexible, and consumers could do more than check for default if they want. In terms of method length, I don't really care about it since I would rather prioritize readability and clarity over terseness. Rust mangles the name during compilation anyway, so this is a user-facing concern only |
…d to scan a correctly binary sorted array of languages faster. Intersections functions with qualification in output added.
|
@mike-engel patch-2 (2513935) contain the agreed function signatures and modification. Ready for a merge and release I would say :-) |
src/lib.rs
Outdated
| /// let user_languages = parse_with_qualification("en-US, en-GB;q=0.5"); | ||
| /// assert_eq!(user_languages,vec![(String::from("en-US"), 1.0), (String::from("en-GB"), 0.5)]) | ||
| /// ``` | ||
| pub fn parse_with_qualification(raw_languages: &str) -> Vec<(String, f32)> { |
There was a problem hiding this comment.
I'm wondering now if parse, intersection, and intersection_ordered should just call parse_with_qualification, intersection_with_qualification, and intersection_ordered_with_qualification and map over the return type to change it from Vec<(String, f32)> to Vec<String>? The function bodies are almost exactly the same, minus the map closure.
Additionally, I think quality is the more standard term over qualification, which would also shorten the names a little bit 😉
There was a problem hiding this comment.
I see your point. But that will also means a slower implementation for the user with a frugal request without quality. Another option would be to re-write it with macro's, so you get the fastest implementation for with and without quality, but I've no experience in writing them: possibly it will become less readable as code?
There was a problem hiding this comment.
I'm not too familiar with macros either, so let's leave it as-is for now 😄
…h for parse* added too. Correction of typo's.
|
Thanks @peter-scholtens this is now released as 3.1.0 and on crates.io! |
For a webserver, where new translation languages may appear after the initial release, it will be handy not to stick users to their non-default best match. This implements the request at issue #9.