Bug#563861: localechooser: Maybe ask preferred locale in more cases?

[Frans Pop <elendil@planet.nl>]

tag 563861 pending
thanks

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 
as possible.

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.

Cheers,
FJP