Internationalization support for the UI

Registered by Julie Pichon on 2016-09-19

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

Status:
Started
Approver:
None
Priority:
Medium
Drafter:
Julie Pichon
Direction:
Approved
Assignee:
None
Definition:
Drafting
Series goal:
Accepted for future
Implementation:
Good progress
Milestone target:
None
Started by
Jason E. Rist on 2017-09-15

Related branches

Sprints

Whiteboard

[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 ( https://github.com/yahoo/react-intl )

Blueprint: https://blueprints.launchpad.net/tripleo/+spec/tripleo-ui-i18n-support-for-js

 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: https://review.openstack.org/#/q/topic:bp/user-locale-api

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: https://review.openstack.org/375477) places:

a. The validation YAML itself: https://github.com/openstack/tripleo-validations/blob/02d8d0a6f00ce03579f424df248a74c85e522858/validations/undercloud-ram.yaml#L16

b. A Python module which implements something Ansible doesn't have out of the box: https://github.com/openstack/tripleo-validations/blob/02d8d0a6f00ce03579f424df248a74c85e522858/validations/library/pacemaker.py#L47

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

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.

Wireframes: https://openstack.invisionapp.com/share/B98IXOG5M#/screens/186611712
Blueprint: https://blueprints.launchpad.net/tripleo/+spec/tripleo-ui-i18n-support-for-js

(?)

Work Items

Dependency tree

* Blueprints in grey have been implemented.

This blueprint contains Public information 
Everyone can see this information.