Re: A new setting for custom gettext domains?

On Monday, August 24, 2015 at 3:30:56 PM UTC+2, Krzysio Gutkowski wrote: > > Hi, > > It looks that implementing it in that ways makes more sense. > > However, if I were to implement it in that way, should I change both > settings in one PR, or should I rework the LOCALE_PATHS setting in a > separ

Re: A new setting for custom gettext domains?

Hi, It looks that implementing it in that ways makes more sense. However, if I were to implement it in that way, should I change both settings in one PR, or should I rework the LOCALE_PATHS setting in a separate PR? -- You received this message because you are subscribed to the Google Groups

Re: A new setting for custom gettext domains?

In my opinion, the question to ask when wondering if a configuration should be a setting or not is: is this setting supposed to be changed for different installations. In this case, I would answer no. So I think this is more an application configuration thing which could be appropriate in an Ap

Re: A new setting for custom gettext domains?

Hi, I think the setting is worth it, it can be really useful when working with complex translation setups. However, I feel that LOCALE_FILENAMES is a poor choice for the setting name, as it differs from standard gettext terminology in a very unclear way. Why not name it LOCALE_DOMAINS? (To me, _F

Re: A new setting for custom gettext domains?

Personally (I'm the author of this PR) this is useful to me as I am using pycountry to get currency names in my project, and i can't get the translations to load without modifying the structure of that package, which shouldn't really be done. W dniu wto

A new setting for custom gettext domains?

Since adding new settings is sometimes controversial, I wanted to ask for thoughts about this ticket [1] / pull request [2] which proposes a new LOCALE_FILENAMES setting to allow using additional gettext domains besides "django". I don't use translations myself, so thoughts about whether the us