Addons-frontend: Add ability to get current locale in a component

[tofumatt]

Describe the problem and steps to reproduce it:

It's not easy--and more important consistently defined--to get the current locale inside a component (especially a nested one)

What happened?

Tried to get the current locale inside a component to render a URL

What did you expect to happen?

Get the locale with a utility function

[tofumatt]

Uhhhh maybe I'm wrong, @mstriemer just explained it's in the state as { api: { lang: 'en-US' } }.

[tofumatt]

Actually I'm still totally unclear on how to get the locale. Maybe I'm being thick 😢

[mstriemer]

const LangBase = ({ lang }) => <p>Your language is: {lang}</p>;
LangBase.propTypes = {
  lang: PropTypes.string.isRequired,
};
const Lang = connect(
  (state) => ({
    lang: state.api.lang,
  })
)(LangBase);

Rendering <Lang /> should give you Your language is: en-US.

Flipping to http://localhost:3000/fr/firefox/ will show Your language is: fr.

[muffinresearch]

As discussed the lang is in the state. I do feel like it wouldn't be a bad thing to expose the lang and locale on the i18n object, since the i18n object is exposed by default to localized components.

To do that we'd just need to add it to both the client and server Jed instances.

[kumar303]

I think it's important to always get current locale from the state because then redux can handle all data flow changes. For example, on the day we add a dropdown to change locales, you'll be glad you accessed the locale on redux state because everything will Just Work.

[mstriemer]

I'll second the redux state requirement and add that if you're using the locale outside of the API code it's probably not a good idea to pull it out of the api state.

I'm thinking the auth reducer should become the user reducer and store email, username, displayName, lang, etc. I'm hoping to make that change when we have a mock for where we might put the username and edit user link.

So to access the lang it should be (once we rename the auth reducer and make it useful):

const LangBase = ({ lang }) => <p>Your language is: {lang}</p>;
LangBase.propTypes = {
  lang: PropTypes.string.isRequired,
};
const Lang = connect(
  (state) => ({
    lang: state.user.lang,
  })
)(LangBase);

We probably don't need to keep this open since the lang is currently in the state so I will close it.

[muffinresearch]

I think it's important to always get current locale from the state because then redux can handle all data flow changes. For example, on the day we add a dropdown to change locales, you'll be glad you accessed the locale on redux state because everything will Just Work.

@kumar303 @mstriemer I had considered this too, but it won't "just work" presently because of where the Jed instance is created. Because of that I reckon if we add lang to the i18n object for now and rely on the i18n instance for everything locale related if we later fix the Jed instance to be updated based on state then it will be easy to have the relevant i18n object props be updated at the same time.

Bear in mind that on the client the locale data requires a request to load a specific bundle (if it's not english) which then is used to create the Jed instance. The locale data isn't all in the state, so getting the the point where all the translations getting updated when changing the locale would require some changes.