I'm going to give this one more pass and then dropout. We're just going around in circles now.
On Mon, 2007-06-18 at 12:09 -0700, Jonas wrote: > On 18 jun, 00:04, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote: > > On Sun, 2007-06-17 at 06:13 -0700, Jonas wrote: [...] > The problem is that you think that everybody would have to know the > english months names, By default, Django uses (North American) English. So, yes, we do assume people know English when using Django in the default locale. If they don't, that is what the very comprehensive translation infrastructure is for. Month names are not going to be the greatest hurdle for a non-English speaker here. > and to feel comfortable with the USA date > format. > In USA is used: *Month Day Year*. But in another countries the people > could use another formats like *Day Month Year* In many countries multiple variations on the theme are used in different contexts and there isn't mass confusion. Let's try to get past the notion that there is a single format used uniformly throughout any individual country. > > They are all also marked as translatable by Django, so people using > > other languages see localised, similarly unambiguous versions of those > > strings. > I'm agree. But the settings should be set by default to that > international format by I just say in the anterior paragraph. You assert this, but without supporting arguments except pointing to some documents that use benefits and drawbacks we already acommodate. The (extra, not mentioned in the links you gave) reason we can use the current format is that it's a very familiar format for native English speakers. There isn't any ambiguity and it looks like it was written to be read by humans and not computers. Humans think of months as January, February, March, etc, not 1, 2, 3, 4... > > > > Django is a project used by an international community (and grown by > > > that community) and its configuration should be set to an > > > international format by default. > > > > "International format" can mean a lot of things, not all of them good. > > One very strong argument against using an ISO format (which is > > well-defined and is what the original ticket was about) is that it isn't > > a very human-friendly string. If your friends asks you what the date is, > > you don't say "2007-06-18", you say "June 18". The goal of a date format > > is to unambiguously describe the date and time in a way that is > > understood by the reader. That is the main justification given in the > > links you posted earlier, too, if you have a look. However, none of > > those links address the human-readable phase particularly clearly. We > > meet the unambiguous and clear in all locale requirements with our > > current setup. If a website says "today is 2007-06-18 08:52", it is > > designed for people who are very familiar with computers and willing to > > compensate for some odd constructs like that; it isn't written to be > > invisible. > It has not been created to be human-friendly else so that it can be > understood by anyone. This assertion (not user friendly) is not something I can agree with. Month names are particularly friendly to humans. It's why we invented them. Which group of English speakers does not understand June 18, 2007? They may choose to use "18 June 2007" sometimes, but they will understand the reverse format without even thinking, where as "2007-06-18 09:32" requires some parsing (is it this month? next month?...). Do you really say 2007-06-18 when your friends ask you what the date is? Does your grandmother, who doesn't use computers as much as you do, use that format? We are trying to encourage websites that feel natural to all users, not just friendly for people who have used computers all their lives. > That's the function of an international format. It's also a function supported by other formats. This isn't an either/or discriminator. > I don't say that location of date and time shouldn't be used, else > that by defect would have to be selected the international format. Or > perhaps, does Django has the location about date and time for all > countries? I don't understand what you're trying to say here. However, if I'm guessing right, I think your concerns can be addressed by pointing out that if your particular locale has a very uniform date time format and it matches the ISO format, that is something the translator for your locale should be using. The default date and time format strings are all translated strings. So the translator for a locale that always uses ISO format should be putting that format into the PO file for DATE_FORMAT, etc. Realistically, there isn't going be an answer that everybody agrees with 100% for this issue. The fact that you feel it is such a serious thing shows that. However, your proposal also hasn't collected any significant support that has raised issues that aren't already addressed, so I can't see it as a really serious problem with the current state of affairs. There are always alternative choices for things like this. We have to choose one. You would prefer we made a different choice, but there are as many arguments against that as against the current system; they are just different arguments. As I've mentioned a couple of time, Django's choice errs on the side of being like the strings you would see in a newspaper or on a sign on the street. We've also made it customisable for those who want something different on their site and translatable so that other locales can use their more traditional formats. I think that comes close to covering all bases. Best wishes, Malcolm --~--~---------~--~----~------------~-------~--~----~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~----------~----~----~----~------~----~------~--~---
