OpenStack Compute (nova)

User Locales for API Messages

Registered by Mathew Odden

I18N/l10n support for API Messages based on the client locale

Current Nova API messages are fixed to the locale of Host OS. However, clients from various countries will use the API, so API messages should be changed based on the locale of the client request. User locale can be determined from the Accept-Language header per request, or retrieved from the user or tenant records in Keystone, using the authentication context for the request.

related to https://bugs.launchpad.net/nova/+bug/898766

A related blueprint in oslo-incubator will hold the general Messaging functionality for porting to other projects. https://blueprints.launchpad.net/oslo/+spec/delayed-message-translation

Blueprint information

Status:
Complete
Approver:
Vish Ishaya
Priority:
Low
Drafter:
Mathew Odden
Direction:
Approved
Assignee:
Mathew Odden
Definition:
Obsolete
Series goal:
None
Implementation:
Good progress
Milestone target:
None
Started by
Thierry Carrez
Completed by
John Garbutt

Related branches

Sprints

Whiteboard

The current implementation under review uses WebOb's Accept-Language functionality for parsing and determining the response to send back any translatable error messages from the APIs. WeBob parses the Accept-Language header according to BCP47 (http://www.rfc-editor.org/rfc/bcp/bcp47.txt) and we determine which language to use based on the best match from a list of languages available on the system where the APIs are running. The list of available languages is determined by getting a full list of locales from Babel and then iterating through them using Gettext to attempt to find the matching locale files on the system. The 'en_US' language is always available, since the inline untranslated messages are assumed to be 'en_US'.

Essentially what this comes down to is: if we have a corresponding .MO file (compiled gettext message format) for that language, we use that in our list of available languages that is sent to WeBob to make a best match determination based on the Accept-Language string. If there is no match or we do not detect any .MO files, it will always default to 'en_US', since that is our always available language. Only error messages from the API are translated, since normally responses coming from the API are data responses.

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

Addressed by: https://review.openstack.org/30479
    Add support for API message localization

Addressed by: https://review.openstack.org/30459
    Sync oslo-incubator gettextutils

Addressed by: https://review.openstack.org/34260
    Sync gettextutils from oslo

Addressed by: https://review.openstack.org/42183
    Sync gettextutils from oslo-incubator

Addressed by: https://review.openstack.org/42013
    Fix typo in exception message

---

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

(?)

Work Items

Work items:
Pull in oslo-incubator delayed translation functionality: DONE
Add support to use Accept-Language languages for translate-able responses: INPROGRESS

This blueprint contains Public information 
Everyone can see this information.