From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mo4-p00-ob.smtp.rzone.de (mo4-p00-ob.smtp.rzone.de [81.169.146.219]) by sourceware.org (Postfix) with ESMTPS id 311403858D3C for ; Tue, 12 Sep 2023 14:44:39 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 311403858D3C Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=clisp.org Authentication-Results: sourceware.org; spf=none smtp.mailfrom=clisp.org ARC-Seal: i=1; a=rsa-sha256; t=1694529876; cv=none; d=strato.com; s=strato-dkim-0002; b=b2ot4+jIeYxsytHbaOv6gmhNML+U+TfkOp5elS5HoLJ1kgfYVmmgnrdo2G+b0ZhgcT gF3I4RrVVpGci4By0jDbbdL/IWb8JS63qmib+EiGLMdM/4e0XdGYl/FfYmthipEB9R1Z eClJzUMWzO8zFAhASzfuAIFzGg8ikk8EhlU9SDRXtYdNHRG4i9w3zkShevzXo/hKAptJ kySa/GfEn41msuEKIxhXU1VvCDli//eDzFWkQXfcMUBm8GMoxnUaUs0sCJbzkulV+Hhb PfQnBzC3flmbC1Gk0VR6p+eDidUFDPnKwm+D7WZ2JTk8fyn14Naca1eyVu9SBQEt5vqW hezw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; t=1694529876; s=strato-dkim-0002; d=strato.com; h=References:In-Reply-To:Message-ID:Date:Subject:Cc:To:From:Cc:Date: From:Subject:Sender; bh=AAIDP8khxYAzrSmGf8Xu4lPnkgJTsFcMIt0O22Bfjvs=; b=QI/McGK8RKAvZOu1EYDIbbiFvnaOuB7YBkFMkF4ne7WTHfrXCJcWfbWxccIdEU744x u03QJ0i0atA1sDC5POsqtPv+GmOgvg4rSlDnRkXIvIo8Y6/phbrvgizqjpLjrym3bOD1 XgOMiIj/ldVStHMbCacbHUSS8fWPIWospEmmRWX/mQDoSdWkQ2v/jBbGIArSZFIMpv+g iEZLoBQT6Y4ZQgoqhoDH4qcrJQGmSB/kiA9bd04wG5iDmd/YuIRdV+ZLsAPVSSKcxFNw ACm7ZFZ43szyeXyNKWh0KAivWjMR9slkRvvx5twS4J5cjS5BJnH/21RZYXDvK8s/orrz R8Iw== ARC-Authentication-Results: i=1; strato.com; arc=none; dkim=none X-RZG-CLASS-ID: mo00 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1694529876; s=strato-dkim-0002; d=clisp.org; h=References:In-Reply-To:Message-ID:Date:Subject:Cc:To:From:Cc:Date: From:Subject:Sender; bh=AAIDP8khxYAzrSmGf8Xu4lPnkgJTsFcMIt0O22Bfjvs=; b=OCvOzbDbhYWaZiQ//l/2YtF9fBfrMiI+7afLZNo5dy7l5Cle8uHvko4JBhUVJ0hBEq jLigRS5s9zza6VXXqLO/KXsUFn+Eal6ljhFU0deNMNiHI0z5Bn5bL1jz921uwD7CkLxF nIyUWwyt9nd+eDAPnmhYeei7oc92YDwRKW3gfDSKmgps6ZQ5yOaqhPoJJXcfmoOCQvDb SOsl20eaaYgw0hgaqHT46i5pPjd9QSmbgSJPvDos1s+SDTxZVYgRFWhLNukxAGAPE3bh h0rP3A6fVeRv16Rwi3tFvM1STJ6T1MWPItI7i0y0tt7IVHicQHGz3g2dEsOkdS/xeIHe DZnA== DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; t=1694529876; s=strato-dkim-0003; d=clisp.org; h=References:In-Reply-To:Message-ID:Date:Subject:Cc:To:From:Cc:Date: From:Subject:Sender; bh=AAIDP8khxYAzrSmGf8Xu4lPnkgJTsFcMIt0O22Bfjvs=; b=hYFWyAkzrV1v7yg7D64S2W7rnbz///Hu5s81An9N234kGk8IEGJFDh5FndbnsuLCRx cIHqd29acGbjbnyJZoBg== X-RZG-AUTH: ":Ln4Re0+Ic/6oZXR1YgKryK8brlshOcZlIWs+iCP5vnk6shH0WWb0LN8XZoH94zq68+3cfpOTiPSPDUfxpScP9m5S8VeRbWcTxQ==" Received: from nimes.localnet by smtp.strato.de (RZmta 49.8.2 AUTH) with ESMTPSA id m03934z8CEia7X3 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256 bits)) (Client did not present a certificate); Tue, 12 Sep 2023 16:44:36 +0200 (CEST) From: Bruno Haible To: Florian Weimer Cc: libc-alpha@sourceware.org Subject: Re: [PATCH] intl: Treat C.UTF-8 locale like C locale, part 2 (BZ# 16621) Date: Tue, 12 Sep 2023 16:44:36 +0200 Message-ID: <10272749.85pcf5A44T@nimes> In-Reply-To: <87o7i92m0p.fsf@oldenburg.str.redhat.com> References: <20230910191739.1083016-1-bruno@clisp.org> <87o7i92m0p.fsf@oldenburg.str.redhat.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Spam-Status: No, score=-3.9 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_LOW,RCVD_IN_MSPIKE_H5,RCVD_IN_MSPIKE_WL,SPF_HELO_PASS,SPF_NONE,TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: Florian Weimer wrote: > > The previous commit was incomplete: gettext() still returns a translation > > if the file /usr/share/locale/C/LC_MESSAGES/.mo exists. This patch > > prohibits the translation also in this case. > > I wasn't sure if this is a bug. The implementation does not fallback to > translation, it just uses C as a message catalog. Do you consider this > a problem? Yes, I consider this a bug, for two reasons: * The wiki page https://sourceware.org/glibc/wiki/Proposals/C.UTF-8 states "It shall be the C locale but with UTF-8 encodings." and "These will be the same as C... LC_MESSAGES" The C locale has the property that gettext() returns the msgid in all cases, regardless of what files are on disk and regardless of the values of any environment variables. If the C.UTF-8 has the property that gettext() returns msgid only if there is no translation catalog at /usr/share/locale/C/LC_MESSAGES/.mo, it is *not* the same as "the C locale but with UTF-8 encodings". * We have this rule, that gettext() returns the msgid when the locale is the "C" locale, because - the POSIX standard specifies the precise output of some programs (e.g. 'diff') in the C locale, and - we wanted, from the beginning in 1995, that gettext() can be used in the source code of these programs, without an explicit check for the locale. It is possible that, in the long run, POSIX adopts the C.UTF-8 locale, since several platforms already have it: glibc, musl libc, FreeBSD, NetBSD, OpenBSD, Cygwin, Android. When this happens, we want that the maintainers of 'diff' etc. can continue to use gettext(), without introducing an explicit check for the locale. Bruno