Add Lingui support, take 2. #1376
Conversation
| /** | ||
| * A global instance of Lingui's I18n object, which can be used to perform | ||
| * localization outside of React JSX. Note that this object is populated | ||
| * by the <LinguiI18n> component, however, so it should only really be | ||
| * used by components that exist below it in the hierarchy. | ||
| */ | ||
| export const li18n = linguiSetupI18n(); |
There was a problem hiding this comment.
I've made the Lingui I18n instance a global instead of always retrieving it from the component hierarchy because we found in Who Owns What that retrieving it for use outside of JSX tags like <Trans> was a huge hassle, as we constantly had to wrap components needing it in Lingui's <I18n> or withI18n(). Since our locale setting is already global anyways (e.g. accessing Routes.locale.home always dynamically looks up the currently set locale) we might as well roll with it.
Regardless, it looks like the in-development version of Lingui is introducing a useLingui() hook that will make things a lot easier in the future, and migrating to it from this setup should be straightforward.
| /** | ||
| * There doesn't seem to be any easy way to have TypeScript | ||
| * ignore first-party code that is explicitly imported by | ||
| * code that is type-checked, so this script goes through | ||
| * all lingui's messages catalog JS files and explicitly | ||
| * tells TypeScript to ignore them. | ||
| */ |
There was a problem hiding this comment.
Blerg, I really wish I didn't have to lift this script from #497 but I can't seem to find any other way of telling TypeScript to ignore Lingui's compiled message catalogs (because they're imported by our TS code, TypeScript insists on type-checking them even if we tell it to exclude the directory they're in).
Ok we're gonna add lingui support for real this time! This supersedes last year's #497.
This adds front-end localization via the Lingui framework. For now I've just localized two strings in the NoRent.org site to Spanish, to make sure that everything works. We're using code splitting to only load the message catalog for the currently selected locale, but outside of that, unfortunately, we have one catalog for the entire codebase, which is suboptimal as I mentioned in #12 (comment). I have some ideas for working around this in the future but we'll deal with that if/when the one massive catalog becomes a burden.
Because we don't want the Django server redirecting browsers that prefer Spanish to our 99.9% incomplete localization, I've added an
ENABLE_WIP_LOCALESsetting that needs to be enabled in order for developers to access the Spanish localization.