X-Recipient: archive-cygwin AT delorie DOT com X-SWARE-Spam-Status: No, hits=-2.5 required=5.0 tests=AWL,BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,T_TO_NO_BRKTS_FREEMAIL X-Spam-Check-By: sourceware.org MIME-Version: 1.0 In-Reply-To: <4E69D9EA.2050004@cwilson.fastmail.fm> References: <7856072A9D04C24B82DFE2B1112FE38A0C27492B56 AT MCHP058A DOT global-ad DOT net> <201109081246 DOT 23238 DOT bruno AT clisp DOT org> <4E68AF35 DOT 9030002 AT cwilson DOT fastmail DOT fm> <201109082344 DOT 55506 DOT bruno AT clisp DOT org> <4E69D9EA DOT 2050004 AT cwilson DOT fastmail DOT fm> Date: Fri, 9 Sep 2011 13:33:20 +0100 Message-ID: Subject: Re: cygwin started speaking German today From: Andy Koppe To: cygwin AT cygwin DOT com Cc: Bruno Haible , bug-gnu-gettext AT gnu DOT org Content-Type: text/plain; charset=UTF-8 X-IsSubscribed: yes Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner AT cygwin DOT com Mail-Followup-To: cygwin AT cygwin DOT com Delivered-To: mailing list cygwin AT cygwin DOT com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by delorie.com id p89CXfTf021596 On 9 September 2011 10:18, Charles Wilson wrote: > On 9/8/2011 5:44 PM, Bruno Haible wrote: >> Find below a patch which ought to fix this. But it has upsides and downsides. >> The upside: It treats LC_ALL, LC_$category, LANG consistently, like POSIX >> wants it. > > Consistently, yes.  Correctly...no.  You said earlier: > > "Users who want to have a German Windows but a non-internationalized > Cygwin can set LANG=C or LC_ALL=C - exactly like POSIX specifies." > > With your patch, this is /technically/ true: if I set LANG=C exactly, > without the UTF-8 charset specifier, then yes -- I'll get english cygwin > with german windows.  But, your patch explicitly ignores "C.UTF-8" -- so > if I deliberately select the "C" locale with the "UTF-8" charset, I will > get...the german locale. > > That can't be right. > > Now, the reason you're ignoring "C.UTF-8" is because you want to > override cygwin's default locale setting -- which is implemented in two > ways: #1, cygwin's internal code for 'setlocale(LC_blah, "")' returns > that value, and #2, some older versions of the base-files startup > scripts (/etc/profile, /etc/skel/.*, and the like) used to set LANG or > LC_* IIRC.  However, they no longer do so Actually, that is still done, in /etc/profile.d/lang.sh. It's for the benefit of other programs who think they know better than the system (emacs, I'm looking at you) by analyzing LC_* and LANG themselves instead of relying on setlocale(). > Now, long term, I think what we will see is that some part of your > suggestions here: > http://cygwin.com/ml/cygwin/2011-09/msg00084.html > will eventually be implemented in cygwin.  When that happens, libintl > will have to change again. > > Until then, what? > > My suggestion for the "interim" libintl behavior is this: > > If /no/ relevant env vars are set > then >        if setlocale(LC_*, "") returns C.UTF-8 >        # which we know is the /current/ cygwin default locale >        then >                query Win32 API for "real" default locale >        else >                use what setlocale returns > else >        use the env var value; don't ignore 'C.UTF-8' >        # if I have explicitly set LANG=C.UTF-8 then I must really >        # really want the "C" locale, not en_US or de. Please, no. As Corinna said: "Do NOT call Windows functions in Cygwin libraries, unless the lib is doing something very special which isn't provided by POSIX functions. Only call POSIX functions. Don't mix the Cygwin and the Windows environment. Please leave the interfacing to the underlying OS the sole job of Cygwin." >> The downside: It makes libintl_setlocale's behaviour diverge a little more from >> Cygwin's setlocale behaviour. >> Should I commit the patch or not? > > I don't think so.  What do you think about the algorithm above, at least > for now, until cygwin's internal behavior is improved -- I tend to agree > with Eric: > http://cygwin.com/ml/cygwin/2011-09/msg00061.html > "I'd argue that if none of LC_* or LANG are set, then > setlocale(LC_BLA,"") should indeed return the system default, rather > than being hard-coded to C. " > and > "I also agree with this sentiment - if setlocale(LC_BLA, "") is not > returning sane results (that is, if there is a system default, but > cygwin is not honoring those defaults), then the bug should be fixed in > cygwin, not libintl." The 'C.UTF-8' default locale is not a bug, it was a deliberate design decision. Of course a good case can be made for picking up the Windows language in case none of LC_* and LANG are set, but there are also obvious arguments against: translations are usually patchy, i.e. you end up with a mix of English and translations of varying quality, which a lot of people hate. Futhermore, Cygwin is mostly a command line environment, with commands and options having English names, its userbase is probably even more geeky than that of your average Linux distribution, and Cygwin's homepage and setup program are English-only anyway. Hence it doesn't seem likely that defaulting to English is keeping a lot of users away. Nevertheless, I'm on the fence on whether the default should be changed, but I certainly agree with Eric in that any such change should be implemented in the Cygwin DLL rather than in particular packages. Andy -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple