I'll push this a little further: In order to handle international sites, one should be able to mark date format strings as translatable. The ordering, punctuation and wording of a date for a specific placement will not be the same for each language, so essentially the date format string is something that should change according to the locale, ergo it should be translatable.
So this points to having one date filter, that is changed to handle translation strings, and since it will know about locales, it would be able to pull custom extensions from the localflavor applications. Thoughts on this ? On Apr 26, 10:25 pm, orestis <[EMAIL PROTECTED]> wrote: > I've searched and this hasn't been brought up before, so I think it's > time to discuss this. I'll post copy of a ticket I've submitted: > > http://code.djangoproject.com/ticket/4147 > ---------------------------------------- > Django's handling of i18n is fairly good, but one major point that it > doesn't handle well (together with almost everything else out there) > is the formatting of dates. > > The most obvious example is the display of the month names. While in > English there is only one case of nouns, in many other european > languages there are more, which have different spellings. For example, > in Greek, in order to be able to diplay full-word months and capture > all possible sentence formats, one needs three cases: > > 1. The subjective case (eg. en: January, 2007 - el: Ιανουάριος, > 2007) > 2. The posessive case (eg. en: 23th of January - el: 23η > Ιανουαρίου) > 3. The objective case (eg. en: Entries posted on January - el: > Δημοσιεύσεις που έγιναν τον Ιανουάριο) > > I'm sure this is common in most european languages, but I'm not an > expert; Please everybody comment on this. > > To implement this in django, I suggest the following: > > * Add MONTHS_POS, MONTHS_OBJ to django.utils.dates. This should > read "of January" and "on January" in english . > * Add a custom extension in django.utils.dateformat: Q for > MONTHS_POS, V for MONTHS_OBJ. Any available letter should do. > > That's all. There is still an issue about the format 'S' that adds the > ordinals (1st, 2nd etc) but I don't know how other languages deal with > this. > > I can submit a patch for this... > ---------------------------------- > To which malcolm replied: > ---------------------------------- > I haven't thought about this enough to really know if this is the > right approach or not. Please have some patience, you are only one of > many people requesting things be added to the code and you only opened > the ticket 24 hours ago. > > Write a patch if you want, it can't hurt. However, I'm trying to think > of some way to do this that maybe doesn't involve creating a bunch of > new settings and format modifiers. It is very important that we also > keep things easy to write the code in the first place. Might be worth > having a discussion on django-i18n first before writing this. Tickets > aren't the best place to have a discussion about a feature. > ---------------------------------- > > So I think I'll start the discussion here. > > Could the translators that have similar issues with cases, genders > etc. point them out ? > > I'll post my thoughts on Greek in another post, to keep things clear. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django I18N" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/Django-I18N?hl=en -~----------~----~----~----~------~----~------~--~---
