Apache OpenOffice (AOO) Bugzilla – Issue 51662
Read separators and formats from Windows Regional Settings.
Last modified: 2017-05-20 09:45:01 UTC
I have dot as decimal separator in my Windows. This is the common situation for Russian users, at least those concerned with programming. My Windows has Russian locale. OO has ',' as decimal separator for Russian locale at the same PC. This is the reason for several problems, including inability to exchange OO spreadsheet data with any other Windows application via clipboard - they interprete each other's data as text. The only way I know to have OO used '.' as decimal separator at Russian Windows is to change the OO locale to English UK as a workaround. Many Russian users solve the above problem in this way. The one and only problem is: OO DOES NOT USE SYSTEM DECIMAL SEPARATOR. It reads its decimal separator from its own setting for the language locale and IGNORES the system settings. This leads to incompatibility of clipboard data, cvs files, absence of common interface.
I get the same on German WinXP. Steps: 1. Set dot as decimal separator in the WinXP language settings. 2. Set German as local in OOo. 3. Open Windows calculator and type 12.06 4. Copy number from the calculator via Crtl-C to the clipboard. 5. Open an OOo-spreadsheet. 6. Paste the clipboard into a cell. You will get a date 12.06.05. If I insert it into an Excel97-spreadsheet, I get a number. This issue is related to issue 1820 and perhaps a duplicate to issue 45312 or issue 31663. But this issue adds the aspect of exchanging data via clipboard, whereas the others focus on entering data via keyboard. I don't know how OOo is designed, but this is probably an enhancement.
FT: That's true. OO.o 2.x does not read out decimal and 1000s separators from the system. Set to later as an enhancement.
Excuse me for interrupting, but I've had this issue for a long time and find it utterly annoying. I'm French, so my locale is French-UTF8, and I have KDE configured to use the dot '.' as a decimal separator. Being a programmer, I'm allergic to using the ',' as a decimal separator, and OpenOffice forces me to do so, or use Number Format everytime I want a number to display correctly. My numpad generates a dot so it breaks. Also, I had to customize every single program I use that generates CSV files for importing into OpenOffice, to generate them with commas instead of dots. This is the most annoying part, which is not covered by the comments on this bug, While it is possible to use Number format on an existing cell, it's not possible to do so when opening a file. This is not an "enhancement" or whatever, it's a serious bug that breaks file import and export. If reading the configuration data is too complicated, at least, please, can we have a global preference for number formats (kind of a default 'cell options') so that I can specify this once and for all, and import CSV files without having to replace dots by commas ? Please ?
First time I've posted this issue as http://qa.openoffice.org/issues/show_bug.cgi?id=3766 It happened on April, 2002 ! It was ignored and marked as duplicate of another bug - NOT THE SAME. I've written it, but gained no attention. The same for my issue http://qa.openoffice.org/issues/show_bug.cgi?id=42802 and the common issue http://qa.openoffice.org/issues/show_bug.cgi?id=31663 It is definentely a bug, not enhancement. But the developers ignore the problem all the time.
FT: I'm leaving so I will re-assign this issue to requirement default user
*** Issue 63049 has been marked as a duplicate of this issue. ***
See to issue 64450. I think, that decimal separator in OOo need correction and I suggest issue 64450 as solution.
Changing issue type to "DEFECT", because specified functionality ("Decimal separator key" - "Same as localle setting") is not functional.
Kpalagin, You're confusing the OOo locale settings with the Windows regional settings. The "decimal separator key" option works according to OOo's locale data setting as intended. Changing type back to enhancement, or even better feature, as inheriting the system settings would be completely new functionality.
*** Issue 58530 has been marked as a duplicate of this issue. ***
ER, he isn't. every well-written program draws locale settings from the system instead of reinventing the wheel. this is what OOo basically does. So it's a defect for sure!
*** Issue 84414 has been marked as a duplicate of this issue. ***
Estimated effort for this is quite high, at least ~30 days. Roughly needed are: read Windows settings, merge to locale data, merge to number formatter, provide means to detect that a used format is a system format, store as usual format in document file, when loading on Windows match the system's format, else use stored format.
*** Issue 7434 has been marked as a duplicate of this issue. ***
*** Issue 31663 has been marked as a duplicate of this issue. ***
Isn't issue 25942 "standard date format not taken from the system properties" a dupe of this issue? Issue 25942 is a DEFECT. That's what this issue also should be.
*** Issue 25942 has been marked as a duplicate of this issue. ***
Not a windows-specific bug (or feature). In Ubuntu 8.04.1 I have modified locale: LANG=ru_RU.UTF-8 LC_NUMERIC=en_US.UTF-8 but OO anyway wants to use ',' as "system decimal separator", instead using '.'.
IMHO the best option would be to handle it, as it is in MS Excel. There you can set directly the decimal and thousands separators (see attached screenshot), also notice the wrong tooltip in OOo, according to the post from er from Jan 10 2007. If there is currently no feature request on this I will submit one.
Created attachment 62955 [details] Language Settings in MS Excel 2003 versus OOo 3.1 Calc
As you can see in other issues which are declared as duplicate the problem concerns not only the separators. So the solution can IMHO only be that OOo uses the system settings.
@famo: the tooltip in the Options' dialog is almost correct. The option is not about overriding the locale's decimal separator, but which character the separator key on the numeric keypad should produce, because some countries' keyboards have a broken design to this regard. The tooltip shouldn't say "set in your system" though, but "set in OpenOffice.org" instead. @jolatt: we need both, use system settings, and be able to override it in OOo.
I guess one of my next pet peeve long term projects will be to build up a "system locale". Reassigning to spare time account. Issue 102517 is related.
*** Issue 103213 has been marked as a duplicate of this issue. ***
*** Issue 95969 has been marked as a duplicate of this issue. ***
FYI As I've announced earlier (see comment above ;-), I opened now an Issue which is solely about changing directly the separators, without regard to any locale settings. I opened the other Issue because, IMHO, its easier to solve than this one (this here is platform depended, the other not) and the other one has a more universal approach, which fix would lead to more options, including a workaround for this issue (this here is a rather a convenience feature, which wouldn't fix my needs). If I made you curious ;-), check it out: Issue 106961 and of course I encourage you to vote for my issue. :-)
*** Issue 45312 has been marked as a duplicate of this issue. ***
*** Issue 40036 has been marked as a duplicate of this issue. ***
*** Issue 111495 has been marked as a duplicate of this issue. ***
Add me to CC
*** Issue 112073 has been marked as a duplicate of this issue. ***
Currently this issue have 206 votes. It is mean place 7 in the votes rating (via issues query page). "Official" dublicates have 19 votes. It looks like other issues (non dublicates) are linked to this at real: 49978, 64450, 106961, 108059. This issues totally have 33 votes. So why is this issue ignored 8 years already (one of the real dublicates was created at 2002!)?! It still don't have real target milenstone. As i understand it mean "we don't plan do anything with this issue". BTW, other issues with more votes don't have real target milenstone too. So does this voting have no sense at real and only for fun? Then maybe it is better to remove this useless (for users) voting from the system? At least issues interface will be simplified...
+1
Quote: "Additional comments from er Wed Aug 20 08:56:50 +0000 2008 ------- Estimated effort for this is quite high, at least ~30 days." IMO, we have a lot less "expensive" and a lot more important issues to fix before this one. (For example, our 89232 (do not fill hidden rows) looks like a lot easier to implement, yet it is much more damaging to our image).
Did not know about this "Erroneously filled autofiltered fields" from 89232 issue. And, yes, it looks important, long-lived and image-damaging bug. But there are workaraunds - you may use cut and paste instead of using mouse. This "decimal point" issue has no workaround - you just can not use Calc for exchanging data with other software, not say about filtering/autofiltering it. And by the way, it has more than twice more votes (208 + 33 related issues) than 89232 (95 votes). So it is twice more important for _users_ than "damaging developer's image" 89232 issue. In my opinion, 51662 (or at least 106961) is the single most important flaw that Open Office Calc has and it is the main reason why our company still does not migrate to OO from MSO.
Asmol +1 It is true. kpalagin, how can you say that issue 89232 "lot more important" if it has less votes and has workaround? About 30 days: for me (and i think for most of users) it will be ok if you provide any normal workaround what take less than 30 days to be implemented. We don't need cool and pretty solution - we need ANY solution. For example, i see next "workaround": create special "custom" locale additionally to existing ones. This "custom" locale settings may be stored in special file (as xml for example). So user will be able to configure it as needed (including decimal separator sign) in this file. Sure, better to have special tool (or dialogue in OO interface) to configure this "custom" locale. Such "workaround" is not so comfortable but will resolve all problems about non-standard locale settings and for me it looks like time needed for implementation is much less than 30 days. Because this solution don't need changes in handling of locale by OO and don't depend on many different OS. It need only mapping between existing locale structure and some file (xml). I'm sure that the developers already have such mapping. And adding such "custom" locale into existing list of locales isn't so big task too (from my understanding). Another thing about "lot more important issues": important for whom? Users or developers? And OO is for users or for developers? I understand that there are some critical bugs (related to security or data lost etc.) and maybe non-critical but very important bugs (related to performance, compatibility, standards etc.). Some issues need more effort and other - less. There are some interesting issues (for developers)...But from my view if issue is not critical then the best way to determine its priority is to ask customers/users. I expected that issue votes are specially for that... But it looks like you invite users to calculate importance of issues via votes... and ignore them. I think many of users expect that their vote mean something but... You just show your "respect" to your users. Maybe better to say "We don't care about users voting and we know better what is good for them" and remove voting from issue tracking. It will be clear and understandable. Microsoft did soft in this way many years and got good results. And is it really good that some small and not so important issues are done quickly but many users still can't use OO normally? It is good that i'm able to zoom spreadsheet quickly in Calc but i have nothing to zoom because i'm not able to put data normally into Calc. And i should to use Excel instead of OO. So should 30 days be determinative to not resolve issue? About Issue 89232 - sure it is important too but less because of less votes. And for me it show that it should be another article created about 8 years old issue (and currently in 10 top wanted) to make it "lot more important"...
One more... If issue issue 89232 is more important then why is it still in status "NEW"? Why "Embedding of SVG graphics" (Issue 49991 ) is in plan for OO 3.3 even if it has less votes than current one and sure it is not about influence on existing data as issue 89232? Can anybody from OO stuff describe such decision? I think many people who vote for current issue want to know developers (or Oracle?) point of view on what is needed for users?
@hev: No doubt that many developers want to - and also do - support wishes of 'users' Have you any idea how many people are paid a normal salary because they work on openoffice.org and thus make our free software available? Decisions that support the health and wealth of sponsors of OpenOffice.org, are seldom visible in the votes in IssueTracker. I bet you!
Just added my two votes for this (although I really care more about being able to set a default date formant than the separator, which doesn't affect me). "------- Additional comments from er Wed Aug 20 08:56:50 +0000 2008 ------- "when loading on Windows match the system's format, else use stored format." Don't ignore Linux. I want the settings from MY locale used (I have patched glibc with custom changes and recompiled). Why shouldn't we be able to set date formats and separators, as well. It is insane that this hasn't been fixed after all of these years. Thirty days seems high, but why can't you (for example), get Google Summer of Code project for this (there are probably plenty of people in Google affected by this, so I imagine they would be very happy to approve it :) ).
One more year. All is the same... Yeah.. "Decisions that support the health and wealth of sponsors of OpenOffice.org, are seldom visible in the votes in IssueTracker. I bet you!" I don't have own business to be a real sponsor who is not seldom visible but are health and wealth... So maybe you just say how much money do you need to fix this issue if problem are in salary? At least be patient to this question taking into account age of issue and still in top-10 votes.
In our company we ended up taking the source code, changing locale definition and recompiling the whole thing. So we have our own "fork" of OO.
Possible solution for company. Even taking into account that you will need to recompile each time after OO update. But few years ago I proposed to use OO for many usual people working in non-IT companies. Some of them already going back to pirate MS Office because of this problem... Such kind of resolution is ok for IT companies only... or if you as programmer are ready to support all your friends :)
*** Issue 121622 has been marked as a duplicate of this issue. ***
Duplicate of bug 106961. *** This issue has been marked as a duplicate of issue 106961 ***
(In reply to Edwin Sharp from comment #44) > Duplicate of bug 106961. > > *** This bug has been marked as a duplicate of bug 106961 *** You must be kidding. That newer bug (106961) has only 12 votes, while this one has collected 226, as of today. Also this bug has more history in comments and more interested users in CC. What's the rationale of closing this bug in favor of less popular bug 106961?
(In reply to Max Lvov from comment #45) > You must be kidding. That newer bug (106961) has only 12 votes, while this > one has collected 226, as of today. Also this bug has more history in > comments and more interested users in CC. What's the rationale of closing > this bug in favor of less popular bug 106961? The information in this bug is not lost but supplements all other bugs concerning this specific topic. In newer bugs, chances are author and commentators are more involved. Bottom line, duplicates are not allowed.