Re: Idea for i18n fields

[akaariai]

On Jul 2, 12:59 am, Ric  wrote:
> Hi there,
>
> i have got a simple approach to make all django fields with a full
> i18n support
>
> the django.models.fields.Field class can be subclassed like this
>
> from django.db import models
> from django.utils.translation import get_language
>
> class i18nField(models.Field):
>
>     def __init__(self, i18n = False, *args, **kwargs)
>         self.i18n = i18n
>         models.Field.__init__(self, *args, **kwargs)
>
>     def db_column_get(self):
>         if not self.i18n:
>             return self._db_column or self.name
>         return "%s_%s" % (
>             self._db_column or self.name,
>             get_language().lower()
>             )
>
>     def db_column_set(self, value):
>         self._db_column = value
>
>     def _column_set(self, value):
>         pass
>
>     db_column = property(db_column_get, db_column_set)
>     column = property(db_column_get, _column_set)
>
> then you can declare all other subfields as usual
>
> this work in that way: you need a separate db column for every
> language installed.
> a field called "name" needs to create ("name_%s" % code for code in
> languages) columns
>
> so the framework automatically select the right column in every query.
>
> problems:
>  - serializing objects, you need to serialize all all fields, not just
> current language
>  - many to many fields, to work they need to create an extra column in
> every througth table, a column to store the language code.
>  - during sync db you need to create a column for every language
> installed
>
> after two years on an i18n django site, i found this simple solution.
> there are some small problems, that can be fixed if we put a i18n
> option when you init a field, and solve some issue during syncdb
> command and serialization of objects.
>
>  for me is a very simple approch,
> it automatically filter, sort and output the right queryset for your
> language, and when you access a field you get the current language, it
> works for every field, ForeignKeys too.
>
>  and it works in admin (with no changes at all)
>
> let me know what you think.

>From my point of view there are a couple of problems with this
approach:
  - The idea of putting a column for all translated languages for
every field directly to the base table is not feasible for many use
cases. If you have 10 translated fields in your model, and you have 10
languages, that is already 100 fields. If you happen to need an index
on one field, you need 10 indexes. For example in EU you might need to
have the possibility to have the model translated in all official EU
languages. That is over 20 languages you need to support right there.
For the EU use case it is better to have a translations table
containing the translations of one language in one row.
  - This approach makes it hard to fetch all the translations of the
model. How does this work for NOT NULL fields?
  - There are ways to have proper fields for every translation in the
DB table. It is better that there is 'name' field which fetches the
default language according to the currently active language, and then
there are the translated fields ('name_fi', 'name_en', ...) if you
need those. See django-transmeta for one such solution (http://
code.google.com/p/django-transmeta/).

For some use cases your solution definitely can be handy. But my
feeling is that this does not belong to core (not that I have any
power in deciding that). The biggest reason for this is that the more
I have worked in different multilingual projects, the more certain I
am that there is no single solution to model translations. At least no
single solution how to handle the database layout part of it.

 - Anssi

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Forced password reset in django-admin

[Wim Feijen]

Hi Bejamin,

Sounds like a cool feature: probably when you build such a thing, it
will be used by dozens (or thousands). I noticed that I am making a
lot of use of custom registration processes. Most of the time, I use
django-registration as a solid basis, are you familiar with that?

Best regards,

Wim

On 30 jun, 12:08, benjaoming  wrote:
> Hello again!
>
> > What you have suggested here **is** an invasive change, because it
> > requires changes to existing code paths.
>
> I think the way to measure "invasive" is by means of backwards
> compatibility. We do not change required arguments, return value or
> model fields... The view normally responds with an
> HttpResponseRedirect object, and that's also the case here.
>
> > A setting is not a good way to
> > make something configurable here. A keyword argument here *would* be an
> > acceptable solution.
>
> You're right. Keywords argument is a good idea!
>
> > However, I don't think it would be that useful, because if it was off by
> > default, and controlled by a keyword argument, then the admin login view
> > wouldn't use it. I think this needs more thought.
>
> True! Actually this speaks against the use of a keyword argument as
> sole option.
>
> Keyword option: Local per-view behavior
> Setting variable: Project-wide behavior used when there is no kwarg
> present
>
> > Again, I should mention that features like this get implemented by the
> > community. If you need it, the way to do it is to build it, and then
> > persuade us to use it - not to try to persuade *us* to build it :-)
>
> I'm actually trying to persuade myself to build it in case there's
> enough support+discussion for it.
>
> > BTW - this doesn't actually force the password reset - it logs them in
> > and then asks them to change their password. If they don't they are
> > still logged in.
>
> Yup, that needs more thought!
>
> all the best,
> Benjamin

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: "c" date formating and Internet usage

[Yohan Boniface]

I've created a ticket to propose a little change in the documentation :
https://code.djangoproject.com/ticket/16392

Yohan

2011/6/29 Yohan Boniface 

> 2011/6/28 Stephen Burrows 
>
>>
>> The "O" formatter - or more specifically, the "Z" formatter - does
>> include that bit of magic. Is there a particular reason for this?
>>
>
> I ask myself the same question. Why for the "Z" (and co) and not for the
> "c" ?
>
>
>> Also, if a timezone is assumed, wouldn't it make more sense to assume
>> the timezone of the project rather than UTC? Rather than noting an
>> inconsistency, can we make this consistent?
>
>
> Defining the default behaviour when the datetime is naive is not that easy,
> in my point of view.
>
> Here is the summary of what I understand (we are talking about the Django's
> dateformat util) :
>
> 1. when the datetime has a timezone, use it : this is what Django does, and
> it's fine.
> => In my point of view, the documentation should be clearer (about the fact
> that the "c" formatter, using isoformat, will add the timezone offset only
> for non naive datetime and about the fact that this behaviour is not
> consistent with other formatters)
> => I'll propose some little patch
>
> 2. when the datetime is naive, what to do ?
> => like I said, I think the answer is not that easy, and Django is not
> completely coherent on the subject
>
>  2.1 Do nothing
>  => this is what Django does for the "c" formatter (as using the
> .isoformat datetime method) [1]
>  => easier, clearer (no magic), but not so user friendly : it means that
> when dealing with naive datetimes, developpers have to manually add the
> timezone everytime (error-prone, not very DRY...)
>
>  2.2 Use the system local timezone
>  => this is what Django does for the "Z" and "O" formatters for example
> (using the time.timezone / .altzone function) [2] [3]
>  => basing the default timezone on the machine local one could be risky
> (and not so "cloud" aware...)
>
>  2.3 Use the settings.TIME_ZONE information
>  => I wonder why this setting is not used by Django here
>  => in theory, this sounds like a good default behaviour
>
>  2.4 Missing something ?
>
> And so the final question is : is there a "good" way to arbitrate the
> handling of naive datetime when formatting them ?
>
> [1]
> https://code.djangoproject.com/browser/django/trunk/django/utils/dateformat.py
> #L126
> [2]
> https://code.djangoproject.com/browser/django/trunk/django/utils/dateformat.py
> #L269
> [3] 
> http://docs.python.org/library/time.html
> #time.timezone 
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.