|
Tue 22 Nov 2005 08:53:41 AM UTC, comment #10:
> Follow-up Comment #9, task #2614 (project savane):
>
> Hm, I don't agree with you here.
>
> > We we certainly not waste time to manage every possible locale
> > on earth while date() already do that.
>
> We would not have to support every locale on earth, but only the few
> locales we already support (seven). All other locales are not
> supported by Savane anyway.
For the dates, all the one managed by date are, even if the dont
translate the rest.
But there's a bug in the way we set locales. We can assume en_US and
en_GB provide the same language, but we should not set LC_DATE to
en_US but to the real language provided.
So we should set LC_ALL differently that LC_DATE.
> Second, it cannot be used when we want to specify additional
> information. For example, the string '%a %x, %R' is not
> localized. For German, I need to use '%a, %x, %R' instead. It's the
> same with '%A %x '._("at").' %R %Z', which would need to be _('%A %x
> at %R %Z').
We can change '%A %x '._("at").' %R %Z' to _('%A %x at %R %Z'), no?
> My thinking is that if we support l10n, we should do it with no
> exception. The difference between using "%x" and e.g. "%d %B %Y" is
> only to provide the translator with a more fine-grained control of
> how the date is going to be displayed. While it might be fine to
> write "Monday 21 November 2005" in one language, another language
> might require "21 November Monday 2005". This would not be possible
> by using "%x".
No no is localized and will now in which order days, month and all
need to be ordered.
%x locale’s date representation (mm/dd/yy)
> Note that I'm not arguing in favour of using "%s" in a simple
> sprintf and manually translating all weekday and month names. We
> already take advantage of the localization done in the C library --
> we only take over more control of how things are done.
%x already does this for us.
Look at
br_FR@euro => 22.11.2005
br_FR.utf8 => 22.11.2005
bs_BA => 22.11.2005
bs_BA.utf8 => 22.11.2005
byn_ER => 22/11/2005
ca_ES => 22/11/05
ca_ES@euro => 22/11/05
ca_ES.utf8 => 22/11/05
cs_CZ => 22.11.2005
cs_CZ.utf8 => 22.11.2005
cy_GB => 22.11.05
cy_GB.utf8 => 22.11.05
da_DK => 22-11-2005
da_DK.iso885915 => 22-11-2005
da_DK.utf8 => 22-11-2005
de_AT => 2005-11-22
de_AT@euro => 2005-11-22
de_AT.utf8 => 2005-11-22
de_BE => 2005-11-22
de_BE@euro => 2005-11-22
de_BE.utf8 => 2005-11-22
de_CH => 2005-11-22
de_CH.utf8 => 2005-11-22
de_DE => 22.11.2005
de_DE@euro => 22.11.2005
de_DE.utf8 => 22.11.2005
de_LU => 2005-11-22
de_LU@euro => 2005-11-22
de_LU.utf8 => 2005-11-22
el_GR => 22/11/2005
el_GR.utf8 => 22/11/2005
you will see that things got in proper place. So it save us the time
of reimplementing that.
But we need to make sure LC_DATE got properly set, not
approximatively. Because while for LC_MESSAGE de_LU is more or less
equal to de_DE, for LC_DATE we really need to set it to de_LU.
|
Mon 21 Nov 2005 07:05:35 PM UTC, comment #9:
Hm, I don't agree with you here.
> We we certainly not waste time to manage every possible locale
> on earth while date() already do that.
We would not have to support every locale on earth, but only the few locales we already support (seven). All other locales are not supported by Savane anyway.
On top of that, the date() localization is not sufficient for our purposes. First of all, it does not solve the ambiguity mentioned in bug #4542 (06/11/05 vs. 11/06/05).
Second, it cannot be used when we want to specify additional information. For example, the string '%a %x, %R' is not localized. For German, I need to use '%a, %x, %R' instead. It's the same with '%A %x '._("at").' %R %Z', which would need to be _('%A %x at %R %Z').
My thinking is that if we support l10n, we should do it with no exception. The difference between using "%x" and e.g. "%d %B %Y" is only to provide the translator with a more fine-grained control of how the date is going to be displayed. While it might be fine to write "Monday 21 November 2005" in one language, another language might require "21 November Monday 2005". This would not be possible by using "%x".
Note that I'm not arguing in favour of using "%s" in a simple sprintf and manually translating all weekday and month names. We already take advantage of the localization done in the C library -- we only take over more control of how things are done.
In conclusion, if we want to provide additional information such as weekdays and times to "%x", we need to go for the fine-grained control approach.
|
Mon 21 Nov 2005 03:49:40 PM UTC, comment #8:
> Finally I put back %a into short and %A into default
(Because the name of the day makes a lot easier to guess a date)
|
Mon 21 Nov 2005 03:49:14 PM UTC, comment #7:
Finally I put back %a into short and %A into default
|
Mon 21 Nov 2005 03:37:13 PM UTC, comment #6:
I reworked your work so utils_format_date() and format_date() are aliases (with arguments in this different order though, the order the new utils_format_date() is better than the one of format_date() but I dont have time to update all format_date() calls) and it is compatible with previous calls.
Here's the list of available styles
case 'short':
{
# To be used in tables, nowhere else
return strftime('%x, %R', $timestamp);
}
case 'minimal':
{
# To be used where place is really lacking, like in feature boxes.
# (Nowhere else, it is too uninformative)
return strftime('%x', $timestamp);
}
default:
{
# Used by default
return strftime('%a %x '._("at").' %R', $timestamp);
}
|
Mon 21 Nov 2005 03:10:11 PM UTC, comment #5:
Ok, I'm a bit puzzled right now.
---------------------
Having utils_format_date() deprecating format_date() seems quite hard to understand. For now on, there are a few aliases that are exactly like the function they are aliases of without the first part (utils_). And then, here, we have format_date() that would not be an alias of utils_format_date()? Ouch!
Also, in fact, why cant we just add an extra parameter to format date so nothing in the code would have to be changed, we should just have to get format_date used where it is missing?
----------------------
Short and minimal are too long. When we want minimal, we want "18.11.2005" or "18/11/2005", nothing longer. And short provide a long month name but it miss the hour.
Finally, it is not the clean way to put up a default which is not a localized one. We we certainly not waste time to manage every possible locale on earth while date() already do that.
To make it clear, the only date strings that should be used are:
%c locale’s date and time (Sat Nov 04 12:02:33 EST 1989)
and
%A locale’s full weekday name, variable length (Sunday..Saturday)
%x locale’s date representation (mm/dd/yy)
%X locale’s time representation (%H:%M:%S)
The others are not acceptable. To get something working, I think we should
have
normal = "%A %x at %X " with the seconds striped, cause we dont care of seconds, and with "at" inside, something a little verbose, not just numbers
short = "%x at %X" with the seconds striped, would be used in tables and things like that
minimal = "%x", that would be used for instance in feature boxes.
If we can't strip seconds from %X, then we'll be forced to use %R.
---------------------------
$sys_datefmt only purpose is for an installation to force something. It should not be used actually but most installation, only on rare occasions.
We should not care about it, only make sure it is taken into account.
|
Sat 19 Nov 2005 07:22:56 AM UTC, comment #4:
And I realize this could be another topic of "CODING STYLE" documentation :)
|
Sat 19 Nov 2005 07:22:30 AM UTC, comment #3:
utils_unixtime_to_date() is quite long to type and make big lines.
Could you add aliases like
utils_cleandate()
and
cleandate()
The problem with long function names that exactly states what they are actually doing is the fact that by reading the code, you know exactly what they do but you dont know exactly why you want to do things like that.
I think we should probably rename plenty of function that are too technical in their meaning and yet unclear about when people should use them. The consequence of that is that people tend to forget to use it because they dont want to guess the intended usage of all functions.
With a thing like cleandate(), the guy working on the code not using cleandate() will automatically guess he's not putting the date in the cleandate() format we would want.
|
Fri 18 Nov 2005 11:05:24 PM UTC, comment #2:
Alright, I wrote a new function utils_unixtime_to_date() which will take care of doing the Right Thing(tm).
Currently, it does nearly the same as the former function format_date(), except that it accepts "default", "short", and "minimal" as format parameters.
It's not used anywhere in the code right now, but I plan to rewrite all calls to format_date (and strftime) with the new function.
|
Fri 18 Nov 2005 07:47:32 AM UTC, comment #1:
Sounds good.
Apart the latest step. As said before, Savane is not the place where people should configure their desktop environment. The calendar is just alike the langage. That the kind of information we must obtain from the desktop via the browser, or deduct.
The function should transparently support different calendars if any, but nowhere in the pages code we should ask for a given calendar.
|
Fri 18 Nov 2005 01:49:08 AM UTC, original submission:
Based on the discussion in bug #4570, I think it's probably a good idea to make Savane agnostic about the calendar which is being used.
This could also help to solve bug #2198 and bug #4542.
I propose in the first step to use format_date() everywhere in the code and remove all direct calls to strftime (there are only four in the entire code base).
Second, the call to format_date() should be modified. Currently, format_date() takes as the first parameter the format to be used. In almost all calls, this is set to $sys_datefmt, which is kind of pointless.
Instead of specifying a format parseable by strftime, we could specify a human readable string with the (meta-)format to be shown.
Examples:
format_date($date, "long");
=> Fri, 18 November 2005 02:33
format_date($date, "short");
=> 18 November 2005
format_date($date, "ultrashort");
=> Nov 2005
format_date($date, "relative");
=> today
The function could then be extended to support different calendars quite easily, just add a third parameter:
format_date($date, "long", "jalali");
=> 27 Aban 1384 02:33 (Warning: this is just guessing ...)
What do you think?
|
Related Recipes:
Savane - Tasks: task #2614, Support different calendar systems