On Mon, Oct 08, 2001 at 05:00:27AM +0200, Christian Rose <menthos@xxxxxxxxxxx> 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 ;)
(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).
> my editor doesn't (Emacs)
It can be taught to. I worked with vim-5.6 and utf-8 for a long time, and
vim does have no native support.
> 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).
> 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 think the main problm is that people aren't aware of all this.
> > 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.
> 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.
And pinning down on iso-8859-1 is, again, neglecting most of the world.
> > 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 ;)
> 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? gnus already converts utf-8 to local charsets (and back)
fine. and utf-8 support is high priority I would think.
> 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.
But anyways, yes, the single-file-idea is a bad one.
> > > 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?
> Nevertheless, insulting me doesn't make your opinion more valid.
Nobody is insulting you. But if you think so, I will try to be more careful
in the future.
> 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.
> 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.
> And so we do in fact agree...
On these points: certainly ;) And even without any insult, believe me!
--
-----==- |
----==-- _ |
---==---(_)__ __ ____ __ Marc Lehmann +--
--==---/ / _ \/ // /\ \/ / pcg@xxxxxxxx |e|
-=====/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+
The choice of a GNU generation |
|
