Rather than iterating over a static array of locales supported by the
site, use locales the PublicBody has translations for to avoid the
email creation failing - and preventing the request or followup from
being sent.
Also only output the short linebreak intended to separate the French and
Dutch footer text if more than one locale/language is in play.
Why was this needed?
Prevents the overridden outgoing email templates from erroring out when looping over a static list of locales if there is no matching translation for the PublicBody. (There are examples on the live site where translations are not available for both languages).
Discovered during upgrade testing rather than on the live site.
Notes to reviewer
Apologies for the lazy way I hacked the view_paths override into the view spec!
Implementation notes
Globalize's available_locales method for translated models is just the result of a (deduped) map operation on the available translation locales so the order may not be consistent. Running sort produces an alphabetical order which is only coincidentally what we want (so good enough for now but fragile). For comparison AlaveteliLocalization sets - and therefore FastGettext returns (when AlavateliLocalization defers to it) the locales in the order they appear in the general.yml file.
I've opened a new ticket in core with an initial sketch of a new library method to strip and sort an array of locales to match the site defaults.
Related issues
Closes #94
What does this do?
Rather than iterating over a static array of locales supported by the site, use locales the PublicBody has translations for to avoid the email creation failing - and preventing the request or followup from being sent.
Also only output the short linebreak intended to separate the French and Dutch footer text if more than one locale/language is in play.
Why was this needed?
Prevents the overridden outgoing email templates from erroring out when looping over a static list of locales if there is no matching translation for the
PublicBody. (There are examples on the live site where translations are not available for both languages).Discovered during upgrade testing rather than on the live site.
Notes to reviewer
Apologies for the lazy way I hacked the
view_pathsoverride into the view spec!Implementation notes
Globalize's
available_localesmethod for translated models is just the result of a (deduped)mapoperation on the available translation locales so the order may not be consistent. Runningsortproduces an alphabetical order which is only coincidentally what we want (so good enough for now but fragile). For comparisonAlaveteliLocalizationsets - and thereforeFastGettextreturns (whenAlavateliLocalizationdefers to it) the locales in the order they appear in thegeneral.ymlfile.I've opened a new ticket in core with an initial sketch of a new library method to strip and sort an array of locales to match the site defaults.