Pablo Saratxaga wrote:
> > > But it's also the way things are done sice ever (or at least as long as > > > I can look at); why to break it and introduce compatibility problems ? > > > > Ignoring case does not appear to lead to compatibility problems. > > It does. > > > I can't think of an example of two existing locales that only differ by > > case. > > Not because of that, but because in various places the handling is case > sensitive; so if case insensitivness is introduced in some places, and > a wrong case used, it will work in some palces, and not in some others. > Or do you plan to also patch X11 so it is case insensitive too? This problem already exists. On MS-Windows case doesn't matter, as far as I know. And encoding names are written in different case in different situations. Even sometimes with the dash omitted. It's hard to remember in which situation what name has to be used. All places that use locale names should ignore case differences. Yes, this would be a new standard. > > > Note that case insensitivity is locale dependent; by introducing case > > > insensitivity you may have some very strange behaviours, like > > > the locale being recognized when you first define it (as you were > > > on another locale previously), then after the change is done you > > > start getting errors (as the new locale defines new case > > > insensitivity rules and the string that previously was considered > > > the same is not anylonger the same). > > > > Locale names are always in ASCII and thus are indifferent to the current > > locale. > > You are wrong. > uppercase(i) will give different results in English or Turkish locale. > same for lowercase(I). > Maybe those are the only two cases involving ascii letters; but that also > mean that if the name of a Turkish locale includes an 'i' the result may be > that it won't work as expected. I don't know the uppercase() or lowercase() function. It's very easy to change case without using the current locale, just using the ASCII characters. I think it's obvious that the current locale should not apply to the locale name itself. > Small yes, but not "a change", but "several changes in several places". > There is at least the glibc, the X11 library, the directories where X11 > ressource files are stored, probably also the KDE locale data > handling, and maybe also some other programs (like the ones not using > gettext but their own translation systems (other than X11 ressources, > told above)) It's still a small price to pay for being user friendly. It's probably the administration and testing that will take most of the time anyway, since making the changes is quickly done. > >> The supposed benefits are too small compared to the troubles. > > > > I think you underestimate the importance of user friendliness. > > case sensitivness in one small place when everything else is case sensitive > is not user friendly; to the contrary: it can only give more trouble. > Now the situation is simple: everything is case sensitive. > But you want to have a system where commands, file namese and variable > names are case sensitive, but the value of some variables are case > insensitive... I have been designing user interfaces for quite a long time. What I have learned is that you can create a consistent and logic UI that users don't like. User friendliness can't be defined by logic. Users don't work logically. You will have to watch what they do and see where they make mistakes. Where mistakes are often made is a good indication that improvement is required. Then you can figure out what causes the mistakes and try to find a better solution. I have hardly ever seen people making mistakes in typing commands or variable names. I often see people using wrong locale names. This is an indication that this should be made easier. It's probably because of the mix of lowercase and uppercase in one value. Command names are nearly always lowercase and variable names all uppercase or lowercase. > Note also that the common locale related problems are not due to case > sensitivity, but to things like using unknown names, typos, bad charset > encodings, locale not defined,... case insensitivity won't help if you > define LANG=a and "a" don't exist; it won't help either for people mixing > country name and language name and asking for LANG=cz instead of LANG=cs, > nor will it help for people defining LANG=fr_FR.iso_8859_1 (the problem here > is not the case, but the use of '_' instead of '-', a common error as a > quite old French Howto gives it that way (as it used to be in libc4 time)). Yes, mixing "_" and "-" is also a problem, especially since it's not used consistently. Ignoring this difference would also be a great help, but might be a bit more difficult to implement. Also, that there is an underscore between the language and region names is a good hint to use a dash in the encoding name. That still requires a bit of thinking though. Mixing up the language code and the region code is also a problem. Unfortunatly I don't know a simple solution for this. Best would be to make one of them three letters, but that would very likely create trouble for people used to the two letter system. Making one of them uppercase doesn't help at all, since there is no intuitive connection between case and the difference between language and region. > > This is > > not unusual when you look at Linux from the point of view of a > > developer. Please try looking at it from the point of view of a user, > > and attempt to make the system as user friendly as you can! > > I simply don't think making the value of an extremely small set of shell > variables case insensitive will do any real change in user frinedliness. > The contents of almost all other variables will remain case sensitive > ($HOSTNAME is the only one I can think of that is already case insensitive, > well, not exactly, but the case has no effect for host names); > the variable names will of course remain case sensitive, and everything > related to filesystem. > If the user happens to do a bit of programing, there is case sensitivity > all the place too, etc. In most places case sensitiveness doesn't bother me. I hardly ever make mistakes (except perhaps in C functions with long names and a mix of upper and lowercase letters). I do make mistakes in locale names. > The gains of having case insensitive locale naming are in practice > very small; and it may even introduce bugs and problems for Turkish > users (they already have too often problems due to the peculiar case > changing rules for dot and dotless i's). If we treat the locale name as plain ASCII then this problem won't exist. -- I wonder how much deeper the ocean would be without sponges. /// Bram Moolenaar -- [EMAIL PROTECTED] -- http://www.moolenaar.net \\\ ((( Creator of Vim -- http://vim.sf.net -- ftp://ftp.vim.org/pub/vim ))) \\\ Help me helping AIDS orphans in Uganda - http://iccf-holland.org /// -- Linux-UTF8: i18n of Linux on all levels Archive: http://mail.nl.linux.org/linux-utf8/
