"pcg"@goof.com ( Marc) (A.) (Lehmann ) wrote: > > My mailer doesn't (pine) > > pine doesn't even parse rfc822 addresses (like mine) - let's face it, pine > is the worst mailer around with regards to features, standards compliance > etc. Everybody is free to use it, but citing pine as an example of a > modern, average program that doesn't support utf-8 is just unrealistic ;) Heh, I'm bound to agree. pine hasn't even supported iso-8859-1 by default for that long, a long time it was configured just for ascii by default. > (As a matter of fact, most people use netscape, outlook etc.. which > work fine, probably kmailxxxtool does as well. All these programs are > maintained and at least try to comply with standards). I'm not sure about Netscape though. > > my editor doesn't (Emacs) > > It can be taught to. Yes, there are two bad hacks for enabling *some* UTF-8 support in Emacs, but I think you're forgetting that this was about native support? > I worked with vim-5.6 and utf-8 for a long time, and > vim does have no native support. Actually wim 6.0 is said to have native UTF-8 support, but that doesn't change a thing for those who dont use vi/vim. :-( > > my terminal doesn't (gnome-terminal) > > it still doesn't need to support utf-8 to display unicode - at least > the subset you are interested in. gtk will soon support utf-8 (put > differently: the next release will). I know about that, thank you, but full native UTF-8 support in gnome-terminals terminal widget still needs to implemented even when gtk+ 2.0 is released. > > my irc client doesn't (xchat), and lots of ordinary console text tools > > don't. > > I have no idea what console text tools are meant to be. Most text-utils > trivially support utf-8 (they basically don't care, and modern systems > often offer a utf-8 locale (glibc does), which makes lots of x programs > and text utils act wonderfully! (i can even enter utf-8 in rxvt ;)). I've experienced problems with multibyte characters in the past at least with tools like less. Also, no sane UTF-8 fonts seem to be supplied by default, so even if the tool doesn't care, it requires trickery to get correct output. > I think the main problm is that people aren't aware of all this. I think the main problem is that it requires a lot of tweaking to get even some UTF-8 support for a lot of applications, if they even claim to support it. > > > utf-8 support is more common than supprot for most other charsets, > > > actually. > > > > Hardly compared to iso-8859-1, which I was referring to. > > Again, by far the majority of languages cnanot be represented in > iso-8859-1. Heck, even most of europa can't, strictly speaking. What has this to do with it? You claimed that UTF-8 support was more common than support for most other charsets, and I pointed out that this was hardly true for iso-8859-1. > > No it's not. Tell me any console text tool that *doesn't* handle > > iso-8859-1 correctly by default nowadays. > > I still don't know, but neither bash nor epic nor ircii do that until > configured to do so. Bash is configured to support iso-8859-1 by default, since even LC_CTYPE="en_US" specifies iso-8859-1. When it comes to ircii, I have to admit that you are right, but if you could insist that I shouldn't use pine because it sucks, I could say the same about ircii. > And pinning down on iso-8859-1 is, again, neglecting most of the world. How very true, but you're forgetting what you claimed earlier. You claimed that UTF-8 support was more common than support for other character sets. I'm simply pointing out that you seem to be wrong in that aspect. > > > Hint: you cannot represrnt the majority of languages with ascii. > > I'm very well aware of that fact, thank you. > > I don't think so ;) Why? > > I know that, but if I'm understanding it correctly, you are suggesting > > that iconv be used manually before and after every translation update as > > extra steps? > > Are you suggesting that the holy emacs is incapable of such a primitive > thing itself? Yes it is, unfortunately. > gnus already converts utf-8 to local charsets (and back) > fine. and utf-8 support is high priority I would think. It seems to have been a high priority for quite some time then. The Emacs page still mentions "We are now working on Unicode support" just like it did almost a year ago when I last checked. This is my point, things are moving slow when it comes to UTF-8 support in tools, and for many western European locales forcing use of UTF-8 will actually be a step backwards in terms of support, and a pain to use, and actually slowing down other localization work for these locales. That is why I advocate that UTF-8 should be converted automatically when needed, and not forced down the throat of people that need working tools for the time being. > > Manual steps that are completely unnecessary since intltool > > does this automatically. > > If your editor forces you to do that manually you should exchange it for > something that works. Please don't start that editor war. > But anyways, yes, the single-file-idea is a bad one. I couldn't agree more. > > > > I'm sure you'll find out many other surprises when you check what text > > > > tools in any major GNU/Linux distribution actually fully supports UTF-8, > > > I'd say the majority does. > > In my experience, that's far from true. > > I use them every day - are you sure you really tried? Yes. A couple of months ago I spent more than a day with investigating UTF-8 support in applications, and analyzed the UTF-8 howto in detail. I quickly realized that UTF-8 support wasn't at all comparable to iso-8859-1 support for a lot of reasons, and that it made no sense to force people to edit UTF-8 directly at that point, instead of automatically converting (using iconv) when needed. And that hasn't changed much. > > Why would this manually piping be favorable over using intltool that > > already does this automatically, requires no additional manual steps in > > I don't know - I didn't offer an answre to this question. It would certainly > make it possible to use utf-8 as the main format for files, though. Yes. > > I'm a translator for a non-ascii language, > > Make it non-latin1 then. Most of europe has a slight compatibility problem > now, since iso-8859-15 will be very common very soon now. True. I was simply referring to the "non-ascii" part. > > And so we do in fact agree... > > On these points: certainly ;) And even without any insult, believe me! Heh. :) Take care, Christian
