Orestis, please, take into consideration several types of websites:
- English only (common for djangoproject admins) - non-English using one different language (eg. local German website) - several languages (eg. Czech as local language and English for other visitors) - quite common in Europe I believe, that the implementation should be ready for the 3rd option, ie. not being stuck by django-server wide setting for choosing the date format. Radek On 4/26/07, orestis <[EMAIL PROTECTED]> wrote: > > 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 -~----------~----~----~----~------~----~------~--~---
