The source locale in APR is specified using apr_os_locale_encoding which in turn uses nl_langinfo which in turn bases its result on the locale currently enabled for the application.
Two important breakpoints are "setlocale" and "apr_os_locale_encoding". With them in place from the beginnin I get this sequence:
setlocale(LC_CTYPE, NULL) // query only
setlocale(LC_CTYPE, "") // set according to environment
setlocale(LC_CTYPE, "C") // set to US-ASCII default
setlocale(LC_CTYPE, NULL)
setlocale(LC_CTYPE, "")
setlocale(LC_CTYPE, "C")
apr_os_locale_encoding // repeated
So it looks like python would not set any locale settings by default in order to provide maximum compatibility for non-locale-aware applications. bzr itself seems to have no call to setlocale. I would suggest this line somewhere in the initialization code of bzr:
locale.setlocale(locale.LC_ALL, '')
So this is neither a bug in subversion nor a bug in bzr-subversion but rather a bug in bzr itself, imo. I'll associate a branch containing a suggested fix with this bug here. It's against bzr.dev, so it won't work directly with bzr-svn, but I'd hope the bzr people merge it to bzr 1.5 as well.
The source locale in APR is specified using apr_os_ locale_ encoding which in turn uses nl_langinfo which in turn bases its result on the locale currently enabled for the application.
Two important breakpoints are "setlocale" and "apr_os_ locale_ encoding" . With them in place from the beginnin I get this sequence:
setlocale(LC_CTYPE, NULL) // query only locale_ encoding // repeated
setlocale(LC_CTYPE, "") // set according to environment
setlocale(LC_CTYPE, "C") // set to US-ASCII default
setlocale(LC_CTYPE, NULL)
setlocale(LC_CTYPE, "")
setlocale(LC_CTYPE, "C")
apr_os_
So it looks like python would not set any locale settings by default in order to provide maximum compatibility for non-locale-aware applications. bzr itself seems to have no call to setlocale. I would suggest this line somewhere in the initialization code of bzr: setlocale( locale. LC_ALL, '')
locale.
So this is neither a bug in subversion nor a bug in bzr-subversion but rather a bug in bzr itself, imo. I'll associate a branch containing a suggested fix with this bug here. It's against bzr.dev, so it won't work directly with bzr-svn, but I'd hope the bzr people merge it to bzr 1.5 as well.