bug in bzrlib/trace.py (bzr 0.0.3)
mbp at sourcefrog.net
Mon Apr 11 02:19:10 BST 2005
On Wed, 2005-04-06 at 19:36 +0300, Taneli Vähäkangas wrote:
> there's a slight bug in bzrlib/trace.py on line 105 that triggers if
> username gecos field has other than ascii (bad practice, I guess, but
> that's what I had). The attached fix works around it by assuming
> latin-1, which is just as bad (but happens to work for me), but I
> have no idea what the real fix would be.
I don't think it's bad practice to have non-ascii characters in there.
I don't think we can just assume it's latin-1 either though.
I suppose it should be determined by the locale settings?
I think in general we need to deal with two encodings on different edges
of the program:
- UTF-8 for all bzr internal data
- whatever $LANG specifies, for the user's environment: command line,
getcos, commit message files, bzr log output, etc etc. In python this
will appear from locale.getdefaultlocale()
That doesn't cover every situation, like a person on a latin-1 machine
wanting to write commit messages in Japanese UTF-8, but perhaps it's
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: This is a digitally signed message part
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20050411/9532b7d1/attachment.pgp
More information about the bazaar