Re: Date Format with month names in genitive case - your opinions?

[Fòram na Gàidhlig <fios foramnagaidhlig net>]

> From my language's point of view. The CLDR approach is what looks the
most sensible. Displaying "of April" as a standalone date would look
very weird in my language, and having the 'genitive' form displayed as
nominative would be the lesser of two evils.

For example:

June = An t-Ògmhios
18 June = 18mh dhen Ògmhios

So, depending on how it's coded, that would give us "dhen Ògmhios" or
"mh dhen Ògmhios" if the 'genitive' was used as a standalone date.



Sgrìobh Rafal Luzynski na leanas 18/04/2017 aig 23:19:
> Hello,
>
> I was told that GNOME i18n is the right place to discuss this issue
> because it gathers translators from more languages than any other
> place in this part of the net. The problem has been reported to GNOME
> bugzilla as bug 749206 [1] but in fact it's not a GNOME bug but glibc
> bug. [2]
>
> What is the issue: in many languages, mostly from eastern Europe,
> including my native language, a correct grammatical form of the month
> name when used in the full date context is genitive. A literal
> translation to English applying the same rule would be "18 of April".
> Also we still need the nominative case when the month name appears
> standalone (for example sometimes we just want to say "April").
>
> The proposed solution is to change strftime() function and anything
> that is backed by or compatible with strftime(): in glib2 the
> functions are g_date_time_format() and g_date_strftime(). These
> functions besides "%B" (full month name) should start supporting
> "%OB" (alternative month name). Also nl_langinfo() function would
> be modified: as now MON_1, MON_2, ..., MON_12 return the data to
> be used as the result of "%B" format specifiers the new set of
> constants ALTMON_1, ALTMON_2, ..., ALTMON_12 would be introduced
> to provide the data for "%OB" format specifier.
>
> This exact solution:
>
> - has been implemented in *BSD systems (FreeBSD, OpenBSD etc.) in
>   1990s;
> - is also supported in Apple systems (OS X and iOS) except exposing
>   ALTMON_n constants in nl_langinfo();
> - has been accepted by POSIX as the future change of the
>   specification but has not yet released it. [3]
>
> Now the controversial part: in all those solutions nl_langinfo(MON_n)
> and strftime("%B") return the genitive case of the month name and
> the newly introduced nl_langinfo(ALTMON_n) and strftime("%OB") return
> the nominative form. It's controversial because now in Linux
> nl_langinfo(MON_n) and strftime("%B") return the nominative case
> while the other case is simply not supported. This would require
> somehow incompatible change. (Note: the backward compatibility feature
> can be introduced.)
>
> Also it should be emphasized that "genitive and nominative" is
> a little unprecise misleading. Correctly it should be named "the
> correct form when using the month in the full date context, together
> with the day number" vs. "standalone, without the day number".
> For example, the languages which have the genitive form but don't
> use it in the full date context would use their own proper form
> instead.
>
> Why did BSD, Apple, and POSIX choose that counterintuitive approach?
> One should make a bigger survey before answering this question but
> I believe that it's because the date formats are more often used to
> format the date with the day of the month number than to format the
> month name standalone. This change would fix all applications which
> display the dates without any change in their source code so I think
> it is good even if it would break those few applications which
> display the month names standalone. By "break" I mean "they would
> start displaying the month names in an incorrect form (similarly
> as all other applications display the month names incorrectly now)".
>
> Note that a similar approach has been chosen by ICU and CLDR with
> their own date formats: MMMM represents the month name in a genitive
> case while LLLL is used when they need a nominative case explicitly.
>
> glibc maintainers hesitate to accept this solution. I believe they
> need some feedback from the people who actually are going to use this
> feature. So far they agreed [4] to accept this solution but only if
> it is documented as the new experimental feature and if it is not
> yet documented which of "%B" and "%OB" is genitive (full date format)
> and which is nominative (standalone). The idea was that it should
> be decided by the language communities which is which. Also sometimes
> they suggest that BSD implementation is wrong and should be switched.
>
> So, language communities, what is your opinion about it?
>
> GNOME is a multiplatform project, it is intended to work correctly
> on Linux but also Windows, OS X, BSD and many other platforms. I think
> it will be easier for the application developers if Linux follows
> other platforms as well as the future POSIX specification.
>
> You may be also interested in seeing my slides about the issue: [5]
>
> Best regards,
>
> Rafal
>
>
> [1] https://bugzilla.gnome.org/show_bug.cgi?id=749206
> [2] https://sourceware.org/bugzilla/show_bug.cgi?id=10871
> [3] http://austingroupbugs.net/view.php?id=258
> [4] https://sourceware.org/ml/libc-alpha/2016-12/msg01103.html
> [5]
> https://rluzynski.fedorapeople.org/slides/2017-01-27-DevConf.cz/GenitiveMonths-updated.pdf
> _______________________________________________
> gnome-i18n mailing list
> gnome-i18n gnome org
> https://mail.gnome.org/mailman/listinfo/gnome-i18n

-- 
-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: GnuPG v2.0.22 (MingW32)

mQINBFNbSyEBEADh+uhohycnZgPPnyMs5pZQG6pKyLzFZoIKbVjY31ZoPZ2SdltB
elrwn6kFZkQiDx4K6nkZFHsPh8RMvWoFWg1rGiWkdsZessLFawraC8YEZDwtlaU5
SFXbE4+QnMfbPhe9tmC8Nbhec3dfV9zcXAhxc+zkIUsKFhSkpJ2Syvo9FCA/5adW
UZgWWKFwlSg4+/lrhJ6QJnldPlXfWcuEasKF7fjdafDIdS5hdKu8Lv+CiPQWvgsi
J2BDlZLzEZf3PD+NMujUbJa0nilD2ltu3/qRvR2f86YV6wRwt4E2OD8JJQOau4X2
Pg7vqkIbnB9rMiQ6T17rQ4rc80eesGCxQ6XOba9oa1eRRZDwY7HJtYwvPdw9HZaN
Lq2RRbGDGO0q7fxrzbp1WuNN+UXOA/pmVzWWczPfPHVcNIehGf3wQI+Vgh/qa+IZ
jLJ25I1Tv85cDzvv5gdtI8PR4JTfK6Db+gUJmsuIg2fmsljxA7OmeTgSPR7nEVq5
VlHYfx1T0uKlthWw/eDwlS44vTgm6HZzIdYqdPMPa/PU1U+WVuDejyDJTn/1TY78
oJMT/IixFR+N+smohhKASprewcsO2ClWGptSG0sRTiCrVHFD3Mt6SCVaxsQLHvek
KuNAUXhR2KSvYuqGT0Nv3bplN6svCp4CuAGZ3lyOIt/Sb7OFUwzcx2sOdwARAQAB
tC5Gw7JyYW0gbmEgR8OgaWRobGlnIDxmaW9zQGZvcmFtbmFnYWlkaGxpZy5uZXQ+
iQI5BBMBAgAjBQJTW0shAhsPBwsJCAcDAgEGFQgCCQoLBBYCAwECHgECF4AACgkQ
UHP09XBr75NHNBAAxv2C/G13Z1kCFOSOnbPpzqcIDcMuP7RK1Mv5XfOZLfqSw4le
gdDmZggX2/EBH6xFTXFPLSE6rVUKTkHLA7IY8D43GBtDWjcIyyuLnIjtR+LhRKCP
3/Sm8MyZMQvUH1CBpUXFNnP/HCR6xjm1Mog5kXxFeCR9PMjeEiobKXIVuMfuNlBD
WzoR2Nh+oroXLjZw3VMFewiCyhu4Pe7F3sLpVldiI3PBOyPQOBZ3HEIM490D/Lrh
rl3Wwmoug8j8rqkh/Fr+kKaToRJik4PkcxsfepzhMdNfCpr7I3jE5XQHzib5Ubv8
wsSaVNBG92NTnGKoAntWXBUaiDN84St9l+Zm/BgedRk+7wdESHBuOuFXoRc0yEjF
4tLOhyO9u5bYGQWHyJiwhbw51R8G+Kh3OPq/tr4KmsuueEI2v5cLkoDzwCpYyMnu
BfU8d0mt5eULbQCWcy7LYeQs6E+CEB+tPL3Qz2zaAAvwt7N2PLMjHf5Fcqj5LqrV
mzQfcB9zQFq9Rtld/IIIDkE1y/q/SNFYsFNW/u/bxWsu+lMOYtBco++O5DJhAq6t
7rJXUBirju50hhogHfBL2v6RG1b8/uiWm0m8713ZhiSvpr4Dd+V+DU9nPli5nTmU
En6gP7TTYJKETMf7O9i873Z8yG6zd0/fBzFyruS2KRTPV2GiVT6CI37gUtw=
=fcOW
-----END PGP PUBLIC KEY BLOCK-----