Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.kernel > #61215 > unrolled thread

Bug#901702: Add locale and gettext support to initramfs

Back to article view | Back to linux.debian.kernel

Contents

  Bug#901702: Add locale and gettext support to initramfs Jonas Meurer <jonas@freesources.org> - 2018-06-17 03:00 +0200
    Bug#901702: Add locale and gettext support to initramfs Josh Triplett <josh@joshtriplett.org> - 2018-07-22 22:20 +0200

#61215 — Bug#901702: Add locale and gettext support to initramfs

[Multipart message — attachments visible in raw view] — view raw

Package: initramfs-tools
Version: 0.130
Severity: normal
Tags: l10n patch

Hello,

when trying to add l10n support to the cryptsetup initramfs script I was
surprised to realize that apparently no initramfs component has l10n
support yet.

Probably that's because most messages from initramfs are more targeted
at developers. Unfortunately, that's not true for the initramfs scripts
of cryptsetup. Here, we need to ask users for input (passphrase) and
therefore the messages we print are targeted at normal users. There's
also an open bugreport that requests support for translated strings[1].

I first thought about adding all the required locale and gettext stuff
to initramfs in the cryptroot hook, but after thinking about it again,
I think it should be done in initramfs itself instead. Other initramfs
components might want to use it as well.

That's why I'd like to add locale and gettext support to initramfs but
make it optional. Without any prompts targeted at endusers, there's no
real need to bloat the initramfs with locales and gettext files. But
e.g. in the cryptsetup package, we would enable it.

I've prepared a patch that optionally adds locale and gettext support to
initramfs (depending on a initramfs.conf variable). You can find the
patch attached to this bugreport or as a merge request on Salsa[2].
Whatever you prefer ;)

Would be awesome if you could consider to merge it. It's a prerequisite
for adding l10n support to the cryptsetup initramfs scripts.

Cheers,
 jonas

[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=688735
[2] https://salsa.debian.org/kernel-team/initramfs-tools/merge_requests/4

[toc] | [next] | [standalone]

#61531

On Sun, 17 Jun 2018 02:53:15 +0200 Jonas Meurer <jonas@freesources.org> wrote:
> That's why I'd like to add locale and gettext support to initramfs but
> make it optional. Without any prompts targeted at endusers, there's no
> real need to bloat the initramfs with locales and gettext files. But
> e.g. in the cryptsetup package, we would enable it.
> 
> I've prepared a patch that optionally adds locale and gettext support to
> initramfs (depending on a initramfs.conf variable). You can find the
> patch attached to this bugreport or as a merge request on Salsa[2].

Reading through the patch, most of it seems reasonable; however, I
noticed a few issues:

- /usr/bin/locale isn't in the locales package, it's in libc-bin, which
  is essential. So, please don't point people towards the locales
  package.
- You're filtering out LC_COLLATE from the locale output, but that just
  leads LC_COLLATE to default to the same locale specified by other
  variables. If you want to avoid referencing the collation files, you
  need to *explicitly* set LC_COLLATE=C.
- For the purposes of localized message support *only*, could you do
  without the (large) LC_CTYPE file as well? Or perhaps more generally,
  would it make sense to *only* support LC_MESSAGES and nothing else?
- For invoking find, please see how other hook scripts do so, and please
  quote the resulting filenames. Yes, files under /usr/lib/locale should
  never contain whitespace, but despite that, please don't encode such
  assumptions.
- Nit: rather than providing a function gettext_support to conditionally
  source /usr/bin/gettext.sh and otherwise provide dummy functions, have
  you considered just putting a /usr/bin/gettext.sh in the initramfs
  that defines those dummy functions, so that scripts can use it
  unconditionally?

Have you confirmed that this support works on a system with locales not
installed and only the C.UTF-8 locale configured?

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.kernel

csiph-web