[WIP] Attempt to add support for lingui.

[toolness]

This attempts to add support for lingui (see #12 for more details on what it is, and what its pros/cons are relative to other i18n frameworks).

We only translate one string in the whole app: the Is your landlord not responding? Take action today! text.

Notes

• The lingui docs recommend creating add-locale, extract, and compile scripts to package.json but I'm concerned that compile in particular might get easily confused with build, so I've prefixed them all with lingui:. Unfortunately some of the CLI tools explicitly mention the non-namespaced names, which could also result in confusion. I guess there is no winning here right now.

To do

• Right now this hard-codes an import of the English messages catalog, which isn't great. We should figure out how to actually choose a locale the user wants, although I suppose it could wait for a future PR since it will likely be a lot of work.

• Add documentation to the readme.

• Add a test to ensure that the message catalog thingys are up-to-date with the source code.

• Add a test to ensure that localization works (possibly an integration test).

• Consider just migrating to using presets (specifically react and lingui) instead of individually importing plugins. Right now I think we have to work around this in our lingui config which is annoying. But since using the react preset will affect things outside of just l10n we can leave that for a separate PR, too.

[toolness]

Urg, so I hit a snag, sort of.

One current limitation of lingui is that it only supports a single compiled message catalog--that is, a single JS module that contains all the code needed to render all the strings in the app in a particular language. However, this runs counter to our code-splitting approach, because it means that for the user's browser to render a single page, it will need the localized text of all pages, rather than loading particular chunks of localized text as they're needed. For example, users who just want to send a letter of complaint will need to load all the strings for filing an HP Action too.

lingui has a RFC-002 which I thought would fix this issue, but on a second reading, I don't think it will, which I've explained in lingui/js-lingui#422 (comment).

So, I'm not really sure what to do now. We could just eat the cost of loading all strings for now, since our app isn't that big, or I could try to find some way to augment lingui and our build pipeline to split the message catalog in a similar way that we're splitting code.

[toolness]

Hmm, so while the problems I've described in my last comment haven't yet been addressed in lingui, at least an issue has been filed and someone else is interested in working on it (and has laid out one potential solution for doing so): lingui/js-lingui#503

[toolness]

Closing this in favor of #1376.