Martin von Loewis wrote: > > > Hmm, if your catalogs are encoded in UTF-8 and use non-ASCII > > chars then the traditional API would have to raise encoding > > errors > > I don't know what you mean by "traditional" here. The gettext.gettext > implementation in Barry's patch will return the UTF-8 encoded byte > string, instead of raising encoding errors - no code conversion takes > place. True. > > Perhaps the return value type of .gettext() should be given on > > the .install() call: e.g. encoding='utf-8' would have .gettext() > > return a string using UTF-8 while encoding='unicode' would have > > it return Unicode objects. > > No. You should have the option of either receiving byte strings, or > Unicode strings. If you want byte strings, you should get the ones > appearing in the catalog. So you're all for the two different API version ? After some more thinking, I think I agree. The reason is that the lookup itself will have to be Unicode-aware too: gettext.unigettext(u"Löschen") would have to convert u"Löschen" to UTF-8, then look this up and convert the returned value back to Unicode. gettext.gettext(u"Löschen") will fail with ASCII default encoding. -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4