It is already Friday here in Japan. But I presume it is still not for most of you, and I hope it all right for me to turn down all the objections I've expressed here towards Dekel Tsur's efforts for the LyX internationalization instead of accusing him further. Today Sun Microsystems is supposed to release their i18n technology open source to X org: http://www.sun.com/smi/Press/sunflash/2000-08/sunflash.20000829.1.html Among other things is IIIMF an Input Method Framework which enable an X client to connect to (possibly multiple) Input Method Server(s) of different locale(s) than that of the process. --Remember, unlike C++, C process has only one locale object-- If this technology becomes a commonality which is widely available, not only on XFree86, then my argument against Dekel's effort will lose the ground. I had proceeded as thus: - some languages, especially Japanese and Korean, requires very sophisticated language engines to be input, which unlike keymaps are obviously too complicated and large to bundle with LyX; - currently X allows an X client to connect to an IM server which may in turn connect to language engines, but only in the process locale (LC_CTYPE) of the client; - so, for such languages, the process locale of LyX and the document language to be edited must be the same; - for CJK which employs thousands of glyphs, a Unicode based text drawing will be inefficient and very complicated (bug prone) unless Unicode fonts are availble; - Unicode CJK fonts are cheaply available only in bitmap (not scalable) and TrueType (not widely supported on X) formats; - then, since the process and the document locale must coincide for such languages, why don't you use the Xlib built-in locale based text drawing method rather than reinventing the wheel in an inefficient Unicode based manner; Dekel already had answered that the point 4 will not count once we adopt to use FreeType for better rendering. Now the points 2, 3, and 6 will no longer be true. What do you think? Regards, SMiyata