Tuesday 22 November, vers 19h, Tobias Toedter tapota :

> 
> (No need to CC me, I'm subscribed)
> 
>
> On Tuesday 22 November 2005 09:59, Mathieu Roy wrote:
> > Monday 21 November, vers 20h, Tobias Toedter écrivit :
> > > 1. The inverted parameters in format_date() and
> > > utils_format_date() are a sure way to mess things up sometime. I
> > > would strongly suggest to uniform the calls; I can do the
> > > necessary conversions in the code.
> > 
> > That would sounds good but I'd like such thing to be delayed after
> > 1.3 release.
> 
> Hm, there's currently a bug which would prevent this to work. The
> function format_date() accepts a strftime() format string as
> parameter, the new utils_format_date() accepts only descriptional
> text (default, minimal, short). Thus, you can't just call
> utils_format_date() from format_date() the way you do it now.
> 
> We can resolve this in two ways: Either revert the utils.php changes
> in your branch completely, or fix all calls to format_date in the
> code, using the new format parameter (and then changing the
> parameter order as well).
> 
> As I already said, I offer to perform the latter option on your
> branch. I could do this tomorrow during the work hours, cause I have
> a day off. We could synchronize then, so no merging errors should
> occur.
> 
> If you don't like this option, I propose to create a new branch for
> the format_date() issue and to merge this into the mainline after
> we've released Savane 1.3.


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.

> > 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.

> 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. 

 
> 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. 


-- 
Mathieu Roy

  +---------------------------------------------------------------------+
  | General Homepage:           http://yeupou.coleumes.org/             |
  | Computing Homepage:         http://alberich.coleumes.org/           |
  | Not a native english speaker:                                       |
  |     http://stock.coleumes.org/doc.php?i=/misc-files/flawed-english  |
  +---------------------------------------------------------------------+

_______________________________________________
Savane-dev mailing list
[email protected]
https://mail.gna.org/listinfo/savane-dev

Reply via email to