[EMAIL PROTECTED] writes: > I understand that in the most general and abstract case it may not > be possible. If you had an interactive process that got feedback > from the user, it could learn about preferences and perhaps provide > better guesses in the future.
I guess "anything is possible" in software, but this one seems just like an enormous amount of work, for very little gain IMO. If it turns out that many other users also don't like having to specify the input charset, I may investigate this further (unless you'd like to attempt this yourself). > From my perspective, this particular problem arises from an > unfortunate coincidence of: > > 1) A mechanism in Python being a certain way > > 2) TMDA employing that particular mechanism > > 3) ISO-2022-JP escape sequences being a certain way > > It's very unfortunate that Python didn't get a lot of feedback from > Japanese-using users early in its development -- I suspect if it > had, this particular problem would not exist. I'm not sure that it's a problem specific to Python. Because ISO-2022-JP is 7bit, it contains many special characters like \, %, &, etc. which I think would cause problems for many languages when doing string manipulation. I've been told that regardless of application or language, EUC-JP is the best to use in programming because all the Japanese characters are msb set 1 (like UTF-8). So, I feel the problem is due more to the extra complexity arising from the fact that Japanese has three different encoding schemes. Anyway, you'd know better than me, but I was under the impression it would not be difficult for Japanese users to write their templates in EUC-JP. At least it doesn't seem to be a problem in the Mailman world. Time will tell I guess. _________________________________________________ tmda-workers mailing list ([EMAIL PROTECTED]) http://tmda.net/lists/listinfo/tmda-workers
