"Stephen J. Turnbull" <stephen@xemacs.org> writes:
> Michael Sperber writes:
>
> > How's this: I make this configurable (default: no locale-munging), we
> > push out a new version, which is supposedly much better with the
> > locales, and the first bug report we get about this, I turn the switch
> > and cut a new release?
>
> I'm not clear on what you mean. Locale handling is by definition
> table-driven, and the table is extensible. So what "better with
> locales" presumably means is that your date parser (are there other
> relevant parsers?) can handle the standard formats in more locales,
> but what are you gonna do if the Steganography locale decides to
> define their date format as YMYMYDYD?
"turn the switch and cut another release", meaning I force the locale to
POSIX. However, maybe there's another way:
> IIRC, you have a big-ball-of-mud regexp (or list thereof) that tries
> to handle all known date formats. The conservative approach I want
> (on POSIX systems) is a variable `dired-grokkable-locales' which
> contains a list of regexps that match grokkable locales.
OK, but is the format of the locale strings sufficiently portable, and
the corresponding output format of ls sufficiently consistent across
systems? In my experience, locale identifiers are wildly unportable
across platforms, but I can't really say I understand the issue deeply
at this point.
> If you're really that confident that you've got almost all the locales
> in actual use, we could do it the way you suggest. I would implement
> the configuration to have a variable `dired-ls-locale' (maybe there's
> a better name that doesn't discriminate against Windows). If nil,
> don't frob the locale. If set, use that locale. The Custom widget
> for the variable should contain a list of common locales that the user
> might want (to approximate their own locale, or to substitute a
> familiar locale). WDYT?
That was my plan.
|