Bugzilla – Bug 119816
Openoffice needs UTF-8 to save files with umlauts
Last modified: 2006-04-02 19:51:41 UTC
Hello, since the first milestones of OOo 2.0 all umlauts in filenames are converted to %XX escape sequences. This makes it impossible to save a file e.g. "Kündigung.odt", it is always saved as "K%FCndigung.odt", which messes up sorting and readability and does not do what the user expects. It is possible that this also happens with other accented characters (I haven't tested). I have witnessed this problem on SuSE 9.1, 9.2, 9.3 and 10.0rc1 with the respective OOorg snapshots. The latest snapshot I'm using is 1.9.125 (I think this is beta2). Thank you, Jens
I was not able to replicate the issue, this works fine with out any issues with OpenOffice 1.9.125.1.2 (It was with SUSE10 RC build) can you try with the latest version and see if you still face the issue.
Yes, I also have the SuSE 10RC1 build. I still have this problem. I also switched off UTF-8 (in YaST -> Language -> Advanced) for compatability with our existing software and data. Perhaps this is the reason. I cannot update my 10.0rc1 installation right now, because all the YaST FTP sources for 10.0 seem to have vanished. Also, my YaST online update still thinks I'm using 9.3, and I cannot think of anything to make it believe otherwise (-> seperate bug). Thanks for your reply! :-)
Hello, has anything been done about this bug? Can I help in some way? Thanks!
I'm unable to reproduce the bug in NLD10pre1, though admittedly I haven't turned off UTF-8. Jens: can you check whether turning UTF-8 back on actually does resolve the problem?
Yes, with UTF-8 turned on everything is fine. I did export LC_ALL=de_DE.UTF-8 export LANG=de_DE.UTF-8 oowriter & and saved a file. It is correctly saved with umlauts in filenames (although they show up strange in the filemanager because the filemanager itself is using my default ISO8859-15 charset).
I can confirm the bug in our infrastructure, too (several machines, SuSE 10 on x86, UTF-8 turned off). Sadly, we cannot easily convert to UTF-8 right now (CVS data needs to keep consistent). Is there a workaround, or any chance this will be fixed soon?
Andi: By "cannot easily convert to UTF-8", do you mean "can't run my entire desktop with LC_ALL and LANG being de_DE.UTF-8 because legacy apps have a problem with it", or "can't run OOo using UTF-8"? If it's the former, I'd suggest invoking OOo through a wrapper (either the system-wide one or a user-defined wrapper around that) which sets the locale to use UTF-8. As noted above, this may not integrate perfectly with the filemanager. If it's the latter, I'd fall back on the old "umlaut -> e" mapping (or, to be pedantic, the unmapping of "e->umlaut"). It may be suboptimal in terms of sort order, but it's at least readable. Really, the solution is UTF-8. I'm closing this bug as INVALID. The underlying problem (need to save files with umlauts) already has a reasonable solution (UTF-8), and reasonable workarounds exist for cases when UTF-8 isn't an option.
Hello, IMHO this is still a bug and it's not invalid. SuSE offers the possibility of setting a system-wide character set different to UTF-8. All applications support this fine, and can cope with non-ASCII characters in the respective charset. Except OpenOffice, which mangles names when not in UTF-8 mode. A workaround that maps ä -> "ae" and so on would work but it would have to provide a substitute for all non-ASCII characters, which is hardly possible or feasible. At the VERY least OpenOffice should provide a warning that umlauts in file names are not supported when not using UTF-8 as a system-wide charset. As I described there are many cases where UTF-8 is simply not an option yet due to legacy data. However, I still don't understand why other applications simply don't have this problem and map all characters correctly according to the charset in use. Jens
I found the same problem when opening (!) files with OpenOffice from 10.1 beta9. It's impossible to open files with umlauts in their names :-( (I use de_DE@euro as locale - but I agree with Jens that using a non-default charset should not cause such a problem. Other applications can handle this, too.) Please consider reopening this bugreport!