I can confirm this issue. On the Mac, OO3.1.1 behaves erratically with
international characters in filenames.
For instance, when saving a file an n-dash gets translated into a - (minus sign)
and an ï (i-umlaut) into %EF (these are just two examples, I suspect all
international characters have problems). This results in the file written with
an incorrect name, or even in an incorrect directory (if the international
character was in the directory name).
Worse, if you try to open a file with international characters (e.g., if you try
to import a picture file with such a name), you get an error.

It seems the file manipulation dialogues are not coping with international
(UTF-8?) characters properly.

Sure hope this gets fixed soon.

Oh, one more thing: I also tested the behaviour of OO's own file dialogues,
these do not seem to support international (UTF-8) characters at all. Here the ï
is displayed as ï...

According to the policies below this is no P1, it is even questional whether
this issue is P2 since there is an easy workaround that allows to edit the file
( just to rename it ).
http://www.openoffice.org/scdocs/ddIssues_EnterModify.html#priority

From other side if it is a problem in the office it should of course be fixed.

changed Prio

I have just installed OOO310m19 on Mac OS 10.6 and it works like a charm with
Russian symbols in the file names.

mav->hrbaan,skladko: Please check that your file system supports UTF-8. By the
way, which version of Mac OS do you have? Which platform ( Intel, PPC )?

Mav,

Are you sure it works for you? Have you tried reopening the file, and does the
filename show up correctly in Finder?

Saving a new file works for me too, but then the filename gets garbled and the
special characters get replaced with %xx codes. It looks as if OO somehow thinks
it is generating filenames for the web (also because it translates – (endash) do
- (minus sign).

I just tried again, now with the filename ©ßøӁӪ (just some random characters),
when I save this file, the filename gets garbled to %A9%DF%F8?? (both in finder
as well as on the command-line). This file I can open just fine by the way, and
the application shows it in the window titlebar as ©ßøӁӪ. This again suggest,
some superfluous (web?) translation of filenames is taking place.

As a side note, I have tried both the OS version and OO's own version of the
file open/save dialogues and files that do have international characters in them
show up correctly in the OS version (as expected), but get completely garbled in
the OO version (©ßøӁӪ.txt becomes ©ÃøÓÓª.txt for instance). In the OO
version of the file dialogue, I can open this file (title bar show the garbled
name), with the OS version I get a file does not exist error.

There is definitely something wrong here. Hope you can solve it.

I'm on 10.5.8 on an Intel Mac Pro. OO 3.1.1 (OOO310m19 (build:9420)
The file system does support UTF-8 characters in filenames (it's HFS+, case
insensitive) and all other applications I've tried support them as expected.

mav->hrbaan: Yes I am sure that it works for me. I have tried all the scenarios
mentioned in the description. I thought that it makes no sense to mention them
second time, but if it helps...
- Create a new document and store it with the name русский.odt
- find the document in the Finder ( it looked good ) and open it with double click
- open the document using system dialog
- open the document using OOo dialog

That does not mean that there is no problem. That only means that your
environment has something special that let the problem be reproducible. So I
need more info.
From where did you download the installation?
What does "locale" command show in the terminal?

Hmm, now things get interesting :( It definitely works for you but not for me...

As an extra test, I also tried your document name but that gives me the same
problem (filename ends up as ???????.odt).

I downloaded OOo_3.1.1_MacOSXIntel_install_en-US.dmg directly from the homepage
of openoffice.org and to make extra sure I got the right one, I just downloaded
the file again and compared it to what I used to install OO 3.1.1. The files
were exactly the same, so that is not it.

The output of locale on my system is:
~$ locale
LANG="en_GB.UTF-8"
LC_COLLATE="en_GB.UTF-8"
LC_CTYPE="en_GB.UTF-8"
LC_MESSAGES="en_GB.UTF-8"
LC_MONETARY="en_GB.UTF-8"
LC_NUMERIC="en_GB.UTF-8"
LC_TIME="en_GB.UTF-8"
LC_ALL=

Perhaps noteworthy: this OO installation is an upgrade to a previous version.

If you need more info, please let me know!

Well, I defined it as P3 priority, but to me it seems p1 as the open office is
unable to open the attachment in the mail.app directly but you have to make this
"sophisticated" workaround to rename the file getting rid of the international
characters. Come on guys, I appreciate your work, but this is a syndrome of an
amateur work.. I can save the attachment, rename it and work with it. Or save it
without any utf characters, but I am an advanced user. What do you say to the
average user? use open-office and ask the neighbor for the workaround?... :-)
well, well, well..

why this issue isn't set to NEW -< I do it

mav->mechtilde: Please read the description, the problem is currently not
reproducible on our side. So we just can not set the issue to new.

mav->hrbaan: Hm, I must confess, I am out of ideas currently. It is hard to say
anything without possibility to reproduce the problem. I will try to play with
the scenario when I get time. Currently OOo3.2 takes the whole time.

Taking the issue over.

mav, I hope you can solve it; it really impedes my work bit as some of my
folders contain special characters and with the bug I can not edit files in them
(they'll end up in a new folder with a "translated" folder name). As a
work-around I put them on my desktop and create a hard-link to them in terminal.
This way they at least (also) reside in their proper location.

Thanks,
    Hayo

For your information, the problem still exists in version 3.2.0 (OOO320m12,
Build: 9483)

And is still present in 3.2.1.
This is becoming very annoying; not being able to open your documents in a
directory with special characters in it. Can this please be fixed asap?

Mac OS X 10.6.3 English

Thanks,
    Hayo

Issue 112708 might be a DUP with some interesting hints

Ok, with the information in
http://www.openoffice.org/issues/show_bug.cgi?id=112708 I did some more
experimenting and I think I found the cause of the problem we're having here.

When, after selecting your region, you do not alter any of the settings on the
panel it works. Changing one of the settings (e.g., the currency) causes the
problem with the files with international characters.

Here's how you test this:
1) on the System Preferences | Language & Text | Formats pane, select the region
you want to use without changing any other setting.
2) Log-out and then back in (this step seems mandatory).

Now you are able to open, edit, and save files with international characters in
them.

3) Change one of the formatting options (e.g. the currency) of your selected region
4) Log-out and then back in.

Now you are NOT able to open, edit, and save files with very same files
international characters in them anymore.

I hope this helps to get this fixed :-)

of: Giving a new target.

*** Issue 112690 has been marked as a duplicate of this issue. ***

*** Issue 112708 has been marked as a duplicate of this issue. ***

*** Issue 92697 has been marked as a duplicate of this issue. ***

I also noticed the problem was related to the currency settings. Moreover you
can see ktrace information I got against an old version (this was OOo 2.1 in
March 2007): http://qa.openoffice.org/issues/show_bug.cgi?id=67438#desc23

*** Issue 114525 has been marked as a duplicate of this issue. ***

Ok, the problem is that the wrong currency is set, and the locale based on the
specified language and currency does not exist. In this case a default value is set.

It is definitely no defect, since the system settings are wrong. It is more an
enhancement to let OOo workaround the wrong settings gracefully. Adjusting the
Issue type and Summary.

mav->pl: The implementation mentioned below
http://svn.services.openoffice.org/opengrok/xref/DEV300_m93/vcl/unx/source/app/i18n_im.cxx#235
seems to try the locale and get the ASCII default if the locale does not exist.
Probably the fallback mechanics could be extended to try the current settings
without currency first and only after that the default solution. Could you
please take a look.

Since that code does not even get compiled on Mac, I somehow doubt that is the
source of the problem ;-)

Indeed, this sourcecode is no more used, I was confused by the link to the log
from OOo2.1.

The problem was that the internal locale representation in sal library was not
correctly generated because of too small internal buffer in this case. Fixed in
cws fwk160.

Just a note to say that there are two currency settings on the Mac: the Mac OS X
specific settings (which are *not* related to the locales) and the locale
settings (LC_MONETARY). In my case, LC_MONETARY is set to POSIX. There is
nothing wrong with that, and "It is definitely no defect, since the system
settings are wrong." is thus incorrect.

Ok, so the problem is fixed now, great! When will we see a release with this fix
implemented?

Thanks,
    Hayo

As the target milestone field shows, the bugfix is currently planned to be
integrated in OOo 3.4 release.

mav->tm: Please verify issue.

.

checked and verified in cws fwk160 -> OK !