Uploaded image for project: 'Puppet'
  1. Puppet
  2. PUP-8013

Translations should be stored in different text domains based on environment



    • Bug
    • Status: Closed
    • Normal
    • Resolution: Fixed
    • PUP 5.3.3
    • PUP 5.3.4, PUP 5.4.0
    • None
    • Bug Fix
    • Puppet will now correctly load module translations per environment. For example, if a user has two different versions of a module installed in two different environments, only the translations for the version in the requested environment will be loaded.
    • Manual
    • We should do some manual testing on top of the automated tests we are adding


      Users can have different sets and different versions of modules per Puppet environment. In the current system we only load module translations once, so if a user changes their environment to one with a new version of the module in it, the translations will not be updated.

      We should make translations environment-aware by creating a new text domain for each environment. (note that it appears the current text domain setting is thread local, like locales https://github.com/grosser/fast_gettext/blob/master/lib/fast_gettext/storage.rb#L54) When we load a module's translations, they should be added to the appropriate text domain, and that domain should be loaded when we select an environment (such as on each compilation request, start an application with a configured environment, or switch environment during an agent run).

      Modules should be responsible for loading their own translation files, by adding the translations to a gettext repository and adding that repository to the correct text domain. This should be idempotent.

      We need to decide where to initialize the text domains themselves. On the server side, this probably happens as part of the HTTP handler for compilation. On the agent side, this is part of application startup. On the agent side, we don't need to tie text domains to environments because we only ever have one active at once.

      Text domains should be tied to the environment lifecycle; i.e. when an environment is refreshed, the text domains should be too, to pick up any updates to module translations that occurred. The EnvironmentLoader might be a good place to put the logic to blow away outdated text domains.

      henrik.lindberg probably has the most expertise on the environment lifecycle and how things are loaded within an environment.


        Issue Links



              eric.delaney Eric Delaney
              michael.smith Michael Smith
              0 Vote for this issue
              5 Start watching this issue



                Zendesk Support