Friday, July 29, 2011

Re: USE_I18N vs. USE_L10N

On Fri, Jul 29, 2011 at 3:48 PM, Masklinn <masklinn@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+unsubscribe@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/django-users?hl=en.

No comments:

Post a Comment