Bug 40497 - User-defined cell format in Calc was particularly broken
Summary: User-defined cell format in Calc was particularly broken
Status: RESOLVED NOTABUG
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Calc (show other bugs)
Version:
(earliest affected)
3.3.2 release
Hardware: x86-64 (AMD64) Linux (All)
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-08-30 10:58 UTC by russianneuromancer
Modified: 2016-04-25 07:47 UTC (History)
3 users (show)

See Also:
Crash report or crash signature:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description russianneuromancer 2011-08-30 10:58:41 UTC
1. Open LibreOffice Calc.
2. Enter for example 1600 in any cell.
3. Open Cell Format of this cell.
4. Select user-defined and Default - English (USA) language.
5. Enter format code:
# ###.00 "something"
Result is correct: 1 600. something
6. So now try language with "," instead of ".". For example Russian.
Select Russian language in Cell Format window.
7. Enter format code:
# ###,00 "something"
Result is broken: 1,60something
8. You may guess the problem in the gap, but:
# ###,00"something"
Result is still broken: 1 600,00something
9. Some kind of solution:
# ###,00" something"
Result: 1 600,00 something
Now it's correct but it's just a workaround.
Comment 1 Björn Michaelsen 2011-12-23 12:39:19 UTC
[This is an automated message.]
This bug was filed before the changes to Bugzilla on 2011-10-16. Thus it
started right out as NEW without ever being explicitly confirmed. The bug is
changed to state NEEDINFO for this reason. To move this bug from NEEDINFO back
to NEW please check if the bug still persists with the 3.5.0 beta1 or beta2 prereleases.
Details on how to test the 3.5.0 beta1 can be found at:
http://wiki.documentfoundation.org/QA/BugHunting_Session_3.5.0.-1

more detail on this bulk operation: http://nabble.documentfoundation.org/RFC-Operation-Spamzilla-tp3607474p3607474.html
Comment 2 russianneuromancer 2012-02-29 11:25:38 UTC
Bug still present in LibreOffice 3.5 release.
Comment 3 ign_christian 2013-06-25 09:32:14 UTC
I think it's spesific to Languange used on that cell, different Languange generates different behavior.
Comment 4 QA Administrators 2015-03-17 00:11:41 UTC
** Please read this message in its entirety before responding **

To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year.

There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present.

If you have time, please do the following:

    Test to see if the bug is still present on a currently supported version of LibreOffice (4.4.1 or later)
    https://www.libreoffice.org/download/

    If the bug is present, please leave a comment that includes the version of LibreOffice and your operating system, and any changes you see in the bug behavior
  
  If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a short comment that includes your version of LibreOffice and Operating System

Please DO NOT

    Update the version field
    Reply via email (please reply directly on the bug tracker)
    Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case)


If you want to do more to help you can test to see if your issue is a REGRESSION. To do so:
1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3)

http://downloadarchive.documentfoundation.org/libreoffice/old/

2. Test your bug
3. Leave a comment with your results.
4a. If the bug was present with 3.3 - set version to "inherited from OOo";
4b. If the bug was not present in 3.3 - add "regression" to keyword


Feel free to come ask questions or to say hello in our QA chat: http://webchat.freenode.net/?channels=libreoffice-qa

Thank you for your help!

-- The LibreOffice QA Team This NEW Message was generated on: 2015-03-16
Comment 5 russianneuromancer 2015-03-17 07:15:20 UTC
Still reproducible in 4.4.1.2.
Comment 6 Jean-Baptiste Faure 2015-03-21 15:13:05 UTC
Nobody confirmed this bug report independently. Set to UNCONFIRMED.

Please, do not set your own bug report to NEW.

Note: 
For me the point 9 is the correct way to do the formatting.
#5 is not correct, it should be 1 600.00something
If you want " something" set " something" in the format descriptor.

Best regards. JBF
Comment 7 russianneuromancer 2015-03-21 17:37:09 UTC
Interesting, I didn't look at this issue from this point of view:
> For me the point 9 is the correct way to do the formatting.
> #5 is not correct, it should be 1 600.00something

You could be right. Can you request opinion of other developers on this issue?
Comment 8 raal 2015-03-21 21:00:13 UTC
Reproducible with Version: 4.5.0.0.alpha0+
Build ID: e3167924fd28c8b854f23139dbf49f53e6282ef7
TinderBox: Linux-rpm_deb-x86_64@46-TDF, Branch:master, Time: 2015-03-17_03:10:47


Setting to new, according to help this should work https://help.libreoffice.org/Common/Number_Format_Codes#Text_and_Numbers
Comment 9 tommy27 2016-04-16 07:28:23 UTC
** Please read this message in its entirety before responding **

To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year.

There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present.

If you have time, please do the following:

Test to see if the bug is still present on a currently supported version of LibreOffice (5.0.5 or 5.1.2 https://www.libreoffice.org/download/

If the bug is present, please leave a comment that includes the version of LibreOffice and your operating system, and any changes you see in the bug behavior
 
If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a short comment that includes your version of LibreOffice and Operating System

Please DO NOT

- Update the version field
- Reply via email (please reply directly on the bug tracker)
- Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case)


If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 

1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3)

http://downloadarchive.documentfoundation.org/libreoffice/old/

2. Test your bug 

3. Leave a comment with your results. 

4a. If the bug was present with 3.3 - set version to "inherited from OOo"; 
4b. If the bug was not present in 3.3 - add "regression" to keyword


Feel free to come ask questions or to say hello in our QA chat: http://webchat.freenode.net/?channels=libreoffice-qa

Thank you for your help!

-- The LibreOffice QA Team This NEW Message was generated on: 2016-04-16
Comment 10 russianneuromancer 2016-04-16 11:31:39 UTC
Version 5.1.2.2, still broken. Result on step seven now is: .02something
I have no idea where ".02" came from while number in field is 1600.
Comment 11 Jean-Baptiste Faure 2016-04-17 09:19:51 UTC
For me it is not a bug. You should think that each character in a format description has a meaning, even an empty or blank character. So the correct syntax for the expected result is the point 9.
Point 8 is correct too but it intended to obtain another result.
Point 7 define two places for the thousand separator. 

I suggest to close this bug report as NotABug.

Best regards. JBF
Comment 12 russianneuromancer 2016-04-17 12:23:23 UTC
Jean-Baptiste, what do you get in latest LO with Default - English (USA) and this format: 
# ###.00 "something"
If number in cell is 1600?
Comment 13 Jean-Baptiste Faure 2016-04-17 12:34:43 UTC
(In reply to russianneuromancer from comment #12)
> Jean-Baptiste, what do you get in latest LO with Default - English (USA) and
> this format: 
> # ###.00 "something"
> If number in cell is 1600?

I get:
1 600.00 something

Note: in the various kinds of formatting for English (USA), the thousand separator is the comma, not the space.

Best regards. JBF
Comment 14 Laurent BP 2016-04-25 07:47:10 UTC
(In reply to russianneuromancer from comment #12)
> Jean-Baptiste, what do you get in latest LO with Default - English (USA) and
> this format: 
> # ###.00 "something"
> If number in cell is 1600?

I agree with Jean-Baptiste, there is no bug.

With EN, space has no special meaning, (it is comma which is considered as thousand separator) so
# ###.00 "something"
will insert two space characters in the result, but no thousand separator. You can check with a huge value bigger than 1 million: 1,243,456 gives
1234 567.00 something

But if you use a language which considers space as thousand separator (like RU or FR), then LibO considers the two spaces as million and thousand separator, and simply ignores second one if value is less than one million.
# ###,00 "something"
gives for 1,243,456
1 234,57something
which can be read as 1,234.57 thousands
As said by Jean-Baptiste, or in your comment 0 step 9, you have to insert your second space character inside your quotes (it is not a workaround, it is as it has to be written):
# ###,00" something"
Otherwise, LibO can not guess if you insert a thousand separator or text space character.

Conclusion: when you change language, you have to adapt both decimal and thousand separators.