[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-US
is technically the correct format, but it's not at easy as just standardizing on the hyphen, sinceGettext
seems 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_US
would return{:ok, "American English"}
The only slight hole is that it currently only works for locales you have added to the
locales
option for Cldr. So for example if you don't havefr-CA
as a locale, but wanted to the string name for it, you'd have to pass"fr-CA"
in, asvalidate_locale
won't validatefr_CA
tofr-CA
if 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-Cyrl
tobs
, 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-WLS
toen-GB
oren
for 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!