Quoting Florian Zumbiehl (firstname.lastname@example.org): > ... 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. 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. 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". > 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"). 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 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 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. > 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.
Description: Digital signature