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"
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.
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
Localeobject with this tag (or using the separate pieces as the language and country for the constructor), Tower does not recognize it as valid:Tower’s
make-localefunction works as well:However, Tower’s
jvm-localefunction 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.