Re: i18n, alternative solution

From: Robin Rosenberg <robin.rosenberg.lists@dewire.com>
Date: Jan 7, 2007, 16:55 UTC
Message-ID: <200701071755.34496.robin.rosenberg.lists@dewire.com>
In-Reply-To: <7vy7om7cs0.fsf@assigned-by-dhcp.cox.net>

måndag 01 januari 2007 20:44 skrev Junio C Hamano:

Show 9 quoted lines

> Robin Rosenberg <robin.rosenberg.lists@dewire.com> writes:
> > What disturbes me is the complexity that the approach of storing multiple
> > encodings in the same repository results in.
>
> We are not encouraging mixed encodings, mind you.
>
> Even though we check and warn comits that do not have a valid
> UTF-8 string, the users can make mistakes and people need be
> able to look at them later.  That is what we are solving.

My is to not convert at all if the uset has locale=UTF-8. Mostly it's an optimization, but it also has the effect of getting the raw message.

Show 6 quoted lines

> At the same time we do NOT force inconvenience on projects that
> want to use legacy encoding for whatever reason.  The world is
> not UTF-8 only, and encoding to UTF-8 is non-reversible a times 
> (positive return value from iconv(3)).  Always re-coding to
> UTF-8 will NOT be accepted to git for now.  We can revisit this
> perhaps in 5 years.

According to the unicode FAQ, unicode is a superset of all local encodings, so why would the conversion be non-reversible for local vs utf-8?

In five years there will be so much legacy, that fixing it in a simple way will be unfeasble (just like CVS, FTP, etc).

-- robin