Opened 6 years ago
Closed 6 years ago
#5449 closed defect (duplicate)
OMEdit can not open .mo file when path contains non-ASCII (e.g., Icelandic) characters
Reported by: | Dietmar Winkler | Owned by: | Adeel Asghar |
---|---|---|---|
Priority: | blocker | Milestone: | 1.14.0 |
Component: | OMEdit | Version: | v1.14.0-dev-nightly |
Keywords: | Cc: |
Description
Just came across this one on Windows. When one tries to open a .mo file OMEdit simply does not do anything (also throws no error) when the file path contains non-ASCII (in this case Icelandic letters. Problem is that the way user profiles are stored on Windows the chances are quite high that they contain non-ASCII letters for people outside ASCII land.
Change History (4)
comment:1 by , 6 years ago
Priority: | high → blocker |
---|
comment:2 by , 6 years ago
@casella, this is about the PATH (directory) where the file is! We support UTF8 contents for the .mo files since forever.
comment:3 by , 6 years ago
All right, I've been wandering through airports for 48 hours and I'm starting to be a bit tired, sorry about that :)
I remember a similar problem was reported by some use who had cyrillic characters in the path, though I can't find it now, I need to catch my (hopefully) last plane now.
comment:4 by , 6 years ago
Resolution: | → duplicate |
---|---|
Status: | new → closed |
OK, it was Italian accented letters, not cyrillic, and I was the reporter, see #5437. It's already marked as blocker for 1.14.0
As per Modelica specification, Section 13.2.2, Modelica files as stored with UTF-8 encoding.
One one hand, this should mean that any file which is created in OMEdit using an Icelandic keyboard is saved as UTF-8. @adeas31, can you confirm?
On the other hand, the question is what should OMC do with files created with any other tool or text editor. Silently ignoring the file is obviously unacceptable. I guess we have two alternatives, when a non UTF-8 file is encountered by OMC.
The second option is apparently more user-friendly, but has a lot of ambiguity in what the final outcome is, particularly because OMEdit has no clue what the original encoding of the file was, so it could mis-interpret it.
My recommendation is to go for the first option. In this case the user has to fix the issue with, e.g., a text editor, and will know if the result is what he/she intends.
@dietmarw, would you mind attaching a sample .mo file to reproduce the issue?
@adeas31, I guess this goes beyond OMEdit and should also apply to the interactive environment, right?