On Tue, 19 Feb 2008 11:42:03 -0600 Nicolas Williams <Nicolas.Williams at Sun.COM> wrote:
> On Tue, Feb 19, 2008 at 08:44:07AM +0000, Darren Kenny wrote: > > Nicolas Williams wrote: > > >> At the moment there are only two settings, you can disable the > > >> whole thing, and you can specify the charset encoding used for filenames. > > > > > > Why should a charset be specified here? Presumably the *language* to > > > localize these directory names to comes from the locale chosen by the > > > user, so why can't the charset come from the locale too? > > > > In GNOME, the charset used for filenames is always utf-8 encoded (it can be > > overridden if needed through environment variables). > > OK. > > > In the case of XDG user dirs, it is not a GNOME applications, but desktop > > independent, hence it doesn't use glib, so we need a way to configure the > > charset to use - that is the purpose of setting the charset at the system > > level. > > I don't get this. No matter what login program and desktop environment > is used there always is a user-selected locale. Therefore, why not > honor the user's locale choice by taking the charset from the locale? Because that's what causes the confusion when switching locales in the first place. By a desktop env consistently using the same charset for the file names then this eliminates one of the causes of issues when people using the same locale but different charset, usualy without realising it see wierd chars in their filenames. > > > Saying that, we actually wouldn't expect this to be changed much, and should > > always be utf-8. > > Someone's bound to set this and a user is going to login using a locale > with a different charset, and things won't look right. Well, I coukd put in a warning or comment against doing it, would that help? > > That the sysadmin can set the charset here is obnoxious, but if the only > way to use a charset other than UTF-8 when the user selects a non-UTF-8 > locale, then that'd be a serious bug. How so? GNOME or KDE wont acknowledge that encoding either at the low levels of glib, but will re-encode for presentation to the user. To use utf-8 like this is consistent with the current behaviour of these environments. > > At the very least we need to support non-UTF-8 locale selections by the > user without having to update this file, and if that's done then why > bother with this system-wide setting? > But we do, it's only the file-system representation that's utf-8, the UI will be, if anything, more consistent in it's presentation to the user in the locale of their choosing -it's much easier to convert from utf-8 to a non-utf-8 locale than from one unknown locale to the current locale. Thanks, Darren.
