Use fallback from DEFAULT_LANGUAGE to 'en'

[c960657]

With the changes in #176, most translations for en_US have been replaces with a generic en translation.

The fallback to the parent locale works fine for providers created with en_US as display locale. But for providers with other locales (such as it_IT), the fallback to DEFAULT_LANGUAGE (if no Italian translation exists) only looks for a en_US and not the parent locale.

In other words, the lookup priority should be this:
it_IT → it → en_US → en → shortName

But currently it is only this:
it_IT → it → en_US → shortName

[stelgenhof]

Don't you mean the fallback language? Any reason this is hardcoded to 'en'/'en-US'?

[c960657]

en_US has always been used as fallback language (Holiday:: DEFAULT_LOCALE). The only change here is that it will now fall back to en, if there is no specific translation for en_US.

[stelgenhof]

Yes, 'en_US' has always been the default fallback, but I thought even the fallback locale was configurable in one of your PR's (Or am I mistaken?)

[c960657]

I don't blame you for being a bit confused about my various PR's. I am a confused myself 🤪. Some of them overlap or extend each other. I'll try to clarify my intentions. For now, I think this PR is the most important one, because it fixed a regression introduced in v2.2.0 (by me 😞).

In #123, I proposed a configurable default locale as an alternative to providing the locale when creating the provider. However — as noted in my last comment in that PR) — I confused the concepts of default locale (the locale to use if no locale is provided explicitly for Yasumi::create()) versus fallback locale (the locale to use as fallback if a given holiday does not have a translation in the requested locale), so I have closed that PR for now. Part of it is split out into a separate PR, #184.

By the above definition, the DEFAULT_LOCALE constant is a fallback locale. It is hardcoded to English, because most holidays have an English translation (in fact, I think it would be cool to ensure an en translation for all holidays — but let's discuss that in a separate PR).

I think it is reasonable to hardcode en or en_US as fallback locale. This is a final resort before returning shortName.

I guess there is a case for making the fallback locale configurable or even providing multiple fallback locales. For example, when using a Catalan locale, you may prefer falling back to Spanish before resorting to English. This could be incorporated into #184, so that getName() is extended to accept not only a locale but an array of locales.

TL;DR
I suggest merging this PR, then consider #184. Eventually I will make a new proposal about a default locale (a new version of #123).

I hope this makes sense 😊

[stelgenhof]

Thanks for the explanation! I understand now. Guess that's why we have reviews :)

When I started this library I hardcoded the fallback locale however with the intention of making it configurable one day. I opted not doing it immediately but wanted to focus on the core first. Making improvements step by step...