From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 122874 invoked by alias); 9 Nov 2016 10:49:30 -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 122850 invoked by uid 89); 9 Nov 2016 10:49:29 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.1 required=5.0 tests=BAYES_50,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=ham version=3.3.2 spammy=dates, rafal, datetime, UD:cldr.unicode.org X-HELO: mx1.redhat.com Subject: Re: [RFC][PATCH v4 06/11] Provide backward compatibility for strftime family (bug 10871). To: Rafal Luzynski , libc-alpha@sourceware.org References: <758885038.1799972.1477615768169@poczta.nazwa.pl> <71b7640e-55b0-06a5-1dff-b0fcbaf0eea9@redhat.com> <1458120697.2205845.1478343189427@poczta.nazwa.pl> <238ab162-7ff7-d90e-9f95-630ac413a064@redhat.com> <579374375.2202122.1478605156225@poczta.nazwa.pl> From: Florian Weimer Message-ID: <36cfa35f-bd1c-d880-ef85-185d07096c8d@redhat.com> Date: Wed, 09 Nov 2016 10:49:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: <579374375.2202122.1478605156225@poczta.nazwa.pl> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-SW-Source: 2016-11/txt/msg00321.txt.bz2 On 11/08/2016 12:39 PM, Rafal Luzynski wrote: > CLDR refers to "stand-alone" and "format", it seemed to ambiguous to me. > More info: > http://cldr.unicode.org/translation/date-time#TOC-Stand-Alone-vs.-Format-Styles I think this distinction is not too bad. It's certainly an improvement over the declension-based approach. The additional explanation regarding elision is also helpful. >> then all applications >> which currently use %B are broken > > Are they broken already? When you type this command: > > $ date +"%d %B %Y" > > is it broken in German locale? Yes, it should be $ date +"%-d. %B %Y This wasn't your point, but it's still relevant because it means that such date format strings need translation. But that's probably true for the strings used by tools like cal (where "%B %Y" may not work unconditionally today). > Note that a genitive form will be used only if it is provided in > locale data. So if German language has a genitive form but does not > require (or even prohibits) using it when formatting a full date then > all you have to do is not to provide any changes to the locale, just > leave it as is. My patch provides a way to provide two different > forms for month names but this second form is optional. There will > be no change visible if there are no changes in the locale data. > That's the reason why I have also provided sample locale data for > some languages; these changes are not intended to be committed > (although may be committed if translators apparently find them > correct). Right, German wouldn't need any changes because there is only one set of month names relevant here. > In your example, a phrase “on the last Sunday of November” looks > like an attempt to employ strftime() to generate natural language > sentences rather than to format a date. It's been discussed in > bugzilla and stated that strftime() will never be suitable for this. Yes, I fully expect that this would not work. The use of the genitive in full date specifications has almost completely died out in German, and the genitive is no longer very pronounced, either (the trailing “s” is sometimes elided). I still find it odd that we want to turn %B into the mangled name for full dates, and not %OB (and switch all the formats in places that want to use the new capability). The latter seems to be better from a backwards-compatibility perspective. In fact, a *lot* of languages today use "%d de %B" as the date format string (although not in our locales, we usually sidestep this by using abbreviations only for %c). In some of these languages, the “e” in “de” is subject to elision, so we really want 14 d'abril and not 14 de abril The only wait to get this is to put the “de” and “d'” into the mangled month name (as has been suggested in the CLDR reference). But this means that "%d de %B" (which seems to be the most commonly used form for these languages today) is expanded into “14 de d'abril”, which is not what we want. I am worried that this puts pressure on us *not* to introduce mangled month names at all for these languages. These issues go away if we keep the existing month names unchanged and add the new mangled names under new identifiers. Florian