Could you explain a little bit more about XIM for those of us
unfamiliar with it and its importance in enabling you to input
Japanese characters? I learned a little bit about it by googling, but
a more thorough explanation from you about its context in Nautilus
i18n usability would help us.
Thanks.

Sure. This is the case for japanese, but I think it applies to other
languages as well. 

In the case of most japanese XIM's, what usually happens is you click
on some kind of input field (whether it be a text box, a url field, or
in this case the selection of text when renaming an icon) and then the
user hits "shift-space" (this is configuration dependent, but most
japanese IMs have this setting). Once this happens, a status window of
some sort pops up, indicating the IM is active. (when i say IM here, i
mean the XIM frontend.. at least in the case of japanese, the input
mechanism is broken into two parts.. a frontend and a backend. The
backend is usually a daemon process that listens for clients and is
home to all the character-conversion functinoality. The frontend is a
glue between the GUI, the XIM protocol, and the protocol that the
backend supports)

To input characters, then, a user will first input the phonetic
representation of the text we wishes to type, then using the IM,
convert that to the intended characters.

Because there are so many characters (especially in chinese, japanese)
that this is the only way to manageable input those characters.
(Imagine a 2000 key keyboard ;-)) (also, when i say only, that just
means to say no one has figured out a better way yet ;-))

Unfortunately, if an application does not support the XIM
infrastructure, then hitting shift-space results in, well, just a
space. And from that point on, no japanese (or chinese, korean for
that matter) characters can be entered.

Gtk solves the problem somewhat by integrating the input method
support into all its components. Any recent gtk application (both gtk1
and gtk2) can recieve japanese input, provided that the environment is
set up correctly (i.e. the XMODIFIERS varialbe is set, and an XIM
server is running) This does not mean, however, the app knows what to
do with the inputted characters. because jap characters will come in
as some double byte encoding (typtically euc-jp or sjis), many (i'm
not gonna say "poorly designed" but rather i18n "unaware") programs
choke on the string data that was inputted.

In relation to nautilus, when a user clicks the "rename" option frmo
the context menu, and the icon title becomes an active selection of
text.. it is a natural expectiation of a japanese user to be able to
hit "shift-space" at this point, invoke the input method, and specify
a name in japanese. (indeed this can be done with konqueror) But
instead, we just get spaces..

As far as implementation goes, I'm not really too familiar with the
XIM protocols and APIs, but every gtk2 app that supports jap input
seems to have some kind of GtkIMContextXIM object that it uses, so
perhaps there are some hints there. It appears that there has been
much work going into implementing a good XIM system for gtk2, so I'd
recommend that if someone is to try to solve this problem, they reuse
to functionality of gtk, instead of rewriting new input support (this
can get really ugly from what i understand.. qt3.0.5 still doesn't get
it right)

hope this was what you were looking for, if not, let me know

Considering that there is a workaround (albeit a kludgy one) I'm not
going to mark this up.  But we should still definitely look at it. 

I think the new rename widge supports this could you please let us
know? ( you need nautilus cvs head)

nautilus should support input methods now it needs some testing. A sun
guy is working on the other bug so marking it a dupe of that one.

*** This bug has been marked as a duplicate of 95429 ***