On Thu, Oct 14, 2010 at 20:54, Jonathan Nieder <jrnieder@xxxxxxxxx> wrote:
> Ã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.
There's definitely a chicken & egg problem here. Unlike what you'd get
in the case of Linux this isn't an unstable device driver that
somebody needs. It's just something that optionally makes life easier
for people that pretty much by definition don't follow this mailing
list.
So it's hard to build an upstream of users. With all other free
software programs that happens by the canonical upstream version of
the program being internationalized. The distros then picking up that
version and give it to end users.
So what I've tried to do to make this acceptable for inclusion in core
is to make this whole thing a no-op unless it's explicitly
requested.
You can skip it altogether with NO_GETTEXT=YesPlease, and even with
NO_GETTEXT= it won't get used unless you've explicitly set LANGUAGE=,
or LC_*= variables accordingly.
Maybe I could do something to make it even less intrusive, e.g. have a
core.i18n=yes config variable. But I haven't gotten any feedback on
that so I've kept the current scheme of making it behave like pretty
much every other internationalized program out there.
>> 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).
The LC_CTYPE problems I'm aware of were worked around in this patch:
gettext.c: work around us not using setlocale(LC_CTYPE, "")
While that's not a perfect solution I think it's the best we're going
to get for the time being. I'm pretty convinced that if I tried to
make git itself LC_CTYPE-safe as part of this already huge series it'd
never get merged. Having messages with question marks from strerror()
on certain platforms is an OK compromise in my opinion.
Are there any other LC_CTYPE related issues I'm overlooking?
>> 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.
That's good to hear.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html