-
Notifications
You must be signed in to change notification settings - Fork 9
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Locale
as a phantom type
#196
Comments
I'd be happy to include this. I think it would make sense to implement it in the same way as CountryCode, e.g. a union of a Literal and a phantom type. What do you think? |
Perhaps it's possible to pair it with a CI job that checks for compatibility against this list? https://www.iana.org/assignments/language-subtag-registry/language-subtag-registry (Assuming the reasoning here is correct: https://stackoverflow.com/a/37062190) |
Hm, I don't think it's viable with a Literal, since the matrix of the language subtag registry (your link) is massive. I've read that RFC 5646 specifies 2 classes of conformance "well-formed" and "valid" (https://www.rfc-editor.org/rfc/rfc5646#section-2.2.9) what if phantom types, per default, checks that a And what if, in replacement of the Literal approach, we try to make it simple to configure/extend What I'm trying to say here is if we can find a way to avoid phantom types shipping with a massive fixture, the language subtag registry, but still allow for users to have a simple way to "plug in" the parsed language subtag registry, or a subset of it for additional validation purposes. |
@flaeppe Did you land on anything with regards to the possibility of introducing types for describing the set of rules that locale codes adhere to? I don't remember all the details, but it sort of seems we shouldn't introduce a |
I haven't dug any deeper into it, actually. I started off with hard coded locale strings to begin with, and haven't attempted to create anything more sophisticated. I agree with your reasoning here. A |
Could it be feasible to introduce a
Locale
phantom type? Perhaps more narrowly a "http locale" type, following the rules of theAccept-Language
header specification (https://httpwg.org/specs/rfc7231.html#header.accept-language). I don't mean thatLocale
would represent the whole header value but rather that the header value would be split into multiple locales.The text was updated successfully, but these errors were encountered: