On Fri, Jul 29, 2011 at 3:48 PM, Masklinn <maskl...@masklinn.net> wrote: > On 2011-07-29, at 06:58 , Russell Keith-Magee wrote: >> To the rest of this thread: I want to head something off at the pass >> right now -- consider it a core-team decision that we're not going to >> rename these settings. I18n and L10n are well understood terms to >> anyone who has been dealing with adapting software to multiple >> languages and cultures reasonable descriptions of what Django does >> with the USE_I18N and USE_L10N settings, and we're not going to change >> the values because someone comes up with a slightly better name. There >> needs to be something fundamentally wrong or misleading before we >> would even consider changing the name of a setting, and given that >> these settings have been in the wild successfully for some time (I >> think it's 4 years in the case of USE_I18N) you're not going to find >> that here. > I think the issue with USE_I18N is not so much that it's been kept, but > that it was not expanded to cover USE_L10N's scope as well, with the > ability to enable or disable each subsection of the domain > (translations and localisation of value formats) added on top of that. > > I would have made more sense, to me, if USE_I18N enabled *all* of the > relevant l10n, m17n and i18n machinery and if new processes in this > field were added to the flag's purview as they were introduced, bringing > a django project with USE_I18N enabled ever closer to full "effective" > internationalization.
If you think things could work better -- we accept patches :-) However, before you embark on a massive rewrite of Django's i18n and l10n systems, keep in mind that there are entirely valid historical reasons why the settings act the way they do -- mostly to do with maintaining backwards compatibility and retaining the ability to opt into potentially expensive (and confusing) options. Any proposal to change Django in a way that loses either of those properties won't be looked upon favorably. In particular, if you think the capabilities of USE_L10N could be subsumed by an expanded interpretation of USE_I18N, I think you need to take a much closer look at Django's source code, and the mailing list discussions that led to the introduction of the USE_L10N setting. Yours, Russ Magee %-) -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com. To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
