Apache OpenOffice (AOO) Bugzilla – Issue 7467
Q-PCD relevant: Dot vs. Comma in int'l keyboard layouts
Last modified: 2013-08-07 15:15:02 UTC
I'm french, so, supposed to use a comma as a decimal separator (like "1,2" and unlike "1.2"). When I make the mistake and type "1.2", OpenOffice.org converts it into a date (e.g. "February 1st"), and changes the format of the cell from number to date. This is very enoying to cancel. This is a nice feature, but it should be possible to disable it. Anyway, I think that "1.2" should always be interpreted as a number, even with french locales. [My father refused to move from XL because of that feature :-( ]
also in german version; probably in all european versions 1.0 becomes 01.01.00 for example and this isn't really reasonable. + it's uncomfortable to change the mask back. So keeping this behaviour will be unwanted in most cases. Or (/and) use the warning technique as in issue 7185. The window could then contain a tick field "don't recognize this as 01.01.00 in the future" next to the things mentioned in above issue.
*** Issue 7341 has been marked as a duplicate of this issue. ***
1.0 ->perhaps Jan.2000 1.2 ->perhaps Jan.2nd or 1st.Feb consistency? No, standard cell mask is number mask "Standard", so conversion is defect.
Hi Matthieu, this is not a bug but could be seen as an RFE. So I set the flags. Frank Hi Falko, 1 4 u
I'am french too. My french-layout keyboard has a numeric keypad with a dot as decimal separator, as most french users, I guess. But by default when you're french (and most other non-us settings are the same) Calc _requires_ a comma as decimal separator. Like described in this issue, if I try to enter decimal numbers with my numeric keypad, which is the most basic operation one wants to perform with a spreadsheet program, they are either recognized as text or converted to dates. But this also happens if you import data or use copy-paste from another program. Note that the date conversion is irreversible : if you reset it as "number" format, you don't recover the value. I know there are a few workaround for this problem, but they are _very_ anoying to implement. Ooo just should not behave like this, period. BTW the date format with dots (eg 29.11) is absolutely uncommon over here since it would normally be mistaken for a number. We rather use dash or slash. So this conversion should not trigger unless two dots appear in the "number". I am surprised this is not recognized as a bug. All right, the code behaves as designed, but then the design is wrong. For me it's obvious that it is a very serious _bug_ since it makes Calc unusable for the vast majority of non-us users. Try for yourself to convince someone that this is not a bug... For as long as this problem persists (643 still has it), non-us people will stick with excell without a doubt. It needs to receive serious and rapid attention.
I agree with Philipe. Don't use that old "This is not bug, it's feature". But truely, if you have a cell of type number, and if you type 1.2 in it, EVERYBODY will expect it to be interpreted as a number, as it is the type of the cell. (keep in mind that the . is where you expect to find a decimal separator in the numeric keypad of french keyboards ...) Probably the best solution is simply to allow the dot as a decimal separator in any locales, as MS XL does.
I want to join to insist on the seriousness of this problem that: (1) prevents one to fully use the keypad to enter numbers, which is really tiring; (2) cause the accidental input of totally wrong numbers, as a faulty number is converted in a date-number even inside a formula in a cell formatted as a number (not a date). As using the keypad's dot does work in every other software I use (and I think that this is the case for most other people), I often make the mistake and this makes Calc really awkward to use... Too awkward to use. Philippe (aka Fousage)
The dot vs. comma on the numeric keypad is day-to-day annoyance for scores of users of localized versions. For instance, since its origin about one year ago, the users_fr@lang.openoffice.org forum has received about 120 messages on this topic, and it is of course one of the FAQs. 120 may not seem a lot, but don't forget it's not specific problem with the fr version (see Lars' post above). Obviously some people are spending a lot of time fighting this little oddity of OOo. I'm afraid many would-be users do not even try to fight and may just think that if such a basic thing is not working "naturally" then the rest must really be terribly bad...
I /may/ try to fix this if I have time. Can anyone give me an advice of how to do this ? Where is it implemented ? Thanx.
this issue is not a duplicate of #1820 (the most voted-for issue), but it is closely related with it. I guess they could both receive a same fix.
*** Issue 8695 has been marked as a duplicate of this issue. ***
changed title and target
*** Issue 22725 has been marked as a duplicate of this issue. ***
*** Issue 23945 has been marked as a duplicate of this issue. ***
Language found in issuezilla affected by this problem : Belgian, Czech (to verify), Dutch, French, Spanish (to verify), Slovak (to verify). More language ? But, in general, which languages are concerned ?
This is not just an enhancement, it's a serious bug! I'm Dutch, and I can assure you that under no circumstances something like 1.2 can be interpreted as a date in the Dutch locale. 24077 closed as being a duplicate of this bug.
*** Issue 24077 has been marked as a duplicate of this issue. ***
Maybe, issue 20181 (Provide temporary fix for comma / dot on Keypad) and issue 1820 (Inputting decimal numbers with Spanish (Spain) keyboars in StarCalc) should be resolved first (And I hope very quickly). And after, see how "." (dot) should be interpreted in French, Dutch, Spain, German,... Text ? Date ? Decimal value ?...
FT: Spec written and put to http://specs.openoffice.org/g11n/numpad_status/Setting_of_Numpad_Decimal_Separator.sxw
As bug 1820 has an older history and is about the same subject, I will close this one here. The pointer to the spec can be found in bug 1820 as well. *** This issue has been marked as a duplicate of 1820 ***
closing duplicate
If you read the original description of the issue, it is not about the keypad, so it is not a duplicate of issue 1820. When you type 1.2 on locale French/France (where decimal separator is ",") in Excel the Standard formating maps to text. However in OOo you input is translated to a date : 01/12/2008. The date separator in France is '/', not '.'. Of course, combined to issue 1820, this make the user crazy. But, please, don't mix the issues: they are different problems that require different solutions. Bug verified on OOo 2.3 on Ubuntu 7.10 and reported there as bug 163809. https://bugs.launchpad.net/ubuntu/+source/openoffice.org/+bug/163809
added cc self
Please, reopen the bug. It is still valid. I reported it as present in OOo 2.3 on Ubuntu 7.10 here: https://bugs.launchpad.net/ubuntu/+source/openoffice.org/+bug/163809
The summary should be changed to "OOo Calc auto corrects decimal numbers with dot to dates". On locale fr_FR, the decimal separator is ',' and the date separator is '/'. There is no reason to convert "19.4" to "19/04/2008".
I kind of support this. It appears that ticket 1820 is `solved' by having the '.' key on the numeric keypad produce a ',' now. I never use the numeric keypad, I just use the normal decimal keys, for me that's easier. When I enter 1.3 it is still converted to a date, which IMHO is still broken (in the Dutch locale at least). The same behaviour I used to observe when importing CSV files, which has obviously nothing to do with keyboards. This I have also verified today on version 2.3.0
Why the hell 1.2 is converted to February 1st? 1.2 is 1.2 I think that we need reopen this bug report, because OOo can not change what I type! If I type 1.2, leave my input as 1.2 If I have two 2 colluns: Car ............ Enginee(cc) Ferrari ........ 5.8 OOo AUTOMATICALY convert this to: Car ............ Enginee(cc) Ferrari ........ August 5 Best regards, Renato S. Yamane
To renatoyamane: I think that this issue inst about autoconvert text to date. If do you want correct go to issue 33723 and vote for it.