> > ... and the window title reads something with language, the menu item > > that gets you there is about language, too. Not very suggestive of time > > zone selection, really ... > > Technical constraint. The "window title" is the menu item name. > > *This* specific menu item name *must* be very short as it is the only > one that gets show *both* in English and in the chosen language (when > one comes back to the menu after setting the language a first > time). This is driven by the need to allow users who mistakenly chose > a language they don't understand to still be able to find the right > choice to change this.
I totally understand and actually suspected that - that doesn't make it the slightest bit less confusing, though. > So, the menu title has to be under about 30 characters. Please feel > free to suggest something that says everything that happens during the > "language selection" step...in less than 30 characters. We never > found. Which is precisely why I suggested to separate the issues - if the matter is simple instead of a bunch of semi-intertwined issues, it automatically becomes easy to describe in a few words, too. > About the suggestion you're about to make: no, it's very hard to make > *two* separate steps. As all this discussion, and the gazillion > discussions that happened before, shows, language, country, locale are > very tight together....so the package that needs to deal with this is > much better if kept as a single package. And then the technical > constraint comes: one package<->one "window title". I think you quite fundamentally misunderstood my suggestion. It's not at all about splitting the language selection in two (at least not more "in two" than it currently is), but mostly about making time zone selection as independent from language/locale selection as, say, mirror selection already is. > > Now, I don't have much of a clue of the internal structure of the > > installer, but from the outside, I think a structural change would be > > more sensible than just changing the explanation. I think something like > > this would be easy to understand (and thus to explain, too): > > > > - first, present a language selection, just as it is now - state > > clearly that this is about language/locale selection only > > - then, ask for language variant, if applicable - state > > clearly that this is about language/locale selection only > > - then, ask for additional locales to install > > - possibly ask for selection of default locale if there is > > more than one locale to be installed now > > I think that the current way this step is working is the best > compromise between the vast majority of needs ("I speak Turkish, I live > in Turkey, my machine is in Turkey, I want to Turkish locale") and > nitpicking corner cases ("I speak German, I live in Bolivia, my > machine is in Philippines, I don't want any localization at all and > please make me coffee as well"). Now, where would the downside of my suggestion be that there is any need for a compromise? > Frans addressed a few quirks you found, particularly when choosing the > C "locale". I think this mostly answers most of the concerns. > > Again, I think it would not be very wise to redesign entirely our > locale selection step because of the 0,01% corner cases where it is a > little bit clumsy.....while it basically is OK for the remaining 99,99% > > > And then, later in the process, use the language variant as a hint > > There is no such concept as "language variant" in D-I. When a given Well, I guess I am interchanging "locale" and "language" a bit to freely. Take it as "locale variant" or "locale territory" or whatever, I guess you know what I mean. > language has a real variant (there are two cases, slightly different: > Portuguese and Chinese), this is made clear from the first screen. > > Don't expect any "German as spoken in Austria" language variant in > D-I.....nor in any major end-user software. Most localization teams Seamonkey^WIceape isn't "major end-user software", then? And what's the point anyhow? If I didn't grossly misunderstand things, you can currently select the de_AT locale in the installer ... > have just agreed this is plain silly and wasted resources. Just look > around and check whether there is such beast for major software and > end-user environments. > > The only widely used variants are pt_BR, zh_CN and zh_TW. Sometimes, > some es_NN where NN is in Latin America but here as well, the real > need for specific variants is very debated. > > So, it's probably better not speaking about choosing a language > variant (we never do that in D-I) but more about choosing a language, > then a country, the country being a choice that drives other > location-related settings. Which is basically what is said in D-I > screens...with the constraint of keeping the message intelligible for > the average user. ... and then just don't force the user to use a time zone that matches their "country" which they selected under "language selection". I guess that's what my suggestion comes down to. > > Somehow I reckon, though, that there is some technical reason for > > things being the way they are that makes my approach impossible ... :-) > > > Many. The first being: why would we redesign entirely this part of the > software while it addresses the vast majority of needs. > > I think this discussion is useful to identify the few quirks that were > remaining (see Frans comments) and we really need to thank you for > this. Still, I'm not convinced we should redesign things entirely. I'd be bit surprised if it really was such a major undertaking ... -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org