Images don't load if vault contains non standard letters such as é

Can’t embed the images either:
image

File path:
/home/thibaultmol/Obsidian/Thibault Privé/Pasted Image 20220818183242_207.jpg

Same thing happens in the other vault:
/home/thibaultmol/Obsidian/é/

Same issue when I use the appimage version
(appimage debug info:)

SYSTEM INFO:
	Obsidian version: v0.15.9
	Installer version: v0.15.9
	Operating system: #1 ZEN SMP PREEMPT_DYNAMIC Thu, 11 Aug 2022 15:22:00 +0000 5.19.1-zen1-1-zen
	Login status: not logged in
	Insider build toggle: off
	Live preview: on
	Legacy editor: off
	Base theme: dark
	Community theme: none
	Snippets enabled: 0
	Restricted mode: off
	Plugins installed: 24
	Plugins enabled: 1
		1: Excalidraw v1.7.13

RECOMMENDATIONS:
	Community plugins: for bugs, please first try updating all your plugins to latest. If still not fixed, please try to make the issue happen in the Sandbox Vault or disable community plugins.

EDIT: how can I verify if it indeed boots with the lang option?
I did
./Obsidian-0.15.9.AppImage LANG=en_US.UTF-8
(which for me then opens the appimagelauncher, and I tell it to launch once)

You need to put lang before calling Obsidian

Same issue here: Images cannot be shown when on path with Unicode symbol (emoji/chinese character...)

I am also using KDE. I could reproduce your bug (with an é).

You need to put lang before calling Obsidian

I tried it. With a folder called é inside the vault and the appimage. Still an issue.

Here is the output from the appimage sandbox vault:

The console error says:

GET app://local/home/wmclt/.config/obsidian/Obsidian%20Sandbox/%C3%A9/obsidian.png?1660943063136 net::ERR_FILE_NOT_FOUND

What happens if you set your system language to English and restart your computer?

We strongly recommend you to search the forum with possible keywords before submitting a new bug report. Please also try your repro steps with third-party plugins and custom CSS disabled and see if it’s still reproducible. If it’s an issue with third-party plugins or themes, try contacting the author for help. Once you’ve done the above, delete this line.

Steps to reproduce

  • create folder with a non-ascii Unicode character (e.g. , 𡗗 or देव) in folder name
  • paste an image (jpg or png) in created folder

Expected result

When clicking on the image, the image should display.
Same when linking the image (![image location]) in a note and opening preview mode.

Actual result

A broken image logo is shown:

Here is a recording of the steps as executed in the test vault:
record-image-error-obsidian-2

Environment

  • Operating system: Linux KDE neon (kernel 5.15) Flatpak
  • Debug info:
SYSTEM INFO:
	Obsidian version: v0.15.9
	Installer version: v0.15.9
	Operating system: #44~20.04.1-Ubuntu SMP Fri Jun 24 13:27:29 UTC 2022 5.15.0-41-generic
	Login status: not logged in
	Insider build toggle: off
	Live preview: on
	Legacy editor: off
	Base theme: dark
	Community theme: none
	Snippets enabled: 0
	Restricted mode: on

RECOMMENDATIONS:
	none


Additional information

There is an existing bug which has been closed by the reporter even though this was not fixed: Images doesn't display

This bug is not reproducible on Windows, nor a default Ubuntu 22.04 with the Gnome desktop environment. In the link above, the reporter was also using KDE as desktop environment however.

I have only been having this bug in the past month. I am using the Flatpak distribution of the app.

Try app image. We don’t produce the flatpak.

Which filesystem do you use?

we can’t reproduce this.

Same issue with the appimage.

I believe the filesystem is part of the OS (Linux), so it should be the same in every distro.

it’s not.

Oh I see: I’m using ext4

What happens if you set your system language to English and restart your computer?

In my case the language of my OS is already set to en_GB.UTF-8.

I switched everything to Default.UTF-8 and the problem is still there.

We can’t reproduce. But we got enough reports to believe that this is real issue. Probably an upstream electron problem with some linux setups.

1 Like

So I tried reproducing it. Made a bunch of vms.
Tested by creating a folder on the desktop called ‘test vaulté’. Downloading the obsidian logo into it. And then dragging the image from inside obsidian’s left panel, to a new note.
(:white_check_mark: means It worked as intended, not reproduced)

Tested using the flatpak version:

  • :white_check_mark: Garuda dr460nized 220822
  • :white_check_mark: Manjaro kde 21.3.7-220816 linux 515
  • :white_check_mark: EndevourOS artemis neo 22.8
  • :white_check_mark: Ubuntu 22.04.1
  • :white_check_mark: Popos 22.04
  • :white_check_mark: Fedora Silverblue 36.1.5

Native package repo:

  • :white_check_mark: Manjaro
  • :white_check_mark: Garuda
  • :white_check_mark: EndevourOS

AUR (appimage version):

  • :white_check_mark: Manjaro
  • :white_check_mark: Garuda
  • :white_check_mark: EndevourOS

SO, I EVENTUALLY FOUND THE PROBLEM:
In kde plasma I set my region settings here to be Belgium English. And when I did that on my garuda vm, I managed to reproduce the issue

image

@zeegroen can you confirm what happens if you set those region settings back to amarican english (all of them)

Can also confirm changing the format settings on Fedora silverblue, Ubuntu and Popos (all running gnome as their desktop environment)

Changing ‘formats’ to Belgium, Germany and many more probably. Seem to cause the issue

Last reply:
On Gnome you only have 1 setting that controls all format related things.
On KDE Plasma you have granual control. And it seems like the ‘Region’ setting is what’s causing the problem there. Even if you set it to ‘default.UTF-8’ it still causes issues. It has to be set to ‘en_US.UTF-8’.
But this seems to be a more general linux/electron issue, not a distro or desktop enviroment specific thing.

AS A TEST. I fully reinstalled manjaro but select Dutch as my language this time.
Interestingly enough. That works fine. (double-checked, it did automatically set the format settings to nl_BE automatically)
Changing it to American English doesn’t break it.
And changing it back to nl_BE again also doesn’t break it.

1 Like

Thanks for all the testing.

Ok my suspicious was correct. This is an electron problem tied to system locale.

1 Like

@Thibaultmol I could reproduce it! The interface in KDE to change regional settings has changed however, and when I changed the settings to American English, I saw no changes. I had to modify /etc/locale.conf to manually set everything to en_US.UTF-8 to make it work. Thanks for investigating!

1 Like