Support Accept-Language for API messages

Registered by Mathew Odden on 2013-07-02

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://blueprints.launchpad.net/nova/+spec/user-locale-api

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:
milestone icon next
Started by
Mathew Odden on 2013-08-09

Related branches

Sprints

Whiteboard

Gerrit topic: https://review.openstack.org/#q,topic:bp/user-locale-api,n,z

Addressed by: https://review.openstack.org/37717
    Small tweaks to recreation of remote errors

Addressed by: https://review.openstack.org/40032
    Add common methods required to allow translation of REST API responses

Addressed by: https://review.openstack.org/40033
    Enable localizable REST API responses via the Accept-Language header

---

Unfortunately, this was disabled late in the havana cycle. See https://etherpad.openstack.org/disable-lazy-translation

(?)

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

This blueprint contains Public information 
Everyone can see this information.

Subscribers

No subscribers.