On Mar 9, 2015, at 18:38, Duy Nguyen wrote:
A minor point on capability negotiation. I remember why I passed capabilities via command line instead of this proposal. With this proposal, daemon.c does not recognize "i18n" capability and cannot switch to the correct language before it reports an error. But perhaps I approached it the wrong way. Instead of letting the daemon produce non-English language directly, if could sort of standardize the messages and send an error code back in "ERR" line, together with an English message (current pack-protocol.txt says "ERR" followed by explanation-text). The client can use this error code to print non-English messages if it wants to. Perhaps we can reuse http (or ftp) return codes or some other protocol then customize to fit Git's needs.
May I suggest that you take a look at RFC 2034 [1]. It describes almost exactly this same situation and how SMTP was enhanced to support error code numbers that could then be translated.
No reason this enhancement needs to be restricted to protocol v2 if it's just an "enhancedstatuscodes" capability the server sends back to indicate that its ERR text is in that format.
-Kyle [1] http://tools.ietf.org/html/rfc2034 -- 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