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

Invalid locale exception with numeric region code #78

Open
brunchboy opened this issue Jan 24, 2018 · 0 comments
Open

Invalid locale exception with numeric region code #78

brunchboy opened this issue Jan 24, 2018 · 0 comments

Comments

@brunchboy
Copy link

I realize that Tower is end-of-life, but I am hoping you can help me figure out the best way to solve this problem. If the answer is “upgrade to Tempura” Then I hope you can help find a migration guide. 😄

Investigating an exception in a web application log, I have discovered that when Tower is presented with the Locale identifier es-419, rather than successfully providing our default translation, it throws an exception, Invalid locale: :es-419 {:loc :es-419, :lang-only? nil}

Digging into this a bit deeper, it seems that although Java will successfully construct a Locale object with this tag (or using the separate pieces as the language and country for the constructor), Tower does not recognize it as valid:

repl> (.getDisplayCountry (java.util.Locale/forLanguageTag "es-419"))
"Latin America and the Caribbean"
repl> (.getDisplayCountry (java.util.Locale. "es" "419"))
"Latin America and the Caribbean"

Tower’s make-locale function works as well:

repl> (.getDisplayCountry (@#'taoensso.tower/make-Locale "es" "419"))
"Latin America and the Caribbean"

However, Tower’s jvm-locale function throws this exception, because evidently even though Java can create the Locale, and it seems to have the right content, it is not present in the 'all-locales' set, which is built by calling (Locale/getAvailableLocales).

Since web browsers are beginning to report this locale, we need some way of handling it, better than crashing with an exception. Wouldn’t it make sense to use the fallback locale in situations like this, even if there is no way to realize that it is actually a valid JVM locale?

Any guidance or suggestions would be most welcome.

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

No branches or pull requests

1 participant