Skip to content
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

[DRAFT]Handle en_US vs en-US vs :en_US #15

Draft
wants to merge 2 commits into
base: master
Choose a base branch
from

Conversation

pejrich
Copy link

@pejrich pejrich commented Apr 3, 2024

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 know en-US is technically the correct format, but it's not at easy as just standardizing on the hyphen, since Gettext 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 have fr-CA as a locale, but wanted to the string name for it, you'd have to pass "fr-CA" in, as validate_locale won't validate fr_CA to fr-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:

  1. I'm unfamiliar with this codebase, and can't get the tests to run locally, so I'm not even sure if this is the best way to handle it, or if it breaks anything else. I'm happy to make changes if you're interested in idea in general.
  2. I wasn't sure if in your comment on this issue: 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 locale bs-Cyrl to bs, 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 broaden en-GB-WLS to en-GB or en for example.

But to support point 2, ex_cldr_number, for example does accept all formats:

iex(83)> MyApp.Cldr.Number.to_string(1000, locale: "es-ES", format: :spellout)
{:ok, "mil"}
iex(84)> MyApp.Cldr.Number.to_string(1000, locale: "es_ES", format: :spellout)
{:ok, "mil"}
iex(85)> MyApp.Cldr.Number.to_string(1000, locale: :"es_ES", format: :spellout)
{:ok, "mil"}
iex(86)> MyApp.Cldr.Number.to_string(1000, locale: :"es-ES", format: :spellout)
{:ok, "mil"}

This in my opinion makes the code much less error prone.

Thanks!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant