git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jeff King <peff@peff.net>
To: "Torsten Bögershausen" <tboegi@web.de>
Cc: semtlenori@gmail.com, Michael Blume <blume.mike@gmail.com>,
	Junio C Hamano <gitster@pobox.com>,
	Git List <git@vger.kernel.org>
Subject: Re: Accept-language test fails on Mac OS
Date: Sun, 7 Dec 2014 02:18:28 -0500	[thread overview]
Message-ID: <20141207071827.GA31014@peff.net> (raw)
In-Reply-To: <54836F46.9080009@web.de>

On Sat, Dec 06, 2014 at 10:04:06PM +0100, Torsten Bögershausen wrote:

> I get this:
> 
> 
> expecting success: 
>         check_language "ko-KR, *;q=0.1" ko_KR.UTF-8 de_DE.UTF-8 ja_JP.UTF-8 en_US.UTF-8 &&
>         check_language "de-DE, *;q=0.1" ""          de_DE.UTF-8 ja_JP.UTF-8 en_US.UTF-8 &&
>         check_language "ja-JP, *;q=0.1" ""          ""          ja_JP.UTF-8 en_US.UTF-8 &&
>         check_language "en-US, *;q=0.1" ""          ""          ""          en_US.UTF-8
> 
> --- expect      2014-12-06 21:00:59.000000000 +0000
> +++ actual      2014-12-06 21:00:59.000000000 +0000
> @@ -1 +0,0 @@
> -Accept-Language: de-DE, *;q=0.1
> not ok 25 - git client sends Accept-Language based on LANGUAGE, LC_ALL, LC_MESSAGES and LANG

I can reproduce the same problem here (Debian unstable). I actually ran
into three issues (aside from needing to use Junio's SQUASH commit, to
avoid the "\r" bash-ism):

  1. I couldn't build without including locale.h, for the
     definition of setlocale() and the LC_MESSAGES constant (both used
     in get_preferred_languages).

     I'm not sure what portability issues there are with including it
     unconditionally. Should this possibly be tied into gettext.c, which
     already uses setlocale?

  2. The call to setlocale(LC_MESSAGES, NULL) in get_preferred_languages
     always returns "C" for me. This seems related to building with
     NO_GETTEXT (which I typically do), as we never init setlocale
     if NO_GETTEXT is set. This program demonstrates it:

	#include <stdio.h>
	#include <string.h>
	#include <locale.h>
	
	int main(int argc, char **argv)
	{
		if (argv[1] && !strcmp(argv[1], "init"))
			setlocale(LC_MESSAGES, "");
		printf("%s", setlocale(LC_MESSAGES, NULL));
		return 0;
	}

     If I run it as "LANG=en_US.UTF-8 ./a.out", it prints "C". If I run
     it as "LANG=en_US.UTF-8 ./a.out init", it prints "en_US.UTF-8". I
     think we either need to start unconditionally calling setlocale()
     as we do in git_setup_gettext, or we need to tie your feature to
     using gettext.

     This is what causes the failure of the de-DE test for me; building
     without NO_GETTEXT makes it work. Note that this doesn't affect the
     first test for ko-KR, because that test sets LANGUAGE, which we
     read ourselves (so we never make a setlocale() call).

  3. Even building with NO_GETTEXT, setlocale() does not want to
     report ja_JP.UTF-8 for me, making the third test fail.

     I think the issue is that I do not build the ja_JP locale on my
     system. Running "dpkg-reconfigure locales" and asking it to build
     ja_JP.UTF-8 makes the test pass. This is somewhat of a Debian-ism.
     From "man locale-gen":

       By default, the locale package which provides the base support
       for localisation of libc-based programs does not contain usable
       localisation files for every supported language. This limitation
       has became necessary because of the substantial size of such
       files and the large number of languages supported by libc. As a
       result, Debian uses a special mechanism where we prepare the
       actual localisation files on the target host and distribute only
       the templates for them.

     I suspect it is inherited by Debian derivatives like Ubuntu. But I
     also don't know that we can count on other platforms having all of
     the locales either (e.g., they may ship them as separate packages,
     not all of which are installed).

     So I'm not sure of an easy way around this. You want 4 separate
     locales to thoroughly test, but you cannot rely on any particular
     locale being present on the user's system.

     Note that this is just a problem with the tests, probably not with
     the feature itself. Presumably people setting LANG=ja_JP actually
     have that locale on their system (though technically this feature
     is about asking the _server_ to use that language, it seems like
     you would do so because you were using that language locally, too).

-Peff

  parent reply	other threads:[~2014-12-07  7:37 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-12-05 22:35 Accept-language test fails on Mac OS Michael Blume
2014-12-05 22:51 ` Junio C Hamano
2014-12-05 23:01   ` Michael Blume
2014-12-06  9:50     ` Torsten Bögershausen
2014-12-06 19:44       ` Yi, EungJun
2014-12-06 21:04         ` Torsten Bögershausen
2014-12-07  6:54           ` Yi, EungJun
2014-12-07  9:56             ` Torsten Bögershausen
2014-12-07  7:18           ` Jeff King [this message]
2014-12-07 10:03             ` Torsten Bögershausen
2014-12-08 15:51             ` Christian Couder

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20141207071827.GA31014@peff.net \
    --to=peff@peff.net \
    --cc=blume.mike@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=semtlenori@gmail.com \
    --cc=tboegi@web.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).