[DRAFT]Handle en_US vs en-US vs :en_US #15
Draft
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
I noticed that this library is quite strict about the locale format that gets passed in.
"en-US"will give{:ok, "American English"}, but"en_US",:en_US,:"en-US"will all return:error. I knowen-USis technically the correct format, but it's not at easy as just standardizing on the hyphen, sinceGettextseems to prefer the underscore version. Plus since locales are a finite set, having them as atoms in Elixir it probably not that uncommon.All this code will do is validate the locale passed in, and use the canonical form if it validated successfully, otherwise it falls back to the current behavior of using the unchanged input. So all of:
:"en-US","en-US","en_US", and:en_USwould return{:ok, "American English"}The only slight hole is that it currently only works for locales you have added to the
localesoption for Cldr. So for example if you don't havefr-CAas a locale, but wanted to the string name for it, you'd have to pass"fr-CA"in, asvalidate_localewon't validatefr_CAtofr-CAif it's not an included locale. But I see this(wanting the locale's string name, but not wanting the locale in Cldr) as a less common use case.I have left it on DRAFT for two reasons:
https://github.com/LostKobrakai/cldr_languages/issues/13, you were implying that this sort of thing should not be handled in the library. Though that issue does seem to be about broadening the localebs-Cyrltobs, whereas this code would only lexically alter the input, but semantically it remains unchanged. It'll only either get the exact value you wanted, or return what you would have gotten anyway. It won't broadenen-GB-WLStoen-GBorenfor example.But to support point 2,
ex_cldr_number, for example does accept all formats:This in my opinion makes the code much less error prone.
Thanks!