[ANNOUNCE] added possessive genitive case month names, HEADS UP localizers ;-)

Hi Eike

I need to change case from months name due to new Portuguese settlement for
spellcheck. Can I get file mentioned, change case and send it to You for
commit?

Hi Sérgio,

I need to change case from months name due to new Portuguese settlement for
spellcheck. Can I get file mentioned, change case and send it to You for
commit?

Yes, that's fine, just be sure you use the /plain/ file for modification,
i.e. either directly from the build tree or if from cgit, for example,
http://cgit.freedesktop.org/libreoffice/core/plain/i18npool/source/localedata/data/pt_PT.xml

I'd prefer you produce a diff against the previous version, but if
that's too complicated I'll also take an entire modified file, or just
a snippet with the updates.

Again, adding Reply-To l10n@global.libreoffice.org
/me wonders why some replies go to the dev list instead.

  Eike

I´m not experienced with diff process. Can You tell me the command used for
that?

Regards

For Estonian, a specific code (say, MMMMMM) would be useful, actually...
The most usual date format has month name in nominative, though, so it's
not that important. Besides, it would probably be outside the "scope" of
the feature discussed here :slight_smile:

Regards,
Mihkel

Hi Sérgio,

> I'd prefer you produce a diff against the previous version, but if
> that's too complicated I'll also take an entire modified file, or just
> a snippet with the updates.
>

I´m not experienced with diff process. Can You tell me the command used for
that?

I presume you're not using source from the git repositories then,
otherwise you could just use

git diff pt_PT.xml >outputfile

in the i18npool/source/localedata/data/ directory with your modifed
pt_PT.xml. Without the git repository, if you're on a sane platform
(e.g. any Unix or Linux) or a sanitized Windows (i.e. cygwin) you
already should have a utility called diff. Copy the original file to
orig.pt_PT.xml, do your modifications in pt_PT.xml, then

diff -u orig.pt_PT.xml pt_PT.xml >outputfile

produces a diff file that you can attach to a mail message, which eases
things for me.

If all this is mumbo-jumbo to you just mail me the snippet with your
changes :wink:

  Eike

Hi Mihkel,

> * if a day of month is present in the format code, the genitive name for
> MMM and MMMM is displayed
> * if no day of month in the format code is oresent, the nominative name
> for MMM and MMMM is displayed

For Estonian, a specific code (say, MMMMMM) would be useful, actually...

Why? What's special for Estonian?

We currently can't introduce a new code as there is no specification how
to store it in ODF.

  Eike

adessive; second one is usually used when something is happening ON the
date and mostly in the sentence or at least in the phrase, not separately
(e.g. something is due ON the date, something will happen ON the date and
so on). When used separately as indicating the date, nominative is mostly
used (e.g. in the tables and so on).

Marek Laane

Hi Eike, all

Well, let's go!. What I'm trying is

-For long dates, with the name of the day and it's number: «xueves, 25 de xineru de 2034» or «llunes, 12 d'agostu de 2115»

-For long dates, only with the day's number: «25 de xineru de 2034» or «12 d'agostu de 2115»

-For shorter dates, just month's name without «de» or «d'»: «25 xin 2034» or «12 ago 2115»

-For dates without the number, just month's name: «xineru de 2034» or «agostu de 2115»

My best guess for that is the attached file, I've included the full ast_ES.xml and not a .diff since it may be useful for catalan and galician/portuguese just by adapting months and days names to these languages. Also I've converted days, months and quarters names to lowercase following the Asturian Language Academy orthographic rules; the diff file may be longer than expected :wink:

Best regards!

It seems that things are a little bit complicated with Finnish Excel.
Essentially it does not have this feature directly in the date format
implementation but instead they have hardcoded the partitive suffix into those
predefined date formats that need it.

I tested this by creating a file in Excel and entering a date with different
formats. Then I saved it and opened the same file in LibreOffice 3.4.4. The
result can be seen in this screenshot:

  http://www.puimula.org/htp/libreoffice/dformat.png

- The predefined format for the date containing partitive month names
translates to format string

  [$-40B]P\. KKKK\t\a;@

(P is Finnish format character for day of month and KKKK is full month name.).
You can see that Excel hardcodes characters "ta" at the end of the month name.
This is visible when you open the file in LibreOffice but can also be seen
within Excel if choose the format and then go to custom format edit view.

There is no direct support for genitive month names in Finnish Excel (thus no
predefined formats where day of month precedes the month name), but of course
you can create the custom format yourself. So actually the current
implementation in Excel matches pretty much exactly LibreOffice 3.4.4 for
Finnish.

It seems to me that the intelligent month name format would lead to doubled
partitive suffixes when a document created in Excel is opened in LibreOffice.
We could avoid that by modifying the rule a bit: in case format specifier MMMM
(or KKKK in the Finnish example above) is immediately followed by a character
literal, nominative form is used even if there is day of month present in the
format. This would also avoid problems with older OpenDocument files where
people may have used similar hardcoded suffixes.

Even then users who take advantage of the new feature in LibreOffice will see
the month names incorrectly if they open the file in Excel. I don't see this
as a problem since no data is lost, the formatting problem is minor and it is
really just a missing feature in Excel which we cannot fix anyway.

Harri

Hi Xuacu,

My best guess for that is the attached file

It would help if you actually attached the file :wink:

  Eike

Hi Harri,

> > Has
> > anyone checked how this affects interoperability with Excel?
>
> I think they use a similar approach for genitive case names (use them if
> a day of month is present), but I haven't heard of partitive case.

Hmm.. maybe that was wishful thinking, I didn't find any reference on
that. Vista seems to have genitive month names, but Excel?

It seems that things are a little bit complicated with Finnish Excel.
Essentially it does not have this feature directly in the date format
implementation but instead they have hardcoded the partitive suffix into those
predefined date formats that need it.

Similar to what was done in our locale data format codes for some
locales. Which reminds me that needs some handling when loading
documents that use such formats.

It seems to me that the intelligent month name format would lead to doubled
partitive suffixes when a document created in Excel is opened in LibreOffice.

Right, also for documents of an older LibO version if they have hard
coded suffixes.

We could avoid that by modifying the rule a bit: in case format specifier MMMM
(or KKKK in the Finnish example above) is immediately followed by a character
literal, nominative form is used even if there is day of month present in the
format. This would also avoid problems with older OpenDocument files where
people may have used similar hardcoded suffixes.

Good approach, I'll implement that.

Even then users who take advantage of the new feature in LibreOffice will see
the month names incorrectly if they open the file in Excel. I don't see this
as a problem since no data is lost, the formatting problem is minor and it is
really just a missing feature in Excel which we cannot fix anyway.

The same of course applies when opening such a document in an older LibO
release, only the nominative name would be displayed, unless the locale
defined genitive names in place of nominative names, which some locales
did as it suited better the common use in date formats.

  Eike

Wow! I did it (at least Thunderbird says so), something went wrong with the mail delivery... or with Earlybird, I will have to check it :frowning:

Meanwhile, let's try via Dropbox:
http://dl.dropbox.com/u/13043022/LibreOffice/ast_ES.xml

Best regards!

Hi Xuacu,

>>My best guess for that is the attached file
>It would help if you actually attached the file :wink:
>
Wow! I did it (at least Thunderbird says so), something went wrong
with the mail delivery... or with Earlybird, I will have to check it
:frowning:

Maybe the list software strips attachments on this list? Anyone in the
know?

Meanwhile, let's try via Dropbox:
http://dl.dropbox.com/u/13043022/LibreOffice/ast_ES.xml

Perfect :slight_smile: pushed to master
http://cgit.freedesktop.org/libreoffice/core/commit/?id=cc2ec946ef4a3d4c4e86cfb17f3a890b2b2ad077

Thanks
  Eike

Maybe the list software strips attachments on this list? Anyone in the
know?

FYI, I've just checked my sent mail box in the Gmail server and my message is there with the attachment unstripped.

Perfect :slight_smile: pushed to master
http://cgit.freedesktop.org/libreoffice/core/commit/?id=cc2ec946ef4a3d4c4e86cfb17f3a890b2b2ad077

Thanks
   Eike

Thank you.
This is my first "real" contribution to LibO code (other than translations); in case it's neccessary, please, consider my work under any LibreOffice compatible free licence, as needed, until further notice.

Best regards.

Hi,

For Finnish (and maybe others) I also added partitive case month names
and the rule for backwards compatibility to force nominative names if
a month format code is immediately preceded or followed by a literal
character, as discussed with Harri Pitkänen in this thread.

Overview:

* Locale data:
  * nominative (nouns) month names always given in <MonthsOfYear>
    element
  * optional genitive case month names in <GenitiveMonths> element,
    following the <MonthsOfYear> element; if not given take nominative
    names
  * optional partitive case month names in <PartitiveMonths> element,
    following the <GenitiveMonths> element, or following the
    <MonthsOfYear> element if the <GenitiveMonths> element is not
    present; if not given take genitive case names, or nominative if
    genitive names aren't defined
    * currently known partitive case matters in Finnish locales

* Rules for use of nominative / genitive / partitive case month names in
  number formatter when encountering MMM or MMMM:
  * MMM or MMMM immediately preceded or followed by a literal character
    other than space => nominative month name (noun), for Excel and
    backwards compatibility such as Finnish MMMM"ta"
  * no day of month (D or DD) present in format code => nominative name
  * day of month (D or DD) after MMM or MMMM => genitive name
    * no genitive names defined => nominative names
  * day of month (D or DD) before MMM or MMMM => partitive name
    * no partitive names defined => genitive names
      * no genitive names defined => nominative names

I hope that's sufficient.

  Eike

Hi Eike, all

Not so perfect after all. Iñigo Varela, one of the Asturian team members, noticed that I forgot to add a separator between the month and the year. It's not very clear for a non-developer like me where to add it, my best guess is in <LongDateMonthSeparator>, but I may be wrong. This is the line:
<LongDateMonthSeparator> de </LongDateMonthSeparator>

And the expected result:
«xueves, 24 de payares de 2011»

Where the first "de" is caused by genitive month and the second "de", between month and year, is the result of LongDateMonthSeparator.

As an extra test, I send the full ast_ES.xml attached. In case it gets stripped again, it's available in Dropbox:
http://dl.dropbox.com/u/13043022/LibreOffice/ast_ES.xml

Thank you!

-- Xuacu Saturio
Sent while testing Thunderbird
Unviáu dende Thunderbird en pruebes

Hi Xuacu,

This is my first "real" contribution to LibO code (other than
translations); in case it's neccessary, please, consider my work
under any LibreOffice compatible free licence, as needed, until
further notice.

Good, thanks, which currently are LGPLv3+ and MPL 1.1 by the way..

  Eike

Hi Xuacu,

Not so perfect after all. Iñigo Varela, one of the Asturian team
members, noticed that I forgot to add a separator between the month
and the year. It's not very clear for a non-developer like me where
to add it, my best guess is in <LongDateMonthSeparator>, but I may
be wrong. This is the line:
<LongDateMonthSeparator> de </LongDateMonthSeparator>

And the expected result:
«xueves, 24 de payares de 2011»

Those long date separators are a bit tricky, they are used in parsing
dates, alas not always consistently and now with the genitive/partitive
month names even more, something that needs to be reworked. Only a very
few rudimentary field display methods use those separators to construct
a date string. With the exception of LongDateDayOfWeekSeparator that is
used in the NNNN format code of the number formatter.

Where the first "de" is caused by genitive month and the second
"de", between month and year, is the result of
LongDateMonthSeparator.

To get "de" between month and year in number formats, the format code
has to state this. For your example that uses

NN, D, MMMM YYYY
or
NNNND, MMMM YYYY
or
NNNNDD, MMMM YYYY

these would have to be changed to

NN, D, MMMM "de" YYYY
and
NNNND, MMMM "de" YYYY
and
NNNNDD, MMMM "de" YYYY

As an extra test, I send the full ast_ES.xml attached.

Stripped again, seems this list is setup such.

  Eike

Hi Eike

Thank you for you patience, but I have two more questions before I edit the file again. The word between MMMM and YYYY needs quotation marks? Should I revert <LongDateMonthSeparator> to it's default state (i.e. blank space)?

Tricky indeed for me :wink:

Best regards

Hi Xuacu,

>NNNNDD, MMMM "de" YYYY

Thank you for you patience, but I have two more questions before I
edit the file again. The word between MMMM and YYYY needs quotation
marks?

Yes, otherwise the characters would be interpreted as format codes.

Should I revert <LongDateMonthSeparator> to it's default
state (i.e. blank space)?

No, leave it as > de <, currently the parser also checks it after the
month (which semantically is wrong, but ...), but does not check the
LongDateYearSeparator before the year.

Tricky indeed for me :wink:

It is.. I'll add some documentation to the locale.dtd file when I have
a consistent use within the parser.

  Eike