Internationalization support for the UI

Registered by Julie Pichon

The UI should be usable in multiple languages.

This is a generic blueprint that covers/discusses/considers different i18n aspects. Once these can be broken down into clearer steps I expect smaller, more specific sub-blueprints to be created in order to work on the actual implementation.

Blueprint information

Julie Pichon
Series goal:
Accepted for future
Good progress
Milestone target:
Started by
Jason E. Rist
Completed by
Juan Antonio Osorio Robles

Related branches



[jpichon 2017.02.17] Items #1 and #6 only depend on UI changes and were implemented in Ocata. From here on, probably figuring out a way to translate THT (#3) would have the most impact. Validations (#4) are very visible as well, and comments on this blueprint suggest they would be translatable using whatever mechanism we end up putting together for THT. Unfortunately there's no obvious path forward to do either at this point.

[jpichon] Places where changes (may) need to be done:

 1. JavaScript UI (Done, target: Ocata)

There is a React library for internationalisation ( )


 2. Messages returned by the various APIs (Lower priority)
(Lower priority because many messages are not translated)

Many of the projects' APIs have implemented the "Accept-Language" header as part
of a "user-locale-api" series of blueprints:

However we need to check if API messages are actually translated in the projects themselves (last I checked there are too many messages and it was too overwhelming for the small translation teams, but this may have changed). We may have to use some of the not-ideal-but-works workarounds Horizon resorted to, like catching errors and rewriting them in a user-friendly manner as we can. Then these messages will be included in our exported strings.

 3. Heat Templates 'description' help strings for the TripleO templates we provide
The templates are YAML text files, with a single 'description' field for each element, that is written in English.

 4. Validations descriptions
The validations are Ansible YAML text files, with description and success/error messages all written in English. It's not immediately obvious to me from the documentation whether there is an i18n mechanism in place.

[shadower] The validation name and description are "just" metadata that is not Ansible-specific. They're keys that the Mistral API knows to look for. We could update the Mistral actions to load their localised versions from a dictionary instead.

The error messages come from two (and soon to be three: places:

a. The validation YAML itself:

b. A Python module which implements something Ansible doesn't have out of the box:

c. The custom formatter (also a Python module) which makes the Ansible output clearer by only showing information that is useful with validations:

I am aware of no mechanism to deal with a) other than a general YAML i18n thing we might use for the Heat templates and Mistral workflows, too.

Since b) and c) are bits of Python code, we should be able to use standard OpenStack tools. Although in b), Ansible copies the Python code to the overcloud when the validation is started and I'm not sure how well would our current tools work with that.

 5. Mistral workflow success/failure messages
The workflows are YAML text files and include some messages in case of success/failures that are written in English. A workaround similar to #2 (catch and rewrite the string in the UI, so as to make it translatable) may have to be put in place.

6. Language Settings menu (Done, target: Ocata)
A menu to select a language. Where to store the selected option? As a possiblity, Horizon used to (and may still be) working around the storage issue by saving the user-set preference in a cookie.



Work Items

Dependency tree

* Blueprints in grey have been implemented.

This blueprint contains Public information 
Everyone can see this information.