So, for Greek: I'll stand by my choice of having more options in the django.utils.dateformat.
But, since Malcolm seems reluctant to change a functionality so basic and simple, maybe something can be put in localflavor, so that each language/country can handle their own needs and peculiarities without bothering everyone else. Maybe a "ldate" or "localdate" filter that: a) Tries to find an implementation in the current locale - localflavor and passes the arguments there and b) failing that, either gives an error message or returns the default date format, using the current django.utils.dateformat This way we free the project administrators from unnecessary decisions about matters they really can't judge as well and leave the current functionality working as before. There could also be a setting like USE_I18N (or it could be the same) that decides which kind of tag it would use - so one could use this in order to decide which kind of filter to use, leading to a bit more complex/magic behavior but gaining in ease of use. --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
