{"thread":{"id":"37077","subject":"[PATCH] http: Add Accept-Language header if possible","startedAt":"2014-07-08T15:54:06Z","lastAt":"2014-07-12T10:11:17Z","messageCount":12,"participants":["Yi EungJun","Eric Sunshine","Jeff King","Yi, EungJun","Peter Krefting"],"isPatch":true,"patchVersion":1,"patchTotal":null},"messages":[{"id":"245536","messageId":"1404834846-11812-1-git-send-email-eungjun.yi@navercorp.com","threadId":"37077","inReplyTo":null,"subject":"[PATCH] http: Add Accept-Language header if possible","fromName":"Yi EungJun","fromEmail":"semtlenori@gmail.com","sentAt":"2014-07-08T15:54:06Z","receivedAt":"2014-07-08T15:54:06Z","isPatch":true,"sender":{"key":"semtlenori@gmail.com","avatar":"https://gravatar.com/avatar/8363435d2badb3450df0dd7c4ec2113f6e1d62c44dd3cf7dfe83c5a389b8a9bf?d=mp&s=160"},"body":"From: Yi EungJun \n\nAdd an Accept-Language header which indicates the user's preferred\nlanguages defined by 'LANGUAGE' environment variable if the variable is\nnot empty.\n\nExample:\n LANGUAGE= -> \"\"\n LANGUAGE=ko -> \"Accept-Language: ko; q=1.000, *; q=0.001\"\n LANGUAGE=ko:en -> \"Accept-Language: ko; q=1.000, en; q=0.999, *; q=0.001\"\n\nThis gives git servers a chance to display remote error messages in\nthe user's preferred language.\n---\n http.c | 43 +++++++++++++++++++++++++++++++++++++++++++\n t/t5550-http-fetch-dumb.sh | 10 ++++++++++\n 2 files changed, 53 insertions(+)\n\ndiff --git a/http.c b/http.c\nindex 3a28b21..c345616 100644\n--- a/http.c\n+++ b/http.c\n@@ -983,6 +983,47 @@ static void extract_content_type(struct strbuf *raw, struct strbuf *type,\n \t\tstrbuf_addstr(charset, \"ISO-8859-1\");\n }\n \n+/*\n+ * Add an Accept-Language header which indicates user's preferred languages\n+ * defined by 'LANGUAGE' environment variable if the variable is not empty.\n+ *\n+ * Example:\n+ * LANGUAGE= -> \"\"\n+ * LANGUAGE=ko -> \"Accept-Language: ko; q=1.000, *; q=0.001\"\n+ * LANGUAGE=ko:en -> \"Accept-Language: ko; q=1.000, en; q=0.999, *; q=0.001\"\n+ */\n+static void add_accept_language(struct strbuf *buf)\n+{\n+\tconst char *p1, *p2;\n+\tfloat q = 1.000;\n+\n+\tp1 = getenv(\"LANGUAGE\");\n+\n+\tif (p1 != NULL && p1[0] != '\\0') {\n+\t\tstrbuf_reset(buf);\n+\t\tstrbuf_addstr(buf, \"Accept-Language: \");\n+\t\tfor (p2 = p1; q > 0.001; p2++) {\n+\t\t\tif ((*p2 == ':' || *p2 == '\\0') && p1 != p2) {\n+\t\t\t\tif (q < 1.0) {\n+\t\t\t\t\tstrbuf_addstr(buf, \", \");\n+\t\t\t\t}\n+\t\t\t\tstrbuf_add(buf, p1, p2 - p1);\n+\t\t\t\tstrbuf_addf(buf, \"; q=%.3f\", q);\n+\t\t\t\tq -= 0.001;\n+\t\t\t\tp1 = p2 + 1;\n+\n+\t\t\t\tif (*p2 == '\\0') {\n+\t\t\t\t\tbreak;\n+\t\t\t\t}\n+\t\t\t}\n+\t\t}\n+\t\tif (q < 1.0) {\n+\t\t\tstrbuf_addstr(buf, \", \");\n+\t\t}\n+\t\tstrbuf_addstr(buf, \"*; q=0.001\\r\\n\");\n+\t}\n+}\n+\n /* http_request() targets */\n #define HTTP_REQUEST_STRBUF\t0\n #define HTTP_REQUEST_FILE\t1\n@@ -1020,6 +1061,8 @@ static int http_request(const char *url,\n \t\t\t\t\t fwrite_buffer);\n \t}\n \n+\tadd_accept_language(&buf);\n+\n \tstrbuf_addstr(&buf, \"Pragma:\");\n \tif (options && options->no_cache)\n \t\tstrbuf_addstr(&buf, \" no-cache\");\ndiff --git a/t/t5550-http-fetch-dumb.sh b/t/t5550-http-fetch-dumb.sh\nindex ac71418..ea15158 100755\n--- a/t/t5550-http-fetch-dumb.sh\n+++ b/t/t5550-http-fetch-dumb.sh\n@@ -196,5 +196,15 @@ test_expect_success 'reencoding is robust to whitespace oddities' '\n \tgrep \"this is the error message\" stderr\n '\n \n+test_expect_success 'git client sends Accept-Language' '\n+\tGIT_CURL_VERBOSE=1 LANGUAGE=ko:en git clone \"$HTTPD_URL/accept/language\" 2>actual\n+\tgrep \"^Accept-Language: ko; q=1.000, en; q=0.999, \\*; q=0.001\" actual\n+'\n+\n+test_expect_success 'git client does not send Accept-Language' '\n+\tGIT_CURL_VERBOSE=1 LANGUAGE= git clone \"$HTTPD_URL/accept/language\" 2>actual\n+\ttest_must_fail grep \"^Accept-Language:\" actual\n+'\n+\n stop_httpd\n test_done\n-- \n2.0.1.473.gafdefd9.dirty\n"},{"id":"245558","messageId":"CAPig+cTbhUKF7OwYJY2_1m9j=khPRaLM2kd5KqDGD=vjRz0qHg@mail.gmail.com","threadId":"37077","inReplyTo":"1404834846-11812-1-git-send-email-eungjun.yi@navercorp.com","subject":"Re: [PATCH] http: Add Accept-Language header if possible","fromName":"Eric Sunshine","fromEmail":"sunshine@sunshineco.com","sentAt":"2014-07-08T21:52:22Z","receivedAt":"2014-07-08T21:52:22Z","isPatch":true,"sender":{"key":"sunshine@sunshineco.com","avatar":"https://avatars.githubusercontent.com/u/163641?v=4"},"body":"On Tue, Jul 8, 2014 at 11:54 AM, Yi EungJun wrote:\n> From: Yi EungJun \n>\n> Add an Accept-Language header which indicates the user's preferred\n> languages defined by 'LANGUAGE' environment variable if the variable is\n> not empty.\n>\n> Example:\n> LANGUAGE= -> \"\"\n> LANGUAGE=ko -> \"Accept-Language: ko; q=1.000, *; q=0.001\"\n> LANGUAGE=ko:en -> \"Accept-Language: ko; q=1.000, en; q=0.999, *; q=0.001\"\n>\n> This gives git servers a chance to display remote error messages in\n> the user's preferred language.\n> ---\n> http.c | 43 +++++++++++++++++++++++++++++++++++++++++++\n> t/t5550-http-fetch-dumb.sh | 10 ++++++++++\n> 2 files changed, 53 insertions(+)\n>\n> diff --git a/http.c b/http.c\n> index 3a28b21..c345616 100644\n> --- a/http.c\n> +++ b/http.c\n> @@ -983,6 +983,47 @@ static void extract_content_type(struct strbuf *raw, struct strbuf *type,\n> strbuf_addstr(charset, \"ISO-8859-1\");\n> }\n>\n> +/*\n> + * Add an Accept-Language header which indicates user's preferred languages\n> + * defined by 'LANGUAGE' environment variable if the variable is not empty.\n> + *\n> + * Example:\n> + * LANGUAGE= -> \"\"\n> + * LANGUAGE=ko -> \"Accept-Language: ko; q=1.000, *; q=0.001\"\n> + * LANGUAGE=ko:en -> \"Accept-Language: ko; q=1.000, en; q=0.999, *; q=0.001\"\n> + */\n> +static void add_accept_language(struct strbuf *buf)\n> +{\n> + const char *p1, *p2;\n> + float q = 1.000;\n> +\n> + p1 = getenv(\"LANGUAGE\");\n> +\n> + if (p1 != NULL && p1[0] != '\\0') {\n> + strbuf_reset(buf);\n\nIt seems wrong to clear 'buf' in a function named add_accept_language().\n\n> + strbuf_addstr(buf, \"Accept-Language: \");\n> + for (p2 = p1; q > 0.001; p2++) {\n> + if ((*p2 == ':' || *p2 == '\\0') && p1 != p2) {\n> + if (q < 1.0) {\n> + strbuf_addstr(buf, \", \");\n> + }\n> + strbuf_add(buf, p1, p2 - p1);\n> + strbuf_addf(buf, \"; q=%.3f\", q);\n> + q -= 0.001;\n> + p1 = p2 + 1;\n> +\n> + if (*p2 == '\\0') {\n> + break;\n> + }\n> + }\n> + }\n> + if (q < 1.0) {\n> + strbuf_addstr(buf, \", \");\n> + }\n> + strbuf_addstr(buf, \"*; q=0.001\\r\\n\");\n\nManually adding \"\\r\\n\" is contraindicated. Headers passed to\ncurl_easy_setopt(c, CURLOPT_HTTPHEADER, headers) must not have \"\\r\\n\",\nsince curl will add terminators itself [1].\n\n[1]: http://curl.haxx.se/libcurl/c/CURLOPT_HTTPHEADER.html\n\n> + }\n> +}\n> +\n> /* http_request() targets */\n> #define HTTP_REQUEST_STRBUF 0\n> #define HTTP_REQUEST_FILE 1\n> @@ -1020,6 +1061,8 @@ static int http_request(const char *url,\n> fwrite_buffer);\n> }\n>\n> + add_accept_language(&buf);\n\nThis is inconsistent with how other headers are handled by this\nfunction. The existing idiom is:\n\n strbuf_add(&buf, ...); /* construct header */\n headers = curl_slist_apend(headers, buf.buf);\n strbuf_reset(&buf);\n\n> +\n> strbuf_addstr(&buf, \"Pragma:\");\n> if (options && options->no_cache)\n> strbuf_addstr(&buf, \" no-cache\");\n> diff --git a/t/t5550-http-fetch-dumb.sh b/t/t5550-http-fetch-dumb.sh\n> index ac71418..ea15158 100755\n> --- a/t/t5550-http-fetch-dumb.sh\n> +++ b/t/t5550-http-fetch-dumb.sh\n> @@ -196,5 +196,15 @@ test_expect_success 'reencoding is robust to whitespace oddities' '\n> grep \"this is the error message\" stderr\n> '\n>\n> +test_expect_success 'git client sends Accept-Language' '\n> + GIT_CURL_VERBOSE=1 LANGUAGE=ko:en git clone \"$HTTPD_URL/accept/language\" 2>actual\n\nBroken &&-chain.\n\n> + grep \"^Accept-Language: ko; q=1.000, en; q=0.999, \\*; q=0.001\" actual\n\nDo you want to \\-escape the periods? (Or maybe use 'grep -F'?)\n\n> +'\n> +\n> +test_expect_success 'git client does not send Accept-Language' '\n> + GIT_CURL_VERBOSE=1 LANGUAGE= git clone \"$HTTPD_URL/accept/language\" 2>actual\n\nBroken &&-chain.\n\n> + test_must_fail grep \"^Accept-Language:\" actual\n> +'\n> +\n> stop_httpd\n> test_done\n> --\n> 2.0.1.473.gafdefd9.dirty\n"},{"id":"245567","messageId":"20140709051040.GB2318@sigill.intra.peff.net","threadId":"37077","inReplyTo":"1404834846-11812-1-git-send-email-eungjun.yi@navercorp.com","subject":"Re: [PATCH] http: Add Accept-Language header if possible","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2014-07-09T05:10:40Z","receivedAt":"2014-07-09T05:10:40Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Wed, Jul 09, 2014 at 12:54:06AM +0900, Yi EungJun wrote:\n\n> From: Yi EungJun \n> \n> Add an Accept-Language header which indicates the user's preferred\n> languages defined by 'LANGUAGE' environment variable if the variable is\n> not empty.\n> \n> Example:\n> LANGUAGE= -> \"\"\n> LANGUAGE=ko -> \"Accept-Language: ko; q=1.000, *; q=0.001\"\n> LANGUAGE=ko:en -> \"Accept-Language: ko; q=1.000, en; q=0.999, *; q=0.001\"\n> \n> This gives git servers a chance to display remote error messages in\n> the user's preferred language.\n\nShould this also take into account other language-related variables? I'd\nthink $LC_ALL, $LC_MESSAGES, and $LANG would affect it, too. Are\ncolon-separated values a standard in $LANGUAGE? I have never seen them,\nbut I admit I am not very knowledgeable about localization issues.\n\nAlso, we do we need to do more parsing? My $LANG is set to en_US.UTF-8.\nThe encoding part is presumably uninteresting to the remote server. I\nalso wonder if there are support functions in libc or as part of gettext\nthat can help us get these values.\n\n-Peff\n"},{"id":"245572","messageId":"CAFT+Tg8HZTsbWK2WHHg_q04LY5Vm7cjfNkfHGBEdbKjf1==rKw@mail.gmail.com","threadId":"37077","inReplyTo":"20140709051040.GB2318@sigill.intra.peff.net","subject":"Re: [PATCH] http: Add Accept-Language header if possible","fromName":"Yi, EungJun","fromEmail":"semtlenori@gmail.com","sentAt":"2014-07-09T05:46:35Z","receivedAt":"2014-07-09T05:46:35Z","isPatch":true,"sender":{"key":"semtlenori@gmail.com","avatar":"https://gravatar.com/avatar/8363435d2badb3450df0dd7c4ec2113f6e1d62c44dd3cf7dfe83c5a389b8a9bf?d=mp&s=160"},"body":"2014-07-09 14:10 GMT+09:00 Jeff King :\n> On Wed, Jul 09, 2014 at 12:54:06AM +0900, Yi EungJun wrote:\n>\n>> From: Yi EungJun \n>>\n>> Add an Accept-Language header which indicates the user's preferred\n>> languages defined by 'LANGUAGE' environment variable if the variable is\n>> not empty.\n>>\n>> Example:\n>> LANGUAGE= -> \"\"\n>> LANGUAGE=ko -> \"Accept-Language: ko; q=1.000, *; q=0.001\"\n>> LANGUAGE=ko:en -> \"Accept-Language: ko; q=1.000, en; q=0.999, *; q=0.001\"\n>>\n>> This gives git servers a chance to display remote error messages in\n>> the user's preferred language.\n>\n> Should this also take into account other language-related variables? I'd\n> think $LC_ALL, $LC_MESSAGES, and $LANG would affect it, too. Are\n> colon-separated values a standard in $LANGUAGE? I have never seen them,\n> but I admit I am not very knowledgeable about localization issues.\n>\n> Also, we do we need to do more parsing? My $LANG is set to en_US.UTF-8.\n> The encoding part is presumably uninteresting to the remote server. I\n> also wonder if there are support functions in libc or as part of gettext\n> that can help us get these values.\n>\n> -Peff\n\nI agree with you. In fact, I tried to get user's preferred language in\nthe same way as gettext. It has guess_category_value() to do that and\nthe function is good enough because it considers $LANGUAGE, $LC_ALL,\n$LANG, and also system-dependent preferences. But the function does\nnot seem a public API and I don't know how can I use the function in\nGit. So I chose to use $LANGUAGE only.\n"},{"id":"245574","messageId":"20140709061853.GA6731@sigill.intra.peff.net","threadId":"37077","inReplyTo":"CAFT+Tg8HZTsbWK2WHHg_q04LY5Vm7cjfNkfHGBEdbKjf1==rKw@mail.gmail.com","subject":"Re: [PATCH] http: Add Accept-Language header if possible","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2014-07-09T06:18:53Z","receivedAt":"2014-07-09T06:18:53Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Wed, Jul 09, 2014 at 02:46:35PM +0900, Yi, EungJun wrote:\n\n> I agree with you. In fact, I tried to get user's preferred language in\n> the same way as gettext. It has guess_category_value() to do that and\n> the function is good enough because it considers $LANGUAGE, $LC_ALL,\n> $LANG, and also system-dependent preferences. But the function does\n> not seem a public API and I don't know how can I use the function in\n> Git. So I chose to use $LANGUAGE only.\n\nI did some digging, and I think the public API is setlocale with a NULL\nparameter, like:\n\n printf(\"%s\\n\", setlocale(LC_MESSAGES, NULL));\n\nThat still will end up like \"en_US.UTF-8\", though; I couldn't find any\nstandard functions for parsing that. It seems like it would be pretty\nstraightforward to do so, though.\n\n>From my brief reading of rfc2616, that should probably become \"en-us\",\nand any time we add \"x-y\", we may want to add \"x\" as a fallback (that is\ncertainly true for English; I don't know about other languages with\ndialects).\n\n-Peff\n"},{"id":"245616","messageId":"alpine.DEB.2.00.1407091127490.22132@ds9.cixit.se","threadId":"37077","inReplyTo":"1404834846-11812-1-git-send-email-eungjun.yi@navercorp.com","subject":"Re: [PATCH] http: Add Accept-Language header if possible","fromName":"Peter Krefting","fromEmail":"peter@softwolves.pp.se","sentAt":"2014-07-09T10:40:05Z","receivedAt":"2014-07-09T10:40:05Z","isPatch":true,"sender":{"key":"peter@softwolves.pp.se","avatar":"https://avatars.githubusercontent.com/u/990764?v=4"},"body":"Yi EungJun:\n\n> Example:\n> LANGUAGE= -> \"\"\n> LANGUAGE=ko -> \"Accept-Language: ko; q=1.000, *; q=0.001\"\n> LANGUAGE=ko:en -> \"Accept-Language: ko; q=1.000, en; q=0.999, *; q=0.001\"\n\nAvoid adding \"q=1.000\". It is redundant (the default for any \nunqualified language names is 1.0, and additionally there has \nhistorically been some buggy servers that failed if it was included.\n\n> +\tp1 = getenv(\"LANGUAGE\");\n\nYou need a fallback mechanism here to parse all the possible language \nvariables. I would use the first one I find of these:\n\n 1. LANGUAGE\n 2. LC_ALL\n 3. LC_MESSAGES\n 4. LANG\n\nOnly \"LANGUAGE\" holds a colon-separated list, but the same code can \nparse all of them, just yielding a single entry for the others.\n\n> +\t\t\t\tstrbuf_add(buf, p1, p2 - p1);\n\nThe tokens are on the form language_COUNTRY.encoding@identifier, whereas \nAccept-Language wants language-COUNTRY, so you need to a) replace \"_\" \nwith \"-\", and b) chop off anything following a \".\" or \"@\".\n\n> +\t\t\t\tstrbuf_addf(buf, \"; q=%.3f\", q);\n> +\t\t\t\tq -= 0.001;\n\nThree decimals seems a bit overkill, but some experimentation might be \nnecessary.\n\n> +\t\tstrbuf_addstr(buf, \"*; q=0.001\\r\\n\");\n\nYou should probably also add an explicit \"en\" here, if none was \nalready included. I've seen some servers break horribly if \"en\" isn't \nincluded.\n\n\n\nFor reference, I have my LANGUAGE variable set to \n\"sv_SE.utf8:sv:nb_NO.utf8:nb:da_DK.utf8:da:nn_NO.utf8:nn:en_GB.utf8:en_US.utf8:en\"\n\n-- \n\\\\// Peter - http://www.softwolves.pp.se/\n"},{"id":"245617","messageId":"alpine.DEB.2.00.1407091142030.22132@ds9.cixit.se","threadId":"37077","inReplyTo":"20140709061853.GA6731@sigill.intra.peff.net","subject":"Re: [PATCH] http: Add Accept-Language header if possible","fromName":"Peter Krefting","fromEmail":"peter@softwolves.pp.se","sentAt":"2014-07-09T10:46:14Z","receivedAt":"2014-07-09T10:46:14Z","isPatch":true,"sender":{"key":"peter@softwolves.pp.se","avatar":"https://avatars.githubusercontent.com/u/990764?v=4"},"body":"Jeff King:\n\n> I did some digging, and I think the public API is setlocale with a \n> NULL parameter, like:\n>\n> printf(\"%s\\n\", setlocale(LC_MESSAGES, NULL));\n>\n> That still will end up like \"en_US.UTF-8\", though;\n\nAnd it only yields the highest-priority language, I think.\n\n> I couldn't find any standard functions for parsing that. It seems \n> like it would be pretty straightforward to do so, though.\n\nRFC 5646 is the current specification on language tags, btw.\n\n> From my brief reading of rfc2616, that should probably become \n> \"en-us\", and any time we add \"x-y\", we may want to add \"x\" as a \n> fallback (that is certainly true for English; I don't know about \n> other languages with dialects).\n\nYes, adding the generic fallback is necessary, as \"en-US\" on the server \nmatches a client's \"en\", but not vice versa. So if you request \"en-US\" \nand \"de\" and the server only has \"en-GB\" and \"de\", you'd get the \n\"de\" version.\n\nDebian's website has a nice writeup on the subject: \nhttp://www.debian.org/intro/cn#howtoset\n\n-- \n\\\\// Peter - http://www.softwolves.pp.se/\n"},{"id":"245710","messageId":"20140710201034.GB15615@sigill.intra.peff.net","threadId":"37077","inReplyTo":"alpine.DEB.2.00.1407091142030.22132@ds9.cixit.se","subject":"Re: [PATCH] http: Add Accept-Language header if possible","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2014-07-10T20:10:34Z","receivedAt":"2014-07-10T20:10:34Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Wed, Jul 09, 2014 at 11:46:14AM +0100, Peter Krefting wrote:\n\n> Jeff King:\n> \n> >I did some digging, and I think the public API is setlocale with a NULL\n> >parameter, like:\n> >\n> > printf(\"%s\\n\", setlocale(LC_MESSAGES, NULL));\n> >\n> >That still will end up like \"en_US.UTF-8\", though;\n> \n> And it only yields the highest-priority language, I think.\n\nI wasn't clear on whether POSIX locale variables actually supported\nmultiple languages with priorities. I have never seen that, though the\noriginal commit message indicated that LANGUAGE=x:y was a thing (I\nwasn't sure if that was a made-up thing, or something that libc actually\nsupported).\n\n> Debian's website has a nice writeup on the subject:\n> http://www.debian.org/intro/cn#howtoset\n\nThat seems to be about language settings in browsers, which are a much\nricher set of preferences than POSIX locales (I think).\n\nIt would not be wrong to have that level of configuration for git's http\nrequests, but I do not know if it is worth the effort. Mapping the\nuser's gettext locale into an accept-language header seems like a\nstraightforward way to communicate to the other side what the client is\nusing to show errors (so that errors coming from the server can match).\n\nIf that is the case, though, I wonder if we should actually be adding it\nas a git-protocol header so that all transports can benefit (i.e., we\ncould be localizing human-readable error messages in upload-pack,\nreceive-pack, etc).\n\n-Peff\n"},{"id":"245768","messageId":"CAFT+Tg8Z5z=vTcCTbwKMQeTAaqpTYzr5OzdfedV0q8J5KzG-Yg@mail.gmail.com","threadId":"37077","inReplyTo":"alpine.DEB.2.00.1407091127490.22132@ds9.cixit.se","subject":"Re: [PATCH] http: Add Accept-Language header if possible","fromName":"Yi, EungJun","fromEmail":"semtlenori@gmail.com","sentAt":"2014-07-11T09:05:56Z","receivedAt":"2014-07-11T09:05:56Z","isPatch":true,"sender":{"key":"semtlenori@gmail.com","avatar":"https://gravatar.com/avatar/8363435d2badb3450df0dd7c4ec2113f6e1d62c44dd3cf7dfe83c5a389b8a9bf?d=mp&s=160"},"body":"2014-07-09 19:40 GMT+09:00 Peter Krefting :\n> Yi EungJun:\n>\n>\n>> Example:\n>> LANGUAGE= -> \"\"\n>> LANGUAGE=ko -> \"Accept-Language: ko; q=1.000, *; q=0.001\"\n>> LANGUAGE=ko:en -> \"Accept-Language: ko; q=1.000, en; q=0.999, *; q=0.001\"\n>\n>\n> Avoid adding \"q=1.000\". It is redundant (the default for any unqualified\n> language names is 1.0, and additionally there has historically been some\n> buggy servers that failed if it was included.\n\nOk, I'll fix it.\n\n>\n>\n>> + p1 = getenv(\"LANGUAGE\");\n>\n>\n> You need a fallback mechanism here to parse all the possible language\n> variables. I would use the first one I find of these:\n>\n> 1. LANGUAGE\n> 2. LC_ALL\n> 3. LC_MESSAGES\n> 4. LANG\n>\n> Only \"LANGUAGE\" holds a colon-separated list, but the same code can parse\n> all of them, just yielding a single entry for the others.\n\nI'll use setlocale(LC_MESSAGES, NULL) as well as getenv(\"LANGUAGE\").\n\n>\n>\n>> + strbuf_add(buf, p1, p2 - p1);\n>\n>\n> The tokens are on the form language_COUNTRY.encoding@identifier, whereas\n> Accept-Language wants language-COUNTRY, so you need to a) replace \"_\" with\n> \"-\", and b) chop off anything following a \".\" or \"@\".\n>\n>\n>> + strbuf_addf(buf, \"; q=%.3f\", q);\n>> + q -= 0.001;\n>\n>\n> Three decimals seems a bit overkill, but some experimentation might be\n> necessary.\n\nI'll use three decimals only if there are 100 or more preferred languages.\n\n>\n>\n>> + strbuf_addstr(buf, \"*; q=0.001\\r\\n\");\n>\n>\n> You should probably also add an explicit \"en\" here, if none was already\n> included. I've seen some servers break horribly if \"en\" isn't included.\n\nI'll send Accept-Language only if there is at least one preferred\nlanguage. Is it enough?\n\nThanks for your review.\n"},{"id":"245771","messageId":"CAFT+Tg_Zkim8DJzdKHa5d7ibN3Za-fftd9m-cZDo3rizLdQ=xg@mail.gmail.com","threadId":"37077","inReplyTo":"20140710201034.GB15615@sigill.intra.peff.net","subject":"Re: [PATCH] http: Add Accept-Language header if possible","fromName":"Yi, EungJun","fromEmail":"semtlenori@gmail.com","sentAt":"2014-07-11T09:43:18Z","receivedAt":"2014-07-11T09:43:18Z","isPatch":true,"sender":{"key":"semtlenori@gmail.com","avatar":"https://gravatar.com/avatar/8363435d2badb3450df0dd7c4ec2113f6e1d62c44dd3cf7dfe83c5a389b8a9bf?d=mp&s=160"},"body":"2014-07-11 5:10 GMT+09:00 Jeff King :\n> On Wed, Jul 09, 2014 at 11:46:14AM +0100, Peter Krefting wrote:\n>\n>> Jeff King:\n>>\n>> >I did some digging, and I think the public API is setlocale with a NULL\n>> >parameter, like:\n>> >\n>> > printf(\"%s\\n\", setlocale(LC_MESSAGES, NULL));\n>> >\n>> >That still will end up like \"en_US.UTF-8\", though;\n>>\n>> And it only yields the highest-priority language, I think.\n>\n> I wasn't clear on whether POSIX locale variables actually supported\n> multiple languages with priorities. I have never seen that, though the\n> original commit message indicated that LANGUAGE=x:y was a thing (I\n> wasn't sure if that was a made-up thing, or something that libc actually\n> supported).\n>\n>> Debian's website has a nice writeup on the subject:\n>> http://www.debian.org/intro/cn#howtoset\n>\n> That seems to be about language settings in browsers, which are a much\n> richer set of preferences than POSIX locales (I think).\n>\n> It would not be wrong to have that level of configuration for git's http\n> requests, but I do not know if it is worth the effort. Mapping the\n> user's gettext locale into an accept-language header seems like a\n> straightforward way to communicate to the other side what the client is\n> using to show errors (so that errors coming from the server can match).\n\nThanks for you advice. I'll write a path to use both of\nsetlocale(LC_MESSAGES, NULL) and getenv(\"LANGUAGE\") to get the user's\npreferred language. setlocale(LC_MESSAGES, NULL) is quite nice way\nbecause it takes LC_ALL, LC_MESSAGES and LANG into account, but not\nLANGUAGE. I think we should take also LANGUAGE into account as gettext\ndoes. [1]\n\n[1]: http://www.gnu.org/software/gettext/manual/gettext.html#Locale-Environment-Variables\n"},{"id":"245793","messageId":"CAFT+Tg9vLE-xr9dBV8uD=f0xu+U4_XOqdRC5ZKd95P0vLqfdbw@mail.gmail.com","threadId":"37077","inReplyTo":"CAPig+cQ05pzU9uVBqS8tBHvB8_3qAtgsPYz1sGhpa0W1CVymqA@mail.gmail.com","subject":"Re: [PATCH] http: Add Accept-Language header if possible","fromName":"Yi, EungJun","fromEmail":"semtlenori@gmail.com","sentAt":"2014-07-11T16:35:30Z","receivedAt":"2014-07-11T16:35:30Z","isPatch":true,"sender":{"key":"semtlenori@gmail.com","avatar":"https://gravatar.com/avatar/8363435d2badb3450df0dd7c4ec2113f6e1d62c44dd3cf7dfe83c5a389b8a9bf?d=mp&s=160"},"body":"2014-07-12 1:24 GMT+09:00 Eric Sunshine :\n> On Fri, Jul 11, 2014 at 5:22 AM, Yi, EungJun wrote:\n>> 2014-07-09 6:52 GMT+09:00 Eric Sunshine :\n>>>> + grep \"^Accept-Language: ko; q=1.000, en; q=0.999, \\*; q=0.001\" actual\n>>>\n>>> Do you want to \\-escape the periods? (Or maybe use 'grep -F'?)\n>>\n>> I just want to match '*' character. I tried 'grep -F' but it does not help.\n>\n> I meant that the periods in your grep pattern are matching any\n> character. If you want to be very strict, so that they match only\n> period, then you should \\-escape them.\n\nOops, I misunderstood you. You are right. I'll \\- escape them.\n"},{"id":"245890","messageId":"alpine.DEB.2.00.1407121110070.18850@ds9.cixit.se","threadId":"37077","inReplyTo":"20140710201034.GB15615@sigill.intra.peff.net","subject":"Re: [PATCH] http: Add Accept-Language header if possible","fromName":"Peter Krefting","fromEmail":"peter@softwolves.pp.se","sentAt":"2014-07-12T10:11:17Z","receivedAt":"2014-07-12T10:11:17Z","isPatch":true,"sender":{"key":"peter@softwolves.pp.se","avatar":"https://avatars.githubusercontent.com/u/990764?v=4"},"body":"Jeff King:\n\n> If that is the case, though, I wonder if we should actually be adding it\n> as a git-protocol header so that all transports can benefit (i.e., we\n> could be localizing human-readable error messages in upload-pack,\n> receive-pack, etc).\n\nThat would be very nice, thre is a lot of language mixing going on at \nthe moment.\n\n-- \n\\\\// Peter - http://www.softwolves.pp.se/\n"}]}