Text-to-columns gives different format when hiding a column

To convert my bank statement that shows “£1.00” to “1.00” I use text-to-columns with separator “£”.

When I let CALC create two separate columns I get a properly formated number “1.00”.

But when I hide the first column the number “1.00” is converted into a string. Is this a feature or a bug?

I can’t reproduce.
Would you share a reduced sample file and the version informattion at menu Help - About LibreOffice?
Edit your question to add there. Thanks.

EDIT:


Comparing both screenshots: my way loses the £ symbol, and @EarnestAl way changes £ for $ (but in the cell formatting, not in the cell content value).
Just choose the GBP Currency format to get a £ symbol, instead of $. imagen
But none of us gets a text string, as stated in the question.

It is an unexpected method but no problem here on 7.3.7.2

You might do better to tick the Detect special numbers box in the Text Import dialogue when you first open the csv and avoid the problem entirely.
[Edit] second time around for screenshot I forgot to change language to UK, the below one works

This wiki page might be useful, How to convert number text to numeric data

1 Like

Not in my spreadsheet, I get pounds, but the language for my documents is English (UK) (we use dollars in NZ and my spreadsheets default to dollars). I assume original poster will also get pounds

I changed cell Language, Locale setting, and Default Language for Documents to English (UK), Default currengy to GBP, and still get the $, not the £.

The language is for human language. It affects spell checking and auto-correct.
The locale is for numeric expressions. It affects the conversion between text and numerals.
Unfortunately, the import dialog labels locale as language which is misleading. I filed a bug report about this.

The #1 problem with text import is that “detect special numbers” is not checked by default.

1 Like

Not in my first screenshot, but I checked it (to no avail) when tested before my previous comment.

In order to detect any numbers correctly, the locale needs to match the assumed cultural context of the numeric strings.
31.12.1999;3.123,45€ → German date and currency
12/31/1999;$3,123.45 → Same values formatted as US date and currency
Both samples need “detect special numbers” plus the right locale setting.

New users don’t understand what a “special number” is and leave the option unchecked which is virtually always wrong.
New users don’t comprehend the meaning of locale (“language”) in this context and keep the default which is derived from the global locale. The default locale is propably the right one when importing something like an account statement from a local bank. It is wrong when you are in Europe and import some listing from some online service (amazon, ebay, anything) with US dates in M/D/Y notation.

I see that in 7.6.0.3 that the field is labelled Locale now so it seems your bug has been at least partially resolved. :+1: