Feat/add locale support

[digitalLumberjack]

Hi, see #852

PR opened for discussion about what we could add for locales.

I added the support for setting the locale in OS Customization (and automatic detection of it based on the timezone, for GB, USA, and France).

The locales list (locales.txt) comes from:

cat /usr/share/i18n/SUPPORTED

on Raspberry Pi OS.

The ui renders like this:

The firstuse.sh scripts is modified to use localectl set-locale LANG=$LOCALE LC_ALL=$LOCALE LANGUAGE=$LOCALE on first boot.
(localectl use locale-gen and update the /etc/default/locale file

#!/bin/bash

set +e

if [ -f /usr/lib/raspberrypi-sys-mods/imager_custom ]; then
   /usr/lib/raspberrypi-sys-mods/imager_custom set_keymap 'fr'
   /usr/lib/raspberrypi-sys-mods/imager_custom set_timezone 'Europe/Paris'
else
   rm -f /etc/localtime
   echo "Europe/Paris" >/etc/timezone
   dpkg-reconfigure -f noninteractive tzdata
cat >/etc/default/keyboard <<'KBEOF'
XKBMODEL="pc105"
XKBLAYOUT="fr"
XKBVARIANT=""
XKBOPTIONS=""

KBEOF
   dpkg-reconfigure -f noninteractive keyboard-configuration
fi
localectl set-locale LANG=fr_FR.UTF-8 LC_ALL=fr_FR.UTF-8 LANGUAGE=fr_FR.UTF-8
rm -f /boot/firstrun.sh
sed -i 's| systemd.run.*||g' /boot/cmdline.txt
exit 0

The user_data cloudinit yaml has the new entry locale (see https://cloudinit.readthedocs.io/en/latest/reference/modules.html#locale):

timezone: Europe/Paris
keyboard:
  model: pc105
  layout: "fr"
locale: fr_FR.UTF-8

Open questions:

• How many locales would you like to keep in this list?
• Is the local file with LOCALECODE [(Human Readable)] something you would like to keep ?
• We could detect the host locale, but I was not able to get the full locale code from QLocale class for now. It seems to have been heavily simplified on Qt.
• Should we use the host Locale (if we can detect it) to preset the keyboard ?

Thanks to every contributor of this great tool :)

[tdewey-rpi]

Thanks for the PR, @digitalLumberjack!

This is indeed a long-standing pain point, and I'm particularly impressed to see a member of the community stepping up to try and address it.

I'll try and address your points in order:

1. It's hard to say how many locales - this must surely be a function of the target operating system, rather than the host?
2. Having an annotated version seems like a sensible idea - but we'll have to be mindful to only show locales available in the target OS
3. The host locale mapping is fraught. I've come across many a new user PC where they've been using an incorrect but close-enough locale. I suspect a drop-down, while expedient today, might have to be replaced with a map selector a la subiquity.
4. As with (3), automatically using properties from the host gives me cause for concern. I think I'd rather see a deliberate action, where no choice avoids setting any locale directives.

[digitalLumberjack]

Hi :)

It's hard to say how many locales - this must surely be a function of the target operating system, rather than the host?
That means having a list of supported locales in os_list.json ?

The problem is the configuration is not os dependent right now. It's global, so if you choose a specific locale that is available on the first os you write, it may not be available in the second one, but you still can press YES when asking for os customization.

As the choice YES can be to apply saved customization for the os you write, having os dependent locales may imply a brand new process for choosing it, hence your reference to subiquity ?

And if the os get a list of supported locales, maybe it can also declare a list of supported customizations. (an os could support wifi but not username, and so on...

[tdewey-rpi]

Hi :)

It's hard to say how many locales - this must surely be a function of the target operating system, rather than the host?
That means having a list of supported locales in os_list.json ?

The problem is the configuration is not os dependent right now. It's global, so if you choose a specific locale that is available on the first os you write, it may not be available in the second one, but you still can press YES when asking for os customization.

As the choice YES can be to apply saved customisation for the os you write, having os dependent locales may imply a brand new process for choosing it, hence your reference to subiquity ?

Yes, I'd suggest we might need to work out a schema change for operating systems to advertise their locale options - lest we feed an OS something invalid, and cause a fatal configuration break.

And yes - I'd actually envision this entire mechanism having to change. Locales are actually too important to be relegated to a drop-down, and if you look at the set-up wizards of eg Ubuntu, that's essentially doing what OS customisation is trying to do - and those wizards do it in a much grander way.

For Imager v2.0.0, I'm hoping to introduce something like that - including a full-window Locale selector.

And if the os get a list of supported locales, maybe it can also declare a list of supported customizations. (an os could support wifi but not username, and so on...

Now that's a good idea (I've been noodling in that direction for a while, and I've broadly come to the conclusion that's the best way forward).

[lurch]

I guess this is now defunct in light of Imager 2.0 ?