Emails: Internationalization & Templates

[krusynth]

We have some ability to use templates with emails right now, but we want to expand this to allow users to customize emails, as well as be able to send emails to users in multiple languages.

This also means that we'll probably want to move the localization files to the server-side so we can do more server things with them, like use them in email templates. The existing locale file could be delivered via the API as JSON like it is now. This also means that we can create a nice interface for admins to override specific text.

Also, with moving this to the API, the social media robots can get localized content, which they currently cannot. We can also move frequently-used global, universal strings (like the site name) into configuration options that get replaced in the translation strings.

Personally, I'd also love to be able to have something like HJSON instead of JSON here as well, as managing those big content blocks is a huge pain. Though a lot of those got moved to the new Pages api, so maybe that's not a big deal anymore.

[krusynth]

@doshitan Mentioned using gettext, which is supported by PHP. It does require locales to be installed on the system though, which could be a dealbreaker.

[krusynth]

Users will eventually need a way to set their preferred language when being contacted via email, when we have full multilingual support. This will be an option in each user's settings. However, this makes localization in Angular hard because we'll have to read that from the API and override the autodetection currently in Angular Translate / MessageFormat.

[krusynth]

Worth noting : all of the locales are currently using MessageFormat for translation & pluralization. There is a PHP package for this but I don't know the ways in which it may be different from the Javascript implementation currently in use.

[doshitan]

I mentioned gettext because it is the most widely used and supported i18n format in the world. If we were to move to it for our translations, we would have access to robust tooling to enable folks to help keep Madison translated like Weblate (has free hosting for free software) or Pootle or a handful of other tools. Professional translation services already have workflows for processing gettext stuff as well. It does have a kinda old-school workflow, e.g., have to compile the translation files and requires locale files installed on the server, but these are things that can be automated. There are Laravel packages and Angular modules to work with gettext.

I don't think it is asking all that much for folks who want to setup their own server by hand to install the locales for the audience they expect. They are already going through our setup guide, adding one more step for apt-get install language-pack-* (on Ubuntu) seems fine. And really they should probably be using our configuration/deploy scripts (once they are ready) which would handle it for them.

While it is kinda clunky, gettext provides a lot of advantages, particularly in crowd-sourcing translations in an automated way. I'm down for whatever, we'll make it work, but I think moving to gettext needs some serious consideration.

[krusynth]

• Wordpress uses Gettext and does so without and special installation requirements on the server (afaik). So, it’s possible.
• There’s no easy way to convert our existing MessageFormat (ICU) files to Gettext (.po). (The only available tool only does half the work.)
• The tooling for submitting translations is vastly better for gettext, in particular we should look at Transifex (free for Open Source)
• We’ll need to convert the frontend to either just read strings from the API inline into content, or replace angular-translate with angular-gettext. We probably will have to do both. The former option is attractive because we could compile mostly-done templates for each language and solve a lot of our preload FOUC problems.