Fail gracefully if language no longer supported

[eloquence]

In the course of development, a language may fall below an acceptable level of translation coverage, in which case we may want to remove it from the list of supported languages.

Currently, the app will fail (Source Interface will display an Internal Server Error) if an unsupported language is specified in SUPPORTED_LOCALES. This means that removing support for a language could break running instances.

Safer behavior could be to ignore such locales (and fall back to English when specified as the default locale). An error could be displayed in securedrop-admin to the user next time they step through sdconfig, and an OSSEC email generated if an unsupported locale is detected in the configuration.

[cfm]

In yesterday's Server hangout, we affirmed interest in the following measures:

1. The Source and Journalist Interfaces should render:
   1. in the selected language, among the instance's configured languages, if it is available; then
   2. in the instance's default language, if it is available; then
   3. in English (i.e., fall back to source strings) if it is among the instance's configured languages; then
   4. with an error message otherwise.
2. securedrop-admin sdconfig should error if a configured language is not available in securedrop/translations.
3. OSSEC should alert if a configured language is not available in securedrop/translations.

[cfm]

As of 635b856 my branch 6366-check-usable-languages addresses and tests these cases:

1. The Source and Journalist Interfaces should render:
   1. in the selected language, among the instance's configured languages, if it is available; then
   2. in the instance's default language, if it is available; then
   3. in English (i.e., fall back to source strings) if it is among the instance's configured languages; then
   4. with an error message otherwise.
2. securedrop-admin sdconfig should error if a configured language is not available in securedrop/translations.
3. OSSEC should alert if a configured language is not available in securedrop/translations.
   • needs testing in staging

(The "selected language" and "default language" cases come from the existing i18n.get_locale().)

Next week once I'm back online: the remaining cases and tests, Git polishing, and the test plan and pull request. The latter will document (at least inline) the fine-grained distinctions introduced by this work in conjunction with #6156.

[cfm]

1. The Source and Journalist Interfaces should render:
   1. in the selected language, among the instance's configured languages, if it is available; then
   2. in the instance's default language, if it is available; then
   3. in English (i.e., fall back to source strings) if it is among the instance's configured languages; then
   4. with an error message otherwise.
2. securedrop-admin sdconfig should error if a configured language is not available in securedrop/translations.

Case (1)(3) is addressed as of 84ac53d, for which a pull request is incoming.

Case (2) is already addressed by SiteConfig.ValidateLocales:

amnesia@amnesia:~/Persistent/securedrop$ ./securedrop-admin --force sdconfig
[...]
Space separated list of additional locales to support (tr cs zh_Hant en_US ru es
_ES de_DE pt_BR ro nb_NO fr_FR sk ca sv ar it_IT is hi zh_Hans el nl): es_ES de_
DE yy_ZZ                                                                        
The following locales do not exist yy_ZZ

amnesia@amnesia:~/Persistent/securedrop$ rm -rf securedrop/translations/de_DE
amnesia@amnesia:~/Persistent/securedrop$ ./securedrop-admin --force sdconfig
Space separated list of additional locales to support (ru en_US zh_Hant is hi ro
 sk nb_NO ar el fr_FR zh_Hans sv nl ca pt_BR cs tr it_IT es_ES): es_ES de_DE    
The following locales do not exist de_DE

3. OSSEC should alert if a configured language is not available in securedrop/translations.

My expectation is that this will happen automatically via OSSEC rule no. 1002 on $BAD_WORDS our Apache logs OSSEC rule.