This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [RFC][PATCH v5 00/13][BZ 10871] Month names in genitive case


On Fri, Dec 30, 2016 at 2:59 PM, Rafal Luzynski
<digitalfreak@lingonborough.com> wrote:
> 30.12.2016 19:02 Zack Weinberg <zackw@panix.com> wrote:
>> On Fri, Dec 30, 2016 at 4:32 AM, Florian Weimer <fweimer@redhat.com> wrote:
>> > The problem is that your approach breaks about as many usage scenarios as it
>> > fixes, and I'm still puzzled why you continue to push for this approach. A
>> > 100% backwards-compatible alternative exists, so why not use it? True, a
>> > future POSIX update may break backwards compatibility, but that's a POSIX
>> > bug in the making, and not something we should follow blindly.
>>
>> FreeBSD using genitive for %B is a strong argument in favor, I think.
>
> That's true and please note that I don't mean just FreeBSD but
> probably whole BSD family which also includes OS X, iOS and
> probably more which I'm not aware of.  Other reasons: [...]

I fully expect that we will switch to genitive %B in a future release,
if we take my suggested approach.

I'm suggesting that 2.25.0 should go out with nominative %B and
genitive %OB strictly as a matter of timing and consensus.  As a
mostly-uninvolved party it's my assessment that you have consensus to
add %OB but not to make %B genitive.  If %OB is in 2.25.0, we can swap
nominative and genitive in a patch release (because that would be
"just" a bug fix to the locale definitions), but if %OB doesn't make
2.25.0 you're going to have to wait a full release cycle (because it's
still a new feature).

(cc:ing Siddhesh with his release manager hat on: is it already too
late for this change to make 2.25?)

> Indeed, those two solutions are not different regarding the source
> code of glibc.  The only differences are:
>
> - documentation: whether we say that ALTMON and %OB provide
>   standalone (nominative) forms and MON and %B provide full-date
>   (genitive) forms or the other way round;
> - locale database: whether we put standalone (nominative) or
>   full-date (genitive) forms into the new alt_mon sections;
> - applications: whether the developers will use ALTMON or MON
>   and %OB or %B when they want a nominative/genitive case.

In 2.25.0, this would be documented as a new _experimental_ feature,
and we would not make any promises about which %-code / langinfo
constant corresponds to which case.  In fact, we would specifically
warn people that we might swap them in a future patch release, and we
would ask for feedback from application developers.

>> p.s. Do we know for certain that no other noun cases will ever be needed?
>
> I think the right question is not if other cases will be needed
> but rather if more than two cases are needed.

Yes, that's what I meant.

> I rely on CLDR:
> http://cldr.unicode.org/translation/date-time#TOC-Stand-Alone-vs.-Format-Styles
> which mentions only standalone and format (full date) context.
> These may be other cases than nominative/genitive as long
> as they are only two.  Of course, languages have more cases
> which are useful in expressions like "in December" or
> "from January to March" or "between May and September" but
> these are all attempts to build natural language sentences
> rather than format a date.  That's beyond the scope of strftime(),
> similarly like it's beyond the scope of strftime() to provide
> plural forms of the month names even if they exist in English.

OK, that makes sense.  We can document that one of the codes is for
standalone month names and the other is for complete dates (which is
which to be hammered out later), and mention that using month names in
complete sentences may require more information than the locale API
provides.

zw


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]