I can't reproduce it in

Version: 6.5.0.0.alpha0+
Build ID: fc1f85127968d1c2e0a53dace51bf8a78f9e6ca5
CPU threads: 4; OS: Linux 4.19; UI render: default; VCL: gtk3; 
Locale: en-US (en_US.UTF-8); UI-Language: en-US
Calc: threaded

@Michael, do you reproduce it on your end ?

I cannot reproduce on current Debian testing with

Version: 6.5.0.0.alpha0+
Build ID: fc1f85127968d1c2e0a53dace51bf8a78f9e6ca5
CPU threads: 4; OS: Linux 5.4; UI render: default; VCL: kf5; 
Locale: en-GB (en_GB.UTF-8); UI-Language: en-US
Calc: threaded

This sounds similar to tdf#129736 (which I can't reproduce either).


Some questions that might help to narrow down the issue:

1) Can you paste the output of the command "locale"?

2) Does anythingchange if start libreoffice from command line with LC_ALL=C.UTF-8 set, like (replace '/path/to/' with the actual path):

    LC_ALL=C.UTF-8 /path/to/soffice

3) Does "Save as" (and saving under a different name in the same folder) work for the file?

Version: 6.4.0.1
Build ID: 40(Build:1)
CPU threads: 4; OS: Linux 5.4; UI render: default; VCL: kf5; 
Locale: en-GB (en_GB.UTF-8); UI-Language: en-US
Calc: threaded

I have the same issue, so adding my observations here. With me it applies to every time the file picker is used (Open, Save, Export).

Output of locale:
LANG=en_GB.UTF-8
LC_CTYPE=en_GB.UTF-8
LC_NUMERIC="en_GB.UTF-8"
LC_TIME="en_GB.UTF-8"
LC_COLLATE="en_GB.UTF-8"
LC_MONETARY="en_GB.UTF-8"
LC_MESSAGES="en_GB.UTF-8"
LC_PAPER="en_GB.UTF-8"
LC_NAME="en_GB.UTF-8"
LC_ADDRESS="en_GB.UTF-8"
LC_TELEPHONE="en_GB.UTF-8"
LC_MEASUREMENT="en_GB.UTF-8"
LC_IDENTIFICATION="en_GB.UTF-8"
LC_ALL=


Changing LC_ALL to "en_GB.UTF-8" fixes the issue. But since LC_ALL is the global override, I wonder if the VCL falls back incorrectly to ASCII if null is returned? Shouldn't fallback be to LANG first?

(In reply to Michael Weghorn from comment #2)

Y Some questions that might help to narrow down the issue:
> 
> 1) Can you paste the output of the command "locale"?

docb@T520:~> locale
LANG=de_DE.UTF-8
LC_CTYPE=de_DE.UTF-8
LC_NUMERIC="de_DE.UTF-8"
LC_TIME="de_DE.UTF-8"
LC_COLLATE="de_DE.UTF-8"
LC_MONETARY="de_DE.UTF-8"
LC_MESSAGES="de_DE.UTF-8"
LC_PAPER="de_DE.UTF-8"
LC_NAME="de_DE.UTF-8"
LC_ADDRESS="de_DE.UTF-8"
LC_TELEPHONE="de_DE.UTF-8"
LC_MEASUREMENT="de_DE.UTF-8"
LC_IDENTIFICATION="de_DE.UTF-8"
LC_ALL=

> 2) Does anythingchange if start libreoffice from command line with
> LC_ALL=C.UTF-8 set, like (replace '/path/to/' with the actual path):
> 
>     LC_ALL=C.UTF-8 /path/to/soffice

Yes, the file selection dialog comes up as expected. I can save the file (with Umlaut) into a folder with Umlaut

> 3) Does "Save as" (and saving under a different name in the same folder)
> work for the file?

After the LC_ALL=C.UTF-8 command? Yes
Before? no

(In reply to erz96cxw from comment #3)
> Version: 6.4.0.1
> Build ID: 40(Build:1)
> CPU threads: 4; OS: Linux 5.4; UI render: default; VCL: kf5; 
> Locale: en-GB (en_GB.UTF-8); UI-Language: en-US
> Calc: threaded
> 
> I have the same issue, so adding my observations here. With me it applies to
> every time the file picker is used (Open, Save, Export).
> 
> Output of locale:
> LANG=en_GB.UTF-8
> LC_CTYPE=en_GB.UTF-8
> LC_NUMERIC="en_GB.UTF-8"
> LC_TIME="en_GB.UTF-8"
> LC_COLLATE="en_GB.UTF-8"
> LC_MONETARY="en_GB.UTF-8"
> LC_MESSAGES="en_GB.UTF-8"
> LC_PAPER="en_GB.UTF-8"
> LC_NAME="en_GB.UTF-8"
> LC_ADDRESS="en_GB.UTF-8"
> LC_TELEPHONE="en_GB.UTF-8"
> LC_MEASUREMENT="en_GB.UTF-8"
> LC_IDENTIFICATION="en_GB.UTF-8"
> LC_ALL=
> 
> 
> Changing LC_ALL to "en_GB.UTF-8" fixes the issue. But since LC_ALL is the
> global override, I wonder if the VCL falls back incorrectly to ASCII if null
> is returned? Shouldn't fallback be to LANG first?

That's interesting and somewhat unexpected. Given your locale settings, I agree that setting LC_ALL to "en_GB.UTF-8" should not make a difference, since all other locale-related vars already have that value.

Interestingly, it works just fine for me on Debian testing with the same locale settings:

$ locale
LANG=en_GB.UTF-8
LANGUAGE=
LC_CTYPE="en_GB.UTF-8"
LC_NUMERIC="en_GB.UTF-8"
LC_TIME=en_DK.UTF-8
LC_COLLATE="en_GB.UTF-8"
LC_MONETARY="en_GB.UTF-8"
LC_MESSAGES="en_GB.UTF-8"
LC_PAPER="en_GB.UTF-8"
LC_NAME="en_GB.UTF-8"
LC_ADDRESS="en_GB.UTF-8"
LC_TELEPHONE="en_GB.UTF-8"
LC_MEASUREMENT=de_DE.UTF-8
LC_IDENTIFICATION="en_GB.UTF-8"
LC_ALL=

so I'm still unable to reproduce the issue myself.


(In reply to Axel Braun from comment #4)
> > 3) Does "Save as" (and saving under a different name in the same folder)
> > work for the file?
> 
> After the LC_ALL=C.UTF-8 command? Yes
> Before? no

Does LC_ALL=de_DE.UTF-8 also work? (similar to what erz96cxw did in comment 3)

Another question: Do other KDE applications (like Kate) also have any issue when using "Save as" with a file located in the same directory?

Hi there,
Kate handles everything as expected without changing the locale. Is this perhaps some VCL/kf5 bug?

To confound matters I did some testing. I can assign total nonsense to LC_ALL and it still works. Folders can be opened as expected. Obviously no locale gets assigned:

:~> LC_ALL="nonsense"  libreoffice
/bin/sh: warning: setlocale: LC_ALL: cannot change locale (nonsense)
/usr/bin/libreoffice: line 173: warning: setlocale: LC_ALL: cannot change locale (nonsense)
Fontconfig warning: ignoring nonsense: not a valid language tag


But if I just run libreoffice from the same command line (no LC_ALL assignment), it does not work. Is perhaps the locale setting bypassed altogether, defaulting to some non-unicode locale, and only when LC_ALL is passed along, the locale setting branch is invoked?

The "fix" does not work with any other locale parameter (e.g. LANG), it has to be LC_ALL.

(In reply to erz96cxw from comment #7)

> Kate handles everything as expected without changing the locale. Is this
> perhaps some VCL/kf5 bug?

Confrirmed regarding the handling of kate.

> To confound matters I did some testing. I can assign total nonsense to
> LC_ALL and it still works. Folders can be opened as expected. Obviously no
> locale gets assigned:
> 
> :~> LC_ALL="nonsense"  libreoffice
> /bin/sh: warning: setlocale: LC_ALL: cannot change locale (nonsense)
> /usr/bin/libreoffice: line 173: warning: setlocale: LC_ALL: cannot change
> locale (nonsense)
> Fontconfig warning: ignoring nonsense: not a valid language tag

Can't confirm this. I can open with the 'nonsense' locale, but not safe it:
Error saving the document The_document:
Object not accessible.
The object cannot be accessed
due to insufficient user rights.

(I doubt this as I'm the owner of the directory. must be a kind of secondary issue)

(In reply to Axel Braun from comment #8)
> (In reply to erz96cxw from comment #7)
> 
> > Kate handles everything as expected without changing the locale. Is this
> > perhaps some VCL/kf5 bug?
> 
> Confrirmed regarding the handling of kate.
> 
> > To confound matters I did some testing. I can assign total nonsense to
> > LC_ALL and it still works. Folders can be opened as expected. Obviously no
> > locale gets assigned:
> > 
> > :~> LC_ALL="nonsense"  libreoffice
> > /bin/sh: warning: setlocale: LC_ALL: cannot change locale (nonsense)
> > /usr/bin/libreoffice: line 173: warning: setlocale: LC_ALL: cannot change
> > locale (nonsense)
> > Fontconfig warning: ignoring nonsense: not a valid language tag
> 
> Can't confirm this. I can open with the 'nonsense' locale, but not safe it:
> Error saving the document The_document:
> Object not accessible.
> The object cannot be accessed
> due to insufficient user rights.
> 
> (I doubt this as I'm the owner of the directory. must be a kind of secondary
> issue)

Confirmed re "nonsense" locale. I can open folders with an Umlaut, unlike when starting with no locale at all. But trying to open a file comes up with an error message, characters seem to indicate that 8859-1 is default fallback in this case.

(In reply to erz96cxw from comment #7)
> Kate handles everything as expected without changing the locale. Is this
> perhaps some VCL/kf5 bug?

Sounds probably, but it's hard to say without being able to see and analyze the issue myself...

What Linux distros (and versions) and what versions of Qt and libkf5kiofilewidgets5 do you have?

And are you using the distro-provided LibreOffice or the packages downloaded from the LibreOffice website?

(In reply to Michael Weghorn from comment #11)
> And are you using the distro-provided LibreOffice or the packages downloaded
> from the LibreOffice website?

I have tried both, package from LO Website as well as from Distro (openSUSE Tumbleweed 20200128), qt 5.14.0
ibkf5kiofilewidgets5 seems to be part of libreoffice-qt5:

nformationen zu Paket libreoffice-qt5:
---------------------------------------
Repository         : openSUSE-Tumbleweed-Oss                     
Name               : libreoffice-qt5                             
Version            : 6.4.0.3-1.1                                 
Arch               : x86_64                                      
Anbieter           : openSUSE                                    
Installierte Größe : 742,6 KiB                                   
Installiert        : Ja                                          
Status             : aktuell                                     
Quellpaket         : libreoffice-6.4.0.3-1.1.src                 
Zusammenfassung    : Qt5/KDE Frameworks interface for LibreOffice

(In reply to Axel Braun from comment #12)
> (In reply to Michael Weghorn from comment #11)
> > And are you using the distro-provided LibreOffice or the packages downloaded
> > from the LibreOffice website?
> 

I am on OpenSUSE Tumbleweed as well, just using their repositories, haven't tried direct download
qt=5.14.0
> rpm -q --whatprovides /usr/lib64/libKF5KIOFileWidgets.so.5
kio-5.66.0-1.1.x86_64

I have set up a Tumbleweed VM and can reproduce there; will take a look.

SAL_USE_VCLPLUGIN=qt5 works, i.e. it seems specific to the Plasma-native Qt file dialog.

The problem is caused by the LibreOffice shell wrapper, which sets LC_ALL, like this:

    LO_SAVE_LC_ALL="$LC_ALL"
    LC_ALL=C
    export LC_ALL
    # ... (call some tools,...)
    # restore locale setting
    LC_ALL="$LO_SAVE_LC_ALL"

This sets LC_ALL to an empty string if not set previously and the Plasma-native file Qt file dialog seems to have problems with this.

The same problem can be seen when running e.g. kate with that env variable:

    LC_ALL= kate

And directly running 'soffice.bin' instead of the 'soffice' shell wrapper also works as expected.

The "locale" command behaves differently from what the kf5 libs seem to do here:

* explicit empty value is ignored

$ LC_ALL= locale
LANG=en_GB.UTF-8
LANGUAGE=en_GB:en
LC_CTYPE="en_GB.UTF-8"
LC_NUMERIC="en_GB.UTF-8"
LC_TIME=en_DK.UTF-8
LC_COLLATE="en_GB.UTF-8"
LC_MONETARY="en_GB.UTF-8"
LC_MESSAGES="en_GB.UTF-8"
LC_PAPER="en_GB.UTF-8"
LC_NAME="en_GB.UTF-8"
LC_ADDRESS="en_GB.UTF-8"
LC_TELEPHONE="en_GB.UTF-8"
LC_MEASUREMENT=de_DE.UTF-8
LC_IDENTIFICATION="en_GB.UTF-8"
LC_ALL=

* setting a non-empty value makes that one take effect, even if invalid:

$ LC_ALL=abcd locale
locale: Cannot set LC_CTYPE to default locale: No such file or directory
locale: Cannot set LC_MESSAGES to default locale: No such file or directory
locale: Cannot set LC_ALL to default locale: No such file or directory
LANG=en_GB.UTF-8
LANGUAGE=en_GB:en
LC_CTYPE="abcd"
LC_NUMERIC="abcd"
LC_TIME="abcd"
LC_COLLATE="abcd"
LC_MONETARY="abcd"
LC_MESSAGES="abcd"
LC_PAPER="abcd"
LC_NAME="abcd"
LC_ADDRESS="abcd"
LC_TELEPHONE="abcd"
LC_MEASUREMENT="abcd"
LC_IDENTIFICATION="abcd"
LC_ALL=abcd

So I'd assume that kf5 libs should probably do the same?
(and probably have done so in the past, at least the LibreOffice wrapper seems to have been doing that for years already)

(In reply to Michael Weghorn from comment #15)
> [...]
> So I'd assume that kf5 libs should probably do the same?
> (and probably have done so in the past, at least the LibreOffice wrapper
> seems to have been doing that for years already)

I'm in contact with KDE developers, but it's not clear at once where that handling comes from. Easiest thing would probably be to adapt the LibreOffice wrapper to unset LC_ALL again in the end if it wasn't set at the beginning, but maybe we can still find out a bit more.

From IRC #kde-devel:

> [16:25] <frinring> michaelweghorn: just did some quick fprint debugging. seems the cause is that QTextCodec::codecForLocale() becomes US-ASCII is LC_ALL= is in the envirnment. lost track of the calls on the border to the icu lib, but seems the issue is over there
> ...
> [16:35] <michaelweghorn> frinring: thx! I'll take a look there to see whether I can rather quickly find more, but will otherwise probably go with adapting the libreoffice wrapper
> [16:36] <frinring> michaelweghorn: yes, that would be good in any case to deal with unfixed qt
> ...
> [16:47] <frinring> michaelweghorn: so, to summarize: Qt's text code when using libicu calls  ucnv_getDefaultName() from unicode/urename.h, which returns US-ASCII when LC_ALL is defined as emptyy string in the env. qt recently switched to libicu IIRC, so that's why it is popping up now
> ...
> [16:49] <frinring> to be tested with linking icuuc, #include <unicode/ucnv.h> and calling ucnv_getDefaultName() which returns const char*
> ...
> [16:52] <michaelweghorn> frinring: thanks for your analysis! Can I paste that to the LibreOffice bugzilla issue?
> ...
> [17:00] <frinring> michaelweghorn: sure. this should also affect other apps using libicu possibly, like chromium

(In reply to Michael Weghorn from comment #17)
> From IRC #kde-devel:
> ...
> > [16:49] <frinring> to be tested with linking icuuc, #include <unicode/ucnv.h> and calling ucnv_getDefaultName() which returns const char*

Indeed, the following test program using ICU compiled with 

    g++ test.cpp $(pkg-config --libs --cflags icu-uc icu-io)

and then called with LC_ALL="" prints "US-ASCII" on Tumbleweed (ICU at version 65.x) and KDE Neon dev edition (ICU at version 60.2), while it prints "UTF-8" on my Debian testing (ICU at version 63.2):


#include <unicode/ucnv.h>
#include <iostream>

int main() {
    std::cout << ucnv_getDefaultName();
}

With a Self-built ICU from current master (as of commit d6b88d49e3be7096baf3828776c2b482a8ed1780 ), the sample program from comment 18 also returns "UTF-8" on KDE neon dev edition, other than the system ICU:

Self-built ICU master:
> user@neondeveloper:~/development/git/icu/icu4c/source$ g++ -o icu-test -O0 -g -I/tmp/icu/include/ -L/tmp/icu/lib/ icu-test.cxx -licudata -licuuc
> user@neondeveloper:~/development/git/icu/icu4c/source$ LC_ALL="" ./icu-test 
> UTF-8

System ICU:
> user@neondeveloper:~/development/git/icu/icu4c/source$ g++ -o icu-test -O0 -g icu-test.cxx -licudata -licuuc
> user@neondeveloper:~/development/git/icu/icu4c/source$ LC_ALL="" ./icu-test 
> US-ASCII

(with LD_LIBRARY_PATH=/tmp/icu/lib , because I passed /tmp/icu as prefix to configure)

Might be related to different ICU configure options used by the distros (I passed none besides '--with-prefix=/tmp/icu'), differing versions (but see comment 18), or something else, but I'll stop investigating at this point for now and will adapt the LibreOffice shell wrapper (which makes sense anyway, also taking into account existing installations).

(In reply to Michael Weghorn from comment #19)
> [...] will adapt the LibreOffice shell wrapper (which makes sense
> anyway, also taking into account existing installations).

-> Patch pending at https://gerrit.libreoffice.org/c/core/+/88003

*** Bug 126812 has been marked as a duplicate of this bug. ***

(In reply to Michael Weghorn from comment #21)
> *** Bug 126812 has been marked as a duplicate of this bug. ***

(In reply to Michael Weghorn from comment #20)
> (In reply to Michael Weghorn from comment #19)
> > [...] will adapt the LibreOffice shell wrapper (which makes sense
> > anyway, also taking into account existing installations).
> 
> -> Patch pending at https://gerrit.libreoffice.org/c/core/+/88003

Tried your patch and can confirm that it is working as expected. Thanks for getting to the bottom of this!

*** Bug 129736 has been marked as a duplicate of this bug. ***

Michael Weghorn committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/25649502e08a52087dea5e482d34a1d4150f0930

tdf#130080 soffice.sh: Avoid exporting empty LC_ALL

It will be available in 7.0.0.

The patch should be included in the daily builds available at
https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
https://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.

(In reply to erz96cxw from comment #22)
> Tried your patch and can confirm that it is working as expected. Thanks for
> getting to the bottom of this!

Thanks for testing!

Fixed on master branch now, backports for libreoffice-6-4 and -6-3 pending in Gerrit.

(In reply to Michael Weghorn from comment #25)

> Fixed on master branch now, backports for libreoffice-6-4 and -6-3 pending
> in Gerrit.

Thank you very much for your quick resolution of this issue. I will try the nightly next days.

Michael Weghorn committed a patch related to this issue.
It has been pushed to "libreoffice-6-4":

https://git.libreoffice.org/core/commit/d037d971b4f4f408c7a6b6c15a0c7e742f61d354

tdf#130080 soffice.sh: Avoid exporting empty LC_ALL

It will be available in 6.4.2.

The patch should be included in the daily builds available at
https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
https://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.

Michael Weghorn committed a patch related to this issue.
It has been pushed to "libreoffice-6-3":

https://git.libreoffice.org/core/commit/3c5eda2a18097547ac9597ccad7477e2aaa65f26

tdf#130080 soffice.sh: Avoid exporting empty LC_ALL

It will be available in 6.3.6.

The patch should be included in the daily builds available at
https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
https://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.

Michael Weghorn committed a patch related to this issue.
It has been pushed to "libreoffice-6-3-5":

https://git.libreoffice.org/core/commit/1253f7e8fa405ee39bb72dc24d02a09dc757aa58

tdf#130080 soffice.sh: Avoid exporting empty LC_ALL

It will be available in 6.3.5.

The patch should be included in the daily builds available at
https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
https://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.

Michael Weghorn committed a patch related to this issue.
It has been pushed to "libreoffice-6-4-1":

https://git.libreoffice.org/core/commit/48117f353c60de971089b793bbdd48f897cb62f0

tdf#130080 soffice.sh: Avoid exporting empty LC_ALL

It will be available in 6.4.1.

The patch should be included in the daily builds available at
https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
https://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.

*** Bug 130726 has been marked as a duplicate of this bug. ***

*** Bug 130791 has been marked as a duplicate of this bug. ***

*** Bug 129770 has been marked as a duplicate of this bug. ***