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 [email protected] http://mail.gnome.org/mailman/listinfo/gnome-i18n
