Yet another locale problem

Gentoo January 27th, 2008

In the last post, we manage to leverage eye3D for standardizing the ID3 tag. But we still got messy code when manually manipulating the tags in the command line. It may result in either wrong arguments or encoding bug.

Further investigation focused on eyeD3’s __init__.py:

LOCAL_ENCODING = locale.getpreferredencoding(do_setlocale=False);
if not LOCAL_ENCODING or LOCAL_ENCODING == "ANSI_X3.4-1968":
    LOCAL_ENCODING = ‘latin1′;

Either LOCAL_ENCODING is None or mysterious ANSI_X3.4-1968, the encoding is assumed as latin1. In my Gentoo box, with do_setlocale set False, getpreferredencoding just returns ANSI_X3.4-1968 though the locale is en_US.UTF-8 instead.

According to the documentation:

On some systems, it is necessary to invoke setlocale to obtain the user preferences, so this function is not thread-safe. If invoking setlocale is not necessary or desired, do_setlocale should be set to False.

I need to dig into whether Linux belongs to some systems. Right now, just apply the patch to eyeD3’s __init__.py:

37c37
< LOCAL_ENCODING = locale.getpreferredencoding(do_setlocale=False);
---
> LOCAL_ENCODING = locale.getpreferredencoding(do_setlocale=True);

And remember to specify the encoding of tags using –set-encoding , RTFM for more details.

Share and Enjoy:
  • Print this article!
  • Digg
  • Sphinn
  • del.icio.us
  • Facebook
  • Mixx
  • Google Bookmarks

One Comment to “Yet another locale problem”

  1. Travis ShirkNo Gravatar | January 28th, 2008 at 6:48 am

    Exactly right, in fact this change lives in eyeD3 svn and will be in the next release.

    -travis

Leave a Comment

This site is using OpenAvatar based on