I just fixed the original description, the encodeName() originates from a commit by @zelzer, not @floca (the commit I originally cited just reused the pattern in multiple other lines)

Wait a little, there's more to this, I'll probably add to the first commit!

I do not see an issue with it. EncodeName is really the wrong function to use at this point, as it was designed for encoding file names into platform/locale specific 8 bit.

However as modern systems tend to support unicode filenames as well we might even want to consider changing the behaviour in QmitkIOUtil

In T22602#96049, @goch wrote:

However as modern systems tend to support unicode filenames as well we might even want to consider changing the behaviour in QmitkIOUtil

Exactly :-( This is what I am currently trying locally. However, when I fix QmitKIOUtil.cpp I run into problems with itksys::SystemTools::FileExists() which decides that "C:/bröd.nrrd" does not exist (though it does!) when the file name string is UTF-8 encoded (as is the case when we convert QString to std::string via .toStdString()). I suspect that there are more of those kind of incompatibilities around..

While I will still investigate a little on why itksys::SystemTools does not like UTF-8 and whether we can change that, the question for the MITK core team is: what encoding _shall_ be used for character strings inside MITK? With (some / a lot of) effort we could normalize all conversions to other string types (like Qt or other libraries), but we absolutely need to be consistent here.

@goch, @kislinsk: have you already had a discussion on this topic? Are there any guidelines?

@maleike I think the current policy could be best described as "free for all"
However I am fully in favor of using a consistent conversion and policy and am open for suggestions. UTF 8 as internal string encoding seems reasonable to me and should harmonize reasonably well with Qt.
The most trouble would probably be the interplay with other, especially file system related, toolkits.
itksys is a problem you already encountered. I believe boost filesystem is currently not used anywhere, Poco might be another issue. I believe tinyxml supports UTF8 as well.

It would probably be a good idea to write a utf8 test which tries to read/write sample files with umlauts/russian/chinese characters for each registered mimetype. However we currently do not have a way to create a sample file for each mime type, even those registered by a third party.

@maleike Did you try to use QString::toLatin1() instead of QString::toStdString()? AFAIK this is used rather often in MITK.

I spent quite some time now on understanding what is happening. Attached to this task are my detailed notes (see two comments further down).
The overall situation is complicated, so I need to meditate on it for some time before any further changes. Discussions are welcome.

The executive summary is: we have two incompatible assumptions on the encoding of DataNode's name in our code (locale-dependent vs. utf-8). Mostly it still works fine. Loading ö.nrrd works but Data Manager displays it as ? when the system's locale is Latin1 (for example).

I think my pull request does not worsen the current state but slightly improves on name editing in Data Manager. So it could be integrated regardless of further encoding cleanups.

@maleike Regarding attachments, simply drag & drop them into the comment text box. 💡

@maleike What's the status. Should we merge the PR for now or wait for more fixes?

In T22602#96071, @maleike wrote:

I think my pull request does not worsen the current state but slightly improves on name editing in Data Manager. So it could be integrated regardless of further encoding cleanups.

Unchanged status, above comment is still valid.

If somebody on your side wants to dive deeper into this subject I remain at your disposal for any discussions.

Pushed new branch T22602-UmlautsInDataManager.