Support Accept-Language for API messages
Currently, error messages coming back from the API are translated using the same locale as the system the API is running on. Ideally, we would like to have the messages translated to the request senders locale, which we can support using the HTTP Accept-Language header to determine before sending back the translated response. Alternatively, there is the possibility of using the tenant/user data from Keystone to store a preferred locale.
There is a similar blueprint for Nova that can be used to track the implementation work there:
https:/
Blueprint information
- Status:
- Started
- Approver:
- Steven Hardy
- Priority:
- Medium
- Drafter:
- Mathew Odden
- Direction:
- Needs approval
- Assignee:
- None
- Definition:
- Pending Approval
- Series goal:
- None
- Implementation:
-
Good progress
- Milestone target:
-
next
- Started by
- Mathew Odden
- Completed by
Related branches
Related bugs
Sprints
Whiteboard
Gerrit topic: https:/
Addressed by: https:/
Small tweaks to recreation of remote errors
Addressed by: https:/
Add common methods required to allow translation of REST API responses
Addressed by: https:/
Enable localizable REST API responses via the Accept-Language header
---
Unfortunately, this was disabled late in the havana cycle. See https:/
Work Items
Work items:
Integrate common gettext utilities for delayed translations from oslo-incubator: DONE
Implement support Accept-Language header support and API layer translations: DONE
Add translatable error messages for API exceptions that did not have one: DONE
