You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Email templates are the one last thing in Indico that's basically untranslated; the templates have no i18n markers and are only in english, but some users require them to be translated as well, and as e.g. #5062 indicates this is a major hassle right now.
Main tasks here:
Add translation markers to email templates; be especially careful in case of plaintext emails to not break the formatting. Ideally, a unit test with a snapshot is added for each of these email templates (see test_move_request_creation_email_plaintext for an example) before touching them to ensure the formatting/spacing does not change.
Provide some way (e.g. a contextmanager) to temporarily switch the active language, either to a specific language or to that of a given user.
Use this whenever we send emails to use the recipient's language if there is one or (in case the recipient is not an Indico user) a reasonable default (DEFAULT_LOCALE)
AFAIK registration emails currently interpolate a title-cased enum key name somewhere, iirc. for the state. This probably needs to be fixed to use a properly translated string, but it'd be OK to open a separate issue for it since it's not directly part of making emails translatable.
The text was updated successfully, but these errors were encountered:
For your second point, we have session_language which seems to work nicely with get_template_module. I'm curious what we should do when there are multiple recipients, each with a potentially different language like in the case of the abstract comments or paper comments. Worth it to send the emails separately or just use DEFAULT_LOCALE in that case?
Email templates are the one last thing in Indico that's basically untranslated; the templates have no i18n markers and are only in english, but some users require them to be translated as well, and as e.g. #5062 indicates this is a major hassle right now.
Main tasks here:
test_move_request_creation_email_plaintext
for an example) before touching them to ensure the formatting/spacing does not change.DEFAULT_LOCALE
)AFAIK registration emails currently interpolate a title-cased enum key name somewhere, iirc. for the state. This probably needs to be fixed to use a properly translated string, but it'd be OK to open a separate issue for it since it's not directly part of making emails translatable.
The text was updated successfully, but these errors were encountered: