Bug#563861: localechooser: Maybe ask preferred locale in more cases?
tag 563861 pending
I've just committed the change.
At medium and low priority we do now have the situation which Colin warned
against: effectively we display the shortlist dialog twice in a row. And I
do agree that it's not the most beautiful design.
However, I think that this commit does improve consistency and that in
combination with all other recent changes it's still logical:
- the "first" shortlist now clearly has the purpose of selecting the user's
location, while the "second" one clearly selects the system locale;
changing the dialog titles has helped a lot with that
- even though the dialogs essentially have the same choices, they look
rather different because of the addition of the second column with
locales for the second one;
- the choice from the "first" shortlist sets the correct default for the
"second", so normally the second can simply be entered through.
On Thursday 07 January 2010, Ferenc Wagner wrote:
> > But then it's maybe better to rewrite the whole para as:
> > There are multiple locales defined for the language you have
> > selected. You can now select your preference from those locales. The
> > locale that will be used is listed in the second column.
> I agree.
The rewrite was still only for the second case. I've kept two distinct
texts as IMO the explanation of context is important.
> If you allow a general observation: it seems that problems
> arise if the texts depend on each other, since their individual presence
> depends on the priority relations.
If you look at the committed change you'll see that the implementation is
fairly straightforward. And note that which text gets displayed does not
depend on the priority, but on the question "is a locale defined for the
combination of language and country". The same question also determines at
which priority the dialog is displayed.
> While it's useful if the installer
> explains its steps (the dependent texts serve this very purpose), maybe
> we have to accept a compromise and relegate that into the logs.
That is a choice we have made in other places, but it's not needed here.
But I do admit that localechooser is now fairly extreme in "building
dialogs at runtime". The main reason for that is not because it is the
only way to implement it, but rather to limit the size of the udeb as much
Without building the dialogs at runtime, the template file would contain
multiple repetitions (not just 2 or 3, but many more) of the same strings
and their translations, and its size would explode.
I expect that despite all the recent changes and even when fully translated
again, the size of the localechooser udeb will be about equal to the
current Lenny version. And that's exactly because I've reduced duplication
of a number of strings.