Issue 51662 - Read separators and formats from Windows Regional Settings.
Summary: Read separators and formats from Windows Regional Settings.
Status: CLOSED DUPLICATE of issue 106961
Alias: None
Product: Internationalization
Classification: Code
Component: localedata (show other issues)
Version: 680m113
Hardware: All Windows, all
: P3 Trivial with 225 votes (vote)
Target Milestone: ---
Assignee: erack
QA Contact:
Keywords: oooqa
: 7434 25942 31663 40036 45312 58530 63049 95969 103213 111495 112073 121622 (view as issue list)
Depends on:
Blocks: 70003 84414
  Show dependency tree
Reported: 2005-07-07 09:50 UTC by bigserpent
Modified: 2017-05-20 09:45 UTC (History)
15 users (show)

See Also:
Issue Type: FEATURE
Latest Confirmation in: ---
Developer Difficulty: ---

Language Settings in MS Excel 2003 versus OOo 3.1 Calc (47.89 KB, image/png)
2009-06-13 01:19 UTC, aoo-bugger
no flags Details

Note You need to log in before you can comment on or make changes to this issue.
Description bigserpent 2005-07-07 09:50:22 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.
Comment 1 Regina Henschel 2005-07-07 13:42:55 UTC
I get the same on German WinXP.
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.
Comment 2 falko.tesch 2005-07-08 07:13:15 UTC
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.
Comment 3 peufeu 2005-09-07 18:58:03 UTC
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 

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 ?

Comment 4 bigserpent 2005-09-08 07:52:50 UTC
First time I've posted this issue as
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

and the common issue

It is definentely a bug, not enhancement. But the developers ignore the problem
all the time.

Comment 5 falko.tesch 2005-10-20 20:41:47 UTC
FT: I'm leaving so I will re-assign this issue to requirement default user
Comment 6 Regina Henschel 2006-03-11 23:40:45 UTC
*** Issue 63049 has been marked as a duplicate of this issue. ***
Comment 7 vaclavik 2006-04-18 13:53:09 UTC
See to issue 64450. I think, that decimal separator in OOo need correction and 
I suggest issue 64450 as solution. 
Comment 8 kpalagin 2007-01-10 12:23:43 UTC
Changing issue type to "DEFECT", because specified functionality ("Decimal 
separator key" - "Same as localle setting") is not functional.
Comment 9 ooo 2007-01-10 15:24:59 UTC
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.
Comment 10 frank 2007-06-08 14:18:31 UTC
*** Issue 58530 has been marked as a duplicate of this issue. ***
Comment 11 Michael Osipov 2007-06-08 18:48:09 UTC

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!
Comment 12 kpalagin 2008-01-09 13:45:01 UTC
*** Issue 84414 has been marked as a duplicate of this issue. ***
Comment 13 ooo 2008-08-20 09:56:50 UTC
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.
Comment 14 ooo 2008-08-20 09:57:20 UTC
*** Issue 7434 has been marked as a duplicate of this issue. ***
Comment 15 ooo 2008-08-20 10:01:35 UTC
*** Issue 31663 has been marked as a duplicate of this issue. ***
Comment 16 Robert Pollak 2008-08-20 20:54:24 UTC
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.
Comment 17 ooo 2008-08-20 22:30:33 UTC
*** Issue 25942 has been marked as a duplicate of this issue. ***
Comment 18 gimly 2008-08-21 14:28:41 UTC
Not a windows-specific bug (or feature).
In Ubuntu 8.04.1 I have modified locale:
but OO anyway wants to use ',' as "system decimal separator", instead using '.'.
Comment 19 aoo-bugger 2009-06-13 01:17:53 UTC
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.
Comment 20 aoo-bugger 2009-06-13 01:19:57 UTC
Created attachment 62955 [details]
Language Settings in MS Excel 2003 versus OOo 3.1 Calc
Comment 21 jolatt 2009-06-13 08:26:01 UTC
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.
Comment 22 ooo 2009-06-15 12:03:01 UTC
@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" instead.

@jolatt: we need both, use system settings, and be able to override it in OOo.
Comment 23 ooo 2009-07-03 20:43:55 UTC
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.
Comment 24 Regina Henschel 2009-07-06 19:28:05 UTC
*** Issue 103213 has been marked as a duplicate of this issue. ***
Comment 25 gibi 2009-07-22 23:03:07 UTC
*** Issue 95969 has been marked as a duplicate of this issue. ***
Comment 26 aoo-bugger 2009-11-16 23:18:02 UTC
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
I opened the other Issue because, IMHO, its easier to solve than this one (this
here is platform depended, the other not)
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. :-)
Comment 27 cno 2009-11-17 09:06:55 UTC
*** Issue 45312 has been marked as a duplicate of this issue. ***
Comment 28 cno 2009-11-17 09:13:49 UTC
*** Issue 40036 has been marked as a duplicate of this issue. ***
Comment 29 ooo 2010-05-12 19:56:45 UTC
*** Issue 111495 has been marked as a duplicate of this issue. ***
Comment 30 vitriol 2010-05-25 07:47:30 UTC
Add me to CC
Comment 31 ooo 2010-06-08 14:54:17 UTC
*** Issue 112073 has been marked as a duplicate of this issue. ***
Comment 32 hev 2010-06-08 16:43:55 UTC
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...
Comment 33 trofimich 2010-06-08 20:43:48 UTC
Comment 34 kpalagin 2010-06-09 06:51:23 UTC
"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).
Comment 35 asmol 2010-06-09 09:21:12 UTC
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.
Comment 36 hev 2010-06-17 12:35:48 UTC
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"... 

Comment 37 hev 2010-06-17 13:13:54 UTC
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?
Comment 38 cno 2010-06-17 13:49:41 UTC
@hev: No doubt that many developers want to - and also do - support wishes of
Have you any idea how many people are paid a normal salary because they work on and thus make our free software available?
Decisions that support the health and wealth of sponsors of, are
seldom visible in the votes in IssueTracker. I bet you!
Comment 39 glupie 2010-07-06 15:41:45 UTC
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 :) ).
Comment 40 hev 2011-07-06 09:17:07 UTC
One more year. All is the same... Yeah.. 

"Decisions that support the health and wealth of sponsors of, 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.
Comment 41 asmol 2011-07-06 09:59:43 UTC
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.
Comment 42 hev 2011-07-06 10:12:46 UTC
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 :)
Comment 43 Ariel Constenla-Haile 2013-01-17 11:44:15 UTC
*** Issue 121622 has been marked as a duplicate of this issue. ***
Comment 44 Edwin Sharp 2013-11-29 11:00:23 UTC
Duplicate of bug 106961.

*** This issue has been marked as a duplicate of issue 106961 ***
Comment 45 Max Lvov 2013-12-02 10:48:54 UTC
(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?
Comment 46 Edwin Sharp 2013-12-02 11:12:40 UTC
(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.