bug-guix
[Top][All Lists]
Advanced

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

bug#32026: [PATCH 05/10] gnu: Add icecat-l10n and icedove-l10n.


From: Maxim Cournoyer
Subject: bug#32026: [PATCH 05/10] gnu: Add icecat-l10n and icedove-l10n.
Date: Fri, 17 Feb 2023 04:37:20 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/28.2 (gnu/linux)

Hi Mark!

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

> Hi Maxim,
>
> Maxim Cournoyer <maxim.cournoyer@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





reply via email to

[Prev in Thread] Current Thread [Next in Thread]