[soc2009/i18n] Status and feedback needed

[Marc Garcia]

Hi folks,

my exams are over, and I'm more than 100% on Django i18n right now.

I've been researching and testing many different options for the part
of displaying values in localized formats, and I have some conclusions
that I would like to discuss with you:

* It'll be a USE_FORMAT_I18N setting, defaulting to False, to avoid
automatic changes on websites after a Django upgrade (and letting
users not use this new feature of course).
* IMHO, Django should localize dates, times and numbers
automatically, when displaying values from database (another option is
forcing to use a filter in templates, like {{ my_field|localize }} but
I don't think it's the right way).
* We should avoid localizing data everywhere, so it could cause
problems, for example if we change the format of data when saving it
to fixtures. I'm not sure on that, may be we can do the opposite,
localizing by default when casting a field to a string, and allow not
doing it for serialization...
* We should allow a way to not localize data in templates, and even
to localize to a specific locale, and not the current one (an idea
could be creating a filter, so something like {{ my_field|localize
('default') }} or {{ my_field|localize('en') }}, to let users use
default or any locale formats)
* I think it's better to add localization stuff on the models, not
directly on the templates, so we could want to format fields in other
places different from templates (directly in a view...).

I implemented a simple prototyping version of what's explained above
[1], any feedback will be really appreciated.

Cheers and thanks for your comments,
Marc

[1] http://code.djangoproject.com/changeset/11159

[Reiner]

Hello Marc,

first, let me thank you for your work, I will run into these problems
in a couple of months, so I am happy to see you tackling the problem.

> * IMHO, Django should localize dates, times and numbers
> automatically, when displaying values from database (another option is
> forcing to use a filter in templates, like {{ my_field|localize }} but
> I don't think it's the right way).

I have a question about your approach of putting localization into
models. In my opinion, storing data and displaying data are two
different things, so I'm in doubt of coupling these two. I can clearly
see some advantage of having specific model field types automatically
localized, but compared to translations, shouldn't localization be
explicit too? To indicate which variable should be localized? I'm
working with django/python for about half a year now, so maybe I
haven't fully grasped the zen of python/django. :)

> * I think it's better to add localization stuff on the models, not
> directly on the templates, so we could want to format fields in other
> places different from templates (directly in a view...).

My reason to ask here - as I understand it, for example a datetime
field on a model is localized automatically when accessing it in a
template. Say I want to store some monetary value in the database, I
use a decimal field. How can localization on model fields know that it
is supposed to be monetary, and not some other decimal value, like
weight? Maybe one could add a CurrencyField, but what if I compute a
new monetary value in my view, that is not part of the model. This is
not going to be localized automatically, right? So as I see it, I have
model fields that implicitly will be localized when accessed in a
template, and other variables that I explicitly need to localize using
a filter.

I hope someone can help me understanding this a bit better.

Regards,
Reiner