Skip to content

Conversation

mstriemer
Copy link
Contributor

We discussed pulling the lang from the state instead of html[lang] on the client but using the attribute is pretty straightforward and taking it from state means we should be checking initialState && initialState.api && initialState.api.lang || config.get('defaultLang') which seems crazy. We could of course just use it but that seems like it could bite us.

Fixes mozilla/addons#9540.

@coveralls
Copy link

Coverage Status

Coverage remained the same at 100.0% when pulling a0c5b73 on mstriemer:locale-in-api-147 into 72e0efb on mozilla:master.

@coveralls
Copy link

Coverage Status

Coverage remained the same at 100.0% when pulling e452e18 on mstriemer:locale-in-api-147 into 72e0efb on mozilla:master.

.returns(mockResponse());
return api.login({api: {}, code: 'my-code', state: 'my-state'}).then((apiResponse) => {
const lang = 'en-US';
return api.login({api: {lang}, code: 'my-code', state: 'my-state'}).then((apiResponse) => {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could take the opportunity to move the then down onto the next line for all of these.

@muffinresearch
Copy link
Contributor

I'm fine with leaving the attribute lookup stuff if it keeps it simple.

Nice, r+wc

@coveralls
Copy link

Coverage Status

Coverage remained the same at 100.0% when pulling 1eb64fe on mstriemer:locale-in-api-147 into 72e0efb on mozilla:master.

@mstriemer mstriemer merged commit 5085de5 into mozilla:master Jun 2, 2016
@mstriemer mstriemer deleted the locale-in-api-147 branch June 2, 2016 14:49
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Use the user's locale for API requests
3 participants