Wednesday, April 17 • 11:00am - 11:40am
i18n strategy for OpenStack services

Sign up or log in to save this to your schedule, view media, leave feedback and see who's attending!

This session will start with a quick overview of the current approach that OpenStack services take to i18n and some of the challenges faced.

We will then step back and look at the bigger picture - OpenStack services currently do immediate translation of messages to the local server locale, yet there are two use cases for the translation of messages from OpenStack services:

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.

If we want to translate log messages (i.e. use case 1), they should be in a separate translation domain from the messages we return to users of the REST API (i.e. use case 2). The problem with having them both in the same translation domain is that translators have no way of prioritizing the REST API messages nor do administrators have any way of disabling the translation of log messages without the translation of the REST API messages.

Another tactic that may help is to delay the translation of messages 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).

As part of this session we will look at some of the difficulties encountered in the implementation of delayed messages: use of gettext.install(…) to install the _() function into Python's __builtin__ namespace (also known as "domain change issue") and the expectation that _() is returning a string.

(Session proposed by Mark McLoughlin)

Wednesday April 17, 2013 11:00am - 11:40am

Attendees (0)