Re: Stable ab/i18n branch

Ævar Arnfjörð Bjarmason wrote:

I could do that, but I've been hoping that it just gets picked up for
the `next -> master` process of git.git itself and *that* becomes the
stable target.

But I have no idea what's going on at the other end, i.e. there's no
comments about it in the "What's cooking in git.git" posts or
elsewhere. So it's hard to know whether something like this is needed.

Probably it is a difference in culture between e.g. the Linux kernel
and other projects.  In the world I'll stereotype as the Linux kernel
world, forks are considered good!  Developments everyone agrees is
good in the long run (like the Linux realtime tree) are not
necessarily merged, for years even, the justification being that
until the _immediate_ benefits for Linus outweigh the risks for Linus,
it just doesn't make sense to merge.

This avoids bloat and bugs from code that is not being used by anyone,
while allowing development to continue to happen.

Now git.git is not the Linux kernel.  In particular, Junio provides
the extra service of a working "proposed updates" branch, including
changes that are not necessarily to be part of the next release.  But
the underlying principle is the same: until there is an _immediate_
benefit to including a feature in releases that does not outweigh
the downsides, it just does not happen.

What that means: interested parties need to start testing the l10n
code.  There should be a reliable upstream for users of this
feature and ideally that should not be Junio unless he wants to (and
Ævar, I think you have been doing a good job of that, just saying it's
valuable).  The code's not going to get into shape otherwise.

It's been about as ready as it's ever going to get for about a month
now.

I hope not!  e.g. the LC_CTYPE problems have not been resolved (and yes,
that would be a regression for people using the it_IT.UTF-8 locale).

I'm starting to get the feeling that there isn't much interest in i18n
support at all.

I'm interested in it, at least.