public inbox for libc-alpha@sourceware.org
 help / color / mirror / Atom feed
From: Florian Weimer <fweimer@redhat.com>
To: Rafal Luzynski <digitalfreak@lingonborough.com>,
	libc-alpha@sourceware.org
Subject: Re: [RFC][PATCH v4 06/11] Provide backward compatibility for strftime family (bug 10871).
Date: Wed, 09 Nov 2016 10:49:00 -0000	[thread overview]
Message-ID: <36cfa35f-bd1c-d880-ef85-185d07096c8d@redhat.com> (raw)
In-Reply-To: <579374375.2202122.1478605156225@poczta.nazwa.pl>

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

  reply	other threads:[~2016-11-09 10:49 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-10-28  0:49 Rafal Luzynski
2016-11-04 13:40 ` Florian Weimer
2016-11-05 10:53   ` Rafal Luzynski
2016-11-07 14:13     ` Florian Weimer
2016-11-08 11:39       ` Rafal Luzynski
2016-11-09 10:49         ` Florian Weimer [this message]
2016-11-10  0:33           ` Rafal Luzynski
2016-11-10 12:41             ` Florian Weimer
2016-11-10 18:42               ` Rafal Luzynski
2016-11-10 19:19                 ` Andreas Schwab
2016-11-15  1:21                   ` Rafal Luzynski
2016-11-11  3:52             ` Rical Jasan
2016-11-15  1:38               ` Rafal Luzynski
2016-11-15 11:09                 ` Rafal Luzynski
2016-11-16 13:06                 ` Rical Jasan
2016-11-17 11:18                   ` Rafal Luzynski
2016-11-18  9:22                     ` Rical Jasan
2016-11-22 23:56                       ` Rafal Luzynski
2016-11-09 11:00       ` Florian Weimer

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=36cfa35f-bd1c-d880-ef85-185d07096c8d@redhat.com \
    --to=fweimer@redhat.com \
    --cc=digitalfreak@lingonborough.com \
    --cc=libc-alpha@sourceware.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).