GNU bug report logs - #32026
IceCat locales are missing?

Previous Next

Full log

Message #121 received at 32026 <at> debbugs.gnu.org (full text, mbox):

From: Maxim Cournoyer <maxim.cournoyer <at> gmail.com>
To: Mark H Weaver <mhw <at> netris.org>
Cc: 32026 <at> debbugs.gnu.org, ludo <at> gnu.org,
 Jonathan Brielmaier <jonathan.brielmaier <at> web.de>
Subject: Re: [PATCH 05/10] gnu: Add icecat-l10n and icedove-l10n.
Date: Fri, 17 Feb 2023 04:37:20 +0100

Hi Mark!

Mark H Weaver <mhw <at> netris.org> writes:

> Hi Maxim,
>
> Maxim Cournoyer <maxim.cournoyer <at> gmail.com> writes:
>> * gnu/packages/gnuzilla.scm (%icecat-locales, %icedove-locales): New variable.
>> (make-l10n-package): New procedure.
>> (icecat-l10n, icedove-l10n): New variables.
>
> Thanks very much for this important work.  Our lack of support for
> language packs has been sore spot for several years, and I'm profoundly
> grateful to you for taking this on and getting it done!
>
> For now, I have just two general questions/comments:

Thanks!  The motivator was a family member starting to use Guix
System... ha!

> (1) Instead of generating the locales in separate "*-locales" packages
>     and then merging them with the main package (which must then be
>     renamed to "*-minimal"), how feasible would it be to incorporate the
>     locale generation directly into the existing packages?

It's entirely feasible, but I see a couple downsides that explain why I
stuck with the current design:

1. The user no longer has an option to install IceCat without the 70 MiB
or so of extra locales (via icecat-minimal).

2. The already lengthy IceCat package definition gets even more verbose
and hard to follow.

3. The locales are slow to generate (it's sequential, and there are a
lot of them).  Currently they can be generate at the same time as
icecat-minimal is built.

4. It makes debugging locale-generation problems more focused.

> (2) In terms of the API, I very much dislike the approach of having the
>     'make-l10n-package' accept just one argument: a symbol, which it
>     uses to construct the variable names of toplevel variables that must
>     be looked up using 'module-ref'.  I'd greatly prefer to simply pass
>     in all of the variables that are needed.
>
> What do you think?

I don't feel strongly about it.  Since you do, I've adjusted it, in an
upcoming v3.

> I'll hold off on a more detailed review until we can (hopefully) reach
> agreement on the overall approach.

OK!  Thanks for the comments.  I hope I don't sound dismissive of them,
although I find myself disagreeing with a few of them :-).

-- 
Thanks,
Maxim

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.