Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Include ?_locale=user in JavaScript REST API requests to load user's locale #10811

Closed
danielbachhuber opened this issue Oct 19, 2018 · 0 comments · Fixed by #10862
Closed

Include ?_locale=user in JavaScript REST API requests to load user's locale #10811

danielbachhuber opened this issue Oct 19, 2018 · 0 comments · Fixed by #10862
Labels
Internationalization (i18n) Issues or PRs related to internationalization efforts [Package] Core data /packages/core-data REST API Interaction Related to REST API [Type] Enhancement A suggestion for improvement.
Milestone

Comments

@danielbachhuber
Copy link
Member

In https://core.trac.wordpress.org/ticket/44758, we're adding support for ?_locale=user to ensure the user's locale is respected a REST API request is handled.

The Gutenberg JavaScript code should include ?_locale=user in the JavaScript requests it makes to the REST API. One end result will be that taxonomy panels will display correctly localized strings (previously #8449).

@danielbachhuber danielbachhuber added [Type] Enhancement A suggestion for improvement. Internationalization (i18n) Issues or PRs related to internationalization efforts REST API Interaction Related to REST API [Package] Core data /packages/core-data labels Oct 19, 2018
@danielbachhuber danielbachhuber added this to the 4.2 milestone Oct 19, 2018
swissspidy added a commit that referenced this issue Oct 21, 2018
danielbachhuber pushed a commit that referenced this issue Oct 23, 2018
* Add user locale api-fetch middleware

See #10811

* Don't modify existing _locale query arg

* Add changelog entry

* Update changelog

* Use new hasQueryArg helper function

See #10885.

* Match on simply the route path, instead of malformed query param

* Fully mock embedding test

* Skip the embedding test until we can make the travis env mock the requests

* Skip demo test too, for now
antpb pushed a commit to antpb/gutenberg that referenced this issue Oct 26, 2018
* Add user locale api-fetch middleware

See WordPress#10811

* Don't modify existing _locale query arg

* Add changelog entry

* Update changelog

* Use new hasQueryArg helper function

See WordPress#10885.

* Match on simply the route path, instead of malformed query param

* Fully mock embedding test

* Skip the embedding test until we can make the travis env mock the requests

* Skip demo test too, for now
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Internationalization (i18n) Issues or PRs related to internationalization efforts [Package] Core data /packages/core-data REST API Interaction Related to REST API [Type] Enhancement A suggestion for improvement.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant