[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#418382: choose-mirror: Better handling of suite/codename; support oldstable

Quoting Frans Pop (elendil@planet.nl):

> Introduce two new internal, but translatable debconf templates (rootskel):
> - debian-installer/suites: oldstable, stable, testing, unstable
> - debian-installer/codenames: sarge, etch, lenny, sid
> The second template would of course need to be kept up-to-date. Should 
> maybe be implemented as Choices to make separate translation of the 
> options possible and thus reduce the impact of partial translations.

I guess you mean "__Choices" of course.

This is a great suggestion. I would even suggest optionnally
"translating" to English to use clearer names, maybe (though the names
are well known now).

I think that the second template does not need translation at all
unless some translators in the non Latin languages community feel like
they would need to transliterate the names.

> I'm not completely sure yet how to display the choices, especially with 
> translations.
> One option could be to just only display the translated values, but IMO 
> the English name still is relevant for users as that is what ends up in 
> the sources.list.
> Another option would be 'codename-l10n (codename) - suite-l10n (suite)'. 

That could however become slightly long

> Or maybe display an additional "You have selected ..." dialog that 
> includes the original names if suite and/or codename are translated.
> Options in this scheme would be:
> - not displaying the question if the default codename matches oldstable
>   (after all, a newer installer is almost certainly preferred for other
>   suites)
> - a hardcoded variable "earliest supported codename" that suppresses for
>   example stable if the "testing" installer does not support installing
>   it (or displays a message if it is selected)

That gives flexibility. I like that.

> - displaying a message if testing/unstable is selected in the "stable"
>   installer that it may not be supported and to try the "testing"
>   installer in case of problems

Another way to give flexibility...:-)

I have no strong advice between those two options, indeed.


Reply to: