Re: [l10n-cs] Date Format with month names in genitive case - your opinions?

[Rafal Luzynski <digitalfreak lingonborough com>]

> Dnia 22 styczeń 2018 o 09:16 Petr Pisar <petr pisar atlas cz> napisał(a):

BTW, this ^^^^^^^ is incorrect in Polish but it only illustrates how common
this bug is.

> On Sun, Jan 21, 2018 at 10:54:52PM +0100, Petr Kovar wrote:
> > On Sun, 21 Jan 2018 00:10:28 +0100 (CET)
> > Rafal Luzynski <digitalfreak lingonborough com> wrote:
> > > In case of Czech, Serbian and (probably) Slovak the case is controversial.
> > > As far as I was told, in those languages the nominative case is used
> > > normally in dates unless whole date is in a genitive case. However,
> >
> > Not sure who provided you with this information, but for Czech, this is not
> > quite true. While using nominative for %B is not exactly incorrect (so the
> > current implementation can be seen as acceptable), being able to use
> > genitive for %B would allow us to provide a translation that sounds more
> > natural.
> That's right.

I heard it from 2 different Czech people. But I will not be surprised if
that's wrong, lots of Polish native speakers do the same mistake.

> > However, changing anything in glibc is very tricky so I won't vote
> > for this change without hearing what other Czech translators think. I
> > think other language groups might share the same sentiment, actually.
> It's not tricky. It's incompatible. "%B" means a month name in a dictionary
> form (i.e. nominativ in case of flective languages) now. Existing translations
> of other programs expect it and changing in into a different form would break
> them.

So, what format specifier do you use when you actually want to format
a date? This is a rhetoric question, of course the answer is that such
a format specifier does not exist. But it has been decided to be changed.
> From now "%B" will return the form which is used when formatting a full
date.

> I'm unable to decide if the change is overall positive of negative. But
> if it happens, it needs proper documentation in nl_langinfo(3), strftime(3)
> etc. E.g. nl_langinfo(3) reads:
>
> MON_{1–12} (LC_TIME) Return name of the n-th month.

If you mean the man pages then indeed, man pages are not part of glibc
project and they need to be changed separately. I'm going to file a bug
report against man today. On the other hand, the info pages are part of
glibc and they will be changed along. BTW, note that no current documentation
says that this month name must be in a nominative (dictionary, standalone)
form.

> With the proposed change it would return the non-dictionary form that cannot
> be used a standalone label and that's wrong. Try running "cal" command.

True, there are some applications which will have to be changed.
cal is on my radar and I'm going to file a pull request today.
Other applications which need change are GNOME Calendar and GNOME Shell
(which also contains a calendar). Minor changes will be required in
date(1) command line utility but this is more tricky. At the moment
I am not aware of other applications, are you?

> Also MON and ALT_MON difference should not be explained with cases. Cases are
> a language specific matter. It should talk about "a dictionary form" and "a
> form used in a date string".

True, it will be described as "the grammatical form required when the month
is used as part of a complete date" vs. "the form required when the month
is named by itself".

> Actually the more I think about it the less I like the change. How do you want
> to solve the breakage of nl_langinfo(3) that's defined by POSIX? I'd rather
> reverse the change. Keep MON for the dictionary form and use ALT_MON for the
> date form and either change strftime's "%x" and "%c" definitions to use
> ALT_MON instead or keep the decision up to translators of the glibc.

These are more development issues rather than translation issues.
They have been discussed for a long time on libc-alpha list. [1] I know that
not everybody participated in those discussions, obviously this is impossible.
Regarding your question, the number of the applications which will need
to be changed is low, definitely much lower than the number of applications
which would need a change in the reverse solution. Also the reverse solution
would be incompatible with what BSD family has been using for about 20 years
now [2] and what POSIX has accepted [2] about 7 years ago (but has not yet
published). However, this may not be true for Czech language so I'm asking
every translators community for a permission before I push the locale data
changes for their languages.

Regards,

Rafal


[1] https://sourceware.org/ml/libc-alpha/
[2] https://www.freebsd.org/cgi/man.cgi?query=strftime&sektion=3
[3] http://austingroupbugs.net/view.php?id=258