Web Images Videos Maps News Shopping Gmail more »
Recently Visited Groups | Help | Sign in
Google Groups Home
Status and feedback needed
There are currently too many topics in this group that display first. To make this topic appear first, remove this option from another topic.
There was an error processing your request. Please try again.
flag
  2 messages - Collapse all  -  Translate all to Translated (View all originals)
The group you are posting to is a Usenet group. Messages posted to this group will make your email address visible to anyone on the Internet.
Your reply message has not been sent.
Your post was successful
 
From:
To:
Cc:
Followup To:
Add Cc | Add Followup-to | Edit Subject
Subject:
Validation:
For verification purposes please type the characters you see in the picture below or the numbers you hear by clicking the accessibility icon. Listen and type the numbers you hear
 
Marc Garcia  
View profile  
 More options Jul 3, 6:56 am
From: Marc Garcia <garcia.m...@gmail.com>
Date: Fri, 3 Jul 2009 03:56:23 -0700 (PDT)
Local: Fri, Jul 3 2009 6:56 am
Subject: [soc2009/i18n] Status and feedback needed
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


    Reply to author    Forward  
You must Sign in before you can post messages.
To post a message you must first join this group.
Please update your nickname on the subscription settings page before posting.
You do not have the permission required to post.
Reiner  
View profile  
 More options Jul 4, 4:52 am
From: Reiner <mr.squ...@googlemail.com>
Date: Sat, 4 Jul 2009 01:52:48 -0700 (PDT)
Local: Sat, Jul 4 2009 4:52 am
Subject: Re: Status and feedback needed
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


    Reply to author    Forward  
You must Sign in before you can post messages.
To post a message you must first join this group.
Please update your nickname on the subscription settings page before posting.
You do not have the permission required to post.
End of messages
« Back to Discussions « Newer topic     Older topic »

Google Groups - Google Home - Terms of Service - Privacy Policy
©2009 Google