<<< Date Index >>>     <<< Thread Index >>>

Re: mutt/1296: iso date/time format by default



Salut Vincent!

 Le lundi 26 septembre 2005 à 14:52:28 +0200, Vincent Lefèvre écrivait:

> what's the point of using the default locale (C)? By default, Mutt
> should either use the user's current locale or the ISO-8601 format.

    The design is that Mutt is independent from user's current LC_TIME
locale, and uses either a variable one ($locale), or a fixed one
(English C) when the format is !-prepended (default). Changing $locale
and $date_format in hooks permits things like attributing Italians in
Italian on an English system, or the reverse.

    There is a flaw in this design, mutt/1158, in that it doesn't permit
properly to attribute Italians on a French machine... Well it permits,
but then the machine becomes Italian. I proposed to add a new format
modifier forcing current env LC_TIME, providing ability to both any
fixed language in menus, and any other variable language in attributions
(I'd need to deredundantize and XMLize doc).

    There is also a bug, mutt/1734, concerning browser's date
inconsistant in specific conditions. And the configurability level of
this specific date does not compare with other dates elsewhere in Mutt.


    I agree Mutt should by default use LC_TIME localized dates when
displayed in its UI, as any other well-written programs. This seems
evident. An easy modification over my 1158 patch could fix this.

    But for attributions it is discussable: It makes some sense to have
default fixed English. It could also make sense to have default variable
defaulting to LC_TIME.

    One difficulty is the presence of English string " at " in default
$date_format used in default $attribution. And the English wording of
$attribution. This doesn't help localization. We can't have runtime
locale dependant default localized string variables, right?


    [current locale attrib]
> the string shouldn't contain any word or should be language-dependent
> to avoid mixing different languages in a same sentence.

    Bof. This would probably lead to an ugly phrase, or to
over-simplification.


    [ISO-8601 attrib]
> The format I'm using (latter case) would be the simplest solution.

    But you use an ISO-8601 variant that is ugly. Simple, parsable, not
needing localization, but ugly. Universaly readable, but not best
adapted to anyone. I way prefer an English attribution perfect for
English guys, and configurable for others.

    Not that I dislike ISO-8601 as a whole, it's usefull. But it's
usefull in its domain: Parsable only or mixed parsable and readable
strings. I hate it in human readable strings.


Bye!    Alain.
-- 
Everything about locales on Sven Mascheck's excellent site at new
location <URL:http://www.in-ulm.de/~mascheck/locale/>. The little tester
utility is at <URL:http://www.in-ulm.de/~mascheck/locale/checklocale.c>.