Comment 14 for bug 1580678

It might be worth noting, that in the *other* critical bug related to this issue - the translation string was already unicode [1] ... so then the fix was to take the bytestring arguments and turn them into unicode.

In the suggested change [2] we're going out of way to ensure that we *always* get unicode out of gettext.

So going forward *anytime* we try to encode non-ascii bytes into into a translated string we're going to blow up regardless of the locale (in lp bug #1597210 - the locale didn't matter either - just the presence of non ascii bytes in the arguments to the unicode translation message).

So rather than fixing some "root cause" - making all translated gettext messages unicode will in someways make unicode errors *more* likely!

Bytes to bytes would always "just work" - so I think it's funny that the best path forward is probably to introduce *more* unicode so that we can't cheat - but it's very much dependent on our tests helping us out to ensure that when we try to introduce non-ascii utf-8 bytestring sources it run through the real machinery! :D

1. because of the additional unicode ring arguments interpolated into the utf-8 bytes coming out of the translation function forced the entire string to become unicode https://review.openstack.org/#/c/338950/1/swift/proxy/server.py@512

2. https://review.openstack.org/#/c/323950/4