From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21900 invoked by alias); 19 Apr 2018 19:55:31 -0000 Mailing-List: contact libc-alpha-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: libc-alpha-owner@sourceware.org Received: (qmail 21884 invoked by uid 89); 19 Apr 2018 19:55:30 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.2 spammy=assured, Mexican, mexican, government X-HELO: mail-qk0-f173.google.com X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=KE9pjJjOyc3AiJ4KYZ4yzrdYavsTVBH1y0Mb0oVTjic=; b=aOobv5DgM0sTx2cxZvqOLrONY2X0AmZkeoZzRYsDIxHFQ6n96rLuCCqsBkJ5opHRaf bUr1VRvqmtKHAvW224ePn4D3QrAteNt2xWFx9mZYLFzcBCg7a8zZgj2sFw8VjYNNrn7Y fgfmqZbENqUDa79l1xfaugnb7R8Xq9jPnfTG9dU6jAO/SnKDba1wVQvy2PJkNxpMDy9L a3RtjGoxJ5AncYUiqSmWwftLZPTfjWqedKKL6w7bTteQeGJA2USkseB6w16CfOOQLzbA tojq6+7hFz0OQjmHjsF8i03nnB0i7DiidJs4ctMLJMUEMZebHzqyqaiUFRNMKJchVTpY ZlSw== X-Gm-Message-State: ALQs6tCPQT7i9ZgCGoz5g5b9tKmDl/aewLyCHCLZ4rTze4Zimka2gnnn NxmamI2Ntj4RR6j+L2TOcERsdN+G6K4= X-Google-Smtp-Source: AB8JxZrV3ph10OoUbCwulvPhk+54W3fe1vKdgAOVqhvgQCUnfL288cEoM48VHNRoJHFHdk8z86bvfg== X-Received: by 10.55.132.132 with SMTP id g126mr7139657qkd.108.1524167726694; Thu, 19 Apr 2018 12:55:26 -0700 (PDT) Subject: Re: de_DE has been using the wrong group separator for over 18 years To: Florian Weimer , libc-alpha@sourceware.org References: <7224816.qpMlRvYOtE@punchy> <4012681.xXnO2VdWZr@punchy> <80f237b7-13c1-982b-fe87-baece295335e@redhat.com> <3237899.yz248PDzAY@punchy> <5afc27d0-e707-0b50-8798-8dbe0b555239@redhat.com> From: Carlos O'Donell Message-ID: <69ed0e78-5c46-60b5-0cff-f628ff1755bc@redhat.com> Date: Thu, 19 Apr 2018 19:55:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: <5afc27d0-e707-0b50-8798-8dbe0b555239@redhat.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-SW-Source: 2018-04/txt/msg00432.txt.bz2 On 04/19/2018 03:55 AM, Florian Weimer wrote: > On 04/18/2018 11:10 PM, kdex wrote: >> Hence, the point is less that locale users need the ability to have >> U+2009 mapped on their keyboards somewhere, but rather that users >> should be able to input regular numbers and rely on their software >> to use their system locale to figure out how their numbers should >> be displayed according to the current locale. > > But that's not how people enter numbers in their word processor. > > U+2009 also has the wrong line breaking property in the basic Unicode > line breaking algorithm , so it > makes it quite hard for word processors to do the right thing even if > the user managers to enter this character. We use U+202F now. There is some history here with regard to U+2009. I reviewed the es_MX case for thousands_sep becoming U+2009, and I wrote to the Mexican government, and reviewed the relative standards and cultural use cases, but I did *not* consider the impact on the ability for users to type or the line-breaking aspects of the change (nor do I think the standard covered these problems). It seemed like U+2009 was the right choice, but this resulted in swbz#20756: https://sourceware.org/bugzilla/show_bug.cgi?id=20756 And Mike Fabian fixed this after my review and we now use Narrow non-breaking space (U+202F). So you could use U+202F, but it seems like this is just wishful thinking on the part of standards. Just like how Canada claims to follow ISO 8601 everywhere and then doesn't. I agree with the sentiment that these should be "trailing standards" that define existing practice. Where existing practice matches government standards, you are assured that there has been consensus and can adjust the locales to match. -- Cheers, Carlos.