Re: [RFC][PATCH v4 06/11] Provide backward compatibility for strftime family (bug 10871).

[Rafal Luzynski <digitalfreak at lingonborough dot com>]

9.11.2016 11:49 Florian Weimer <fweimer@redhat.com> 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 “e” in “de”
> 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 “de” and “d'” 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 “14 de d'abril”, 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=10871#c7
[2] https://bugzilla.gnome.org/show_bug.cgi?id=749206