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

Previous Next

Full log

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

From: Mark H Weaver <mhw <at> netris.org>
To: Maxim Cournoyer <maxim.cournoyer <at> gmail.com>
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: Sat, 18 Feb 2023 15:22:28 -0500

Hi Maxim,

Maxim Cournoyer <maxim.cournoyer <at> gmail.com> writes:

> Mark H Weaver <mhw <at> netris.org> writes:
[...]
>> (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.

Okay, that makes sense.  Thanks for explaining it.

I didn't realize until now that there's no way, in the current patch
set, to install a subset of language packs.  I see that the icecat-l10n
package installs each language pack into a separate output, which led me
to initially guess that users could install a subset of those outputs.
At present, I guess that those separate outputs are not yet usable.

At some point, it would be good to facilitate the creation of custom
'icecat' packages with only a subset of language packs added, but we can
work on that later.  There's no need to hold back on this important
first step.

>> (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.

Thank you!

       Regards,
         Mark

Previous Next

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