On Fri, Mar 28, 2003 at 11:32:21AM -0800, H. Peter Anvin wrote: > WHOA... that's a pretty darn strong statement. In particular, that > would seem to request internationalization of kernel (or other > debugging or logging messages), which is probably a completely > unrealistic goal. > > For user-interface issues, I would agree with you however.
I think handling i18n in cooked input mode is realistic and important. (This is both UI and kernel.) > When it comes to (a), it pretty much means that the complexity needs > to be hidden from the application programmer. Terminal applications, > toolkits, and perhaps libraries like readline need to support this, > but applications shouldn't need to be affected beyond a few basic > guidelines, such as don't assume byte == character. Getting UTF-8 > universally deployed will be a huge part of this, because it means > that anything other than 7-bit ASCII will have to take this into > consideration. Chicken and egg. :) > > Of course several Japanese companies are competing in Input Method > > area on Windows. These companies are researching for better input > > methods -- larger and better-tuned dictionaries with newly coined > > words and phrases, better grammartical and semantic analyzers, > > and so on so on. I imagine this area is one of areas where Open > > Source people cannot compete with commercial softwares by full-time > > developer teams. > > This seems to call for a plugin architecture. More than anything I > suspect we need *standards*. And, in this case, non-GPL licensing (if being able to use proprietary input method plugins is desired) ... -- Glenn Maynard -- Linux-UTF8: i18n of Linux on all levels Archive: http://mail.nl.linux.org/linux-utf8/
