I like this quite a bit. It's clean, and it allows for a common i18n pattern
where the footer contains a translation link for each supported language, and
the language names are localized to themselves (i.e. "Español | Français |
Deutsch").
Sam
On 2011-07-04, at 5:23 AM, brocaar wrote:
> On
On 2011-06-29, at 5:27 AM, Daniel Swarbrick wrote:
> Storing the TZ in a separate field is going to get pretty nasty for
> sorting as well, as the query will have to somehow concatenate or
> compute together the two fields before applying the sorting algorithm.
I don't see why. If the datetime
store the timezone.
>
> On Jun 27, 3:12 pm, Sam Bull <osir...@gmail.com> wrote:
>> On 2011-06-02, at 12:34 AM, Stephen Burrows wrote:
>>
>>> Django actually already adds support for some capabilities to certain
>>> database backends, if I'm not mistaken - s
On 2011-06-02, at 12:34 AM, Stephen Burrows wrote:
> Django actually already adds support for some capabilities to certain
> database backends, if I'm not mistaken - such as cascades through GFKs
> on delete.
>
> In terms of time zones, could django "assume"/ensure that the datetime
> stored in
Hey,
I've got a reusable app that offers the functionality you're looking for, I
think. I just commented on the ticket, so I hope this doesn't count as
double-posting, but you can check it out here:
https://github.com/trapeze/fancy_tag
It's got unit tests, keyword argument support (like the
