Apache OpenOffice (AOO) Bugzilla – Full Text Issue Listing |
Summary: | Inputting decimal numbers with Spanish (Spain) keyboars in StarCalc | ||||||||
---|---|---|---|---|---|---|---|---|---|
Product: | Calc | Reporter: | drspock2k <dr.spock> | ||||||
Component: | ui | Assignee: | thorsten.martens | ||||||
Status: | CLOSED FIXED | QA Contact: | issues@sc <issues> | ||||||
Severity: | Trivial | ||||||||
Priority: | P3 | CC: | bijumaillist, falko.tesch, issues, jesus, joerg.barfurth, khendricks, khirano, lohmaier, maho.nakata, maison.godard, ooo, ooo, pavel, stephan_schaefer, stx123, t8m, tom, wouter, yoshimit | ||||||
Version: | OOo 1.0.0 | Keywords: | oooqa | ||||||
Target Milestone: | --- | ||||||||
Hardware: | PC | ||||||||
OS: | All | ||||||||
Issue Type: | ENHANCEMENT | Latest Confirmation in: | --- | ||||||
Developer Difficulty: | --- | ||||||||
Attachments: |
|
Description
drspock2k
2001-10-07 23:10:01 UTC
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.... |