Created attachment 198470 [details] CSV which exhibits the problem when being loafded Consider the following CSV file: cola,colb,colc 1,2,3 4,5,6 (also attached). When I try opening it in Calc, the dialog which comes up suggests to me the codpage "Western Europe (DOS/OS2-865/Nordic)". I woud expect one of "System", "Unicode (UTF-8)", or "Western Europe (ISO 8859-I)". Bukd: Version: 25.8.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 2305fe302e12c4256e452589e2533772d4213e59 CPU threads: 4; OS: Linux 6.6; UI render: default; VCL: gtk3 Locale: en-IL (en_IL); UI: en-US Calc: threaded
I get: Western Europe (ISO 8859-1) Version: 25.2.0.1 (X86_64) / LibreOffice Community Build ID: ddb2a7ea3a8857aae619555f1a8743e430e146c9 CPU threads: 16; OS: Linux 6.8; UI render: default; VCL: gtk3 Locale: ro-RO (ro_RO.UTF-8); UI: en-US Calc: threaded The same in Version: 25.8.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 8b2f6b4fba6c466ed399f4f4b80e9631f13a6232 CPU threads: 16; OS: Linux 6.8; UI render: default; VCL: gtk3 Locale: ro-RO (ro_RO.UTF-8); UI: en-US Calc: threaded
I think Calc does not select the code page, but uses the last one used. Version: 25.8.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 89c00618b9cee6e786fd11a7fdbf7aaf24e4fbb7 CPU threads: 16; OS: Windows 11 X86_64 (build 26100); UI render: Skia/Vulkan; VCL: win Locale: en-US (es_ES); UI: en-US Calc: CL threaded
(In reply to m_a_riosv from comment #2) > I think Calc does not select the code page, but uses the last one used. No, it does seem to apply some detection logic. If I put some Hebrew characters in UTF-8 encoding, that's what Calc picks up. Also, even if that were the case - I've never opened any CSV files with Nordic text, so it was wrong the first time it detected that...
Created attachment 198497 [details] Screenshot import options Reloading in save mode, doesn't show what you get. Version: 25.8.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: c9ae567c791bcffdc3fff9e3fb11b46275a13d2b CPU threads: 16; OS: Windows 11 X86_64 (build 26100); UI render: default; VCL: win Locale: es-ES (es_ES); UI: es-ES Calc: threaded
I am 100% sure, that this is bug 166208. Specifically: 1. I suspect, that Eyal had no automatic detection in his dialog (only activated explicitly by choosing topmost "-Automatic-" element in the dripdown); 2. I think, that before upgrading to 25.2, Eyal had "Western Europe (ISO-8859-1)" selected there in the text import dialog; 3. System information shows, that Eyal uses en-US UI; and in that UI, the element immediately above the "Western Europe (ISO-8859-1)" is exactly "Western Europe (DOS/OS2-865/Nordic)"; 4. After the upgrade, bug 166208 added a new entry to the top of the dropdown; and since our config only stores the index of selected entry, the old index started to point to the element that previously was 1 higher in the list. No, this was not a sign of automatic detection, just of a bug. *** This bug has been marked as a duplicate of bug 166208 ***
(In reply to Mike Kaganski from comment #5) You're probably right, but I can't reproduce, and I don't remember what I had selected in the dialog before I opened the 'Nordic' CSV.
(In reply to Eyal Rozenberg from comment #6) To reproduce: 1. Run LO v.24.8; in it, open a CSV, and make sure to select "Western Europe (ISO-8859-1)" in the dialog, then OK (this will save the setting). 2. Run LO v.25.2+ (using the same user profile!), and try to open a CSV.