From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13767 invoked by alias); 10 Nov 2016 00:33:17 -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 13753 invoked by uid 89); 10 Nov 2016 00:33:16 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-0.7 required=5.0 tests=AWL,BAYES_00,KAM_LAZY_DOMAIN_SECURITY autolearn=no version=3.3.2 spammy=H*x:Mailer, H*UA:Mailer, Therefore, italian X-HELO: aev204.rev.netart.pl Date: Thu, 10 Nov 2016 00:33:00 -0000 From: Rafal Luzynski Reply-To: Rafal Luzynski To: libc-alpha@sourceware.org, Florian Weimer Message-ID: <1326125332.562051.1478737983449@poczta.nazwa.pl> In-Reply-To: <36cfa35f-bd1c-d880-ef85-185d07096c8d@redhat.com> 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> <36cfa35f-bd1c-d880-ef85-185d07096c8d@redhat.com> Subject: Re: [RFC][PATCH v4 06/11] Provide backward compatibility for strftime family (bug 10871). MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Originating-Client: com.openexchange.ox.gui.dhtml X-SW-Source: 2016-11/txt/msg00371.txt.bz2 9.11.2016 11:49 Florian Weimer wrote: > > > On 11/08/2016 12:39 PM, Rafal Luzynski wrote: > > [...] > >> 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. Yes, they do, and the translators do their jobs correctly already. However, they are unable to provide a correct form when a month in a genitive case is required (or more generally: a different form is required for the month name in a date while the current form must be retained for other purposes). > But that's probably true for > the strings used by tools like cal (where "%B %Y" may not work > unconditionally today). Yes, and in many other cases: some languages require a dot after a day number, some don't; some prefer "%d %B" some "%B %d" etc. > [...] > 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. I've discussed all possible solutions in [1], including what you have proposed here. Shortly, no solution is perfect and each has its advantages and disadvantages. Your solution has these pros: - does not cause any backward compatibility issues; - does not break any existing application where the current solution is correct. At the same time it has the following cons: - introduces incompatibilities with *BSD family (including OS X) and with the probable future POSIX specification which will remain forever - please read below why I find it important; - does not actually solve the problem for any existing application until the authors or translators change %B to %OB (in case of open source programs we can reach the upstreams and suggest solution). My solution has these pros: - will automagically solve the problems for all applications where it is broken; - will remain compatible with an existing *BSD solution and possible future POSIX specification. Also has this disadvantage: - will break some existing applications where current solution is correct; but: - in case of open source software we can reach the upstreams and suggest solution; - in case of closed source software distributed in a binary form we can provide a backward compatible ABI which will provide the old behaviour for older programs. I believe there are less cases where the a month name is displayed standalone than those where it is displayed with a day number therefore I believe that a fallout caused by applications broken by my solution is smaller than the fallout caused by the applications broken now. And the severity of the new bugs is equal to the severity of the current bugs. Therefore I'm still on the side of my solution. Of course I'm not a regular glibc developer so if you use your power and provide your solution (you're even free to rework my patches) then I'll have nothing more than live with that; the apps are able to adopt to it, too. Now more about why it's valuable IMHO to remain compatible with other systems. The next thing I'm going to do is to fix the same bug in glib. [2] The solution of swbz#10871 will automagically fix bgo#749206 on Linux and provide a specification of how to fix it on other platforms. Glib is a portable multiplatform library so if we implement ALTMON_x and %OB in a manner incompatible with *BSD then we'll have to say to the developers: - on Linux in g_date_strftime() use %B and %OB; - on OS X and *BSD use %OB and %B (note: swapped); - on Windows we'll provide a custom solution, yet to be decided whether it'll be Linux-like or BSD-like; - similar problems with g_date_time_printf(). > 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 =E2=80=9Ce=E2= =80=9D in =E2=80=9Cde=E2=80=9D > is subject to elision, so we really want > > 14 d'abril > > and not > > 14 de abril Good point, CLDR lists this feature for Asturian and Catalan. I think I read somewhere about the same problem in Italian but CLDR does not list it. > The only wait to get this is to put the =E2=80=9Cde=E2=80=9D and =E2=80= =9Cd'=E2=80=9D into the mangled > month name (as has been suggested in the CLDR reference). Exactly! > But this > means that "%d de %B" (which seems to be the most commonly used form for > these languages today) is expanded into =E2=80=9C14 de d'abril=E2=80=9D, = which is not > what we want. "%d de %B" is just a temporary workaround which already works incorrectly generating "de abril", as you quoted above. > I am worried that this puts pressure on us *not* to > introduce mangled month names at all for these languages. Local language communities will have a chance to decide whether they want this change or not. Same as with German, no change will be visible until the locale data are updated. Each language will have to provide their data, or, if all locale data will be copied from CLDR, they will be able to revert the change. > These issues go away if we keep the existing month names unchanged and > add the new mangled names under new identifiers. > > Florian I understand your objections and still I keep my opinion. Is there any committee in glibc which would decide which way to choose? Best regards, Rafal [1] https://sourceware.org/bugzilla/show_bug.cgi?id=3D10871#c7 [2] https://bugzilla.gnome.org/show_bug.cgi?id=3D749206