Enable delayed translation through Message object

Registered by Michael Fork on 2013-04-02

Current OpenStack does immediate translation of messages to the local server locale. This proves problematic for two use cases:

1) As an OpenStack technical support provider, I need to get log messages in my locale so that I can debug and troubleshoot problems.

2) As an OpenStack API user, I want responses in my locale so that I can interpret the responses.

To solve these issues, we propose enabling delayed translation by creating a new Oslo object that saves away the original text and injected information to be translated at output time. When these messages reach an output boundary, they can be translated into the server locale to mirror today's behavior or to a locale determined by the output mechanism (e.g. log handler or HTTP response writer).

NOTE: API responses in the user locale is handled separately under https://blueprints.launchpad.net/nova/+spec/user-locale-api

Blueprint information

Status:
Complete
Approver:
Mark McLoughlin
Priority:
High
Drafter:
Michael Fork
Direction:
Approved
Assignee:
Mathew Odden
Definition:
Approved
Series goal:
Accepted for havana
Implementation:
Implemented
Milestone target:
milestone icon 2013.2
Started by
Michael Fork on 2013-04-29
Completed by
Mark McLoughlin on 2013-06-10

Related branches

Sprints

Whiteboard

Havana Summit etherpad: https://etherpad.openstack.org/havana-oslo-i18n-strategy

--

Review was posted here: https://review.openstack.org/26982

The main point of discussion right now is whether something like sphinx's TranslationProxy is a better starting point -- markmc

(?)

Work Items

Work items:
(locke105 & markmc) identify base message object: INPROGRESS
(locke105) upstream base message object: INPROGRESS
(locke105) update log handler to take optional language with default of system language: TODO

This blueprint contains Public information 
Everyone can see this information.