Markus Kuhn <[EMAIL PROTECTED]> writes:
> > Anyway, the original question was why *Red Hat* decided not to ship
> > utf-8 on by default for those locales. I was imagining that there must be some
> > technical reason, because despite its drawbacks, utf-8 is still much
> > more advantageous, so political sensitivity alone doesnt seem reason
> > enough...
Some of main reasons for not switching for CJK locales were:
* A lot of Japanese (and to a lesser extent Chinese, Korean)
tools (such as input methods) are really localized for particular
encodings rather than internationalized. There was more of a gap
between what existed and what needed then for Western locales.
* Some stuff has only partial UTF-8 support that doesn't cover
CJK (emacs comes to mind)
* Generally just a bit more components to internationalization
to deal with. (More fonts, input methods, printing is harder)
* Just not enough time to do the testing.
We do hope to get these locales switched as soon as possible.
> Another question is, why did RH8 switch to UTF-8 by default for everyone
> else already. Even though UTF-8 support has improved dramatically over
> the last few months (Emacs 21, perl 5.8, bash), in practice still a lot
> of widely used applications are not ready for it and will case user
> dissatisfaction. A2ps and pine come to mind as important examples used
> at this place.
There has been suprisingly little user disastification, for one
reason or the other. Not sure why exactly. US-centric user base?
Techie user base that uses English anyways? Easy enough to switch
back? People who understand the problems think UTF-8 is a good thing
and are willing to accept some pain? People too busy complaining
about our GNOME and KDE themes? You can come up with lots of
theories.
Emacs is probably my biggest area of disatisfaction for UTF-8
support. But then again, I probably deal with a lot more different
languages in texts I want to edit than most people.
> Perhaps Linux distribution developers in the US who do not have a single
> non-ASCII key on their keyboards underestimated the consequences of this
> switchover. On the other hand, I have by no means any objections against
> forcing the issue a bit, especially in the countries where most Linux
> application developers are located. The Linux community has never shied
> away from radical changes that break lots of old installations in the
> interest of what is eventually a far better system (ELF, glibc, etc.).
> So UTF-8 is just the next major improvement to the Linux platform that
> will cause a bit of a temporary headache here and there.
Hmm, well, I don't think we underestimated the consequences of the
switchover ... we have quite a few developers who are not exclusively
English-speakers.
Why do it now?
- We wanted to do it at a major version revision; putting it off
could have meant a substantial delay (years)
- The more we waited, the worse it would get to switch; the
expectations of our eustomers for stability don't _decrease_.
Plus the worse the "random encodings in filenames" issue got.
- To some extent we _did_ see a need to force the issue; the
number of people who were testing UTF-8 locales and reporting
issues was very small.
- There is a substantial fraction of the Linux codebase which
has been traditionally been of the "works for latin1 and patches
exist for Japanese" nature. It's easier to fix things for UTF-8
than for N different encodings. (If you use fix it to use mbs*,
it should fix everything, yes, but that's not always feasible.)
Regards,
Owen
--
Linux-UTF8: i18n of Linux on all levels
Archive: http://mail.nl.linux.org/linux-utf8/
