On 01/17/2012 05:23 PM, Eike Rathke wrote:
On Tuesday, 2012-01-17 07:41:42 +0200, Yury Tarasievich wrote:
Actually, it'd be better to have possibility of switching off the
feature altogether, "across the installation", as the traditional
fractional part separator /comma/ tends quite often to be
substituted by the /dot/, in these times.
I'm not sure I understand. If you're saying that people tend to input
decimal numbers as #.# instead of #,# then better not define the D.M
date acceptance pattern to prevent confusion, and a #.# input will just
be a textual string. Is that what you meant?
No, no. Just that these times some people
(who've taken pains to learn computer, for
example) tend to use *both* traditional /comma/
and non-traditional /dot/ indiscriminately. Sort
of, putting /dot/ in decimal separator place,
because "it's so "in computer".
E.g., once upon a time I myself wanted a quick
spreadsheet or something, and began to enter
numbers with /dot/ ("what blessed difference
does it make?"). Imagine an annoyment when my
inputs were one by one converted to dates (what
about user working on an installation without a
favourite locale?) And then I had to hunt for
the switch-off, because the first place I turned
to was in Preferences->OOO->General, and there
wasn't anything about this besides the
"interpret two-digit year as".
Now, I've noticed that guys from ru_RU team
requested "D/M/" and "D.M.", precisely for that
reason, I believe (/slash/ is, of course, a
traditional symbol for a fraction or division
sign; single /dot/ is handier to have just as a
fractional part separator).
But, in fact, both forms are somewhat
counterproductive, because these 1) are not
guessable and will require separate learning by
the user (nobody without specifically learning
those will enter one of the sequences
deliberately), and 2) are anyway two digits away
from the short form of the date (DD.MM.YY).
Of course, if the functionality is there,
anyway, and has to be "fed" something, even such
not-quite-intuitive forms will do. *In fact, I
hereby request "D/M/" and "D.M." for the be_BY,
please.*
But it would be ever so better to have a
possibility for computer to not second-guess at
all, as such guesses might even be culturally
irrelevant.
Historically, it was often D/M (D in Arabic numerals, M in Roman).
With roman numbers that wouldn't work. We could define a D/M pattern,
but input would have to be in Arabic numerals.
No need to, as it was historical example, anyway.
Yury
--
Unsubscribe instructions: E-mail to l10n+help@global.libreoffice.org
Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/
Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette
List archive: http://listarchives.libreoffice.org/global/l10n/
All messages sent to this list will be publicly archived and cannot be deleted
Context
- Re: [libreoffice-l10n] [ANNOUNCE] Locale data date acceptance patterns, localizers HEADS UP please :) (continued)
Privacy Policy |
Impressum (Legal Info) |
Copyright information: Unless otherwise specified, all text and images
on this website are licensed under the
Creative Commons Attribution-Share Alike 3.0 License.
This does not include the source code of LibreOffice, which is
licensed under the Mozilla Public License (
MPLv2).
"LibreOffice" and "The Document Foundation" are
registered trademarks of their corresponding registered owners or are
in actual use as trademarks in one or more countries. Their respective
logos and icons are also subject to international copyright laws. Use
thereof is explained in our
trademark policy.