Suggestion: select language from set of available languages

[atezet]

Similar to intersection it would be useful to be able to just select one from a list of available languages. Also, I think it would be useful if it would be possible to match en-US and en-GB with en in the available languages, for projects that don't support regional versions of languages. Some sort of "lossy" select.

[mike-engel]

Hi @atezet, thanks for the suggestion! I'm curious how you think this would work. Would it be random? Just the first in a list? If you could design the API, what would it look like?

[atezet]

Thanks for your reply! I'll try to write it up somewhere next week if that's okay

[atezet]

So, I think neither of my suggestions should be random, but either quality-based or order-based. The select/select_with_quality should have the same API as the intersection, but always just return one result. So something along the lines of:

pub fn select(raw_languages: &str, supported_languages: &[&str]) -> Option<String> {
    let user_languages = parse(raw_languages);
    user_languages
        .into_iter()
        .find(|l| supported_languages.contains(&l.as_str()))
}

I'll submit it as a PR later, if this is okay.

The select_lossy is a tad more complicated, as the regions aren't split from the language in the current type. but let me try:

/// `supported_languages` is an array of languages without region
pub fn select_lossy(raw_languages: &str, supported_languages: &[&str]) -> Option<String> {
    let user_languages = parse(raw_languages);
    user_languages
        .into_iter()
        .find(|l| supported_languages.contains(&ls.split('-').next().unwrap()).as_str())
}

While writing this, I realised it's type-wise probably nicer to have the region split off and put it in its own field. That's a pretty major change, but I'd be willing to help if you're up for it. I always like it if crates provide nice types to interface with the functionality they provide.

Disclaimer: I wrote both of these in the comment field of Github. The unwrap is based on the assumption that user_languages doesn't contain any empty strings, but I don't know that for sure.