http://code.djangoproject.com/ticket/4846

=3==3=3

텍큐를 개발하는 건지 django를 개발하는 건지... orz;

textcube 홈페이지도 Django로 만들고 있는데요, 역시나 i18n의 중요성을 깨닫고 있습니다. ㅠㅠ;;
(여기서의 i18n은 번역이 아니라 테스트에 관한 겁니다)

Django 개발자 커뮤니티에서 지난 5월 경부터 branch되어 개발되어 온 full-unicode branch가 하나 있었는데, 이게 며칠 전에 메인 소스 트리로 merge되었습니다.
예전 태터툴즈로 따지자면 태터툴즈에 티스토리 소스를 merge한 것과 같은 격입니다. (교주님 기억 나시죠? -_ㅠ)
이 branch는 Django 내에서 사용되는 모든 문자열을 unicode로 처리할 수 있도록 하는 다양한 변화 사항을 담고 있습니다.

근데 문제는, 원래 Django의 개발 트리에서 HTML Form을 출력해주는 부분을 newforms라는 클래스 라이브러리로 새로 개발하고 있었고, 이에 맞춰서 사이트 관리자 모드도 함께 새로이 개발 중이라는 것과 관련이 있습니다.
현재 사용되는 사이트 관리자 모드는 '어차피 버려질 것'으로 생각했는지 그쪽 코드에는 unicode 관련 처리를 하다 만 거지요. -_-;;;

그래서 관리자 모드에서 DB model을 건드릴 때마다, 건드리는 동작 자체는 잘 수행된 다음(여기는 merge가 잘 되어 있음), 관리자 DB에 log를 남기는 부분이 있는데 여기서 한글 처리를 못하더군요.
역시나 테스트 케이스에 CJK 문자열이 없어서 그런지 -_- 티켓도 없고 그쪽 커뮤니티는 깜깜한 듯합니다;
걔네들이 직접 CJK 문자열을 넣어서 테스트를 해봐야 하는데 하질 않으니 full-unicode 지원이다 해놓고 막상 안 돌아가는 거죠. ㅠ_ㅠ
(해당 에러메시지로 구글 검색해보면 중국/타이완 쪽 페이지만 몇 개 있고 영미권은 전혀 없는.....)

하아, 아무튼 당분간 Django하고 이것저것 씨름 좀 해야 할 듯 합니다. ;;

ps. 그럼에도 Django가 대단한 게, 소스를 들여다볼수록 참 잡다한 처리를 잘 해놨다는 걸 알 수 있습니다. sql 쿼리문을 실행한 다음에도 db 엔진하고 통신해서 쿼리가 수행은 되었으되 warning이 발생하지는 않았는지까지 다 체크를 하게 되어 있더군요. (체크해서 이상이 있으면 exception을 발생시켜 줍니다.) 이 에러도 그 exception의 stack trace를 따라가면서 잡아냈죠.