[ruby-core:35524] Re: [Feature #2350](Rejected) Unicode specific functionality on String in 1.9

The problem is that the definition of #upcase doesn't only depend on the
encoding used, but also the language of the encoded text. For instance, if
you're writing in Turkish, you would expect "i".upcase to return a dotted
uppcase I: http://www.i18nguy.com/unicode/turkish-i18n.html

<http://www.i18nguy.com/unicode/turkish-i18n.html>Doing this properly is
*really* hard and needs to have a lot of flexibility, especially when it
comes to non-Western languages. It's far easier for everyone that the
built-in #upcase is simple and fast and you'll have to be explicit about an=
y
other I18n stuff IMO.

// Magnus Holm


On Fri, Mar 18, 2011 at 11:19, Nikolai Weibull <[e-mail]> wrote:

> On Thu, Mar 25, 2010 at 19:33, Nikolai Weibull <[e-mail]> wrote:
> > On Thu, Mar 25, 2010 at 18:24, NARUSE, Yui <[e-mail]> wrote:
> >> (2010/03/26 0:02), Nikolai Weibull wrote:
>
> > I was wondering if there was a way to do it without having to do
> >
> > String.new.unicodify.upcase
>
> >> But I think, people want both ASCII version and Unicode version of
> upcase.
> >> So you should name your Unicode methods another names.
>
> > Why would they want that?  Having an ASCII-only version of #upcase
> > makes no sense for a Unicode String more than supporting #upcase
> > requires that you load the Unicode character database information,
> > which takes up quite a lot of memory.
>
> So, what=E2=80=99s the reasoning here?  Having "=C3=A4bc".upcase return "=
=C3=A4BC" makes
> absolutely no sense and means that quite a few methods on String are
> completely useless in a m18n context.
>
>