Translations in Angular controllers and related code


#1

Hi,
What is the recommended way to translate things in Angular js controllers and html (not haml) files?
(that is - translation guidelines for strings in non Ruby controllers)

Examples for places that need translation in js controllers:
https://github.com/ManageIQ/manageiq/blob/master/app/assets/javascripts/controllers/provider_foreman/provider_foreman_form_controller.js#L94

https://github.com/ManageIQ/manageiq/blob/master/app/assets/javascripts/controllers/container_topology/container_topology_controller.js#L33

The above is a followup on those topics:


Thank you.

@chessbyte @martinpovolny @himdel


#2

Regarding JavaScript: we already have javascript gettext support – see the part JavaScript i18n in https://github.com/ManageIQ/manageiq/issues/3775

Regarding HTML: one way to see it is that HAML should be used. As suggested in the discussion that you referenced and as I wrote on GH. By requiring translation, you cross the line from simple static usecase where HTML is enough and get to the point where you need to call functions or do branching. And we use HAML for that.

I prefer to limit the number of ways to do a single thing in a single project. But we can surely discuss the possibilities. Especially in the context of the self-service and other new UIs.

There’s e.g. this: https://angular-gettext.rocketeer.be which seems to be compatible with the tools and processes that we already have in the mix.

But theres work involved with use of such tool such as packaging the necessary dependencies and making string extraction work. We should consider what we get for the effort.

Should the result of this effort be that we can allow use of HTML in places where HAML would be used otherwise, then I am not a fan of that.

But if the result would be that we have a unified way to do i18n for self-server UI and for other possible UI’s on top of ManageIQ then it might be worth serious consideration.

Ping @mzazrivec.


#3

angular-gettext becomes easy enough if we ever abandon rails’ asset pipeline for a gulp/grunt based building solution. But until then, I think the guidelines for browser-side translations should be:

  • if it’s javascript code, in a .js file, you can use __("string literal") (note the double underscore, to prevent conflicts with lodash)

  • if it’s static HTML in a template, use HAML and rely on ruby-side gettext

  • if it’s static HTML in a .js file, don’t do that

  • if it’s javascript code in a template, define a variable in the corresponding JS controller, and use that

  • if you want to do more complicated things in JS, use sprintf(__("string literal with %s"), "untranslated whatever")

(And once we go ES6, we would define a gettext modifier for template strings - something like ```__`string literal with ${expr}````, but don’t rely on it now.)


#4

if it’s javascript code in a template, define a variable in the corresponding JS controller to store the result of a __() call and use the variable.