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 any
other I18n stuff IMO.

// Magnus Holm


On Fri, Mar 18, 2011 at 11:19, Nikolai Weibull <now / bitwi.se> wrote:

> On Thu, Mar 25, 2010 at 19:33, Nikolai Weibull <now / bitwi.se> wrote:
> > On Thu, Mar 25, 2010 at 18:24, NARUSE, Yui <naruse / airemix.jp> 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°«s the reasoning here?  Having "bc".upcase return "BC" makes
> absolutely no sense and means that quite a few methods on String are
> completely useless in a m18n context.
>
>