Re: Accept-language test fails on Mac OS

["Torsten Bögershausen" <tboegi@web.de>]

On 07.12.14 08:18, Jeff King wrote:
> 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
> --
(I remember debugging t0204 some time ago)

We may get inspiration from this, either how to adjust the locale to be used,
or if the test should be skipped.

 grep -l is_IS *
lib-gettext.sh
t0200-gettext-basic.sh
t0203-gettext-setlocale-sanity.sh
t0204-gettext-reencode-sanity.sh