Semantics of fallback in case of invalid locale

[pastafari]

Hi @ptaoussanis

I was bitten recently by the InvalidLocale exception when one of the consumers of my code sent in a locale like "foobar" which doesn't exist.

My naive understanding was that this would be handled by translate or t by falling back to the fallback locale specified in my config. I got around the problem by wrapping locale-key catching the exception and falling back to my prefered locale.

I wanted to start this discussion with a view to clarify the semantics of fallback.

Wouldn't it be better for translate to fallback when given an invalid locale?

[ptaoussanis]

Hi Mohit,

My naive understanding was that this would be handled by translate or t by falling back to the fallback locale specified in my config.

Translations will fallback from one valid locale without a dictionary entry to one valid locale with a dictionary entry. In all cases the locale needs to actually be valid (well-formed).

So the fallback contract is: locale without translations = okay, but locale must be a valid (well-formed) locale.

If you're parsing a possibly unsanitary locale from a client, there's a try-locale util which will return nnil iff the input (anything) is a valid locale. You can use that to sanity-check a given locale before passing it along to your translation fn.

Does that help?

[pastafari]

Hey Peter

Sorry I dropped the ball on this. I understand that I can use try-locale, and I do use it.

Re: the fallback contract, I understand it now, but I still feel it is a little too narrow.

The name "fallback" gives the impression, that Tower will fallback to a particular configured locale in exceptional cases as well.

[ptaoussanis]

Hi Mohit, I'll be adjusting this behaviour in v2.1.0 final - thanks for the suggestion! Cheers :-)