No progress for ~3 years, marking as dead.

We need a better approach for the locale handling. One possible solution would 
be to generate locales that aren't available on the live system yet right just 
on demand during bootup iff the specified lang=... bootoption doesn't match 
available locales. I'd appreciate help in specifying and implementing that.

Dropping the release-stopper tag again, won't catch the next upcoming stable 
release. Further feedback and help appreciated.

Marking this bugreport as release-stopper for now (it's not really stopping us 
to release but it should receive attention better sooner than later).

/etc/grml/fai/config/scripts/GRMLBASE/25-locales

The meaning of class LOCALES has changed now. Therefore you cannot build
a live-cd with minimal locales support anymore :-(

I suggest two possible solutions:

1. Introduce another class MINLOCALES which could be used to build minimal
locales support (from /etc/locale.gen.minimal) in contrast to class
LOCALES which could be used for full locales support (from /etc/locale.gen.grml).
Without LOCALES or MINLOCALES all locales files should be deleted.

2. Another solution providing more flexible control of locales settings would
be to not rely on classes and /etc/locale.gen.* template files but rather use
a new variable LOCALES in /etc/grml/fai/config/class/GRMLBASE.var. This could
be evaluated in the script 25-locales to create the files /etc/locale.gen
and /etc/locale.nopurge. The LOCALES variable could be a comma separated list
of items. Valid items might be full locale specifications (e.g. "en_US ISO-8859-1")
or language codes (e.g. "de_DE") or the special item "all". Any given language
code must be translated to all the locales found in /usr/share/i18n/SUPPORTED.
The special item "all" would expand to all locales available.
To get the default behaviour for the new grml live-cd you would set LOCALES=""
(or use another special item "none" to make it very clear to the user). For the
old minimal locales support you would set LOCALES="de_AT,de_CH,de_DE,en_GB,en_US".

I believe the second solution is much more user friendly and should be
prefered, even if it requires bit more code changes.

Bugreport and ideas by Thomas Lehmann, thanks!