On Thu, Sep 13, 2012 at 02:10:41PM -0700, Junio C Hamano wrote: > Jeff King <peff@xxxxxxxx> 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 (i18n.projectlang). 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. -Peff -- 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