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

Translations should be stored in different text domains based on environment

    XMLWordPrintable

    Details

    • Type: Bug
    • Status: Closed
    • Priority: Normal
    • Resolution: Fixed
    • Affects Version/s: PUP 5.3.3
    • Fix Version/s: PUP 5.3.4, PUP 5.4.0
    • Component/s: None
    • Labels:
    • Template:
    • Sub-team:
    • Team:
      Platform Core
    • Sprint:
      Platform Core KANBAN
    • Method Found:
      Needs Assessment
    • Release Notes:
      Bug Fix
    • Release Notes Summary:
      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.
    • QA Risk Assessment:
      Manual
    • QA Risk Assessment Reason:
      We should do some manual testing on top of the automated tests we are adding

      Description

      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.

        Attachments

          Issue Links

            Activity

              People

              Assignee:
              eric.delaney Eric Delaney
              Reporter:
              michael.smith Michael Smith
              Votes:
              0 Vote for this issue
              Watchers:
              5 Start watching this issue

                Dates

                Created:
                Updated:
                Resolved:

                  Zendesk Support