[ANNOUNCE] Locale data date acceptance patterns, localizers HEADS UP please :)

l10n
#41

Hi Eike,

In order to get rid of the annoying "accept every input as date that
might resemble some date in almost any locale" behavior I recently
implemented locale dependent date acceptance patterns that need to be
matched for date input, for full details see
http://erack.org/blog/archives/8-LibreOffice-date-acceptance-patterns.html

Thanks a lot for your work!

(snip)

Just mail me the pattern(s) for your locale, I'll add it then.

For ja_JP could you add the same patterns as the following one for zh_CN:
http://cgit.freedesktop.org/libreoffice/core/commit/?id=605707652afebf0e5c90311adcc7767ebe807e45

Cheers,
-- Takeshi Abe

#42

Hi Takeshi,

For ja_JP could you add the same patterns as the following one for zh_CN:
http://cgit.freedesktop.org/libreoffice/core/commit/?id=605707652afebf0e5c90311adcc7767ebe807e45

Done, except that I used "Y／M／D" instead of "Y/M/D" as the latter is
already automatically generated from the YYYY/MM/DD date format, ja-JP
uses '/' instead of '／' as date separator.
http://cgit.freedesktop.org/libreoffice/core/commit/?id=af25972c19bcd0bef7739bd777c67907d61b2b16

Thanks
  Eike

#43

Only one answer saying that fr_CH will be happy with "D/M".

Best regards.
JBF

#44

Hi Yury,

>... I'm confused now, does be-BY want incomplete date patterns, yes or
>no?

Yes. Sorry.

Ok :wink: done
http://cgit.freedesktop.org/libreoffice/core/commit/?id=09c1d111208619197fa851b21ff24bd261a93b15

And also it wants a possibility to switch off "incomplete date
recognition" completely? Is this doable?

No (not yet?) Best would be to implement an editable list of not
auto-generated patterns, so the user could add/remove to her likes.

  Eike

#45

Hi Eike,

Ok it seem D/M is probably the best.

Regards,

AAK

#46

Hi Aferkiw,

Ok it seem D/M is probably the best.

Added
http://cgit.freedesktop.org/libreoffice/core/commit/?id=bffecae79a79feec906f55f25d0d563915d64c6e

Thanks
  Eike

#47

Hi Jean-Baptiste,

Only one answer saying that fr_CH will be happy with "D/M".

Sigh.. so fr-CH will be happy with D/M for fr-FR ... because fr-CH
doesn't even use '/' date separator..

Anyway, now added D/M to fr-FR, fr-BE and fr-LU

  Eike

#48

...

Well, I really believe we could do without another editable list in the auto-correction. :slight_smile:

Yury

#49

Indeed. But they use the dot as decimal separator and date separator. So
there is a conflict if you type 1.2 in a cell.

Best regards.
JBF

#50

Hi again

When looking closer at the date- and time-formats for sv_SE I find a lot of duplicates of YYYY-MM-DD
and YY-MM-DD. There are a few lets say questionable formats there as well. When it comes to time-
formats. I really hope we at least can have HH.MM and MM.SS

Is it possible not to turn inputs on format MM.DD into dates in Calc. It is much more likely that it is
supposed to be a time value HH.MM? MM-DD is good to have accepted though. Not really sure
if it's possible.

I will have a closer look at the current formats and discuss them locally. But that might take some
time so. I appended a few formats to the sv_SE.xml do you want a patch, or how should i proceed?

Thanks,
Niklas Johansson

Niklas Johansson skrev 2012-01-18 18:08:

#51

For Finnish (fi_FI) please add "D.M.", I don't think other abbreviated formats
are used here.

Harri

#52

Hi Jean-Baptiste,

>> Only one answer saying that fr_CH will be happy with "D/M".
>
> Sigh.. so fr-CH will be happy with D/M for fr-FR ... because fr-CH
> doesn't even use '/' date separator..

Indeed. But they use the dot as decimal separator and date separator. So
there is a conflict if you type 1.2 in a cell.

I wouldn't call that a conflict, 1.2 then takes precedence as decimal
number. Adding "D/M" as date acceptance pattern is no problem, just how
widespread is its use and would users be aware? This could be a case for
"D.M." if that's used in writing or informal speech. I have no idea.
Would be good if fr-CH natives chimed in.

  Eike

#53

12 Ocak 2012 15:43 tarihinde Eike Rathke <erack@redhat.com> yazdı:

Hi,
Just mail me the pattern(s) for your locale, I'll add it then.

Hi,

D.M
D/M
D-M
should be all fine for tr-TR (Turkish). The common seperator is "."
but there is not a rule for it so any seperator can be used. I checked
MS Excel and all the above are completed fine.

Regards,
Zeki

#54

Hi Niklas,

When looking closer at the date- and time-formats for sv_SE I find a
lot of duplicates of YYYY-MM-DD
and YY-MM-DD. There are a few lets say questionable formats there
as well. When it comes to time-
formats. I really hope we at least can have HH.MM and MM.SS

As said, there can be only one TimeSeparator that is recognized by the
input scanner, which currently is ':', you may change that to '.' and
need to adapt at least the format codes that are used to edit existing
values, see current locale.dtd for details.

If you don't want to change the TimeSeparator you can still add HH.MM or
MM.SS formats to the already existing (use formatindex above 50 for
that), but those wouldn't be used to edit times, which may confuse
users.

Is it possible not to turn inputs on format MM.DD into dates in
Calc.

If there is no M.D DateAcceptancePattern defined then such input will
not yield a date. This was the main point of the change :slight_smile:

It is much more likely that it is
supposed to be a time value HH.MM?

Would be recognized as time only if the TimeSeparator would be '.'
instead of ':'

MM-DD is good to have accepted though. Not really sure if it's
possible.

With DateAcceptancePattern M-D yes.

I will have a closer look at the current formats and discuss them
locally. But that might take some
time so. I appended a few formats to the sv_SE.xml do you want a
patch, or how should i proceed?

Yes, a patch diff would be appreciated.

  Eike

#55

Hi Harri,

For Finnish (fi_FI) please add "D.M.", I don't think other abbreviated formats
are used here.

Added
http://cgit.freedesktop.org/libreoffice/core/commit/?id=49e685663146b9ad59a47cfaf9cf499fc6a6b937

Thanks
  Eike

#56

Hi Zeki,

D.M
D/M
D-M
should be all fine for tr-TR (Turkish). The common seperator is "."
but there is not a rule for it so any seperator can be used.

Added
http://cgit.freedesktop.org/libreoffice/core/commit/?id=2d8a5940a0369127602fcc6144e9c31aae4917bd

I checked MS Excel and all the above are completed fine.

I think (not sure) Excel does that for all locales, as we did before,
leading to the same annoyances.

Thanks
  Eike

#57

For Estonian, please add the officially correct incomplete date pattern
"D.M" and also some which are technically not correct, but which are used
nevertheless (and I don't think they'd conflict with anything, so it
shouldn't hurt): "D. M", "D.M.", "D. M.".

Best regards,
Mihkel

#58

Hello,

For breton language, we use DD/MM for the short pattern, DD/MM/YY or DD/MM/YY for the developped one.
Many thanks.
Best regards
Alan

For Estonian, please add the officially correct incomplete date pattern
"D.M" and also some which are technically not correct, but which are used
nevertheless (and I don't think they'd conflict with anything, so it
shouldn't hurt): "D. M", "D.M.", "D. M.".

Best regards,
Mihkel

#59

Hi Mihkel,

For Estonian, please add the officially correct incomplete date pattern
"D.M" and also some which are technically not correct, but which are used
nevertheless (and I don't think they'd conflict with anything, so it
shouldn't hurt): "D. M", "D.M.", "D. M.".

Done
http://cgit.freedesktop.org/libreoffice/core/commit/?id=e6870cf32d7e95aca07f260b9cc9965da3299cce

Btw, I noticed that et_EE uses identical characters for
QuotationStart/DoubleQuotationStart and QuotationEnd/DoubleQuotationEnd
which are both double quotation marks. QuotationStart/End are meant for
single quotation marks though.

Maybe I already asked this times ago over at OOo but forgot ...

  Eike

#60

Hi alan.monfort,

For breton language, we use DD/MM for the short pattern, DD/MM/YY or DD/MM/YY for the developped one.

Done
http://cgit.freedesktop.org/libreoffice/core/commit/?id=91e9cdd32943de6d3075a26e468bba11fa60bdee

Note that acceptance patterns don't use replicated codes, i.e. it
doesn't matter if a single or double digit day or month is entered, so
it's just a D/M pattern. D/M/Y is already generated from FormatElement
with index 21 (DD/MM/YYYY)

Thanks
  Eike