Date: prev next · Thread: first prev next last
2012 Archives by date, by thread · List index


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


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.