Fully internationalize NoRent.org #1384
Comments
This was referenced May 6, 2020
Closed
toolness
added a commit
that referenced
this issue
May 6, 2020
Due to reasons explained in #1384, we're still going to be using the English-localized version of Mapbox's API in our Spanish locale, but it would be nice if we could at least still be consistent and show the Spanish version of the state name from our own locale data. This implements that, along with some other refactorings that simplify our code a bit.
This was referenced May 18, 2020
toolness
added a commit
that referenced
this issue
May 21, 2020
This helps with #1384 by adding a `locale` field to the `JustfixUser` model. This will help us when we need to initiate tasks on behalf of the user from a context where we can't retrieve their email from a request, e.g. sending them an email or text message from a worker process. The `locale` field is set when a user first onboards with us, and its value is taken from the request, so if the user onboards in Spanish, `locale` will be `es`.
|
Ok, I am closing this PR now that everything's done! |
18 tasks
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Ok, we're ramping up i18n for the NoRent site, which resides in this codebase, so this is a big priority now.
This is a subset of #12, in that we're not going to internationalize parts of the codebase that are only used by the JustFix.nyc side of the platform.
Out of scope
To do
We've been using LinguiJS with Crowdin on Who Owns What for a while now (see Add foundational internationalization support via lingui who-owns-what#186) and it works great, so we'll probably go with that here too. Update: Did this in Add Lingui support, take 2. #1376.
We'll need to run (and document) Django's
makemessages/compilemessagesin the codebase to make sure that everything on the Django-side can be internationalized. Update: done in Enable Django i18n of first-party strings. #1386.Need to figure out what to do about our Mapbox and NYC GeoSearch autocompletes. Mapbox appears to support localization but I'm not sure about NYC GeoSearch. And even though Mapbox supports localization, I'm not actually sure if it'll be easy to use it, since we ultimately want the addresses in English for Lob/the landlord, and storing them in the user's locale and English will make Mapbox a requirement (not just a nice-to-have), will make it hard/impossible to specify addresses Mapbox/our algorithm might not know about, and other things. Sooo, really 🤞 that Spanish speakers will be OK with English city names and street addresses. Update: Thankfully we don't need to worry about localizing city and street names, so we can just keep Mapbox on
en.Ok, even though we don't need to internationalize street/city names, we should probably make the Mapbox city/state autocomplete widget use the Spanish name of the state, since we're doing that everywhere else in the app. Update: fixed in Use our localized state label in Mapbox autocomplete #1394.
Support the viewing and (eventual) asynchronous sending of the letter and associated emails in their preferred locales:
JustfixUsermodel that can be set during onboarding based on the request locale (Add 'locale' field to JustfixUser model. #1472)We'll have to figure out how we want to localize content in the
common-datadirectory. Update: fixed by Internationalize commondatabuilder. #1383.Make sure dates on the front-end (e.g. "July 1") are localized (Install full ICU data to tenants2_base image. #1494, Factor out date-util.ts, internationalize friendlyDate(). #1495).
We'll have to figure out how to localize content we pull from Airtable for NoRent.org. Update: Airtable content can now be localized thanks to Add support for i18n in norent airtable. #1392 and Load locale-specific national metadata bundle. #1400.
Make sure we're setting the
langon the<html>element of the page properly too. Update: did this in Set <html> lang attribute dynamically. #1373.Actually internationalize all strings on the Django side
Actually internationalize all strings on the React side:
letter-builderdirectory (Internationalize files inletter-builderdirectory. #1406)start-account-or-logindirectory (Internationalize start-account-or-login directory. #1437)norentdirectory (Internationalize more messages on NoRent.org. #1476).Ensure that the server-side rendered modals contain localized text (Internationalize more messages on NoRent.org. #1476)
Set up the project for translation on Crowdin. Update: I filled out the Crowdin open source project setup request form and they responded, and we have a project slot available that we can use for the TP now!
Work around a Lingui bug that makes updating localizations challenging (Work around lingui/js-lingui#616. #1486).
In order to activate the translation, we need to do so in a way that ensures that we don't direct app.justfix.nyc users to the almost-entirely-untranslated Spanish locale if the user's browser indicates the user prefers Spanish (Redirect Spanish routes on JustFix.nyc to the English version. #1498).
Design and implement a user-facing way to change the locale. Without this, the only way for a user to see the Spanish version is if their browser indicates their language preference to our server, or if they are given a direct link to the Spanish version (Add a language toggle to NoRent. #1503).
Low-priority/bonus items
Right now the Django side can't use any of the localization data that was extracted by Lingui, but it might be nice if it could: for example, we error with "{city}, {state} doesn't seem to exist!" on the Django-side and it'd be nice if the state name could be localized, but the localization data for that is on the front-end. Since both tools ultimately use
.pofiles it'd be nice if we could just compile Lingui's.pointo an.moand Django could use it too. (Alternatively, I suppose Django could transmit an error code instead of an error string, and the l10n could be done in the front-end, or we could change the error message to say "That city and state combination doesn't seem to exist"). Either way probably not too big a deal, though.A big downside of the current i18n solution is that we have a single Lingui message catalog that's shared across the entire project, which sadly means that app.justfix.nyc users will be loading strings for NoRent.org. It would be nice at the very least to be able to have separate per-site message catalogs, and even better to have a solution where message catalogs are transparently split and loaded in a way that mirrors the code splitting we're already doing (there's an issue in lingui for this at Message files splitting lingui/js-lingui#503 but it hasn't seen activity for a while). Update: Fixed by Split compiled message catalogs into multiple files #1407!
Some of the default ids that are being assigned are really, really long, which could bloat our code size. Update: Fixed by Raise errors on long i18n message ids #1438!
It's possible that our extracted localization catalogs could become out-of-date from our actual code, which isn't great. Update: Fixed by Ensure localization catalogs don't go out of date. #1443!
It's hard to figure out what's internationalized and what's not, it'd be nice to have a tool that automatically "garbles" any internationalized content with a fake translation so it's easier to see. Update: Fixed by Add a --garble option to localebuilder. #1468!
The text was updated successfully, but these errors were encountered: