[openstack-dev] [tripleo][ui] [heat] i18n proposal for heat templates 'description' help strings

Julie Pichon jpichon at redhat.com
Wed Apr 5 16:22:35 UTC 2017


Hi,

Peng, thank you for looking into how we might be able to provide
translations for the THT content in TripleO UI! I think this would be
helpful for users, and we have a couple of translators interested in
helping as well.

On 23 March 2017 at 09:07, Thomas Herve <therve at redhat.com> wrote:
> On Thu, Mar 23, 2017 at 9:39 AM, Peng Wu <peng.e.wu at gmail.com> wrote:
>> Hi,
>>
>>   For TripleO UI project, some users requested to translate the web UI.
>> But some web UI string are from heat template files in tripleo-heat-
>> templates project.
>>
>>   In order to get translated templates displayed in tripleo-ui, we
>> propose a blueprint as follows, which needs to change code in heat,
>> tripleo-heat-tempates and tripleo-ui projects.
>>
>>   I18n proposal for heat templates 'description' help strings
>>
>>   1. Update heat project to accept "translation-domain" header in
>> RESTful request, like "translation-domain: tripleo-heat-templates"
>>
>>      a. With "translation-domain" header, heat will try to translate
>> "title" and "description" field using "tripleo-heat-templates.po"
>>
>>      b. Without "translation-domain" header, heat will return the
>> fields like before
>>
>>      c. Add some field in config file for security to have a list of
>>         allowed "translation-domain",
>>         like "allowed-translation-domains: ['tripleo-heat-templates',
>> ...]"
>
> From the Heat side of things, that sounds like a big no-no to me.
> While we've done many things to cater to TripleO, this is way too
> specific of a use case. It doesn't even make sense for the general use
> case of passing user templates to Heat.

I would have thought maybe providing a standard mechanism for Heat
users to share templates with descriptions in multiple languages would
be interesting to Heat as well, but it looks like the workflow isn't
quite the same as I thought so that's fair enough.

>>   2. Update tripleo-heat-templates to generate the translation files,
>>      like "tripleo-heat-templates.pot"
>>
>>      a. May need to write python script to extract "title" and
>> "description" field from yaml files
>>
>>      b. May need to integrate into python babel config or use separate
>> po files
>>
>>
>>   3. Update tripleo-ui to use locale API with "translation-domain"
>> header to ask the RESTful response with translated "title" and
>> "description" fields from heat services
>>
>>      a. tripleo-ui will send request with two additional headers:
>>         "Accept-Language" and "translation-domain: tripleo-heat-
>> templates"
>
> Those last 2 steps may make more sense. Possibly try to store those
> translation files somewhere and manage them in the UI?

If it's at all possible, I think it'd be good to figure out a mechanism
where we can keep the translations together with the templates that
have the original strings (so in the THT repo itself), rather than
store them all in the UI repository where it could easily get out of
sync and could never be reused outside of the UI use case.

Of course this means the translations would likely be stored in
standard PO files, while the tripleo-ui i18n library only understands
JSON for the message catalogues... so there'll probably be some
interesting things to figure out here. I imagine the PO files would end
up stored in Swift with the rest of the plan, maybe we could get to
them via a Mistral action that would convert them to JSON? Or modify
the current action that gets the titles/descriptions to look for the
new Accept-Language header, I'm not familiar with how it currently works.

If there is a blueprint or bug or spec where you're tracking the work,
I'd love to know so I can follow what's happening and see if there are
places where I might be able to help. If the new Python script requires
some additional infra work, I also have some experience with updating
the translation proposal jobs to work with different formats.

Thanks,

Julie



More information about the OpenStack-dev mailing list