Closed c960657 closed 4 years ago
Thanks again for the PR! Only had time for a quick look, but seems a good alternative. Do you prefer this one to be included rather then the previous PR (#184) ?
Yes, this is my favourite :-)
@c960657 Planning to do a minor release soonish, so I will review this PR this week.
This pull request has been open 30 days with no activity. Please remove the stale label or comment, or this will be closed in 5 days
This PR is an alternative to #184. This PR additionally adds support for multiple fallback locales.
Sometimes you need multiple translations for the same holiday.
Pre v2.2.0 you could easily access all translations in
$holiday->translations
. With the introduction of locale fallback in #176, things got more complicated, especially with substitute holidays (introduced in #162), so accessing thetranslations
property is difficult.I suggest adding an optional
$locales
parameter to$holiday->getName()
. This allows passing an array of locales to be searched for translations. E.g if['es_ES', 'de_AT']
is provided, the following lookup priority is used:es_ES
→es
→de_AT
→de
.If no parameter is provided, use the display locale with fallback to
DEFAULT_LOCALE
and the short name. E.g. if the display locale ises_ES
, the following lookup priority is used:es_ES
→es
→en_US
→en
→ short name.Note that when providing the optional
$locales
parameter,DEFAULT_LOCALE
and the short name is not used as fallbacks unless explicitly requested. This offers the user better control over fallback behaviour while preserving backwards compatibility.Parent locales (e.g.
de
is the parent locale ofde_AT
) are always used, even when not specified explicitly. Parent locales are not considered a “fallback”. Instead, all strings in a parent locale are considered to be identical in the child locales unless explicitly overridden. I believe this convention is also used elsewhere, e.g. in CLDR.