about ki18n/locales: installing only a subset?

[René J.V. Bertin]

On Wednesday December 16 2015 13:46:08 Chusslove Illich wrote:

> It has a use in every situation where multiple-language users work in a
> centrally administered network. Like in... an office. My personal experience

How many offices do you know that require all known languages to be installed?
The only organisations I can think of where that situation might be approached are the UN and (to a much lesser extent) EU administrations.

> in this regard is that whenever I sat at some machine of that type, I get
> translated all software *but* the KDE software. And the unacceptable
> overhead in that case is asking IT to do something about it.
> 
> > [...] but it'll end up amounting to a significant disk overhead (the one
> > that comes with lots of small files) [...]
> 
> I don't think the disk overhead is significant. There are no loud complains
> about other Gettext-using software, which normally comes with all
> translations.

This practice evolved in times when disks had small(er) blocks, and the number of available languages considerably smaller. Configure-style packages most all had a --disable-nls or similar option, and AFAIK it's always been a habit among distributions to package languages separately.

> To put it in perspective, a single contemporary high-budget
> game will occupy much more disk blocks than all Gettext translations on the
> system combined.

You haven't read (or understood) my argument, which is about how blocks are used, not how many. 

It is NOT my intention to make a huge point of this, but I stand by my opinion that the current approach leads to waste of disk space that is significant (no matter how small) for the vast majority of users.

> Furthermore, if one thinks of stripping the translation files from release
> packages, or fetching them manually from the repo, that will not work
> properly.

It worked just fine with KDE4, esp. with the fallback feature to a language that isn't automatically the developer's language (usually en_US).