[Bug localedata/10871] ru_RU: 'mon' array should contain both nominative and genitive cases

["van.de.bugger at gmail dot com" <sourceware-bugzilla@sourceware.org>]

https://sourceware.org/bugzilla/show_bug.cgi?id=10871

--- Comment #31 from van.de.bugger at gmail dot com ---
(In reply to keld@keldix.com from comment #29)

Thanks for the link. I didn't read entire spec, but LC_TIME section looks very
similar to POSIX. The only additions I found are first_weekday, first_workday,
cal_direction, and timezone; the rest looks the same.

After looking through ISO/IEC 30112 and studying existing locale definitions in
glibc, it is clear to me that O modifier is intended for writing numbers in
traditional style. Some languages (Japanese, Persian, Oriya, Burmese to name a
few) have traditional symbols for digits and numbers. So O modifier is
applicable to numeric values only, and using %OB is a non-standard BSD hack.

BTW, I found a dirty hack in glibc: uk_UA locale has *month names* in genitive
case in alt_digits table. Now they can get month name in genitive case by %Om,
but applying modifier O to another format specifier (like %Od, %Of, %OH) is
meaningless: %OI converts hour to a months name in genitive case... 

You see: users want to have properly formatted dates and ready to implement any
dirty hacks for getting result.

> Well, can we see what is the extent of the problem?
> Russian, Polish, possibly all of the Slavian languages, Finnish,
> Hungarian, Estonian?

All the Slavic languages for sure. Sorry, I am not aware about other languages.

> One could also list all the grammatical cases,  number them and make a
> notation
> in the format specifiers, but if the already implemented and specified
> solution solves the problem for all languages with this problem, then
> an extended solution could be overkill.

I already wrote that two cases (%B and %OB) does not solve the problem in
general. 

However, I understand that two cases (nominative and genitive) cover the great
majority of use cases (for Russian language at least), and I know why: (1) all
the demanding applications have implemented (and had to implement) date/time
formatting routines in-house due to lack of support in standard libraries; (2)
fixing standard libraries takes ages: you see, this issue was open 6 years ago,
but problem is not yet solved.

-- 
You are receiving this mail because:
You are the assignee for the bug.