On Mon, Oct 08, 2001 at 05:00:27AM +0200, Christian Rose <[EMAIL PROTECTED]> 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      +--
      --==---/ / _ \/ // /\ \/ /       [EMAIL PROTECTED]      |e|
      -=====/_/_//_/\_,_/ /_/\_\       XX11-RIPE         --+
    The choice of a GNU generation                       |
Gimp-developer mailing list

Reply via email to