Hi Falko,
again a request for enhancement.
Regards, Peter

I will investigate this issue asap

Ok, I had a chat with the developer and we concurred that this is a
bug on the OS side that we cannot fix. MS can since they "just" tweak
their ownn OS. We would have to build in a very awkward workaround
_only_ for one language and _only_ for one OS to accomplish this.

MS knows how important is this issue and fixes it in Excel. Why 
can't you see the amount of productivity spanish people can lose 
because this stupid thing?
I work a lot with spreadsheets, and my speed entering numbers in 
OOCalc is by far too slow compared with any other spreadsheet.
Surely I won't know what to say to my customers when they will ask 
me about this.

This is very problematic. This keeps a lot of potential users from
making the step towards OpenOffice.org.

I try to live with it, but lots of potential users that would use Calc
every day decide on this point ;-) to wait for versions that have this
bug fixed.

They don't want to use the dot for decimal notation. Mostly because
they are working with currency.

This is not only for 1 country. Belgians and people of Holland have the exact same problem. Decimal seperation is , not . 

I can't verify at the moment 'cause i'm at school, but this isn't one OS either, since I use linux and have experienced the same problem before (but this could be the occasional time i use windows)

I dont think it's an os bug but a keyboard issue.

For user, It's not so easy to get the , decimal separator.
All numeric keys are all accessibles using SHIFT. Not comma. Comma and
? should be swapped . But there are not :-(

Thus if you want to be productive you must patch the keyboard code 
Easy for information technologist, what about others.
On my mind OpenOffice should do it for us, except if OpenOffice is
only intent for specialist ..... :-)

After a little research done by a colleague from Softcatalà and me, 
we have verified that this issue is extensible to the languages 
below, because its locale characteristics and their keyboard designs:

Afrikaans, Basque, Catalan, French (all except Switzerland), 
Galician, Italian, Portuguese (Portugal), Serbian (Latin) and 
Spanish (all variants).

This list may not be complete because it has been tested only on a 
Spanish distribution of Windows, and other languages afected may be 
missing.

I think this issue should be easylly fixed, perhaps including an
option for the spreadsheed.

For example, when entering data I supose it would be a function or
procedure that detects if the input is a number, date, formula or
string. On the detection routine: given ####.## if substitute . for ,
is enabled substitute it for ####,##. I my oppinion this should be
enought for mow.

After all this feature has a potential "market" of 400 10^6 users! and
is always claimed by people moving from Excel to OpenOffice.

Best regards,

---
Antoni Aloy

This is *no* defect but an enhancement.
Re-assigned to Bettina Haberer therefore.

This issue should be regarded as one of the major one.  Regardless if
the problem is mainly an OS issue, from the user perspective the
numeric pad is useless when running Calc.  Over a year passed by since
it was reported.  Please work on a solution for this issue.  I cannot
"sell" OpenOffice Calc to anybody because of this.  Whenever I
encourage a new user to try it out, this issue comes back right in my
face.  The new user then discards Calc and returns to Excel.

This issue tarnish the reputation of the product.  What does it tell
of a spreadsheet when the numeric pad, of all things, is useless?  How
can people believe that the product is well design and user friendly
if it exludes upfront the use of the numeric keypad?  Calc is being
dismissed as a toy because of that.

Either you convince the OS design team to fix things (fat chance) or
you adapt the product around the OS.  But this issue must be resolved,
and not in a year from now, please.

Hello, I'm Stefano Liviero.
I'm Italian, I use OOo on a Pc with Windows 95 as OS and I have some 
problem with decimal separator.
I think that this problem is linked to the way OOo managed 
International setting.
In fact MS Excel and Star Office 5.2 use settings in the Number tab 
(where I'm free to decide if use a dot or a comma as decimal 
separator and how to separate thousands), but OOo seems to use 
a 'default' "Italian" setting, with comma as decimal separator and 
dot as thousands separator.
I think that OOo could use setting in the Number tab of International 
setting everybody should be able to choose the best setting for all.

I have the same problem, cause the not English spoken part of Europe
use commas in decimal numbers. Maybe is there a solution with using of
the keyboardlanguage in Windows e.g.

Edgar from Holland

Yes, it's vey annoying not to be able to use the numerical keyboard. I had to go to   
English locales in order to use it.  
 

*** Issue 3157 has been marked as a duplicate of this issue. ***

Hello,

I found that this issue is a very annoying problem in OOo 
Spreadsheet. So I was looking 

for a possible solution, and here are some starting points I 
thought. Might them be 

usefull!

I had talks in dev@fr, dev@sc, dev@gsl, here are some pointers :

The solutions I proposed and the thread in dev@sc :
http://sc.openoffice.org/servlets/ReadMsg?msgId=583255&listName=dev
The following thread in dev@gsl : 
http://gsl.openoffice.org/servlets/ReadMsg?msgId=590212&listName=dev

Robert Cabane has also entered a related issue (11404) with another 
possible solution. 

I am now convinced that probably the best solution would be to be 
able to distinguish a 

'.' of the keypad and a '.' of the numpad, and to replace directly 
(in vcl) the '.' of the 

numpad by the numerial separator key of the current language. That 
would mean some 

important modifications in the vcl code, but would have the 
advantage to definitely solve 

this problem for all languages (do they have '.' as thousand 
separator or not).

Best Regards

-- 
Rémi Peyronnet

Come on people, this thing is already around for one year and a half,
and as far as i can it is the issue with the most votes on it. Maybe
somebody could raise priority or something, or better, somebody may
actually write some code for it to work. If only I had the skills to
program.

*** Issue 12954 has been marked as a duplicate of this issue. ***

Aren't issues # 7341, 7467 and 8695 also duplicates ?
As this is the currently most-voted-for issue, I hope it will be
resolved quite quickly now.

All the best,

Philippe (aka Fousage)

*** Issue 14348 has been marked as a duplicate of this issue. ***

just my 2 Cts:
This is an OS-Issue. At least linux (or better let's say users of
XFree86) can easily change Numpad-behaviour easily by putting e.g
keycode 91 = comma
(If you're not sure about the keycode run "xev" amd press the desired key)
in their ~/.Xmodmap file and have it parsed on startup using
xmodmap ~/.Xmodmap

You'd better nag Microsoft to create a new Keyboard-layout
specification for spanish-layout.
(my personal opinion - I'm not a programmer nor do I decide what gets
implemented - I don't even work at Sun :-)

Your keycode 91 = comma suggestion is flawed.  If you do so, OO Calc
will work fine, but many other application which expect "." will not
work.  Run python and try 3,5+1,5.  It will return you a list (3, 6,
5) instead of return you 5.0.

So Linux is not better.  The problem lies that the OSs have never been
designed for locale in the first place, and changing things would
require too much of a redesign, requiring us, users to wait very long
for a solution.  In an ideal world, the numkey pad "." should be
assigned to a keysym named "decimalseparator", and the character
attached would depend of the locale in use, but such is not the case.
 There is no "decimalseparator" in /usr/X11R6/include/X11/keysymdef.h.

BTW, Microsoft does not have any problem with Excel.  So you can nag
them how you want, they will tell you that you should use Excel
instead of the "inferior" OO Calc.  Its to their advantage not to
solve the problem.

You can try to change the world, but it wont be done tomorrow.  Or you
change OO Calc, and it could be done in less than a month.  A simple
checkbox in the preference suggesting the use of "," as a decimal
separator, and a keyevent catcher which would replace "." with ","
before sending the input to the widgets would do the trick.  Or
easier, OO Calc should simply ignore the locale setting for decimal
separator and always use ".".

> Your keycode 91 = comma suggestion is flawed.  If you do so, OO Calc
> will work fine, but many other application which expect "." will not
> work.

So just add the line
"keycode 91 = KP_Delete KP_Decimal comma"
to your xmodmap-config and you can switch between . and , by pressing
Mode_Switch (usually altGr)
You can alter the order to "comma KP_Decimal" if you use . more often...

This soulution comes very handy when you want to enter dates as well
as currencies..
Other apps won't be affected at all...

I tried your configuration, but it does not work.  For one, I do not
have altGr on my keyboard.  I assume that the modifier is something
else  and tried those reported by xmodmap (shift, ctrl, alt, left &
right), but it did not worked.

Still, even if it worked, I hope you were providing this as a
workaround, and not as a final solution.  To have to hold a modifier
while using the numeric key pad is not very practical.  BTW, I am not
an export with xmodmap; I will admit to that.

Also, its not a solution for the Windows platform.

Well, let's find a solution for 90% of the targhet of OO, that means
Windows and Linux on a PC keyboard.
If the problem is to distinguish from the period in the numeric keypad
and the other in the alphanumeric part, in windows we have scancode
110 (VK_DECIMAL) for the numeric keypad, and scancode 190 for the
alphanumeric, while in X-Window, AFASK, we have XK_KP_Decimal for
numeric and XK_period for alphanumeric.
In addition, code from KSpread (KDE spreadshit) could be taken, since
they don't remap kaystroke but parse the input string instead and swap
period with the apropriate decimal separator if a valud number was
entered (or with a logic like this, I guess).
Belive me, when I propose OO to someone in Italy, I get embarassed
when the Calc behaves the way now does.
Thanks a lot

I'm setting a target milestone, maybe this will bring some live to
this issue (besides user comments).
I want to state again that I am just like you an ordinary user - so
don't take my opinions as a decision regarding this issue...
(PS: AltGr is left to space on a german layout = right alt if you want
- you can configure this as well
And of course this is a workaround (but I think it's a good one) you
don't have to press the modifier all the time, only when you type into
your "not-so-often-used" application - you can set the default to
whatever you want (. or , -it's your choice) - and of course you could
add a small skript to your "launcher/trask/menu-bar" just klick that
botton and you can switch between the two states or assign a keycomo
of your favourite window-manager to switch between "." and "," - linux
(or better X in this case) is very flexible)

Sorry, but there is no chance to implement this before OOo 2.0.

You are downgrading from P2 to P3 a bug that has a max number of votes.  
Incredible decision. Tell me I'm dreaming .

Here is the top 3 classified by votes number  :
46 votes for this issue
38 votes for issue 2109
22 votes for issue 1940 

(and there are only 17 bugs - these ones included - with at least 10
votes)

What about final user satisfaction ?  

I think this should have top priority and it should be fixed for the
release after 1.1. Version 2.0 seems too far away.

Maybe someone with source code knowledge can tell if this needs a
simple fix or a major redesign.

The solution is to allow 2,3 input to be automatically infered as a
number (like today) if the locale sais so, but as keyboards don't
change the numeric keypad in different languages, in ALL LOCALES
accept 2.3 as a number. Does this look like the correct solution? I
think there must be a separation between how the numbers are stored
(the content) and how they are displayed (what we see).

OO.o seems very proud of their international support, but this issue
means the world to a spreadsheet user and the fix seems so simple to
someone that knows the code (what can it take, tell me, 1 person and 2
weeks?). 
If I'm wrong, tell me why.

Please resolve this problem ASAP, we need it to perform effective
advocation versus MS excel.

TIA

I just reached this issue (after entering a duplicate, sorry for that)
and cannot believe what I am reading so far.

Is this an open community or what?
This is a VERY important BUG, not an enhacement in first place. An
open source spreadsheet program that cannot correctly use the
numerical keypad in more than half of the countries of two continents
(Europe and Latin America, and perhaps even more unknown!) and that
gives to this BIG PROBLEM the priority and relevance I'm seeing right
now, should seriously reconsider what its target really is.
If reaching the greatest possible number of users around the world is
barely considered as a priority, then believe me. This issue must be
resolved ASAP!
And if Bettina Haberer doesn't want to take it over her shoulders,
then perhaps she should pass this HOT ISSUE to someone else with more
time, knowledge and/or predisposition to give it the attention it
truly deserves.
But the community really need this issue to be fixed, BEFORE other not
so crucial bugs in Calc!

Right now, I will go to the spanish OOo community mailing list and
will tell everyone there (where there are several complaint by month
regarding this topic) to vote for this issue, and wholeheartedly
recommend anyone reading this who cares to actively search for votes
for this issue. We have to raise our voice, we need this corrected
ASAP and we cannot wait another year until 2.0 to have this fixed,
let's do something about it!

See you,
Gabriel Gazzán

I think this shouldn't be happenning... to answer the question Herpey 
made, yes, we use "." as thousand separator, and this happens in 
almost all non-english speaking countries. 

Please do something about this issue, it is quite annoying not to be 
able to write numbers quickly... I agree it should be fixed before 
2.0 release, but also I can imagine maybe it's difficult to do for 
next release.

If I'd only knew anything about programmming...

*****************
- Localization
  -- ease of and support for -- will always be at
  least as important as functionality
*****************

This was extracted from the "Development goals for 1.1" page found here:
http://tools.openoffice.org/releases/index.html

I think the development team should not forget what the above text states.
There are millions of potentials users in at least 3 continents
affected by this problem, ...and localization "will always be at least
as important as functionality". I seriously doubt the same could be
said from any other issue.

Please reconsider it, we have a serious need for it.

Gabriel

P.S: The vote count is already starting to raise (76 and counting),
and it's Sunday! We're gonna fight for this one!

Very important feature needed
Perharps it is not a defect of the programation but it is a defect in 
Calc use and this issue should be solved as soon as possible

Fault also present in danish version

The same problem is in Czech and Slovak languages.

This should not be seen as merely an enhancement, because it is a
major issue for all European and possibly also Latin-american countries. 

I think the Summary of the Issue should be changed to reflect the real
core of the problem, keeping out the sensation that only one language
is affected. Also this happens both in Linux and Windows.

Perhaps something like:
"Calc unable to translate numeric-keypad "." key into current OS
decimal separator setting"

It's a little too long I admit :) but at least it'd really explain
what the problem is.

By the way, I've found that French-spoken Canadians also face this
problem.

Please read issue # 11404 which is closely related !
These are virtuzlly identical.

Robert

What can I say ? After reading all of the above comments, and as a
native English speaker using French localized software in France, I am
rather surprised at the attitude that has been taken by the
development team.

THis problem is not new and it is a bug, not an enhancement. The
problem has existed since at least StarOffice 5.2, if not before, so
Sun's engineers knew about it or should've known if any of the irate
user messages from the StarOffice usenet forums get to them. Come on
people, we've got a voting system, but good is it for, it obviously
doesn't appear to have any weight, or am I mistaken ? I certainly hope
so. Development teams on a project this big can not simply ignore half
of the world's users or potential users on the pretext that a much
encountered, documented and repeated problem isn't considered as
important. If this is a design flaw, then so be it, but at least we
should be honest enough to own up to it. How can anyone seriously
expect adoption of OOo against other branded software when old
problems like this one are constantly pushed back with no explanation ?

What is more disturbing here is that no reason has been given at all.
 Has any kind of debate taken place between the developer team and the
user community ? It doesn't look like it to me. What have Daniel Rentz
or Niklas Nebel or Eike Rathke got to say about this ? Anything ?
Nothing ?

The community has been crying out for a solution for far too long and
now we hear that it will be pushed back again at least a year. No
reason, no explanation, period. Maybe we ought to slashdot this one,
to bring our plight to a wider audience.

Alex.  

It is also the worst problem with Calc in French (with cell drag & drop)
It's very difficult to convince people to use OOo because of this problem

*** Issue 15601 has been marked as a duplicate of this issue. ***

this is surely an important issue but per definition not a P1, so I
reset the prio to 3 (see
http://www.openoffice.org/project/www/issues/bug_status.html#priority).

Maybe not P1, but surely P2, according to the link given by Martin
Hollmichel. I quote :

**************
Priority 2	This priority describes major bugs.

Examples:
# Crashes in basic functionality
# Freezes in basic functionality
# Data loss
# Functional area gets lost (i.e. printing)
# Basic functionality is not working correctly

Issues with this priority must be fixed before release.
*****************************

I guess most of us who have voted for this issue would agree that "
Basic functionality is not working correctly" and that "Issues with
this priority must be fixed before release".

Absolutely, if this is not called "Basic functionality not working
correctly" I don't know what qualifies for that category!
We can't even type a decimal number in a speadsheet program!

P2 would be the correct priority for this defect I think.

Gabriel Gazzán

Alex: "I am rather surprised at the attitude that has been taken by the
development team."

Remember: the only developers commenting on these issues were Falko
(who reassigned the issue to the appropriate person) and Bettina (who
retargeted the issue to OOo2.0 -> the issue has been accepted)

I cannot tell where the hell you could be suprised by the attitude of
the development team.

The problem is that the branch to 1.1 is almost closed. NO new things
get into that tree besides bigfixes to *existing* features. As
explained above, implementing this would add a new feature with the
chance to break other things.

I don't know who "wurzel" is and why he/she changed the target back to
1.1 (which cannot be done, "Sorry, but there is no chance to implement
this before OOo 2.0."), why he/she changed the issue type and that's
the main thing - messed with the priority without having a look at the
priority guidelines and *without giving a comment*

Feel free to provide a patch to be included (or only applied for
spanish/<other lang> builds for the moment).

Restoring Target Milestone and issue type.

I know that you feel this is a defect, nor a RFE, but you have to see
this from the technical point of view - the decicion of which
functionality gets implemented by the paid employees has been taken by
Sun Microsystems to coordinate this effort.
Volunteers can of course take this issue and fix it on their behalf
(with good chance that their patch will be accepted).

Note that I´m not a developer, nor am I working for Sun. The
statements above reflect the understanding of the process that I
gathered in various mailing-lists.

Again: 1.1 is almost complete. No new features will be introduced
(There may be exceptions of course). Please discuss things not related
to the issue itself on the mailinglist(s) (maybe native-lang?)

And regarding priority: Sure this can be discussed, but it's easy to
workaround (just use the dot/comma on your standard-Keyboard) or
change keyboard-layout..)
OOo doesn't crash, doesn't freeze, doesn't loose data.
You can however enter numbers, enter numbers with comma, calculate
with these numbers. 

And the description for P§ reads:
  [...]
    *  single function doesn't work the way it is supposed to be, 
       but none of the P2 criteria apply

(here you go)

  [...]

Issues with this priority must be fixed before release.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

(what else do you want?)

These priorities aren't "linear" like the grades at school..

Then, for this, the developement team should make an exception. To
whom should we talk about? Who's the one that can take the decission
to make it an exception?
Let's talk...
Millions of potential users are crying for this to be fixed ASAP, Sun
should be one of the main concerned ones, because millions of its
customers won't be able to use it's product or worse: won't want to
use it!
What answer will Sun give to it's customers? "We didn't know?"

Perhaps we should seek for more support on the public open source
community? We will do if necesary. This is affecting a lot of people,
many of these, customers of Sun.
What should a teacher at one of the schools to which Sun provided
StarOffice for free will teach to his students?
"You see this? Well... in this product it doesn't work, but in other
products such as Excel it works. Now, do as if it worked and type..."
:)

Come on... Sun should be the first in the line... just try to make
them really aware of the problem!

Sincerely,
Gabriel

Thank you Christoph for your last statementI found very qualified.

Changing flags to tell the developpers / product management "This
issue has to be fixed quickly!" is the wrong way to communicate.
The fact is:
- the objective technical severity of this problem is average.
(the field P3 reflects this state)
- BUT the *subjective* impact of this isuue on *YOUR* daily work is huge!

So, please go one voting for this issue as you have all started to do
but don't change the qualification of the issue anymore.

Thank you!

What is the OOo 1.1.1 target milestone for ?
Is it possible to have some work done on this version ?

Laurent

***********
OOo doesn't crash, doesn't freeze, doesn't loose data.
You can however enter numbers, enter numbers with comma, calculate
with these numbers. 
***********

Sorry Christian, I ask you to change your decimal separator setting to
comma "," in your OS (Linux or Windows, don't matter). Then try to
enter 500 decimal numbers in the shortest possible time.
Now change back your decimal separator to the dot and do the same
using the numeric keypad dot key.

If you don't suffer from it it's really easy not to see it as a number
1 priority, but is so basic and important the functionality affected
by this problem (either being catalogued as a bug or not) that is
really hard to convince anyone to make the change from Excel to Calc.
Believe me this single problem will detract more users from making the
change from MS-Office than the whole SCO - IBM affair!

Gabriel

***********
- BUT the *subjective* impact of this isuue on *YOUR* daily work is huge!
***********

Eric,
The impact in your daily is not a subjective one, it's an objective one!
It's time that's lost in the middle of something that should be done
by heart, it represents a los't in productivity and ultimately a lost
of money!

So perhaps Sun could sell StarOffice as the mos economic way to lose
productivity!
Hey! What you think about it? Will it work?
I don't think so...

I not to be spoken English, but ... Votes for issue 1820: 194 !!!!!
No sufficient?

Not solving this issue is as letting Microsoft take the chance to do
good publicity with it in all the affected markets.
France, Canada, Spain, Italy, Holland, all Latin America, Turkey...
There's a lot of money both MS and Sun wants there.
So if ultimately it's a matter of in what should the Sun paid
developers invest his/her time. ...well, if I were Sun I'd put a
little money on this.
It's safe to say that it's rather difficult to find any other issue to
resolve that with so little effort would cause such a great impact in
the usability of the program for so many potential users.

Gabriel

Christian,

I am the user wurzel, that is my nickname here, and I'm not afraid to
say so. 

Re the change of priorities and target. Let's just say that I was as
surprised as you were, when I noticed that I could indeed change the
target and priorities. I hadn't expected this to work, since after all
I'm not a developer, and I don't think I have any developer rights,
and I was not the one who opened the issue. What it did though was
stimulate some response, which is what I felt, and I think a few
others who have contributed here, was lacking.

You have now explained that it is too late to include this in the
current 1.1 development without risking breaking something. That may
be, but the fact of the matter is that the problem isn't new, and no
justification was given by those doing the work on behalf of Sun as to
why there had been a shift in target (I'm not going to haggle about
the priority status, because I just don't agree that it's not an
important functional defect - we'll just agree to differ on that one).

One thing that this does leave clear in my mind is :

1) that the native-lang mailing list will not bring this kind of
problem to the attention of the developers

2) that IZ is totally unsuitable for resolving conflicts of this kind,
for here we are in conflict between what Sun sees as essential
development, and what the users in the OOo community see as essential. 

3) that at present no mechanism exists for resolving such problems,
other than "If you're not happy, do it yourself, or lump it"  Were I a
programmer, then I would probably have done so or at least tried.

If I have fallen into disgrace through my actions, so be it. At least
there has been some important debate about this important problem.

Alex (wurzel)

@Gabriel:
There are already volunteers working on this issue. Sun is aware of
this problem as well but hasn't enogh ressources to work on a /clean/ fix.
The short-term-solution would probably be a dirty hack that has to be
rewriteen anyways, that's the reason why Sun has no interest in
working on this issue *at this time* (release of OOo1.1RC is sheduled
for 26. - ten days that won't be enough since developers have to
create the tarballs, build it,...)
And not so serious:
If I want to enter 500 numbers as fast as possible, I'd just enter
these  into a simple cvs (txt)-file with my favourite editor and then
copy it into OOo (maybe I'd do a ":%s/\./,/g" first (vim-notations
substitute every occurence of "." (quoted, otherwise would be
treatened as a regex) with "," - in every line (% - the whole file)
and every occurence (g - otherwise only the first match would have
been replaced) :-)
Since I'm german, this issue affects me as well..

(for priorities: Please read the priority-guidelines from an objective
point of view - in no way this is P1 - P2 not really P3 definitely. P2
and P3 both have to be fixed before release - this is the most
important part
IMHO it is not basic functionality to enter data the most comfortable
way. Again: I fully understand your point - It bothers you and many
other users, but P2 doesn't really fit for this one - no crash, no
freeze, calc works. The problem can be circumvented. See also this
link: http://www.via.ecp.fr/~remi/win/ooovirg/ooovirg.php3 )

I think you underestimate the effort needed for a clean solution. (I'm
not a programmer - I don't know how this is handled at the moment and
how it /should/ be handled - probably you don't know this as well)

@Alex (wurzel)
I'm not mad at you because you changed something nor did you fall in
disgrace. But changing things without any comment is just a bad idea.

Point 2) Sun is aware of this but doesn't want a quick'n'dirty
solution - a clean fix however needs more time. That's all.

and "[...]and no justification was given by those doing the work on
behalf of Sun as to why there had been a shift in target[...]"
This is wrong (or maybe I don't understand you):
When Bettina changed target to 2.0 the comment was:
"Sorry, but there is no chance to implement this before OOo 2.0."
I think this is enough explanation. The initial target was set by
myself: "I'm setting a target milestone, maybe this will bring some
live to this issue (besides user comments)."
So I don't get your point.

**********
I think you underestimate the effort needed for a clean solution. (I'm
not a programmer - I don't know how this is handled at the moment and
how it /should/ be handled - probably you don't know this as well)
**********

I'm not a programmer now, but I programmed in the past, I know
sometimes it's not easy.
But regarding this issue, I tend to think that if the OS (being that
Linux or Windows) has an internal variable in which it's stored the
chosen decimal separator character. This variable could be accessed by
Calc, and just replace every press of the numeric-keypad "dot" key
with the character stored in the OS's (let's call it) "decimal
separator" variable.

It doesn't seem to be that time consuming to do it. Or am I soo wrong?

Gabriel

I'm really astonished. You prefer having MILLIONS people have trouble
for the numeric keypad decimal separator because you need a "clean
solution", and not a (and seems really easy) fast fix (and THEN have
time for a 2.0 solultion that you like)!
You label "Enhancement" this issue??? A spreadshet that makes really
painful enter NUMBERS? Are you all joking? So what about if the "0"
number of the numeric keyboard were not working and you have to use
the aphanumeric keyboard? The situation is THE SAME, the troubles are
THE SAME! Is it an enhancement request, are you sure???
In my "additional comment of 2003-05-17 15:11" I've traced the way of
a fast fix, but I can't fix it by myself because having to download
170Mb of source and find the right position for the fix having never
seen the code before is a "non sense" (and I program in Delphi, not
C/C++). A programmer with knowledge of OO sources strutcure could find
it in a snap instead.
You coul also take KCalc source code if you want a different solution,
since KCalc parses the input and decides that if recognized as a
number, "." have to be translated to current locale.
Christian Lohmaier is from Germany, right? What do you think that the
Munich municipality or the Bundestag will consider this problem? Have
you ever told your secretary to use Calc for daily work?
I invite all the (lucky?) programmers that have the point as decimal
separator to switch to coma, and try to do productive work!
And please, read priority guidelines, since this is at least a P2, or
revert the problem so only countries with coma as decimal separator
can use numeric keyboard, and then will see that Issue type and
priority will be assigned (yes, I'm also a bit angry;)
regards
Marco Menardi

Two possibilities: 
1) You actually read and try to understand what I write
2) Just keep on going flaming

and BTW: OOo does not only run on Windows or Linux.
And Munich will cope with the situation easily since the desktops will
run linux (and X) as operating system. Therefore thy can use Xmodmap
to redefine the keys. (there won't be the need for other applications
on insisting having dot as separator - and if so, you could still use
my suggestion with a modifier key or a small skript that changes the
behaviour and put a botton to it on some launcher bar). There exist
workarounds for Windows as well (see the link I posted with my last
comment)
I won't reply on any flames...

> It doesn't seem to be that time consuming to do it. Or am I soo 
> wrong?
The problem might be that what Calc receives is simply the 
character '.' without a way to determine if it resulted from a 
numeric keypad or an alphanumeric area keypress. 

It could possibly be solved at a lower level, where actual scan codes 
are handled. The lower level code could translate the decimal point 
to a ',' character if appropriate. But to know if it's appropriate, 
it should be aware of higher level data such as the current language 
of the part of the document being edited. For example, using a Dutch 
version of OOo, I may edit documents that are (partly) in English, I 
want to get the '.' again when editing the English parts!

However, such a fix would go against the design of the software, and 
this should be avoided because it makes it more difficult to 
understand the operation of the software, and thus to keep developing 
and improving it.

So I think the developers are correct in thinking about the future 
quality of the OOo software, and in wanting to go for a well-
constructed fix instead of a quick and dirty one. 

(at the same time, if the problem could be fixed in an elegant way in 
the 1.1 version, so much the better). 

***********
Falko Tesch wrote on 2002-05-24:
Ok, I had a chat with the developer and we concurred that this is a
bug on the OS side that we cannot fix. MS can since they "just" tweak
their ownn OS. We would have to build in a very awkward workaround
_only_ for one language and _only_ for one OS to accomplish this.
***********

Now, if this was the time when the fate of this issue was decided, we
should go back to then, and examine it.

Saying that "this is a bug on the OS side that we cannot fix" sounds
like a silly answer which has nothing to do with the actual problem.
Did the programmer consulted really ever got to know what it was
consulted about?
What is that bug on the OS side? What OS: Windows? Linux?
Both OSs face the same problem, so saying that "MS can since they
"just" tweak their ownn OS." is just nonsense to me.
Are we talking about the same thing? Supposedly the decimal separator
character should be available to any programmer wanting to use it,
both under Windows or Linux. Isn't this available in Windows? But if
the bug is only present in Windows, how is that the problem Calc has
is present also in the Linux version?

Could someone clarify my mind on this? I'm really curious!

Gabriel

***********
For example, using a Dutch 
version of OOo, I may edit documents that are (partly) in English, I 
want to get the '.' again when editing the English parts!
***********

Are you talking about Calc documents writen part in english part in
other languages?
If we look at MS-Office, the kind of fix that we require is only
present in Excel, not in Word. Just because the place where you really
need that speed at your hands is the spreadsheet, not the wordprocessor.
So only Calc should correct this issue. Not because is the way MS do
it, just because is what people asks, what people knows and expect.

On the other side if you are really referring to a bilingual
spreadsheet, then I tend to look at the bulk numbers, how many people
need to have bilingual spreadsheets, how many just need to have a
decent spreadsheet workflow when using colon as decimal separator.
I know the answer, you too.

Sincerely,
Gabriel

*********
Could someone clarify my mind on this? I'm really curious!
*********
Well, IMHO from a "theoretical" poit of view, the "point" on the
numeric keyboard is not "the point", but the "decimal separator"
(keyboard has a point because of the "USA-centric" situation, see
pocket calculators), so the OS should translate it to the apropriate
one based upon locale settings. But since this does not happend,
almost with PC architecture under Windows or Linux, and since this is
a real problem, programs usually do the job instead of the OS. In
Italy, all accounting programs do this, Excel do this, any program
that manages data entry of numeric values has to do this if wants not
to annoy people and not be used. But OO developers seem not to care ;)
BTW, is any developer in this discussion? Why not discuss in
#openoffice.org IRC channel too? Why there are no europen developers
that take care of problems related to our countries? Or Sun decisions
prevents them to an active collaboration?
regards
Marco Menardi

Note: I am not one of the developers that might be involved into
implementing this feature.

One thing I noted is, that there is not even a clear specification for
this enhancement. I makes no sense to discuss how difficult or 'clean'
a fix would be, unless we discuss what exect feature we want.

We need to determine what should be translated into what under which
circumstances. There seems to be agreement that presses of the
'decimal separator' key on the numeric keypad should be translated
into some specific decimal separator.

Firstly note that the decimal separator key may have varying native
meaning. For example the decimal separator key on my current (german)
keyboard shows a comma and creates a comma when pressed. This makes it
work well in a german spreadsheet, but less well when typing a list of
(english) numbers into vi. Let's call that the 'native' decimal
separator: It is what the vendors of the operating system and hardware
combination have decided to give to you. 

BTW: If they have made the wrong decision, one can properly say that
this is a bug of the OS.

Secondly: to what should the press of that key be translated.

If I press a key that shows a period (or commma, or ...) that creates
the corresponding native character almost everywhere in the OS, I
expect OOo to do the same. So the default behavior for this key should
stay exactly as it is now.

OTOH there seems to be a need to remap the key, when numbers are
entered into a location where numbers are entered frequently and where
the numbers entered are processed according to a number format that
uses a decimal separator that differs from the native one.

So as 'wish' goal we want an option (a user should need to activate
this non-conforming behavior and be able to deactivate it) that
enables the following behavior:

In defined contexts, pressing the decimal separator key inputs a
character that is the decimal separator of the number format used for
parsing and detecting numbers in that context.

The contexts here include at the least input into spreadsheet cells.
They might also include edit fields in dialogs which are meant to
receive non-integral numerical input. Whether they should also include
tables in text documents is more debatable. 

If a set of contexts is specified, it would need to be decided whether
the feature can be deactivated for each of them separately or not.

That was just the beginning of a specification. Several details still
need to be defined.

As this feature (with all the associated UI and configuration changes)
can't be implemented in the 1.1 timeframe, someone should create a
proposal for a less sophisticated feature that can be implemented as a
'quick and dirty' interim solution. 

This issue is related to calc only an needs to be fixed only for the
cells, not for dialoques or other UI-Items (yes, this is quick and
dirty, will fullfill the users request and that's it, what counts).

The basic idea has already reported on 2002-12-08:
------
For example, when entering data I supose it would be a function or
procedure that detects if the input is a number, date, formula or
string. On the detection routine: given ####.## if substitute . for ,
is enabled substitute it for ####,##. I my oppinion this should be
enought for mow.
-------

in a later release, we could introduce an option, if this substitution
should be used or not.


BTW: knowing, this is an issue with 211 votes and target milestone
actually 2.0, why don't we set the "needhelp" keyword?

I've tried my french version of Excel and I haven't found any option 
related to the automatic remplacement of the decimal point by a comma. 
The decimal point is _always_ replaced by a comma (even in strings). I 
think that's really a dirty solution but it works and nobody 
complains.

And it shoul be not too time consuming to implement this 
functionnality (I'm not involved in the development of OOo and I can 
be wrong :-) ).

Regards, Michel.

I've tried my french version of Excel and I haven't found any option 
related to the automatic remplacement of the decimal point by a comma. 
The decimal point is _always_ replaced by a comma (even in strings). I 
think that's really a dirty solution but it works and nobody 
complains.

And it should be not too time consuming to implement this 
functionnality (I'm not involved in the development of OOo and I can 
be wrong :-) ).

Regards, Michel.

*************
For example the decimal separator key on my current (german)
keyboard shows a comma and creates a comma when pressed. This makes it
work well in a german spreadsheet, but less well when typing a list of
(english) numbers into vi. Let's call that the 'native' decimal
separator: It is what the vendors of the operating system and hardware
combination have decided to give to you. 

BTW: If they have made the wrong decision, one can properly say that
this is a bug of the OS.
*************

The problem is not the OS, it's the keymap, the german one seems to be
well designed, on the contrary the spanish, french, italian, chezc,
turquish, etc. ones are not.
That's independent of the OS and is used by keyboard manufacturers to
"know" what to print on the key, as well as OS makers to "know" what
to map that key to.
I really have no idea how to change the keyboard map specifications
themselves or which organization is responsible for that, if there is one.
Just think that even Microsoft couldn't do that in the past, so they
just adapted Excel to their users needs. End of the problem. It's not
strange we expect Calc should do the same.

***********
If I press a key that shows a period (or commma, or ...) that creates
the corresponding native character almost everywhere in the OS, I
expect OOo to do the same. So the default behavior for this key should
stay exactly as it is now.
***********

Sorry, but your line of thinking is a theoretical one, not a practical
one. I can assure you that everyone working in a spreadsheet will
expect the dot (comma or whatever is printed on it) key to work as the
decimal separator key (because it's the way numeric keypads should
work! if not for practicity, what's the reason of it existence in
first place? there are already other keys in the keyboard for every
one of the keys present in the numeric keypad! Think of
it...practicity. It's what half of the western world is losing with
Calc right now.)
So, not working this way is what is logically (from a practical point
of view) perceived as wrong or defective, no matter how "ilogical"
from a theoretical point of view this could seem.

Gabriel

info from francophone project:
--------------------
and for those who need it and don't have the link, this is a small
tool to replace period by coma on Calc :
http://www.via.ecp.fr/%7Eremi/win/ooovirg/ooovirg.php3
It's in french but I have asked the author for translations, I'm
waiting for his answer.
---------------------

Maybe worth a look, if this could be the solution. If yes, someone
should contact the Author if he is willng to contribute directly to OOo.

HI Andre, all
I've already write to Remy Peyronnet to ask him if he would agree with
the JCA and change the licence (I'm waiting for his answer) as Kevin
thought it would be possible to put it in OOo and have it for rc. 
The discussion is taking place on dev@ for the moment. I've forwarded
a mail to our native-lang list, answer is quiet urgent
Best - Sophie

Andre, thanks for the link, but here is not a discussion about a
"workaround", here a lot of people are requiring a OO's code FIX.
Suggesting a tool for some "work around" is like telling us "it's not
a problem, let's stay with actual OO code, why are you screaming? Just
use this tool", so the effect of your post is hurting the advocacy for
a fix (I'm sure you just wanted to help and I thank you:)).
Not having the main OO code work as expected *straight from the
installation* is damaging OO acceptance and use by ordinary people A LOT.
regards
Marco Menardi

Hi, 
 
Adding myself to CC on this topic, just to keep up with the changes. 
 
Two points .... 
 
1. Sun/Hamburg sees the need and agrees with it and has accepted the issue and a 
nice context sensitive soltuon will I am sure be forthcoming for OOo 2.0 or sooner. 
 
2.  The real question is what can be done in timeframe for OOo 1.1 RC or OOo 1.1 
final?  The constraints are: it needs to be doable with the minimum of changes to 
assure that nothing else will get broken by the changes, so no api changes, no 
interface changes, no or few documentation changes.  It needs to be done fast so 
that something is available to be tested in time for OOo 1.1 rc 
 
There are a couple of things possible for to answer question 2 above: 
 
1: an interim solution that tries to remap number pad periods to some locale 
depdendent decimal separator.  Sophie has posted a specification to for users to 
feed back on for this interim solution.  Without this information being collected so that 
the developers know what to do, nothing will be done.  So please 
take a moment to read what Sophie wrote on native-lang and let the list no your 
feelings about this interim solution. 
 
2. a separate gui program to allow the user to control the remapping of this  
number pad period to comma for use under Windows (it exists now and is usable 
with translations coming).  Under Linux/Unix, use of xmodmap can be enabled to 
remap this key just in OpenOffice.org.  Hopefully, if a change in license is approved, 
the WIN GUI app might even be included as part of OOo download so that it can be 
easily found. 
 
So please feedback on these two interim solutions.  Please note, neither solution is 
being suggested as the final best solution for the long term.  They are being 
considered as interim soltuions only to provide some relief until a better / smarter 
solution is made available.  And I would assume that given the improatnce of this 
issue something more premanent might come along in one of  the OO 1.1.1 follow up 
time frames so we should not be talking a year or more for something better. 
 
Please feedback on the proposed specification for an interim solution if you really 
want to see anything beng done in the OOo 1.1 timeframe. 
 
Thanks, 
 
Kevin 
(Volunteer developer - just trying to help) 
 
 
 
 
works similarly to  the Excel solution that hard codes number pad period to  commas  

Kevin B. Hendricks : who is Sophie and where can I find "the
specification" she posted and give her feedback? Maybe I've
misunderstood something...
Anyway, if this is the correct place to post my opinion (if not, plz,
forward it), as a Delphi developer (sorry, not OO... yet) I suggest
solution 1, i.e. "remap number pad periods to some locale depdendent
decimal separator", that is what I do in my programs. Since more
widely used platforms are Windows and Linux, if Calc can receive the
correct keyboard code (and it's not translated by some middle layer in
OO), as I posted time ago there are (my msg by 2003-05-17):
"If the problem is to distinguish from the period in the numeric
keypad and the other in the alphanumeric part, in windows we have
scancode 110 (VK_DECIMAL) for the numeric keypad, and scancode 190 for
the alphanumeric, while in X-Window, we have XK_KP_Decimal for
numeric and XK_period for alphanumeric".
Sure there is some method/property to query the OS about the current
locale settings and decimal separator, so in the keypress event of a
cell you have to write code like (I'm not fluent in C syntax...):
"if key == XK_KP_Decimal then key = locale_dec_separator_code"
regards

Hi,  
  
Here is what Sophie posted to the dev@l;ist saying it would be forwarded to  
native-lang for comments from affected users:  
  
Date: Tue Jun 17 13:57:07 2003  
  
>>Here is a candidate for that interim feature:  
>>  
>>- When 'numpad decimal separator' is pressed and [some user-accessible  
>>configuration] is set then in ALL the application the character  
>>[suitably determined decimal separator] is input.  
>>  
>>- suitably determined decimal separator: To be defined. Some candidates  
>>   - always comma (',')  
>>   - character determined by [some user-accessible configuration]  
>>   - decimal separator for current locale of [entity with locale]  
>>  
>>- some user-accessible configuration: To be defined. Some candidates  
>>   - environment variable  
>>   - ini-file entry  
>>   - bootstrap variable (command-line arg or ini-entry or env-variable)  
>>   - configuration entry (user accessible via some macros provided by us)  
>>  
>>The specification should be reviewed by some of the affected users, to  
>>see if that is what they want. In particular, if some feel that frequent  
>>switching might be necessary for them, it makes little sense to start  
>>with a configuration that can't be changed at runtime.  
>   
>   
> Okay, let's ask them.  I think we should bring this to the fr and es and it   
> and other effected native language groups and ask them what they think.  
  
I'll translate your message and send it to our fr list, and I'll forward   
it to native-lang so we could have some answers.  
Thanks for taking care of this issue. I've writed to Remy Peyronnet for   
the licence but don't have the answer yet.  
If you think a work around could be done in basic, I think Laurent   
Godard (OOoConv) and some others from fr-group will be happy to help.   
Just let me know.  
Best regards  
Sophie  
 
Hope this  helps, 
 
Kevin 
 

Hi Marco,
Just look three comments above yours and you will see me. I'm the lead
of fr project. You can post you comments here (add +1 in front of what
you want to see implemented) or on you own native lang list (as you
seems to be Italian, just post on one of the lists at it.openoffice.org).
We need to act now if we want things to move.
Best regards - Sophie

In reply to "Additional Comments From Andre Schnabel 2003-06-17 
10:36 PDT "

--------------------
http://www.via.ecp.fr/%7Eremi/win/ooovirg/ooovirg.php3
Maybe worth a look, if this could be the solution. If yes, someone
should contact the Author if he is willng to contribute directly to 
OOo.
--------------------

I am the author of OOoVirg, which is, as stated in some replies, 
just a quick work around.

I have seen all the recent buzz about this important issue, and I 
would like to add two things : 

1/ I read comments like "you developers don't want to implement an 
important feature cryed by the community". I cannot understand such 
a clash between OpenSource developers and the User Community. As an 
OpenSource developer, I always tried to do my best for the users, 
and I am convinced that OpenOffice.org developers are doing the same.

2/ This problem is a tough one : 
 - from the user point of view, it is really a silly bug, and very 
easy to fix "what easy should be to replace a point by a comma ?"
 - from the developer point of view, this simply cannot be done 
AFAIK easily with the current core architecture of OOo. So it is 
considered as a major enhancement.

In the beginning of the year, I tried to find a good solution to 
solve this directly in OpenOffice. You can see the results of my 
thoughts in my comment on this issue 

"Additional Comments From herpey 2003-03-18 13:43 PST"

and on the mailing lists I have asked (which have always kindly 
reponded).

From what I have seen, I see two possibilities : 
 - the integration in calc of a workaround for Windows (based on the 
principle of OOoVirg) and Unix/X11 (based on the implementation of 
the FAQ). I guess this could be done quickly, as I do not see any 
major problem, maybe for OOo 1.1 if OOo wants it. (but only for 
these OSes...)
 - review in depth the behaviour of the abstraction layer of OOo to 
find a clever and smart solution. Obviously, this cannot be targeted 
before OOo 2

I am fully ok to contribute to OOo, and I will answer this to 
Sophie, but I may not have all the time I would have.

I am quite pleased to see some debate about this issue, and I am 
sure solutions will be found for short and long term.

-- 
Rémi

Sophie, thanks for your interest. 
But there one possibility missing in [some user-accessible  
configuration], that is NO CONFIGURATION AT ALL. I would like to avoid
settings pollution, with 1000 possible parameters (have a look at the
book "About face" by Alan Cooper, www.cooper.com).
So I would vote for "- decimal separator for current locale" and "- no
user configuration", but maybe some API that can be accessed by macro
(so if you realy really need to change it, you can).
But I've to vote for your list of choice, so here is my vote:
********
- When 'numpad decimal separator' is pressed and [some user-accessible  
configuration] is set then in ALL the application the character  
[suitably determined decimal separator] is input.  
  
- suitably determined decimal separator: To be defined. Some candidates  
   - always comma (',')  
+1   - character determined by [some user-accessible configuration]  
   - decimal separator for current locale of [entity with locale]  
  
- some user-accessible configuration: To be defined. Some candidates  
   - environment variable  
   - ini-file entry  
   - bootstrap variable (command-line arg or ini-entry or env-variable)  
+1   - configuration entry (user accessible via some macros provided
by us)

In reply to "Additional Comments From herpey 2003-06-17 14:23 PDT"
As you stated, and like my convinctions, a fix for Windows and
Unix/X11 is easy and with low impact.
This I'm sure will cover 98% of OO market, and since this problem is
so wide spread all over the world, maybe 50% of OO is suffering now. I
can't understand OO developers rejecting community pressure for such a
fix because they want a solution to cover "100%" of the OO platforms.
Does it make any sense? When they will find "the perfect solution"
they will remove the "orrible patch" and make happy the rest of 2%
patforms, but choose to afflict 48% of OO users.... mmmmm... so bad.
The general feeling I think is that: 
a) since 98% of the developers are not afflicted by this problem, they
don't care 
b) they are loosing contact with the user base, thinking of the
"perfect hack" instead of a "really needed patch".
I've a really deep gratitude to ALL the people are contributing to OO,
so don't take my criticism as a "fundamental one",  but stating clear
and loud that those people have my gratitude and respect, I keep
crying for my daily pain with the decimal separator! ;)
best regards, and apologise for my bad english or harsh tone, not
mastering the language is a really limiting factor in harmonious
discussions.

I'm starting to feel there could be a satisfactory solution for this
in a reasonable time frame. Let the creative juices flow! :)

I'm all for a quick and effective solution now (even if it's seen as a
workaround), then a clean and profesional solution for 2.0 a year or
so later.

Greetings,
Gabriel Gazzán

P.S. ...and I too would like to stress my gratitude towards the whole
OOo development team for giving us an incredible tool!

A short reply to some:

@Andre Schnabel: iirc Niklas nebel explained, that changing the number
parsing the way you suggest is impossible, as in many countries where
the decimal separator is comma the period is used as thousands
separator. Thus "1.024" is 2^10 rather than 1 + 0,024.
The key->character remapping that is being discussed instead, can't
easily be restricted to Calc data entry in a quick solution.

@Michel Pinquier: It is clear that Excel applies this to all data
entry. Does it also apply the substitution to fields in dialog boxes?
Is the same substitution applied in Word?

@ggabriel: 
> I can assure you that everyone working in a spreadsheet will
expect ...
Firstly: not everyone is working in a spreadsheet. And the fixes being
discussed now for 1.1 will apply to all of OOo, including Writer. I am
not sure that text authors would expect a key marked with a dot to
produce a comma.
Secondly: There may be people using Spanish OOo, that primarily use
English spreadsheets (e.g. in multinational companies). Such people
will probably not expect to suddenly get a comma from their numpad.
And the preliminary fixes being discussed currently for 1.1 could not
find out the proper decimal separator for the current document, but
would deliver a comma unconditionally.

@herpey & Marco Minardi: I don't think the problem is in getting this
to work on all platforms. But with the current architecture that
information is not known in Calc, but in the windowing abstraction
layer (VCL). Thus a remapping would apply to all of OOo, including
Writer, all dialog boxes, etc..

@Marco Minardi:
As to "NO CONFIGURATION AT ALL", I explained repeatedly (e.g. in this
comment), that OOo has many users that don't use Calc often or that
use Calc to edit spreadsheets in a language different from their UI
language. This includes users that use english OOo (maybe because of a
missing localization) to edit sheets in their native language (having
decimal comma). For such users this option must be configurable. And I
maintain that the default novices encounter should be 'do as the OS does'.
As to your remaining comments: People do care. But there is not yet a
specification for a fix that (a) can be done for 1.1 without
endangering the release and (b) works for all people, not just heavy
users of spreadsheets in the UI language, if that happens to be one of
[list of languages].

Joerg:

************
@Michel Pinquier: It is clear that Excel applies this to all data
entry. Does it also apply the substitution to fields in dialog boxes?
Is the same substitution applied in Word?
************

I've just checked in Excel.
The conversion is applied just to cell input, without any context
sensitive work (i.e. if you enter "AAa.Bb" it's also translated to
"AAa,Bb"), but it's not done in dialogs (which is actually a problem
too(!), as dialogs requiring numerical input anyway expect a comma,
not a dot, as it's decimal separator but in this case you don't have
the coversion working). Anyway I think, this doesn't represent a big
problem, as there will be hardly anyone constantly inputing decimal
numbers in such dialogs as it inputs numerical data in cells. I think
the priority is more than clear.
Just anyone which don't suffer this from day to day, could spend all
this time discussing about the nuances of this, really. :)

Word doesn't have any key conversion, but if it did, I think everyone
could easily get used to it, just because nobody uses a text
processing program for heavy data entry and there is another dot in
the main keyboard, perfectly suited for this kind of *ocasional* use.

Also I think is really important to substitute the dot, not in favor
of the comma in a fixed way, but for the current country OS decimal
separator instead! That way it's not the language in which the
interface is in, but the locale in which the program is used what
determines if there should be a coma or a dot as decimal separator. 


************
not everyone is working in a spreadsheet. And the fixes being
discussed now for 1.1 will apply to all of OOo, including Writer. I am
not sure that text authors would expect a key marked with a dot to
produce a comma.
************

See above.

************
Secondly: There may be people using Spanish OOo, that primarily use
English spreadsheets (e.g. in multinational companies). Such people
will probably not expect to suddenly get a comma from their numpad.
And the preliminary fixes being discussed currently for 1.1 could not
find out the proper decimal separator for the current document, but
would deliver a comma unconditionally.
************

Two things about this VERY IMPORTANT thing you brought to discussion:
A) There is no such thing as an english spreadsheet nor a spanish
spreadsheet! It's just a spreadsheet. Numerical values are stored
internally in such a way that if you entered the data in a
french/spanish/italian/checz/etc. configurated PC, when you review it
in an english configurated PC, the numbers automatically appear in the
correct format (i.e. comas are substituted by dots). So the problem
you depict simply does not exist either Excel or Calc wise.

B) We have to admit that Excel is a little better designed than Calc
in this respect. Because Excel looks directly for the decimal
separator setting, even when the user customizes it to something
different to what's the standard for this country; whereas Calc just
seems to look at the standard decimal separator for that country and
determines based on that, not reflecting any customization done by the
user to the decimal separator field.
Anyway, I think this is not a big problem, we just need to tell the
user to temporarily change the country setting to one having the dot
as decimal separator if he/she needs to see the information that way
(I really don't see that need, because of the reason explained in
point (A), but it's there anyway if someone wanted to use it. :)

C) Also, I've found that if the OOo QuickStarter app. is active there
is no update of the decimal info. You have to manually close the
quickstarter for this change to be reflected in OOo the next time you
start it. Besides this, it works perfectly. Users should be warned
about that.

cu
Gabriel

@Joerg 
---------
Thus a remapping would apply to all of OOo, including
Writer, all dialog boxes, etc..
---------

You are right, but since ooocalc has now its own launcher, we could 
place some code there (for a quick'n dirty solution) that would 
apply only for ooocalc (under Windows, we are able to hook only the 
current process).

About the substutiuon occuring also in dialog boxes (not the same 
bahaviour as Excel). In my opinion, this is certainly a good point : 
I have always found that this behaviour of Excel was not handy, and 
I have seem other users that were rather surprised, like me. OOo 
must not imitate Excel if Excel is not user-friendly on some 
points :-)

I totally subscribe what herpey says, and I'm thinking about
contacting KDE and Gnome about the problem. The goal/meaning of the
keyboard period is "decimal separator", was just a problem of
localization (we don't discuss here why) that a lot of keyboards have
the period there. The numeric keypad's goal is to provide a convenient
way to enter numeric data. If you really need a period, you can use
the alphanumeric part of the keyboard instead.
So if you have to enter an IP adress, it's formed with PERIODS, so you
have to use the alphanumeric part of the keyboard (i.e. for
192.168.1.3). If you are requested for a decimal separator, and I find
it usefull even in Writer when I write costs or prices, you press the
decimal separator key (that is the period in the numeric keypad) or
find the correct one on the alphanumeric part (i.e. coma in italy,
period in USA, etc.).
Other behaviour is illogical, inconvenient and... wrong!
best regards

Just a word to say that Gnumeric, in its latest version, has this
remapping. The key is remapped to the decimal separator in the whole
application.

Actually, for french people, I think that the keypad dot should have
been a comma (Why in the world did the azerty kbd creator put a dot
here !) ... In any application, it is much more usual to type a dot
where you wanted a comma than the opposite.

Herpey wrote:
> 1/ I read comments like "you developers don't want to implement an 
> important feature cryed by the community". I cannot understand such 
> a clash between OpenSource developers and the User Community. As an 
> OpenSource developer, I always tried to do my best for the users, 
> and I am convinced that OpenOffice.org developers are doing the
> same.
> 
> 2/ This problem is a tough one : 
>  - from the user point of view, it is really a silly bug, and very 
> easy to fix "what easy should be to replace a point by a comma ?"
>  - from the developer point of view, this simply cannot be done 
> AFAIK easily with the current core architecture of OOo. So it is 
> considered as a major enhancement.

Well, the feedback given was rather dry and unexplicative. Read the
first answers (in this issue and in the duplicates). We feel the the
devellopers are 'unwilling' to fix this 'simple' bug/rfe because
almost no explanations were given and almost no user knows where to
look for what discussions are happening (if it is in a plublic space
at all). Which gave birth to the impression that those who answered
were saying 'This is not important' / 'I do not care' / 'This is not
my job'.

I believe there was no real user/develloper clash, but only a
perceived one for the users, caused by the lack of information. Now,
that perceived clash may foster a real one with the rise of
aggresivity - I am really happy this has not happened. Although I am
sure some people felt (and were) unjustly aggressed but wisely decided
not to react in kind. Kudos to them!


Philippe (aka Fousage)

There should be a new option (i.e. "decimal separation") under Tools /
Options effective for all applications (i.e., it is possible to edit
numbers at dimensionlines in Draw or calculate in Writer-tables). This
option (switched on) would it make possible to change the
keyboard-output depending on the selected locale setting ( currently
to be found under Tools /Options / Language Settings /Language (e.g.
Spanish)). With this option the user could use the decimal-separator
he is used to in his language via the num-pad. If the language setting
reads 'Default' the standard decimal separator of the system locale
will be sent. Note: the decimal separator itself will not be
configurable, it's really just changing the keyboard input that is
sent to the application. When this option is switched off, the
keyboard-output will be unchanged, i.e. the character code provided by
the system will be used. An addition would be to provide this option
as a toolbar button. 
Please also have a look at openoffice.dev, where we shared our
thoughts for this problem too.

"Started" great!
This seems to be a perfect solution.
Thanks very much to all the people involved!

cu
Gabriel Gazzán

Some countries has done it right: in Norway the local keyboards have
",", and not "." on the numerical keypad. Naturally if you choose
Norwegian layout for the keyboard, then pressing the numpad key that
generates "." in US layout would produce "," for any application
including OO. 

So if the default localized kayboard missed this feature, it should be
indeed a ssytem option for fix that for all applications but until it
is done at least such option should be put into OO.

Czech locale does NOT suffer from this problem. Just like Norway. 

If you choose Czech layout for the keyboard, then pressing the numpad
key that generates "." in US layout would produce "," for any application
including OO.

At least in Linux. I do not know about Windows. But in Linux, it is
not an OpenOffice issue. It is a keyboard layout issue.

I should add my 2c. 
The decimal separator in Calc is not only the key one should press to
enter a number, but at least in Windows is the decimal separator in
clipboard operations. So if one want to copy data from some cells and
insert them into other application (not OO), it is required now to
copy them to other part of the list as numbers, replace OO "," by "."
(Russian locale), copy data, delete additional text. 
So I vote for system decimal separator in OO as default settings and
the ability to change it as an option.

At least in the linux version this should be easy to solve. The events
generated for the different points are different. The one on the text
part produces the "period" key symbol, while the numpad one produces
the "KP_Decimal" symbol. Mapping the KP_Decimal onto the actual
decimal separator should be quite doable. This is with xfree-4.3.0

an issue for a solution on the 1.1 codeline has been files as issue 20181

*** Issue 20799 has been marked as a duplicate of this issue. ***

Hello Niklas, this issue has no the go to be implemented without
further  approvement. Please take this issue into your ownership. Than
you.

This will be handled in VCL, not the spreadsheet, so I reassign it to
Stephan.

I will provide the setting and react to it (ie, sending the default
separator or the locale dependent one). The dialog will be changed by
the UI team.

FT->SSA: I will work on a spec regarding this issue. This issue is
(AFAIS) duplicate with #i22152#

I don'tknow if it's too late to propose an idea or it was already 
proposed : Add an option in OOo language setup, Use "," or "." as 
decimal separator.
Depend in which language to compile, "." or "," is choosing 
automatically.

In French Win 2k, numpad "." (dot) always give a dot. When you write 
with Worpad or Notepad, the numpad "." (dot) give a "." (dot).

I also use French MS Office 97, When writing with Word 97, the 
numpad "." (dot) give "." (dot). BUT, with Excel 97, the numpad "." 
(dot) give "," (comma).

I just posted an issue about decimal point (.) which gives date type.
Test on Win2k with English OOo 1.1 and French OOo 1.1.

See issue 22725.

If you think issue 22725 is a duplicate of issue 1820 (this issue), 
close issue 22725.

At 2003-11-20 19:41, I wrote a proposal.
I've made a mistake. I've wrote "decimal separator" instead "numpad 
dot".

My idea is :
Add an option in OOo language setup, Use "," or "." for numpad dot.
Depend in which language to compile, "." or "," is choosing 
automatically for numpad dot.

*** Issue 13803 has been marked as a duplicate of this issue. ***

*** Issue 23239 has been marked as a duplicate of this issue. ***

While converting a Dutch school to Open Office I ran into this issue. The end
result when I told them that Open Office did not support inputting numbers with
the numpad is that they ordered MS Office XP.

IMHO this is not a Enhancement but a serious bug, because it breaks inputting
numbers with the Numpad. Anyway my vote has been added. 

*** Issue 23553 has been marked as a duplicate of this issue. ***

Created attachment 12216 [details]
A program to put the comma separator only while is running

I have added an attachement with a program to put temporaly the decimal comma 
on the numeric keypad. I find this progam on the net a few months ago and sorry 
but i can't find where and mentioned the Autor, who give a big thanks. At the 
moment the program runs well without bugs.

By length's program, i think not is a very complex and difficult 
implementation. (I'm not a programmer). The difficult to implement this 
modification, don't see so pretty, only affect versions different than english.

Sametimes is vefy difficult to understand, how the priorities are fixed. I 
think would be better star with a hight number of persons afected and a low 
cost of implementation.
Thanks. 

Created attachment 12217 [details]
A program to put the comma separator only while is running

It would be nice if you specify the platform for which the program was written
for (in this case, Windows).  This would avoid the need for people to downloaded
it, to find out that it is not meant for their platform (in my case, Linux).

So the problem still persist on the Linux platform.  

And I do not understand your comment: "only affect versions different than
english".  I use the english version of scalc.  Its my locale setting/keyboard
configuration that is not supported by scalc.

a program can also be found here
http://people.via.ecp.fr/~remi/win/ooovirg/ooovirg_en.php3
for windows with a solution for linux

Language found in issuezilla affected by this problem : Afrikaans (to verify), 
Basque (to verify), Belgian, Catalan (to verify), Czech (to 
verify), Dutch, French (except Switzerland ?), Galician (to verify), Italian 
(to verify), Portuguese (to verify, Portugal), Serbian (to verify), Spanish, 
Slovak (to verify).

More language ?

But, in general, which languages are concerned ?

I can assure that Basque, Catalan and Galician are affected by this issue.

I can assure Czech and Slovak

The brazilian portuguese language is affected too...

The italian (Italy) setting is affected too. On my opinion, the deafult
behaviour of OO is that the dot on the numeric keypad must be mapped into the
correct locale decimal separator, because that's the "meaning" of it. I don't
think there should be an option to make it work in a different way, like there
is no option to override num-lock or caps-lock keyboard settings, for instance.
Numeric keyboard is there to provide fast numeric data entry, and the dot there
is the "numeric separator". If the "usa centric" market has produced pocket
calculators and localized keyboards with the wrong decimal separator on the
numeric keyboard must not be used as an excuse to leave this distortion, or
consider it as "something that needs an explicit option to fix".
regards
Marco Menardi

Well, the question there is not "should this key be a dot or a comma", but "This
key is a dot. §*@~#!!! How can I work with it ?"

Excel has a solution and remaps the key,
gnumeric has a solution and remaps the key.

A friend of mine refused to drop XL for OpenCalc for this reason. For anyone
entering numerical data into a spreadsheet, this makes the software almost
unusable. Just look at the number of votes, and the number of duplicates ...

If we want to encourage people to migrate to OOo, we *must* get this fixed,
that's all.

In every OS I have seen (DOS, Windows, Mac and linux), in every word processor I
have used (from the DOS version of PC Write to the latest Windows 2000 and, of
course, many incarnations of OOo), the locale setting is a keyboard issue and
not a wp issue.  In every OS you can set the keyboard over a 100 different
locales (it wasn't over a 100 in DOS, but is in all recent OS's).  When I want
to type Spanish or German, I go to the control center (with different names in
different OS's) and change the keyboard to a Spanish or German keyboard.  Only
THEN do I open the word processor and it types as if I had that kind of keyboard.

To make it simple, I type out each key both shifted and unshifted to make a
keyboard map as writing in three languages makes it a bit difficult to remember
just where the different keys are (the worst for me is the switching of the "y"
and "z" keys in German).

To have OOo make a locale change requires several settings -- not just the
locale one.  Tools > Options > Language Settings > Languages; Tools > Options >
Language Settings > Writing Aids (Both thesauri and dictionaries) and Tools >
Options > Text Document > Basic Fonts (Western) (Make sure that the fonts
support the special characters).

Especially on this issue a growing number of users are getting fed up with this
still not completely solved problem. The Dutch mailinglist users are letting
know that they are getting tired on the way how OOo is solving bugs. It takes
too long. Especially since this issue has been known since 2001 and many users
have voted to solve this problem! If this continues more people are getting back
to MS Office. Already cases has been known that schools and companies who were
at first interested in OOo are getting back to MS Office because of this
problem. News is that this problem would be solved in 2.0 but then we've to wait
until september/october. Already we're waiting for 2.5 years!

So, let's try to convince the developers that this way of developing and bug
reports are undesirable, since problem-solving is taking too long for this. If
this is not changing, I'm afraid OOo will be disappointing for a growing number
of (wannabe) users.

Please: An issue is not a discussion forum. 

This issue has been accepted and will be resolved. Further comments inside IZ
are only disruptive to this work. E.g. if I were tasked to implement this now, I
would have a very hard time to find the comments that state what the agreed
solution is, that I have to implement.

People that complain should at least read the entire comment history to find out
what is happening and has happened. Much of this has also been discussed at
length in various mailing lists and in the Community Council. This also implies
that further lobbying should not be necessary.

Here a summary:
*This* issue is tracking a fully integrated fix within the OpenOffice.org
application. For various reasons this change could not be incorporated into OOo
1.1 nor any compatible bugfix release (the OOo 1.1.x series). Thus the target of
this issue is OOo 2.0.

Note: The correct fix is neither 'easy' nor 'obvious' as is also documented in
the preceding discussion.

There is the separate issue #20181# to track a preliminary solution for OOo 1.1.x.

There is a workaround for the problem, that uses an external tool. On windows
this is 'ooovirg' (mentioned multiple time on this list), on Linux it appears to
involve 'xmodmap'.

Issue #20181# basically states that this workaround needs to be integrated with
the OOo application in 1.1.1. That issue originally was targeting 1.1. By some
accident it was missed for that release. After that, the Community Council has
decided that #20181# (not this issue !) will be an absolute stopper for 1.1.1 so
the problem will be resolved in the next release there is.

Implemenation will be done according to
http://specs.openoffice.org/g11n/numpad_status/Setting_of_Numpad_Decimal_Separator.sxw

SSA->OS: In CWS vcl18 two new methods were added, that can be used in the dialog
implementation to enable/disable the localized decimal separator.

void MiscSettings::SetEnableLocalizedDecimalSep( BOOL bEnable );
BOOL MiscSettings::GetEnableLocalizedDecimalSep() const;

If you will not finish this task in VCL18, please create a subtask and send this
one back to me.

Hi,

the document Setting_of_Numpad_Decimal_Separator.sxw was reviewed by Czech users
and developers. We found the feature quite good. Some doubts were raised for the
inconsistency between Calc and Writer, but this is minor issue IMHO.

Thanks!

*** Issue 7467 has been marked as a duplicate of this issue. ***

cc added

*** Issue 25219 has been marked as a duplicate of this issue. ***

UI changes are checked in - 
svtools: syslocaleoptions.hxx/cxx, source/config/makefile.mk
officecfg: registry/schema/org/openoffice/Setup.xcs
svx/source/dialog/optgdlg.*

Fixed in cws vcl18 on so-cwsserv6, wntmsci8.pro, unxlngi5.pro and unxsols4.pro

It is nice of the OO people to provide a WORAROUND for this problem users 
have. But it is nothing more than a workaround and lilited to OO. 
The real solution mut be provided by means of propper keyboard layout 
definitions. Has this issue already been raise with the Linux distro's or 
XFree86? 
 
I have checked and tested 10 major keyboard layouts in my Windows98. I five  
(5) cases the keypad-del key genareted a comma the other 5 a dot. So this 
looks good. Only the Spanish and Italian keyboards are not amongst them. 
Are these keyboard definitions wrong or incomplete?  
 
In my Mandrake9.2 is see (not tested) only 3 keyboard definitions out of 10 
different from the US one.  So here definately some work need to be done. 
 
Never the less it is the keyboard definitions that must be fixed!!! 

If you read all the thread, hovel, you'll see it's not only affecting spanish or
italian keyboards.

>>Afrikaans, Basque, Catalan, French (all except Switzerland), 
>>Galician, Italian, Portuguese (Portugal), Serbian (Latin) and 
>>Spanish (all variants).
>>
>>This list may not be complete because it has been tested only on a 
>>Spanish distribution of Windows, and other languages afected may be 
>>missing.

You're right, it's due to a defective keyboard layout. But do you really think
we can change the industry of keyboard manufacturing? I'd love it, but I think
not. We MUST provide a workaround. We can always drop it in the future, if
things go better.

One of the first weapons of the free (libre) software is its localization.
Ignoring a little issue like this can result in full countries not using our
software.

Its a nice intention the idea to fix the keyboard layouts, but it does not
resolve the problem.  Some software can only take '.' as a separator.  For
instance, I use a US keyboard with US-intl layout which allows me to type
characters of all sort of latin languages.  My locale is french canadian, so in
some apps, comma is the seperator.  However, when I code, the decimal seperator
is always dot for any programming language.  Thus if you force one way or the
other for the numpad del key to be only one kind of seperator, I have a problem.

This decimal seperator has to be configurable in each application.  Its the best
solution.  So when I work under OO, its a comma, when I code in Vim, its a dot.

Checked and verified fix in cws vcl18 -> OK !

.

This is still not fixed for 1.1.1 :-((((((((((

SBA->pbielen: A look at the target milestone shows "OOo 2.0". The development of
OOo is working in FOREWORD direction, so that the "milestone order" was/is/will
be OOo 1.0,  1.0.1, 1.0.2, 1.1, 1.1.1, 1.1.2, then 1.1.3, and later ther wil be
2.0 (not fully complete, but gives a hint of how we sort numbers :-). Then
probably followed by 2.1 

This is a feature implementation that wil NOT make it in a version starting with
"1". Or time machine broke last week :-)

The simple lenght of this issue makes it a very good example of how NOT to
contribute: Making it longer by ignoring things written above. This already
happend several times a few meters of comments above. 

The comments in here sum up to more than 40 (fourty!!!) pages when pasted into a
document with 12pt font. That makes a whole book for a feature. Believe it or
not: This is hard to handle. 

So please stop commenting as the feature is in good hands and on its way.
Thank you for your comprehension.

*** Issue 22152 has been marked as a duplicate of this issue. ***

*** Issue 29701 has been marked as a duplicate of this issue. ***

*** Issue 29379 has been marked as a duplicate of this issue. ***

Problem has already been fixed in more recent 680 builds and will therefore be
closed. Setting can be adjusted under tools/options/language settings.

I do have 680M41 and I see "Decimal separator key" checkbox. But there is still
no any possibility to  select manually decimal separator from "." or ",".

*** Issue 30483 has been marked as a duplicate of this issue. ***

reopen issue.
Checkbox in option doesn't do anything.
(using a german keyboard layout, numpad returns ",")
Set language of document to english -> decimal seperator is dot ("."). 
Using the numpad, OOo still gets "," and doesn't recognize numbers. 
Toggle the "decimal seperator key" option -> no change, still "," and input
still recognized as text.

-> fix not working in 1.9m51 (linux)

ssa->pl: seems to be an issue with the gtk plugin, generic X just works fine.
the plugin must deliver a KEY_DECIMAL keycode when the numpad decimal separator
is pressed.

fixed in CWS vcl27

reopen for reassigne

pl->tm: please verify in CWS vcl27

fixed

Checked and verified in cws vcl27 -> OK !

*** Issue 31963 has been marked as a duplicate of this issue. ***

.

Today my secretary has dumpled all my spreadsheet files I converted to
OpenOffice back to Office97... and what annonyed me more is that she is right!!!
Cannot enter lots of decimal numbers with the alfanumerical comma instead of the
numerical keypad!!!

THIS IS NOT FIXED, THIS IS A PATCH ONLY FOR WINDOWS!!! PLEASE REOPEN IT AND FIX
IT INSIDE OPENOFFICE.CALC

Another set-back with this "PonComaDécimal.zip" patch. Other programs, in
particular a famous accounting application in Spain "Contaplus" does not work
with it, so it affects fatally other apps.

Again, please reopen this issue and treat it as it must be treated: inside
OpenOffice, without affecting other apps.

Please stick to the netiquette, you won't gain anything by screaming (-> use of
CAPITAL letters) around.

Please re-check on this issue.
It doesn't work on a m65 on SuSE Linux 9.0 Professional. Changing the decimal
separator doesn't affect the input in Calc.

->jferrando : Did you notice that the target milestone for this task is OOo 2.0
and did you really install a recent (developer!) snapshot of the OOo2.0 branch ?
This bug *is* fixed within OOo and does not require any additional software.
However, it is *not* fixed OOo 1.1.x.

Please keep in mind that the last change (vcl27) has not yet been integrated. I
would recommend to have a look at 1.9.m67 or later.

@jferrando:
Wait a minute: On which version are you working on?
It appears to me that you talk about a patched 1.x, is that right?
If so please do not expect any fixes. TThis feature is *clearly* assigned (as
well as its related specification) to OO.org 2.0.

ssa-> However, it is *not* fixed OOo 1.1.x.
We are using Windows2000 and WindowsXP Spanish as production desktop 
environments, OpenOffice 1.1.3 Spanish in Windows (production/limited trial) 
and in a Suse Linux 9.2 test environment.
I does not work in 1.1.3 for Windows and Suse.
I will test 2.0 preview release.

There is a good reason why it does *not* work in 1.x:
It is *not* a feature in 1.x and it will never be.
If this was addressed by some inofficial patch than this has nothing to do with
this IssueTracker issue.

ES->SSA: I'm sorry to reassign it back to you but, as Falko noticed, this
feature does not appear to work at least on Linux (SuSE 9.1). I've done
following test:
- set in term 'export LC_ALL=fr_FR' and 'export LANG=fr_FR'
- verified with 'locale' -> all are fr_FR
- switched the keyboard to French
- started from this term OOo m65_8850
- started Calc and Writer
-> in both applications, the decimal sign of the num pad was outputting a period
while a comma is expected.

Did I miss something?

Yes, you miss this:

------- Additional comments from st Tue Dec 14 01:17:14 -0800 2004 -------

Please keep in mind that the last change (vcl27) has not yet been integrated. I
would recommend to have a look at 1.9.m67 or later.

---------------------------------------------------------------------------

y jferrando@, antes de escribir por favor lee todo el tread, te evitarás
escribir demás. Y por favor pide las disculpas del caso, tu exabrupto no tiene
pies ni cabeza.

Sorry 1000 times!
Reassigning to QA owner.

TM: This issue has been fixed for OOo 2.0 and integrated in a 680m57 build ! It
works fine as designed (spec.:
http://specs.openoffice.org/g11n/numpad_status/Setting_of_Numpad_Decimal_Separator.sxw).
However, the checkbox on tools/options/language settings/languages -> use locale
settings may hang sometimes and needs to be unchecked and checked again (another
task exists for this problem). So this is set back to fixed, verified and closed !

.

.

reopen issue.  (All test performed with m73)

Only fixed partially.
When using plain X -> everything works as expected.

But when using Gnome/GTK, the feature only works in one direction.
When numpad-key sends KP_Seperator (","  - for example german keyboard layout),
everything works as expected. I can change the regional settings to "English
(USA)" and depending on whether I check the box or not, the "," gets replaced by
the "." (option checked) or it keepts the "," (option unchecked).

But when numpad-key sends KP_Decimal ("." - for example english keyboard layout)
I always get the "." no matter what settings I choose. (switch regional settings
to German (seperator would be ",") but OOo still enters "." no matter whether
the box is checked or not -> number recognition doesn't work).

I guess this is because in vcl/unx/gtk/window/gtkframe.cxx only the mapping for
 GDK_KP_Separator -> KEY_DECIMAL exists, but  not for GDK_KP_Decimal.
In vcl/unx/source/app/saldisp.cxx the mapping exists for both XK_KP_Seperator as
well as for XK_KP_Decimal

So please check again. (Please also check Windows since on IRC the function was
mentioned to fail as well (numpad sends "." -> reginal setting requires "," but
OOo doesn't change "." to ",")

I opened issue 41403 for the gtk problem.

In addition to what cloph said, I've done some tests again, with Win2K and
m71s1, and "paolom", a friend of mine in #openoffice.org-it, with m69 under
Slackware 10.

Seems to be not a code-translation problem, but the ability of keeping and using
the set value:

load calc -> disable "same as locale setting" -> OK button -> exit calc (not
saving the spreadsheet)
load calc -> enable "same as locale setting" -> OK button -> it works -> exit
calc (not saving the spreadsheet)
load calc -> does NOT work, even if the flag is still checked (enabled)

I've NOT enabled the "pre-loader OOo" (sorry, I don't remember what is the name
of the icon on the system try that pre-loads some part of OOo).

So seems that the value is loaded by the Language dialog, but not by the program
 itself, except when exiting from the Language dialog.

In addition, I would suggest to change the label of the option from "same as
local setting" to "convert to local setting".
thanks

The problem with the dialog is fixed in issue 39040, which is, however, not yet
integrated.

I use M74 and still see the problem: OO doesn't look for the Windows decimal
separator settings. It determins the ',' from the Russian locale although
Windows has '.' as the decimal separator.

> OO doesn't look for the Windows decimal separator settings. It determins the 
> ',' from the Russian locale although Windows has '.' as the decimal separator.

? But this is the whole point of the fearure. No matter what the keyboard sends,
 if the option is activated OOo will use the seperator defined using the locale
settings.

Since this works and no one else responded to my postings to the dev@qa and
other lists regarding windows, I consider this working and thus resolve the
issue again.

Main feature is added and working (for those cases where this fails there are
seperate issues) -> verifying.

closing again.
If you find out about other problems concerning this feature, please file a
seperate issue and post the ID to the issue here.

*** Issue 41987 has been marked as a duplicate of this issue. ***

*** Issue 44516 has been marked as a duplicate of this issue. ***

*** Issue 47105 has been marked as a duplicate of this issue. ***

I download this program to fix this. It put the comma when I write a decimal 
numbers. But the spreadsheets recognize this element like text, not a number.
Other issue: I have a laptop and I have not numerical keyboard. ¿What I do?

Dan,

Which program are you talking about? the attachment or OOoVirg which you can
find in the program directory of OOo's installdir? OOovirg is supplied to
compensate for LOCALES that use comma as a decimal separator but the users have
only a US-style keyboard.

I just tried this: set the Locale to Dutch, and type 1.3 in a cell.
Result: it converts it to 01-03-08. So IMHO it is still not fixed.
I think that outside Germany there's nobody in the world that would
interpret 1.3 as a date. So even if I could disable this behaviour,
(I don't know how), I don't think it should be the default.

bbouwens: apparently you didn't read this issue/don't know what this issue is about.
Dutch uses the comma as decimal operator, so when you enter "1.3" it is not a
number, but parsed as a date instead. This was the behvaiour and wasn't changed
by this issue at all.

What changed is: If you enter 1<numpad-"dot/comma">3 - then you'll always get
the decimal seperator of the defined reginal setting, no matter whether the key
on your numbad sends a . or a ,
With dutch locale, you would get 1,3 - with english locale you would get 1.3 

When you explicitly enter a dot, then you would get a number in an english
locale only (in locales that uses a dot as decimal seperator).

So: This change only affects the "dot" on the numpad.

PS: Dutch != Germany - but decimal seperator in the Netherlands is , and not . -
just like in Germany. Either use the numpad or use the comma explicitly

Oh, yes, I did read that, and I do understand what is fixed 
here. Nevertheless, several *other* tickets are closed as
being a duplicate of this ticket, while they explicitly
address a different issue, namely that 1.3 is converted to
a date, which is totally illegal in most locales.
E.g. ticket 7467, which doesn't mention the numeric keypad at all.
Obviously, when 1.3 can not be a number because the decimal separator
is a comma, it can not be anything else than text. Not date, never.

First text available in this issue wrote:
"...Some spreadsheets like excel overrides the system default character for the
dot of our numeric keypad outputting a comma..."

Dot is dot! Comma is comma!

Why the hell we need change dot to comma?

If your keyboard have a dot printed on key, correct output is really a dot (and
not a comma).

If your country use comma as decimal separator, so BUY a keyboard with comma in
numeric keypad.

And I really don't understand why when I type 1.03 OOo Calc convert this to date
(01/03/08). Never 3 number with dot (1.03) can be a date!

Best regards,
Renato S. Yamane
Brazil

renatoyamane, you must be the only one that hasn't understood this issue in
seven years. Maybe in your country you can choose what character generates each
key of a keyboard, but not in Spain (there is ONLY a dot there on a spanish
keyboard). ¿An ancient design error? Maybe, but this is what we have, and
OpenOffice.org staff thinks so.

Hi drspock2k,

Here in Brazil we can find a lot of keyboard with comma and dot on numeric keypad.

But in OOo, when I press dot, I get a dot (this is correct), but when I press
comma (in same keyboard), I get a dot (ridiculous)!

Correct:
Press comma key = Get a comma output
Press dot key = Get a dot output

Best regards,
Renato S. Yamane

So it sounds like OpenOffice.org needs to be smart enough to determine what the
keyboard actually has available and not always override the keys.

If an user have a numeric keypad only with DOT and your caountry use COMMA as
decimal separator, he can (with Linux) use xev to capture keycode and use
xmodmap to change keysym.

OOo need show us output as printed in keys.

If my keyboard show me a DOT, give me a DOT when pressed.

If my keyboard show me a COMMA, give me a COMMA when pressed.

If an user need other output as printed on keys, edit keymap himself, or buy a
correct keyboard (with COMMA and not DOT, or with COMMA and DOT - All this in
numeric keypad).
http://www.microsoft.com/spain/hardware/mouseandkeyboard/productdetails.aspx?pid=040

Best regards,
Renato S. Yamane
Brazil (yes, here we use comma as decimal point, and I buy a keyboard with COMMA)

You don't get what this issue is about. Users keying in numbers with the numeric
keypad expect the separator to match the one used in their locale. For some
languages the keyboards on the numeric keypad do not have the decimal separator
that is used in the locale, and there are no other keyboards available for that
language, and not all users are capable to properly use xmodmap or similar tools.

By default OOo will deliver the decimal separator matching the locale that is
set. For Portuguese in Brazil (pt-BR) this happens to be a comma. If you do not
want that behavior but want whatever character is delivered by the keyboard,
simply uncheck the option under Tools->Options->LanguageSettings->Languages
"Decimal separator key".

Closing again.

I accept your resolution, but don´t agree.

- If your keypad have printed a dot over key, OOo need show me a dot when
pressed. The problem is not with OOo but with YOUR KEYBOARD.

- All brazilian standard keyboard have dot AND comma in numeric keypad.

- If you buy a US Standard keyboard and try use in Brazil, the problem is YOUR
(you are doing wrong buying a *En-US* Standard and using in BRAZIL), and not
with OOo.

- And is not true that "...there are no other keyboards available for that
language..."
This is absolutely wrong.

OOo default need be: Show me character as printed in my keyboard!

If your numeric keypad don´t have COMMA and you need it, go to:

This is an example:
"Tools -> Options -> LanguageSettings -> Languages -> and set "I use an En-US
numeric keypad but my country don´t use En-US standard (choose this if you need
change DOT in your numeric keypad to COMMA)"

Best regards,
Renato S. Yamane

Renato, you don't understand me.

I'm not using an en-US keyboard. Here nobody uses it. The fact in Brazil you can
choose a keyboard with a dot or with a comma doesn't mean you can choose it
around the world.

There is only one kind of es-ES keyboard, and it comes with a dot (damn!). This
discussion is a nonsense in a closed issue, and I will not answer here again. If
you want, you can create a new issue to revert this one, or you will be welcome
in Spain if you want to come here and see our keyboards for yourself.

Yes, I understand you... But you don't understand me :-)

- If your NUMERIC Keypad have a dot/period instead of comma, it is an En-US
NUMERIC layout. Because there, DOT is more useful than COMMA.

Default OOo Seting need be: "Output is what is printed in each key".
If a key show a DOT, give me DOT when pressed.

AND, to fix YOUR problem OOo need an option to be set: "My NUMERIC Keypad have
only DOT key, but I need change it to COMMA".

This setting never can be default, because DOT is DOT... COMMA is COMMA.

Best regards,
Renato S. Yamane

And now, using Ubuntu 9.10 and OpenOffice 3.1.1 (OOO310m19 Build 9420)
the problem continues...

With ABNT2 keyboard, in the numerical keypad, if I press DOT "." or COMMA ","
all I get is COMMA ","

And I understand it was a "feature request" some years ago, but it makes
no-sense. Comma should be comma, dot should be dot. The OOo behavior (give
comma, no matter what the user typed) as a hard-coded solution, isn't a good
solution....