Follow-up Comment #10, task #2614 (project savane):
> 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
[EMAIL PROTECTED] => 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
[EMAIL PROTECTED] => 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
[EMAIL PROTECTED] => 2005-11-22
de_AT.utf8 => 2005-11-22
de_BE => 2005-11-22
[EMAIL PROTECTED] => 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
[EMAIL PROTECTED] => 22.11.2005
de_DE.utf8 => 22.11.2005
de_LU => 2005-11-22
[EMAIL PROTECTED] => 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.
_______________________________________________________
Reply to this item at:
<http://gna.org/task/?func=detailitem&item_id=2614>
_______________________________________________
Message posté via/par Gna!
http://gna.org/
_______________________________________________
Savane-dev mailing list
[email protected]
https://mail.gna.org/listinfo/savane-dev
