From: Kyle J. McKay <mackyle@gmail.com>
Date: Tue, 10 Mar 2015 19:36:40 GMT
Subject: Re: [PATCH] protocol upload-pack-v2
Message-ID: <96E9559D-9B15-464D-AC9E-8C17229A0A78@gmail.com>
In-Reply-To: <CACsJy8AuCAfHMbnV3N4ZyZCCqF6WAs_k2dS_Y1ZccWAzWm0yVA@mail.gmail.com>

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