Quoting Florian Zumbiehl (florz@florz.de):
> ... 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.
Attachment:
signature.asc
Description: Digital signature