On Tuesday 22 November 2005 19:17, Mathieu Roy wrote:
> I believe the following bit of code do the trick already:
>
>
> # The installation configured a specific date format. This is not nice
> # this will prevent locales from being used
> if ($sys_datefmt)
> {
> return strftime($sys_datefmt, $timestamp);
> }
>
> If $sys_datefmt is set, we actually don't care about arguments, apart
> from the timestamp.
Alright, although there are two more calls which don't conform to either the
old or the new format:
files/index.php:156
include/trackers/general.php:319
Those need to be fixed as well. The first call does not seem to be used on
Savane anymore, I guess it is a leftover of the old sourceforge days?
The second call is a bit tougher. The cleanest solution would be to rewrite
trackers_field_date() to accept a unix timestamp instead of a preformatted
date, because this is the format which is used all over in the database and
is our internal date representation. However, this is probably too much to
do on the current branch for the 1.3 release.
> > > No no, we cannot remove it. It is used on several installation
> > > that use no localization at all and want to push a unique kind of
> > > date format. If installation want this, we must keep it for them,
> > > even if it is a not a recommended usage. And if it display dates
> > > in a stupid fashion, it is their problem, not ours, we did our
> > > part the best we could.
> >
> > Hm, if you think that we must support this abuse, I guess I have no
> > chance ;-)
> >
> > But seriously, this approach is not consistent. Even though most
> > date displays can be controlled by $sys_datefmt, there are some
> > displays which use their own (hard-coded) date format, e.g. the
> > feature boxes and the display for "Member since June 2004".
>
> No they don't, no longer. Now feature boxes use "minimal" and the
> display for "Member since x..." use the usual model.
True, I wasn't up to date.
> > I still think we should fade out the support for this custom date
> > format. The change doesn't have to be abrupt, we can fade out the
> > support over the next few releases.
>
> I tell you, it is not like if it was an option. The major contributor
> to Savane, which is CERN, does not want any localization, neither in
> dates, neither in text. They want it English only for reasons that are
> none of our business.
>
> It cost us nothing to let them forcing a specific date format, so we
> let it go.
OK. I'm sad to hear that, but I guess that's the way things are.
> > We seem to agree that $sys_datefmt is an unlucky configuration
> > option and is not recommended by the Savane development team because
> > it has several drawbacks. So why keep this forever, instead of
> > providing good alternatives so that the need for a custom date
> > format is eliminated?
>
> There are no real alternative. We want Savane to be i18n-aware, CERN
> wants the contrary.
> When it cost us nothing to satisfies both upstream and CERN, is it not
> really an option to make one unsatisfied just for the sake of
> cohesion.
>
> $sys_datefmt is an unlucky configuration, that should not be used in
> most cases. Unless the people running a given installation really want
> to push hard a specific date format. We must not lock this door. We
> can just keep it closed by default.
I agree. How about changing the configuration help text to something more
explicit, then? It currently says:
Date formatting. If you want to use the default locale formating, comment
out (it's usually a good idea)
Can we change the help text to:
Date formatting. Savane normally does a pretty good job at providing a
correctly localized date. Unless you really know what you are doing, leave
this commented out.
... and, by the way, the item just before that one seems to be wrong:
AskSetting("sys_default_locale", "Default locale", "It must be a valid
locale name.", "french", $sys_default_locale);
Shouldn't the example value be "german" instead of "french"? No, just
kidding ;-) I think the example should be fr_FR, no?
Cheers,
--
Tobias
"Only two things are infinite, the universe and human stupidity,
and I'm not sure about the former" -- Albert Einstein
pgp9J41UzUrD8.pgp
Description: PGP signature
