Re: clock capplet and nautilus date and time formats

[Carlos Perelló Marín <carlos pemas net>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Peter Nugent wrote:
| Hi Danilo
| yes, I agree the POSIX standard is pretty limited in what you can do
| with it.
|
| The reason I asked the question in the first place is that I was
| thinking of extending the "Locale and Culture capplet" to wrap glibc
| (currently it does ICU only). However, this doesn't make a lot of sense
| if most of GNOME is not using the OS's date and time formatting. The
| other option would be to extend the capplet further to configure other
| app specific stuff.
|
|
| I had a quick look at KDE and the "Country/Region & Language Control
| Center" (which looks pretty much like a glibc interface judging by the
| data in it) does provide a mechanism to configure the desktop clock's
| date and time format and the file manager date and time format. I assume
| they implemented some sort of logic in code to knock off seconds  or
| year or whatever when they don't want to display these things.

I found a way to do that creating our own customized locale in user's
home and was planning to implement it with that capplet. The problem is
that it was a long ago and was so stupid I didn't wrote down how to do
it. Will try to find how to do it and will send you it.

KDE just creates its own classes to handle date and time and all
programs should use them to get it. The way I'm talking about gives you
that feature for all applications that use glibc locales.

|
| GNOME's dispersive , inconsistent approach to locale data looks like a
| pretty big defect. Most competing desktops have a consistent approach.

I agree and that was the point I started the capplet.

Cheers.

|
| thx
| Peter
|
|
|
| Danilo Šegan ha scritto:
|
|>Hi Peter,
|>
|>Today at 12:01, Peter Nugent wrote:
|>
|>
|>
|>>I've noticed that neither the clock applet or nautilus take their date
|>>and time formats from the underlying OS eventhough the do take the day
|>>and month names from it . Is there a reason for this ? and are there any
|>>plans to change this so that they do ?
|>
|>
|>I'd be strongly opposed to such a change.  We have much bigger control
|>of these fields, and locale definitions simply don't provide enough
|>options for us.  I.e. for clock applet, we might be interested in the
|>following:
|>  time with seconds (13:14:15)
|>  time without seconds (13:14)
|>  date and time, but *without* year (пон, 14. феб, 13:14)
|>
|>while locales (in GNU libc, don't know about other systems) provide
|>for me only:
|>
|>  $ date +%x # d_fmt
|>  14.02.2005.
|>  $ date +%X # t_fmt
|>  13:16:30
|>  $ date +%c # d_t_fmt
|>  понедељак, 14. фебруар 2005. 13:16:31 CET
|>
|>This is simply not enough, and I'd hate to be limited to these options
|>(ok, there's also a t_fmt_ampm, but that doesn't apply to my locale).
|>
|>Also, it's very hard to change locales (I've been trying to do that
|>for GNU libc, which is still the base platform for Gnome, for around
|>two years, where the sr_YU locale even includes a plus sign in the
|>string, which is clearly wrong), while it's much easier to
|>administrate translations.
|>
|>As for Nautilus, it's using a larger granularity (i.e. it again has
|>messages for "Yesterday", "Last Thursday"), so above options are
|>simply not sufficient.
|>
|>Yes, in a perfect world we'd have it based on the operating system,
|>but we're still far off from perfect world.
|>
|>
|>
|>>Most apps seems to be doing their own thing regarding the date and time
|>>formats which leads to an icconsistent end user experience. Other
|>>desktops have a more cocsistent approach which measn that these things
|>>can be made configurable through a single app.
|>
|>
|>I think our response has so far been: let translators provide
|>consistency instead.  If they feel agree with you, you can ask them
|>to use "%x", "%X" and "%c" wherever strftime formats are asked for,
|>but I doubt that will happen.
|>
|>The step forward might be the "Language and Culture" capplet (part of
|>Gnome Control Center, not installed by default), but I think that the
|>major problem is the inscalability of locale system used by systems
|>Gnome runs on top of.
|>
|>
|>We might actually go another route: instead of relying on OS, develop
|>a library of supported time and date formats (or simply extend
|>g_strftime, or whatever it's called, to support special modifiers in
|>addition to %x, %X and %c).
|>
|>Cheers,
|>Danilo
|>_______________________________________________
|>gnome-i18n mailing list
|>gnome-i18n gnome org
|>http://mail.gnome.org/mailman/listinfo/gnome-i18n
|
|

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFCGmNWEuPMamD5V9cRAg8YAJsEFsvE5QthyYVVT3dloWI6HsOAlQCeJc3T
KzOX4xLebfIwkOtb5JXD6OU=
=XoTE
-----END PGP SIGNATURE-----