"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

> (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 ;)


> > 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.


> > 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,
Gimp-developer mailing list

Reply via email to