On Thu, Sep 13, 2012 at 02:10:41PM -0700, Junio C Hamano wrote:
> Jeff King <p...@peff.net> writes:
> > I suspect we will end up with people not setting i18n.projectlang, and
> > getting Klingon diffstats on the list.
> Yes, but when our starting point is that the diffstat summary is not
> meant for machine consumption, which I tend to agree, that is a
> logical consequence no matter how you cut it, no? After all, they
> want to be careless when running format-patch meant for _this_
> project whose project language is C locale, but still want to be
> able to see output that is not meant for machine consumption in
> their native language, and these are incompatible goals.
I do not think they are incompatible if you separate it into three
categories: machine readable (must never be translated), for the current
user right now (current i18n), and for sharing with other humans
Whether the maintenance of that three-way split is worthwhile, I don't
know (and that is why I said "in an ideal world..." in my original
mail, and left the implementation for people who care more). In the
meantime, before we have a working i18n.projectlang solution, which slot
should we put those messages in?
I'd argue for putting them in the machine-readable category, because it
is less likely to cause interoperability annoyances (and since git is
not fully translated anyway, we kind of assume at this point that people
know some basic phrases in the C locale).
And of course it is not fool-proof. The "for the current user right now"
messages may bleed into conversation with other people. But that cannot
be helped if we are to do any localization at all, and it does not seem
to be a big problem in practice. The only practical problem so far is
with certain meant-to-be-shared messages.
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html