Re: Status towards next release (1.1.4)

[Rich Felker <dalias@libc.org>]

On Sun, Jul 13, 2014 at 02:16:30PM +0530, Weldon Goree wrote:
> Just because I figure someone should propose the most brute possible
> strategy: what about storing the .mo data in the library itself? Port
> the built-ins to the format, and you have a single code path for locale
> access, and it doesn't involve persistent storage. If I'm understanding
> your idea right and you're talking about the equivalent of
> SYS_LC_MESSAGES and parts of LC_TIME and LC_COLLATE, this isn't nearly
> as bloated as it sounds at first (particularly if one is putting, say, 4
> locales in a given build rather than 446).
> 
> Now, obviously maintainers wouldn't like the choice of either 1 bloated
> binary or 446 non-bloated binaries (or God forbid the Cartesian product
> of all the possible locale combinations), and this kind of violates the
> basic idea of locale that you shouldn't need to recompile software to
> get it to speak French, but I just wanted to throw that idea out there.

Indeed, this idea violates that and many other principles:

- That support for Unicode should be cheap (your idea makes
  setlocale(), which any portable program supporting non-ASCII text
  needs to call, pull in a huge part of the library)

- That the person compiling the software generally has no idea what
  languages the user will care about.

- That while character encodings and character identity are
  essentially finished, settled matters that won't change, language
  and culture are fluid. A program with locale data hard-linked into
  is is basically guaranteed not only to be incomplete in the future,
  but outright WRONG in the future. The best analogy I can think of
  would be hard-coding timezones into the binary.

And probably many others. So I don't think this idea is viable.

Rich