Issue 62460 - Implement genitive forms of month names (posessive context)
Summary: Implement genitive forms of month names (posessive context)
Alias: None
Product: Internationalization
Classification: Code
Component: i18npool (show other issues)
Version: OOo 2.0.1
Hardware: All All
: P3 Trivial with 77 votes (vote)
Target Milestone: ---
Assignee: AOO issues mailing list
QA Contact:
: 65413 72186 (view as issue list)
Depends on:
Reported: 2006-02-23 08:32 UTC by gkocur
Modified: 2017-05-20 11:31 UTC (History)
12 users (show)

See Also:
Issue Type: FEATURE
Latest Confirmation in: ---
Developer Difficulty: ---

offering changes to "locale.dtd" and "ru_RU.xml" files (14.09 KB, application/zip)
2012-03-09 23:23 UTC, sorath
no flags Details

Note You need to log in before you can comment on or make changes to this issue.
Description gkocur 2006-02-23 08:32:05 UTC
Is it possible to have month names in 2 forms, like in CLDR? It is important in
all slavonic languages. Example:
Polish name for January is "styczeń". But correct date format is:
"1 stycznia 2006". In CDLR it is OK.

From pl.xml file:

<calendar type="gregorian">
<monthContext type="format">
<monthWidth type="wide">
<month type="1">stycznia</month>
<month type="2">lutego</month>
<month type="3">marca</month>
<month type="4">kwietnia</month>
<monthContext type="stand-alone">
<monthWidth type="wide">
<month type="1">styczeń></month>
<month type="2">luty</month>
<month type="3">marzec</month>
<month type="4">kwiecień</month>
Comment 1 ooo 2006-02-24 14:11:39 UTC
I presume we're talking of genitive forms (month names in posessive context)
versus simple nouns here. This differentiation is not implemented yet. I'm
assigning the issue to the requirements queue.
Comment 2 pavel 2006-08-08 09:59:20 UTC
The same applies to Czech :-(
Comment 3 pavel 2006-08-08 09:59:32 UTC
*** Issue 65413 has been marked as a duplicate of this issue. ***
Comment 4 pavel 2006-08-08 10:00:56 UTC
Eike: isn't this simply a bug than new requirement? ;-)
Comment 5 ooo 2006-08-08 11:39:16 UTC
It may be a seen as a bug by people from languages where the genitive forms are
used ;-)  From a developer's view it is a new feature, we need new data
structures, API, implementation.

Changing summary line for better description and searchability.
Comment 6 ooo 2006-12-05 14:47:02 UTC
*** Issue 72186 has been marked as a duplicate of this issue. ***
Comment 7 rail_ooo 2006-12-05 16:01:24 UTC
The same applies to Russian and Ukrainian.
Add CC.
Comment 8 dma2002 2007-12-24 06:55:49 UTC
Please set target at least. However, is it hard to implement this feature?
Comment 9 ooo 2007-12-29 14:53:33 UTC
Requirements usually don't have a target as it is not decided when the feature 
would get implemented. Not hard to implement, but a lot to implement at
different places.
Comment 10 smyrwa 2009-10-10 22:49:10 UTC
I checked how it is in all Slavonic languages. In almost all there is one
nominative form. But in Slovak language there are two: nominative and genitive. 

I understand that the problem has been somehow solved and there may be 2 forms. 

If it is so, the correct genitive form of months may be soon implemented. Is it
Comment 11 ooo 2009-10-12 12:11:12 UTC
@smyrwa: AFAIK this hasn't been worked on. What do you mean by "the problem has
been somehow solved"? Where in a Slovak locale do you see both, nominative and
genitive forms?
Comment 12 smyrwa 2009-10-31 23:31:59 UTC
@er: I have Polish language menu, so I am not sure if the English commands I
give here are 100% correct. 99% rather ;-) But I think you find the correct way.

In Writer:
Insert > Field > Other (Ctrl + F2) > Document
Type: Date | Format: Additional (formats)... (very end of the list)
Category: Date | Format: here I check different (Nominative and Genitive) forms
ot months in various versions of dates | Language: default is Automatic, I
scroll to different Slavonic languages and as I wrote only the Slovak has two
forms of months

In Impress:
Insert > Date and Time > Date and Time: Variable | Language: here I scroll and
choose different languages and check in previous list various versions of dates
Comment 13 ooo 2009-11-16 11:55:10 UTC
@smyrwa: I now see what you mean. The Slovak locale data has the two different
forms in the abbreviated month name (used with format code MMM) and the full
month name (used with format code MMMM), which is actually wrong and an error.
Apparently someone thought it would be a good idea to "solve" it that way.. This
means there are no abbreviated month names available in that locale and it also
will break when the document is loaded in another ODF application or in a
version where the locale data is corrected.
Comment 14 xyepblra 2010-08-11 20:38:45 UTC
Let me contribute to problem description, too.
Problem with Slavonic languages can be divided into 2 parts:
1. Months names are erroneously capitalized in Slavonic versions of OO.o. I
mean, it is correct to use capitalized months names in OO.o in other languages,
but in Slavonic languages (at least Russian and Ukrainian, as far as I know)
this is a mistake that makes users look totaly unproffessional. Same thing
applies to the names of days of week, they are not supposed to be capitalized.
2. Genitive form of a month name is used after day numbers.

Is there a solution allowing to change MMMM output from "Month" to "[of] month"
(a specific word form with different ending, without capitalization)?
Comment 15 sorath 2011-02-11 23:45:29 UTC
Please add posibility to use as "date format" non-capitalized Genitive form of a 
month name that should be used after day numbers.
Comment 16 smyrwa 2011-02-14 00:33:47 UTC
I think it's a pity that the problem we are talking about during five(!) years
(since 2006!) had not been solved yet! It is the highest time to fix it.

The OOo is praised and gloryfied for many various solvings and functionalities.

However, hundreds of thousands its potential users from Central and Eastern
Europe cannot use the Date Field in correct genitive form of month names with
correct ending ('dd OF mmmxx' instead of 'dd mmmm' - like '3 maja', ''22 června'
instead of '3 maj', '22 červen' which is in OO today). Hundreds of thousands
users - because the Slavonic languages are spoken by more than 300 millions
people, and some of them use OO for sure.

The problem concerns all Slavonic languages except Bulgarian and Macedonian
(where declination is reduced). Among them are languages: Belarusian, Czech,
Polish, Pomeranian/Kashubian, Russian, Rusyn, Slovak, Slovene, Serbo-Croatian
(Croatian, Bosnian, Serbian, Montenegrin), Silesian, Upper and Lower Sorbian and
Ukrainian. But not only in Slavonic, other languages using noun declinations are
injured too.

There is no problem to prepare the list of nominative and genitive forms of
month names in the given above languages. The matter is to improve the mechanism
in OO applications and make them put the month names in the proper form.

I have to repeat with stress: it's a pity that the problem had not been solved
yet! If I could help someone to fix it (I am not a programmist but I know a few
languages), please write here.
Comment 17 erack 2011-02-14 09:58:16 UTC
Grabbing issue for spare time.
Comment 18 sorath 2012-03-05 18:06:14 UTC
Are there are any news?

This "Feature Request" is still very important for many users.
Comment 19 sorath 2012-03-05 20:02:48 UTC
Despite of "3.4_release_blocker" that indicates that the bug must be fixed in the Apache OpenOffice 3.4 release, I didn't see any changes in "date formating" for Russian and some others slavonic languages in the "Unofficial Developer Snapshot" binary package of OOO340m1 (build:9586) by 13 Feb 2012 - Rev. 1243392
Comment 20 T. J. Frazier 2012-03-05 21:14:50 UTC
(In reply to comment #19)
> Despite of "3.4_release_blocker" that indicates that the bug must be fixed in
> the Apache OpenOffice 3.4 release ...

You are misreading the flag item; it is somewhat confusing. Release Blocker is not set on this issue, and will not be set. This is not a blocker issue.

This feature probably needs a programmer who is a native speaker – or very fluent – in at least one of the affected languages; someone who is confident of knowing all the rules and exceptions. Please note that patch contributions are very welcome.
Comment 21 sorath 2012-03-06 16:29:07 UTC
As noted in the fisrt post of this bug/request the "CLDR" (Unicode Common Locale Data Repository) contains names of all months names for gregorian calendar ( both for "stand-alone" name and for "wide" date format, the last corresponds genitive form of month's names, so there is no requirement of native speaker programmer to realize months name in 2 forms: "stand alone" name (styczeń) and for "wide" date format (1 stycznia 2006), as noticed in the bug reporter's comment - as all necessary data is freely available.

The possibility at least of such two types of month's names representation is very important for users from East Europe where it is very actual feature as it used in many official and financial documents.

Also, in addition, I can provide additional description (with full table of dates examples) for Russian rules of full "wordy-numerical" date format representation that required by Russian "State All-Union standard" (GOST-R 6.30 "Unified systems of documentation. Unified system of managerial documentation. Requirements for presentation of documents").
Comment 22 sorath 2012-03-06 21:20:44 UTC
LibreOffice 3.5.0 resolve this feature for Russian locale of date format :(
It's work only with "DD. MMMM YYYY" format (point can be deleted and genitive form remain creating "new" format style). But it solved only for Russian language during localization, it isn't resolve this issue globaly.
Comment 23 Regina Henschel 2012-03-06 21:34:55 UTC
You can find more information about the solution in LibreOffice in
Comment 24 sorath 2012-03-07 14:22:37 UTC
Great Thanks for your information! But I'm not programmer and I don't have possibility to implement it. It looks rather simple to implement it by adding some cases depends on order of arrangement of day and month and representadion of day at all in the output format.

Sorry, I checked only for some language mention this feature request, at the time in LibreOffice3.5 this request it seems this issue resolved globaly but changes taken into account only for next localization teams: 
[an-ES] Aragonese, Spain;
[ast-ES] Asturian, Spain; 
[be-BY] Belarusian, Belarus;
[fi-FI] Finnish, Finland; 
[gd-GB] Gaelic (Scottish), United Kingdom 
[la-VA] Latin, State of the Vatican City 
[lt-LT] Lithuanian, Lithuania 
[ru-RU] Russian, Russia
Comment 25 sorath 2012-03-09 18:19:57 UTC
I found that similar structure of "Calendar" discribed for LibreOffice-3.5.0, mentiond by Regina Henschel, lays in the 
of source code.

Could anybody help me ? :) Does it conserns only XML data structure of this file and localization names of months?
Comment 26 sorath 2012-03-09 19:05:34 UTC
So if it does depend only of structure of "locale.dtd" and files such as "ru_RU.xml" what does prevent to implement this feature? 
Is it any licence violence of such implementation expanded standart XML structure ?
Comment 27 sorath 2012-03-09 23:23:40 UTC
Created attachment 77311 [details]
offering changes to "locale.dtd" and "ru_RU.xml" files

The next changes implemented in "locale.dtd" are in accordance to (of LibreOffice 3.5)

to add possessive genitive and partitive genitive cases of month's names.

Changes of "ru_RU.xml"
1. Genitive case of month's names (also changed to lower case) have been added 
in accordance to

to correspond the GOST-R 6.30 (State All-Union standard. 
"Unified systems of documentation. Unified system of managerial documentation.
Requirements for presentation of documents").

2. Abbreviation of days of week have been changed
to correspond the GOST 7.12-93 
(System of standards on information, librarianship and publishing. 
"Bibliographic record. Abbreviation of words in the Russian language. 
General requirements and rules")
Comment 28 sorath 2012-03-09 23:27:26 UTC
Sorry, but currently I'm not able to build AOO with with changes and check if does it work.

Could anybody to say does is any global files except locale.dtd need has to be chaged?
Comment 29 sorath 2012-03-10 16:43:04 UTC
I finaly try to compile AOO-3.4 with files I attached and recive next error:

file generated=../../../
parsing document ru_RU started
Warning: QuotationStart may be wrong: U+201E „
Warning: QuotationEnd may be wrong: U+201C “
Error: A Gregorian calendar must have 2 eras, this one has 12
Error: First era of a Gregorian calendar must be <EraID>bc</EraID>
Error: Second era of a Gregorian calendar must be <EraID>ad</EraID>
Error: <StartDayOfWeek> <DayID> must be one of the <DaysOfWeek>, but is: 
Error: Bad value of MinimalDaysInFirstWeek: 0, must be 1 <= value <= days_in_week
Error: in data for ru_RU: 5
parsing document ru_RU finished
dmake:  Error code 5, while making '../../../'
dmake:  '../../../' removed.

1 module(s): 
need(s) to be rebuilt


ERROR: error 65280 occurred while making /mnt/sdc2/animation/aoo-3.4/main/i18npool/source/localedata/data

When you have fixed the errors in that module you can resume the build by running:

        build --all:i18npool

Is anyone here alive? :)
I have no idea what files are need to be modified and what changes need to include to resolve this request.

I recently check Lotus Symphony 3.0.1 (on Ubuntu under virtualbox) - it seem there was just only month's names  in genitive form (at least for russian language) - but it is not good for absence of right names of stand-alone month's names.

PLEASE NOTE, that this issue is very important as current method of representation of local date format doesn't allow to correspond National Standarts of formats representation.
Comment 30 Ariel Constenla-Haile 2012-03-10 16:53:30 UTC
(In reply to comment #29)
> I finaly try to compile AOO-3.4 with files I attached and recive next error:
> Is anyone here alive? :)

I guess you should move the discussion to the Development mailing list
Post (after subscription):

You may submit patches in an issue, and wait for them to be reviewed by a developer in the know of the related code, but general questions concerning building belong to a mailing list, not an issue.
Comment 31 Marcus 2017-05-20 11:31:10 UTC
Reset assigne to the default "".