Implement pseudo-localization

[jordajm]

When developing a new feature in the DApp, it may be helpful to be able to view the component with longer/taller strings to identify inflexible containers and make sure they can handle non-english strings. Otherwise, we have to wait until translators complete translation of the new strings, which will usually not be available until after the feature is released.

Inspired by this blog post from Netflix:
https://medium.com/netflix-techblog/pseudo-localization-netflix-12fff76fbcbe

Here's someone's open-source implementation of the concepts in that blog post:
https://www.npmjs.com/package/pseudo-localization

We could trigger pseudo-localization via a query string like ?localize=true or some other method.

[wanderingstan]

Interesting.

Since we already have react-intl wired up, I think that putting the npm module in the DApp is not the right move; it doesn't "know" which strings have been wrapped for localization, and adds another dependency to the DApp.

Could we instead add the package to your processTranslatedMessages.js script, creating an additional "language" called "Pseudo Localization", build from our English strings, that we only enable on non-production builds?

https://github.com/OriginProtocol/origin-dapp/blob/master/translations/scripts/processTranslatedMessages.js

---

EDIT: But that said, I don't know if this is a priority. In my experience, 99% of translations issues can be found by testing German (for length) and Chinese (for odd characters). Since we can get instant machine-translated versions of these, that's good enough to get testing going even before real human translations are complete.