Sorry, but I do not clearly understand what is meant.

Please describe step by step what you are doing and what you want to achieve.

Frank

Josh Ohana, 9-21-04

I am running OO 1.1.2 on WindowsXP and did encounter the problem you did.  When
I changed the language setting OO Spreadsheet still used a . as the decimal
separator.

Josh Ohana, 9-21-04

I am running OO 1.1.2 on WindowsXP and did encounter the problem you did.  When
I changed the language setting OO Spreadsheet still used a . as the decimal
separator.

George Brittingham - Wednesday 22, 2004

  I was able to replicate this error on my machine:

Open Office 1.1.2
Windows XP Home Edition Service Pack 2
AMD Athlon(TM) XP 1800+,  MMX,  3DNow, ~1.2GHz
512MB RAM
249MB used, 1000MB available Page File
DirectX 9.0c (4.09.0000.0904)

  By following these steps:

1. Go to your control panel. (Start > Control Panel)
2. Go to regional and language options
3. Under Regional Options, Select Czech
4. Open OpenOffice Spreadsheet
5. Format a cell to use the , and . to seperate numbers (Such as 1,234.12)

  In the Czech language, as well as many other European countries, the comma 
(,) is used as the decimal instead of the English decimal (.).  This can lead 
to misinterpretation of numbers between people of different languages.

  Example: 
    In the United States we write: I will pay you $100,000.00 to fix this bug.
    Elsewhere it could be written: I will pay you $100,000,00 to fix this bug.

  I don't know all the countries that use this system, but I've been to a few. 
I believe Spain uses this as well but I may be wrong.

I don't think windows language setting affects most programs. I was able to get
the decimal to comma by doing:
1. Going to Format
2. Click on Cells
3. Changing the language to Czech there
4. Then picking the format you wanted

Then you should be able to use the comma as a decimal divider. The only problem
is I was then having trouble getting a comma used for a thousands place divider.
I was getting 1 234,12 instead of 1,234,12.

System Specs:
English 1.1.2
XP Pro SP1
P4 2.0 GHz
512 MB RAM
280 Total GB Harddrive
NVidia GeForce FX 5200 128MB
Open Office v1.1.2

Alex

Tim Coulter
22 Sept. 2004

I tested this error on two separate configurations and I was not able to
reproduce it. Here are the steps that I used:

1)Run OpenOffice.org Calc (Spreadsheet)
2)Make sure OpenOffice.org is running in the “English (USA)†locale
   a) From the menu bar, select Tools > Options...
   b) In the Options window, expand the “Language Settings†tree
   c) Select “Languagesâ€
   d) From the drop-down box labeled “Locale setting†in the right hand side of
the window, select “English (USA)â€
   e) Click the “OK†button to close the window.
3)Select cell A1 in the spreadsheet
4)Type the decimal 12.34
5)Using the same steps described in step 2 above, change the locale setting to
“Czechâ€
6)Using the same steps described in step 2 above, change the locale setting back
to “English (USA)â€

After preforming step 5, I noticed that cell A1 contained the data “12,34â€; the
decimal separator did change to the comma (,). Similarly, after performing step
6, the decimal separator correctly changed back to the decimal point (.),
leaving a correct value of “12.34†in cell A1. 

The exact nature of this error was hard to determine from the original post. I
chose to test the locale setting options available within OpenOffice.org instead
of the locale setting options made available by the Windows operating system. By
changing the locale setting in OpenOffice.org, I was able to correctly switch
between the Czech and English (USA) locales without error.

The configurations I used for testing were as follows:

Machine 1:
	Gentoo Linux Kernel 2.6.8-gentoo-r3 (via “uname -râ€)
	Running OpenOffice.org 1.1.2
	AMD Athlon XP Mobile processor 2600 (2.0 Ghz)
	ATI Radeon Mobility IGP 320M (U1)
	768 MB RAM total
	64 MB RAM shared with video card
	

Machine 2:
	Microsoft Windows 2000 build 5.00.2195, Service Pack 4
	Running OpenOffice.org 1.1.2
	Intel Pentium 4, 2.8 Ghz 
	Intel 82865G Graphics Controller
	1 GB RAM
	  

Thanks gbritin for elaborating on the bug.

Tcoulter, adickens: sorry but you did not get the problem right. Changing the
locale in OO works PERFECTLY. This is not the problem. THe problem is when you
in OO do not slect neither Czech neither English but DEFAULT. In this case IT
SHOULD use the default computer locale settings. Otherwise remove the DEFAULT
option if it is not meant like that.

Adickens: Most of programs I work with respect the computer locale and it is the
way it should be! There should not be unncessary fiddeling with locales in
individual programs if it does not add any value - the locale can be set on OS
level in great detail. The only thing application should do is to respect the
setting. Locale settings in the application itself are only ADDITION to this,
for more flexibility etc.

Lastly I would like to add a comment to gbritin's explication of the . vs ,
separator problem. Actually it is quite an issue, because if you have different
comma separators in different applications it is quite a mess. Imagine company
with 50 computers like we do have here ... there are company procedures
including cutting and pasting spreadcheet data to text files and other
applications. Then the , vs . conversion and checking it all the time can be
real headake for company developers and administrators. If some application gets
the bad separator, in a serie of numbers it can for example divide each number
to two numbers and screw everything or consider numbers beeing text and refuse
to compute with them or format them differently.

Hi gorn,

this Issue was short before closing as wfm as I got no answer on my latest
question. After these ties from the others and your comment, I set czech as
regional setting and saved a document containing numbers with decimals, a comma
as separator was used. Closing the Office and changing the regional settings to
English USA making the decimal separator a dot, starting the office and opening
the previously saved document gave me the cells with numbers and a dot as
decimal separator.

If you do something different, please describe step by step what you're doing to
get your trouble, otherwise I close this Issue as worksforme.

Frank

I will write down the procedure which works on czech windows. I will try to test
it on English Windows later on, but if iI remember well, it works simillary. I
am usin Windows XP Proffesional version 2002 Service pack 1. 

* Go to your control panel. (Start > Control Panel)
* Go to regional and language options
* Under Regional Options, Select Czech
* start OO, Tools > Options > Language settings > Languages - fill in : Locale
setting: Default
* open new Spredsheet document
* fill in some formula, so that we are sure that result is a number. I use =SQRT(5)
* in Czech windows you will see 2,24  maybe in English windows you will see 2.24
but it is not important, the important comes right now:
* save and close the document an close OO
* Go to your control panel. (Start > Control Panel)
* Go to regional and language options
* Under Regional Options, Select English
* reopen the document - you will see the SAME thing as before. It has NOT
changed according to language setting of windows, thought you said to OO that it
should use DEFAULT locale

Just a comment: the procedure seems stupid but in real life you would have two
computers and the first half ut to saving the document is done on one computer,
then the document is sent over to different place and reopened here. If one of
the computer has czech windows locale and the other one english locale, the
recipient is confused, because he has got the sheet with strange numbers [bad
separators]

I hope that is detailed enough now.

Jakub

Hi,

so you've done exactly that I've done. The consequence is that I close this as
worksforme. I've tried it with several systems Windows and also different Linux
distributions. OOo acts correctly and changes the decimal separator according to
the locale setting.

Frank

closed wfm

may be I do not understand the WORKSFORSOME tag, but at least gbrittin has
reproduced the bug. Have you tried the procedure on Czech windows? If it is onlz
bug which appeard on Cyech windows, then where I should submit it?

Hi,

AFAIK all of the participants in these Issue except you and me are students from
Florida Tech University. So they use mostly the same systems and just only one
guy thought he can duplicate the Issue. Performing your steps and also the ones
from gbrittin I was not able to reproduce this Issue. I've used several windows
machines and also Linux distributions. Ok, not a single Czech windows, but this
should not be the problem as the regional settings are set to Czech. You may ask
pjanik at the czech lang project if he can reproduce this. If so, he can add
some comments to this Issue and maybe re-open it.

Frank