Hi Maxim, Maxim Cournoyer <[email protected]> writes:
> Mark H Weaver <[email protected]> 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
