title: Using React Context for Internationalization
body: <p>I know from doing a fair amount of research that internationalization/localization is one of the few legitimate use cases for React's <a href="https://facebook.github.io/react/docs/context.html" rel="nofollow noreferrer">context</a> feature. However my question is about whether one really <em>needs</em> to use context. Wouldn't it work just as well to wrap the components to be internationalized in a higher-order component that provides the localization strings as a prop? e.g. for an app that supports English and Spanish:</p>
  
  <pre><code>// WithLocale.js
  import React from 'react';
  
  import en from './locales/en-US.json';
  import es from './locales/es-ES.json';
  
  const locales = {'en-US': en, 'es-ES': es};
  
  let currentLocale = (navigator.languages &amp;&amp; navigator.languages[0])
      || navigator.language
      || navigator.userLanguage
      || 'en-US';
  
  const WithLocale = (WrappedComponent) =&gt; {
      return (props) =&gt; {
              const locale = { strings: locales[currentLocale] };
              return &lt;WrappedComponent {...props} locale={locale} /&gt;
      }
  };
  
  export default WithLocale;
  </code></pre>
  
  <p>With localization JSON such as: </p>
  
  <pre><code>// en.json
  {
    "header": "My App",
    "description": "This is an internationalizated app in React",
  }
  </code></pre>
  
  <p>And a really basic example of how it could be used in a component:</p>
  
  <pre><code>import React from 'react';
  import PropTypes from 'prop-types';
  import WithLocale from './WithLocale';
  
  const SubComponent = (props) =&gt; (
          &lt;div&gt;
              &lt;p className="App-intro"&gt;
                  {props.locale.strings.description}
              &lt;/p&gt;
          &lt;/div&gt;
  );
  
  SubComponent.propTypes = {
      locale: PropTypes.object
  };
  
  export default WithLocale(SubComponent);
  </code></pre>
  
  <p>The main issue I can think of is the overhead of injecting a potentially large JSON into every component that needs one of the strings. Are there any other reasons that this solution is not preferred?</p>