Upgrade react-intl to a version that uses the new Context API, then to the latest.

android/app/build.gradle

@@ -133,7 +133,7 @@ def shrinkResourcesInProguardBuilds = false
  * give correct results when using with locales other than en-US.  Note that
  * this variant is about 6MiB larger per architecture than default.
  */
-def jscFlavor = 'org.webkit:android-jsc:+'
+def jscFlavor = 'org.webkit:android-jsc-intl:+'
 
 /**
  * Whether to enable the Hermes VM.

docs/architecture/react.md

@@ -109,10 +109,10 @@ third-party library we use that isn't there yet.
 
 We should use the [current Context
 API](https://reactjs.org/docs/context.html) instead of the [legacy
-one](https://reactjs.org/docs/legacy-context.html) wherever possible.
-The new API aggressively ensures consumers will be updated
-(re-`render`ed) on context changes, and the old one doesn't (see
-below). From the [new API's
+one](https://reactjs.org/docs/legacy-context.html) in our own code,
+and avoid libraries that haven't updated yet. The new API aggressively
+ensures consumers will be updated (re-`render`ed) on context changes,
+and the old one doesn't. From the [new API's
 doc](https://reactjs.org/docs/context.html):
 
 > All consumers that are descendants of a Provider will re-render
@@ -147,33 +147,6 @@ bad effects that `shouldComponentUpdate` returning `false` is meant to
 prevent: losing the scroll position, mainly (but also, we expect,
 discarding the image cache, etc.).
 
-#### Legacy Context API
-
-The legacy Context API is
-[declared](https://reactjs.org/docs/legacy-context.html#updating-context)
-fundamentally broken because consumers could be blocked from receiving
-updates to the context, and not just by the consumer's own
-`shouldComponentUpdate`:
-
-> The problem is, if a context value provided by component changes,
-> descendants that use that value won’t update if an intermediate
-> parent returns `false` from `shouldComponentUpdate`. This is totally
-> out of control of the components using context, so there’s basically
-> no way to reliably update the context.
-
-We have to think about the legacy Context API because the `react-intl`
-library's `IntlProvider` uses it to provide the `intl` context. Our
-workaround is a "`key` hack":
-
-If `locale` changes, we make the entire React component tree at and
-below `IntlProvider` remount. (Not merely re-`render`: completely
-vanish and start over with `componentDidMount`; see the note at [this
-doc](https://5d4b5feba32acd0008d0df98--reactjs.netlify.app/docs/reconciliation.html)
-starting with "Keys should be stable, predictable, and unique".) We do
-this with the [`key`
-attribute](https://reactjs.org/docs/lists-and-keys.html), which isn't
-recommended for use except in lists.
-
 ### The exception: `MessageList`
 
 We have one React component that we wrote (beyond `connect` calls) that

docs/howto/translations.md

@@ -156,14 +156,14 @@ to contribute translations into in the Zulip project on Transifex,
 which we do when someone expresses interest in contributing them.
 
 Each messages file in `static/translations/` should be reflected in
-three boring, more-or-less mechanical lists:
+two boring, more-or-less mechanical lists:
  * `flow-typed/translations.js`
- * `src/i18n/locale.js`
  * `src/i18n/messages.js`
 
 The first of these has a comment with a trivial command to help
-automate updating it.  The others are smaller, and are maintained
-manually.  It'd be good to fully automate all of them; we haven't yet.
+automate updating it.  The other is smaller, and is maintained
+manually.  It'd be good to fully automate both of these; we haven't
+yet.
 
 So, when a new messages file appears, update those three lists.
 Then see if the next section applies too...