Jira (PUP-8040) Puppet does not initialize I18N locale per thread
Title: Message Title Enis Inan assigned an issue to Unassigned Puppet / PUP-8040 Puppet does not initialize I18N locale per thread Change By: Enis Inan Assignee: Enis Inan Add Comment This message was sent by Atlassian JIRA (v7.7.1#77002-sha1:e75ca93) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at https://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.
Jira (PUP-8040) Puppet does not initialize I18N locale per thread
Title: Message Title Enis Inan assigned an issue to Enis Inan Puppet / PUP-8040 Puppet does not initialize I18N locale per thread Change By: Enis Inan Assignee: Maggie Dreyer Enis Inan Add Comment This message was sent by Atlassian JIRA (v6.4.14#64029-sha1:ae256fe) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at https://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.
Jira (PUP-8040) Puppet does not initialize I18N locale per thread
Title: Message Title Kenn Hussey updated an issue Puppet / PUP-8040 Puppet does not initialize I18N locale per thread Change By: Kenn Hussey Flagged: Impediment Add Comment This message was sent by Atlassian JIRA (v6.4.14#64029-sha1:ae256fe) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at https://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.
Jira (PUP-8040) Puppet does not initialize I18N locale per thread
Title: Message Title Michael Smith updated an issue Puppet / PUP-8040 Puppet does not initialize I18N locale per thread Change By: Michael Smith Release Notes Summary: Puppet Server will now consistently use the system locale when processing requests. Release Notes: Bug Fix Add Comment This message was sent by Atlassian JIRA (v6.4.14#64029-sha1:ae256fe) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at https://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.
Jira (PUP-8040) Puppet does not initialize I18N locale per thread
Title: Message Title
Michael Smith updated an issue
Puppet / PUP-8040
Puppet does not initialize I18N locale per thread
Change By:
Michael Smith
From a few hours of investigation, the puppetserver appears to track translation repositories from compile to compile, but either "forgets" about the locale after each compile, or must have the locale initialized in EVERY thread individually.Some technical details:- {{Puppet::GettextConfig.initialize_i18n}} checks {{translation_repositories}} before initializing {{FastGettext.locale}}, and thus only initializes the locale once ever (see https://github.com/puppetlabs/puppet/blob/5.3.2/lib/puppet/module.rb#L427-L446).- {{FastGettext.translation_repositories}} are a class variable. According to the FastGettext readme, {{FastGettext.locale}} must be initialized once per thread: https://github.com/grosser/fast_gettext#3-choose-text-domain-and-locale-for-translation- The locale should be negotiated at every module load, contrary to what this says: https://github.com/puppetlabs/puppet/blob/5.3.2/lib/puppet/gettext/config.rb#L83-L84 (watch out for performance implications) but the translation repositories should only needed to be loaded once.We are going to explore refactoring the gettext initialization code to skip the logic around {{available_locales}} and {{FastGettext.locale}} in favor of just setting {{FastGettext.default_locale}} to the system locale directly, since {{default_locale}} is not thread local, unlike {{FastGettext.locale}}. That library should already handle the fallback cases from this configuration (though we will be writing tests to verify this, see PUP-8080). In order to avoid breaking other users of GettextSetup, we will likely be implementing most of this directly in Puppet as gettext utils, and drop our runtime dependency on GettextSetup.It looks like we might run into a similar issue when we start trying to use more text domains (see PUP-8013 and https://github.com/grosser/fast_gettext/blob/master/lib/fast_gettext/storage.rb#L54) as the current text domain also appears to be a thread-local variable. Currently we're avoiding issues here by only using one text domain which is both set as {{FastGettext.text_domain}} and {{FastGettext.default_text_domain}}, the latter of which is not thread local.Reproduction steps in a basic PE 2017.3.1 install - {{ localectl set-locale LANG=ja_JP.UTF-8 }} - add ` {{ fail('trigger failure') ` }} to {{node default}} section of {{ /etc/puppetlabs/code/environments/production/manifests/site.pp }} - set {{ disable_i18n=false }} in {{/etc/puppetlabs/ puppet /puppet .conf }} - {{ systemctl restart pe-puppetserver }} - {{ puppet agent -t --noop }} (several times)Expect to see{quote}Error: リモートサーバからカタログを取得できませんでした Could not retrieve catalog from remote server : SERVERのエラー500 Error 500 on SERVER : サーバエラー: Evaluation Error: a Function Callの検証中にエラーが生じました。trigger failure at /etc/puppetlabs/code/environments/production/manifests/site.pp:31:3 on node a2kqzra8n7avi2i hwcijw3gfrqxsiw .delivery.puppetlabs.net{quote}Will mostly see{quote}Error: リモートサーバからカタログを取得できませんでした Could not retrieve catalog from remote server : SERVERのエラー500 Error 500 on SERVER : Server Error: Evaluation Error: Error while evaluating a Function Call, trigger failure at
Jira (PUP-8040) Puppet does not initialize I18N locale per thread
Title: Message Title
Michael Smith updated an issue
Puppet / PUP-8040
Puppet does not initialize I18N locale per thread
Change By:
Michael Smith
From a few hours of investigation, the puppetserver appears to track translation repositories from compile to compile, but either "forgets" about the locale after each compile, or must have the locale initialized in EVERY thread individually.Some technical details:- {{Puppet::GettextConfig.initialize_i18n}} checks {{translation_repositories}} before initializing {{FastGettext.locale}}, and thus only initializes the locale once ever (see https://github.com/puppetlabs/puppet/blob/5.3.2/lib/puppet/module.rb#L427-L446).- {{FastGettext.translation_repositories}} are a class variable. According to the FastGettext readme, {{FastGettext.locale}} must be initialized once per thread: https://github.com/grosser/fast_gettext#3-choose-text-domain-and-locale-for-translation- The locale should be negotiated at every module load, contrary to what this says: https://github.com/puppetlabs/puppet/blob/5.3.2/lib/puppet/gettext/config.rb#L83-L84 (watch out for performance implications) but the translation repositories should only needed to be loaded once.We are going to explore refactoring the gettext initialization code to skip the logic around {{available_locales}} and {{FastGettext.locale}} in favor of just setting {{FastGettext.default_locale}} to the system locale directly, since {{default_locale}} is not thread local, unlike {{FastGettext.locale}}. That library should already handle the fallback cases from this configuration (though we will be writing tests to verify this, see PUP-8080). In order to avoid breaking other users of GettextSetup, we will likely be implementing most of this directly in Puppet as gettext utils, and drop our runtime dependency on GettextSetup.It looks like we might run into a similar issue when we start trying to use more text domains (see PUP-8013 and https://github.com/grosser/fast_gettext/blob/master/lib/fast_gettext/storage.rb#L54) as the current text domain also appears to be a thread-local variable. Currently we're avoiding issues here by only using one text domain which is both set as {{FastGettext.text_domain}} and {{FastGettext.default_text_domain}}, the latter of which is not thread local. Reproduction steps- localectl set-locale LANG=ja_JP.UTF-8- add `fail('trigger failure')` to /etc/puppetlabs/code/environments/production/manifests/site.pp- set disable_i18n=false in puppet.conf- systemctl restart pe-puppetserver- puppet agent -t --noop (several times)Expect to see{quote}Error: リモートサーバからカタログを取得できませんでした: SERVERのエラー500 : サーバエラー: Evaluation Error: a Function Callの検証中にエラーが生じました。trigger failure at /etc/puppetlabs/code/environments/production/manifests/site.pp:31:3 on node a2kqzra8n7avi2i.delivery.puppetlabs.net{quote}Will mostly see{quote}Error: リモートサーバからカタログを取得できませんでした: SERVERのエラー500 : Server Error: Evaluation Error: Error while evaluating a Function Call, trigger failure at /etc/puppetlabs/code/environments/production/manifests/site.pp:31:3 on node a2kqzra8n7avi2i.delivery.puppetlabs.net{quote}
Jira (PUP-8040) Puppet does not initialize I18N locale per thread
Title: Message Title Kenn Hussey updated an issue Puppet / PUP-8040 Puppet does not initialize I18N locale per thread Change By: Kenn Hussey Flagged: Impediment Add Comment This message was sent by Atlassian JIRA (v6.4.14#64029-sha1:ae256fe) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at https://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.
Jira (PUP-8040) Puppet does not initialize I18N locale per thread
Title: Message Title
Maggie Dreyer updated an issue
Puppet / PUP-8040
Puppet does not initialize I18N locale per thread
Change By:
Maggie Dreyer
From a few hours of investigation, the puppetserver appears to track translation repositories from compile to compile, but either "forgets" about the locale after each compile, or must have the locale initialized in EVERY thread individually.Some technical details:- {{Puppet::GettextConfig.initialize_i18n}} checks {{translation_repositories}} before initializing {{FastGettext.locale}}, and thus only initializes the locale once ever (see https://github.com/puppetlabs/puppet/blob/5.3.2/lib/puppet/module.rb#L427-L446).- {{FastGettext.translation_repositories}} are a class variable. According to the FastGettext readme, {{FastGettext.locale}} must be initialized once per thread: https://github.com/grosser/fast_gettext#3-choose-text-domain-and-locale-for-translation- The locale should be negotiated at every module load, contrary to what this says: https://github.com/puppetlabs/puppet/blob/5.3.2/lib/puppet/gettext/config.rb#L83-L84 (watch out for performance implications) but the translation repositories should only needed to be loaded once.We are going to explore refactoring the gettext initialization code to skip the logic around {{available_locales}} and {{FastGettext.locale}} in favor of just setting {{FastGettext.default_locale}} to the system locale directly, since {{default_locale}} is not thread local, unlike {{FastGettext.locale}}. That library should already handle the fallback cases from this configuration (though we will be writing tests to verify this, see PUP-8080). In order to avoid breaking other users of GettextSetup, we will likely be implementing most of this directly in Puppet as gettext utils, and drop our runtime dependency on GettextSetup.It looks like we might run into a similar issue when we start trying to use more text domains (see PUP-8013 and https://github.com/grosser/fast_gettext/blob/master/lib/fast_gettext/storage.rb#L54) as the current text domain also appears to be a thread-local variable. Currently we're avoiding issues here by only using one text domain which is both set as {{FastGettext.text_domain}} and {{FastGettext.default_text_domain}} , the latter of which is not thread local .
Add Comment
Jira (PUP-8040) Puppet does not initialize I18N locale per thread
Title: Message Title
Maggie Dreyer updated an issue
Puppet / PUP-8040
Puppet does not initialize I18N locale per thread
Change By:
Maggie Dreyer
From a few hours of investigation, the puppetserver appears to track translation repositories from compile to compile, but either "forgets" about the locale after each compile, or must have the locale initialized in EVERY thread individually.Some technical details:- {{Puppet::GettextConfig.initialize_i18n}} checks {{translation_repositories}} before initializing {{FastGettext.locale}}, and thus only initializes the locale once ever (see https://github.com/puppetlabs/puppet/blob/5.3.2/lib/puppet/module.rb#L427-L446).- {{FastGettext.translation_repositories}} are a class variable. According to the FastGettext readme, {{FastGettext.locale}} must be initialized once per thread: https://github.com/grosser/fast_gettext#3-choose-text-domain-and-locale-for-translation- The locale should be negotiated at every module load, contrary to what this says: https://github.com/puppetlabs/puppet/blob/5.3.2/lib/puppet/gettext/config.rb#L83-L84 (watch out for performance implications) but the translation repositories should only needed to be loaded once.We are going to explore refactoring the gettext initialization code to skip the logic around {{available_locales}} and {{FastGettext.locale}} in favor of just setting {{FastGettext.default_locale}} to the system locale directly, since {{default_locale}} is not thread local, unlike {{FastGettext.locale}}. That library should already handle the fallback cases from this configuration (though we will be writing tests to verify this, see PUP-8080). In order to avoid breaking other users of GettextSetup, we will likely be implementing most of this directly in Puppet as gettext utils, and drop our runtime dependency on GettextSetup. It looks like we might run into a similar issue when we start trying to use more text domains (see PUP-8013 and https://github.com/grosser/fast_gettext/blob/master/lib/fast_gettext/storage.rb#L54) as the current text domain also appears to be a thread-local variable. Currently we're avoiding issues here by only using one text domain which is both set as {{FastGettext.text_domain}} and {{FastGettext.default_text_domain}}.
Add Comment
Jira (PUP-8040) Puppet does not initialize I18N locale per thread
Title: Message Title
Maggie Dreyer updated an issue
Puppet / PUP-8040
Puppet does not initialize I18N locale per thread
Change By:
Maggie Dreyer
From a few hours of investigation, the puppetserver appears to track translation repositories from compile to compile, but either "forgets" about the locale after each compile, or must have the locale initialized in EVERY thread individually.Some technical details:- {{Puppet::GettextConfig.initialize_i18n}} checks {{translation_repositories}} before initializing {{FastGettext.locale}}, and thus only initializes the locale once ever (see https://github.com/puppetlabs/puppet/blob/5.3.2/lib/puppet/module.rb#L427-L446).- {{FastGettext.translation_repositories}} are a class variable. According to the FastGettext readme, {{FastGettext.locale}} must be initialized once per thread: https://github.com/grosser/fast_gettext#3-choose-text-domain-and-locale-for-translation- The locale should be negotiated at every module load, contrary to what this says: https://github.com/puppetlabs/puppet/blob/5.3.2/lib/puppet/gettext/config.rb#L83-L84 (watch out for performance implications) but the translation repositories should only needed to be loaded once.We are going to explore refactoring the gettext initialization code to skip the logic around {{available_locales}} and {{FastGettext.locale}} in favor of just setting {{FastGettext.default_locale}} to the system locale directly, since {{default_locale}} is not thread local, unlike {{FastGettext.locale}}. That library should already handle the fallback cases from this configuration (though we will be writing tests to verify this, [ticket to be filed] see PUP-8080 ). In order to avoid breaking other users of GettextSetup, we will likely be implementing most of this directly in Puppet as gettext utils, and drop our runtime dependency on GettextSetup.
Add Comment
This message was sent by Atlassian JIRA (v6.4.14#64029-sha1:ae256fe)
Jira (PUP-8040) Puppet does not initialize I18N locale per thread
Title: Message Title Maggie Dreyer updated an issue Puppet / PUP-8040 Puppet does not initialize I18N locale per thread Change By: Maggie Dreyer Story Points: 3 Add Comment This message was sent by Atlassian JIRA (v6.4.14#64029-sha1:ae256fe) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at https://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.
Jira (PUP-8040) Puppet does not initialize I18N locale per thread
Title: Message Title Larissa Lane commented on PUP-8040 Re: Puppet does not initialize I18N locale per thread Thanks for the updated description Maggie Dreyer Add Comment This message was sent by Atlassian JIRA (v6.4.14#64029-sha1:ae256fe) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at https://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.
Jira (PUP-8040) Puppet does not initialize I18N locale per thread
Title: Message Title
Maggie Dreyer updated an issue
Puppet / PUP-8040
Puppet does not initialize I18N locale per thread
Change By:
Maggie Dreyer
From a few hours of investigation, the puppetserver appears to track translation repositories from compile to compile, but either "forgets" about the locale after each compile, or must have the locale initialized in EVERY thread individually.Some technical details:- {{Puppet::GettextConfig.initialize_i18n}} checks {{translation_repositories}} before initializing {{FastGettext.locale}}, and thus only initializes the locale once ever (see https://github.com/puppetlabs/puppet/blob/5.3.2/lib/puppet/module.rb#L427-L446).- {{FastGettext.translation_repositories}} are a class variable. According to the FastGettext readme, {{FastGettext.locale}} must be initialized once per thread: https://github.com/grosser/fast_gettext#3-choose-text-domain-and-locale-for-translation- The locale should be negotiated at every module load, contrary to what this says: https://github.com/puppetlabs/puppet/blob/5.3.2/lib/puppet/gettext/config.rb#L83-L84 (watch out for performance implications) but the translation repositories should only needed to be loaded once. We are going to explore refactoring the gettext initialization code to skip the logic around {{available_locales}} and {{FastGettext.locale}} in favor of just setting {{FastGettext.default_locale}} to the system locale directly, since {{default_locale}} is not thread local, unlike {{FastGettext.locale}}. That library should already handle the fallback cases from this configuration (though we will be writing tests to verify this, [ticket to be filed]). In order to avoid breaking other users of GettextSetup, we will likely be implementing most of this directly in Puppet as gettext utils, and drop our runtime dependency on GettextSetup.
Add Comment
This message was sent by Atlassian JIRA (v6.4.14#64029-sha1:ae256fe)
Jira (PUP-8040) Puppet does not initialize I18N locale per thread
Title: Message Title Susan McNerney updated an issue Puppet / PUP-8040 Puppet does not initialize I18N locale per thread Change By: Susan McNerney Comment: took 2016.4.9 fix version off as it's unclear the team can make the Oct 26 deadline for that z. Will be updated if that changes. Add Comment This message was sent by Atlassian JIRA (v6.4.14#64029-sha1:ae256fe) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at https://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.
Jira (PUP-8040) Puppet does not initialize I18N locale per thread
Title: Message Title Susan McNerney commented on PUP-8040 Re: Puppet does not initialize I18N locale per thread took 2016.4.9 fix version off as it's unclear the team can make the Oct 26 deadline for that z. Will be updated if that changes. Add Comment This message was sent by Atlassian JIRA (v6.4.14#64029-sha1:ae256fe) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at https://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.
Jira (PUP-8040) Puppet does not initialize I18N locale per thread
Title: Message Title Eric Delaney updated an issue Puppet / PUP-8040 Puppet does not initialize I18N locale per thread Change By: Eric Delaney QA Risk Assessment: Needs Assessment Manual Add Comment This message was sent by Atlassian JIRA (v6.4.14#64029-sha1:ae256fe) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at https://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.
Jira (PUP-8040) Puppet does not initialize I18N locale per thread
Title: Message Title Craig Gomes updated an issue Puppet / PUP-8040 Puppet does not initialize I18N locale per thread Change By: Craig Gomes Sprint: Platform Core KANBAN Add Comment This message was sent by Atlassian JIRA (v6.4.14#64029-sha1:ae256fe) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at https://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.
Jira (PUP-8040) Puppet does not initialize I18N locale per thread
Title: Message Title Craig Gomes assigned an issue to Maggie Dreyer Puppet / PUP-8040 Puppet does not initialize I18N locale per thread Change By: Craig Gomes Assignee: Maggie Dreyer Add Comment This message was sent by Atlassian JIRA (v6.4.14#64029-sha1:ae256fe) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at https://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.
Jira (PUP-8040) Puppet does not initialize I18N locale per thread
Title: Message Title Maggie Dreyer commented on PUP-8040 Re: Puppet does not initialize I18N locale per thread So to be clear, the logic around setting the locale in gettext/config.rb is designed to change the locale to something other than English (the default) only if FastGettext's locale is currently English AND we have a translation set that matches the system locale. What do you mean when you say "manually set to ja"? Manually setting the system locale, or updating the locale in Ruby code? Michael Smith that makes sense to me, the initialize function is hopefully setting the locale to ja when it does the work for Puppet, and then not doing anything around that code thereafter. Add Comment This message was sent by Atlassian JIRA (v6.4.14#64029-sha1:ae256fe) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at https://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.
Jira (PUP-8040) Puppet does not initialize I18N locale per thread
Title: Message Title Michael Smith commented on PUP-8040 Re: Puppet does not initialize I18N locale per thread Ok, while testing this I'm unable to get translations actually working with environment_timeout=unlimited. Turning it to 0 lets me see translations the 1st compilation, then they break again. It doesn't seem to be the GettextConfig.initialize that's causing it either, as this always sees FastGettext.locale as ja. Add Comment This message was sent by Atlassian JIRA (v6.4.14#64029-sha1:ae256fe) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at https://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.
Jira (PUP-8040) Puppet does not initialize I18N locale per thread
Title: Message Title Michael Smith updated an issue Puppet / PUP-8040 Puppet does not initialize I18N locale per thread Change By: Michael Smith Fix Version/s: PUP 5.3.3 Add Comment This message was sent by Atlassian JIRA (v6.4.14#64029-sha1:ae256fe) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at https://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.
Jira (PUP-8040) Puppet does not initialize I18N locale per thread
Title: Message Title Hunter (Hunner) Haugen commented on PUP-8040 Re: Puppet does not initialize I18N locale per thread I'm not sure I understand the need for negotiating locale on every module load. Can you provide more example of what happens, and how to reproduce a problem? My current understanding is that - if you include translations in modules that aren't part of Puppet - those translations will be used inconsistently based on what JRuby they're first loaded into. Printing FastGettext.locale during each compile when _() is called, it is initially set to en and when manually set to ja is reset to en each compile... or perhaps just each thread and I got a different thread each time. I'm not sure about that, but it was not initialized to ja for each sequential compile. Add Comment This message was sent by Atlassian JIRA (v6.4.14#64029-sha1:ae256fe) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at https://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.
Jira (PUP-8040) Puppet does not initialize I18N locale per thread
Title: Message Title Michael Smith commented on PUP-8040 Re: Puppet does not initialize I18N locale per thread What system are you running on? I tend to test with CentOS 7. Add Comment This message was sent by Atlassian JIRA (v6.4.14#64029-sha1:ae256fe) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at https://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.
Jira (PUP-8040) Puppet does not initialize I18N locale per thread
Title: Message Title Hunter (Hunner) Haugen commented on PUP-8040 Re: Puppet does not initialize I18N locale per thread localectl set-locale LANG=ja_JP.UTF-8 will work with puppetserver if you restart puppetserver. I've done this many times. From pry'ing in a puppetserver foreground and looking at ENV I did not see LANG in the environment. Secondly, it seems like LANGUAGE also needs to be in the environment variables for the locales to be loaded, but I didn't verify that fully. Add Comment This message was sent by Atlassian JIRA (v6.4.14#64029-sha1:ae256fe) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at https://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.
Jira (PUP-8040) Puppet does not initialize I18N locale per thread
Title: Message Title
Hunter (Hunner) Haugen updated an issue
Puppet / PUP-8040
Puppet does not initialize I18N locale per thread
Change By:
Hunter (Hunner) Haugen
The modules team have run into an issue with I18N in From a master/agent(s) set up. The crux few hours of investigation, the issue is that when modules are installed on the master pluginsync copies the modules over puppetserver appears to the agents - but pluginsync is not copying over the modules 'locales' directory containing the PO files so the translations are not available on the agent - meaning that on the agents all strings only appear in English regardless of which locale is selected.We believe the fix required is for pluginsync to be updated so that when it is copying modules over to the agents it will include the 'locales' directory and its contents.See below for a more detailed description track translation repositories from Hunter:- The puppetserver ignores all environment variables. /etc/puppetlabs/puppetserver/conf.d/pe-puppet-server.conf needs `jruby-puppet: environment-vars: { "LANG": "ja_JP.UTF-8" compile to compile , but either " LANGUAGE forgets " : "ja_JP.UTF-8" }` or other locales for any translation to happen in about the puppetserver.- `localectl set- locale LANG=ja_JP.UTF-8` does not affect the puppetserver (see above) after each compile , but does affect or must have the puppet-agent because the agent reads environment variables apparently. (This command creates /etc/ locale initialized in EVERY thread individually . conf iirc.) The bug of server-side locales being reset every compile Some technical details :- {{ Puppet::GettextConfig.initialize_i18n }} checks {{ translation_repositories }} before initializing {{FastGettext. locale }} , and thus doesn't set only initializes the locale in each thread once ever (see https://github.com/puppetlabs/puppet/blob/5.3.2/lib/puppet/module.rb#L427-L446) . - {{ FastGettext.translation_repositories }} are global for a class variable. According to the puppetserver but FastGettext readme, {{FastGettext .locale is }} must be initialized once per thread : https://github.com/grosser/fast_gettext#3 - local (according to the FastGettext readme) choose-text-domain-and-locale-for-translation - The locale should be negotiated at every module load, contrary to what this says: https://github.com/puppetlabs/puppet/blob/5.3.2/lib/puppet/gettext/config.rb#L83-L84 (watch out for performance implications) - agent-side _() calls (inside types & providers, for example) are executed on the agent node, but the agent node has no access to the .po files as those translation repositories should only exist on the master. We will have needed to create or reuse a master/agent file distribution mechanism (pluginsync sync's lib/ and tasks sync tasks ad-hoc, but neither sounds great for i18n be loaded once . po files per module) or bundle i18n data in the catalog (nightmare for users bandwidth) or have the master respond to i18n indirector calls?
Jira (PUP-8040) Puppet does not initialize I18N locale per thread
Title: Message Title Michael Smith commented on PUP-8040 Re: Puppet does not initialize I18N locale per thread I'm not sure I understand the need for negotiating locale on every module load. Can you provide more example of what happens, and how to reproduce a problem? My current understanding is that - if you include translations in modules that aren't part of Puppet - those translations will be used inconsistently based on what JRuby they're first loaded into. Add Comment This message was sent by Atlassian JIRA (v6.4.14#64029-sha1:ae256fe) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at https://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.
Jira (PUP-8040) Puppet does not initialize I18N locale per thread
Title: Message Title Michael Smith commented on PUP-8040 Re: Puppet does not initialize I18N locale per thread Also, I think this should be considered in conjunction with PUP-8024, as it has significant implications for the code pointed to here. Add Comment This message was sent by Atlassian JIRA (v6.4.14#64029-sha1:ae256fe) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at https://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.
Jira (PUP-8040) Puppet does not initialize I18N locale per thread
Title: Message Title Michael Smith commented on PUP-8040 Re: Puppet does not initialize I18N locale per thread localectl set-locale LANG=ja_JP.UTF-8 will work with puppetserver if you restart puppetserver. I've done this many times. Add Comment This message was sent by Atlassian JIRA (v6.4.14#64029-sha1:ae256fe) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at https://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.
Jira (PUP-8040) Puppet does not initialize I18N locale per thread
Title: Message Title Hunter (Hunner) Haugen updated an issue Puppet / PUP-8040 Puppet does not initialize I18N locale per thread Change By: Hunter (Hunner) Haugen Summary: I18N Puppet does not working for modules in Master/Agent environments initialize I18N locale per thread Add Comment This message was sent by Atlassian JIRA (v6.4.14#64029-sha1:ae256fe) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at https://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.
