Hi,
On 12/30/05, Rick Stockton <[EMAIL PROTECTED]> wrote: > Yes, it's NASTY-WIDE. My Proposed Patch implements the wider dialog. Both > "Date/Time" and "Size" are re-sizable columns, which helps a little bit. But > the key, I think, is to address the internationalized format itself. If we > have to work from %c (which we probably DON'T, see asterisk section below) > then I think that: > > the first thing to chop off is the time zone, DEFINITELY not needed; > the second thing to chop off is the seconds, (hard to imagine when someone > would need "seconds" within the filechooser.) > And, the 3rd thing I'd like to chop off is the day-of-week. > > If necessary, this leads to 2 questions: > > (1) Are all timezones shown via a 3-character code, or do some locales have > more characters? (I'm not counting bytes, I'm counting characters). If so, > we could chop it off inline. I've got a bad feeling that at least one of the > many-glyph languages (e.g., Chinese), might use just a single character for > this. See below. > > (2) Similarly, is it possible that all locales use a 3-character code for > Day-Of-Week? Again, I doubt it, but it would be easy to chop off if this was > true. Both (1) and (2) may not be true. There exists 4-letter timezone (e.g. HKST) though I don't really know if anything like that is actively in use. And you guessed it correctly that some places don't use 3 letters to represent day of week. In general, chopping letters off %c is almost certain to cause problem. > > > If short string is more desired, I'd suggest showing only the time if > modification time is within 1 day, and only showing the date if more than > 1 day. And use ISO8601 format for date representation as well: > "%Y-%m-%d". This avoids ambiguity. For display of time, perhaps > the seconds part can be removed as well? > > Per above, I really like chopping out the seconds. But showing "time" only > for today's files doesn't really do any good-- once we've printed a couple > files with the time included, the column width is set large, and the empty > space (shown with the other files) wouldn't save room, it would just be a > visual distraction. More importantly, I think that we'd be cutting out > useful data. May I ask: what useful data will be cut out? > > 3rd idea, I don't like it. I feel that using ISO8601 is really ugly for > "non-experts" in the US locale: 2005-10-11 is clearly the 11th of October, > but almost *EVERY* other program they've used, especially if they come from > Windoze, shows m/d/y. Too radical and upsetting, I think. For other countries, I'd disagree; but for US people, then I also think you're correct. > I'd say try to use %x and/or %X for dates and times. They usually > produce shorter string representations than the %c specifier. > Unfortunately, there is no standard specifier that produces a > localized time string without the seconds part... :-( > > *********************** THANK YOU !!!! ******************** > > How about %x (local-appropriate date), > > preceded by %R (24-hour hh:mm) ??? > > > if %x leaves out stuff which we don't want, like Time Zone, but handles > correct MM/DD/YYYY versus YYYY/MM/DD according to the locale, I think that > further adjustments are low priority. > (But I'm a newby, and I can't even spell "i10n".) Agreed %x would be the better default choice, and I'd be grateful if it's translatable - because on the contrary of most locales, %x is a bad and ugly choice for Taiwan and Hong Kong. About %R: beware that some countries may prefer 12hr notation instead of 24hr one. I'm not sure what can be done in this area. gnome-panel currently uses translation to decide whether to use 12 or 24hr. > > Is 24 hour clock formatted as "hh:mm" universally understood? I suspect > that it *is*. > There went the seconds! > ************************************************************ > > > And of course, make the string translatable is the best thing to do, since > translators can decide if there are any better date/time representation > for their own language. > > If any translator is not pleased by the %x date, or the hh:mm time > preceding it, > then we WILL want to go there. Yes, yes, please :-) Abel > Agreed. If you want to use both %x and %X in the time display, you > probably have to make it translateable, so that translators can > reorder the arguments if necessary. > > However, this sucks for users who only want to have the display > language be something different (LC_MESSAGES), but otherwise want to > have times etc. be formatted according to their own locale, since > doing it like this and hooking up the date/time display in the > translations makes the time display be dependant on the display > language. But it is probably the best thing to do right now, until we > have something better. > > Christian > > I don't have any idea of the weakness in having locale control > everything... > but you do, so I'm all ears. For right now, I think that someone who chose > "en-us" > would accept, with just a little frustration, the resulting (weird) > MM/DD/YYYY. > > > > > > The standard way to do it is using whatever makes sense to use for > United States English that strftime offers (say "%b %e, %y ..."), then > make it translatable with a comment like: "translators should try to > make this as short as possible, while mentioning the complete date and > mentioning both minutes and hours in the translation". Something like > that. > > > I *don't* like this-- most of the world is YYYY-MM-DD, we shouldn't > hard-code the WEIRD > en-us as the standard. (But mostly, I suspect that we won't have to... > testing shortly). > > > We will try to make date and time formatting better in Giulia > (http://live.gnome.org/LocaleProject), possibly even as the > first > priority, but the project is currently inactive because of the very > limited developer resources. > > roozbeh > > > There are programming errors which I need to fix (this was, after all, > my first attempt at C... ever). With Federico's direction, > I hope to have a revised patch up tomorrow. I'll try too 'diff' it as an > actual patch, rather than > raw code. > > Question: Is there a reason why we do private email instead of posting to > the bug? > > Thank you all so much! > Rick > > > -- Abel Cheung (GPG Key: 0xC67186FF) Key fingerprint: 671C C7AE EFB5 110C D6D1 41EE 4152 E1F1 C671 86FF -------------------------------------------------------------------- * GNOME Hong Kong - http://www.gnome.hk/ * Opensource Application Knowledge Assoc. - http://oaka.org/
_______________________________________________ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
