아주 오래 전부터 적용시키고 싶은 패치가 하나 있었다. 바로 KDE 3.x CP949 패치이다. Konversation이 자꾸 죽는 것은 둘째치더라도, 매일같이 뤂놈을 갈궈야 하는데 뤂이라는 글자는 EUC-KR에는 포함되지 않기 때문에, 프록시로 사용하고 있는 irssi를 켜서 뤂이라는 글자를 입력해 주는 수고를 해야만 했다. 그래서 해결책으로 Qt 3.x에 CP949 코덱을 추가하고, KDE 라이브러리에서 추가한 코덱을 인식시켜 주는 패치를 하면 되긴 된다. 허나 시도를 하면 할 때마다 실패해서 도대체 뭐가 문제인지 몰랐다. 며칠 전에 내가 미쳤는지 삽질을 해서 해결하기 시작했다.

Qt는 다양한 언어로 된 텍스트를 처리하기 위해서 텍스트 코덱이라는 것을 사용한다. 제일 미치고 환장하는 게 왜 Qt는 iconv라는 좋은 걸 놔두고 이딴 걸 쓰느냐기본적으로 들어있는 텍스트 코덱이 EUC-KR까지만 지원한다는 것이다. 하여튼 저기 용자 segfault 햏이 CP949를 지원하는 텍스트 코덱을 만들어서 트롤텍노키아에 갖다 바쳐서 Qt 4.3.0부터는 기본적으로 CP949 지원이 들어 있지만, 그 이전 버전이라면 대책이 없다. 여튼 Qt 3.x용으로 나온 CP949 패치와 KDE 라이브러리 패치를 여기에서 긁어서 빌드하기 시작했다.

일단 Qt 3.x용 CP949 코덱은 걍 빌드가 된다. 걍 빌드가 된다. 다음으로 남은 큰일은 고행이라고도 할 수 있는 KDE 라이브러리 패치이다. 이쯤에서 데비안 할렐루야를 외치고 싶어지는 게 패치 과정이 그다지 복잡하지 않은 편이기 때문이다.

• apt-get build-dep kdelibs
• apt-get source kdelibs

이 두 단계는 KDE 라이브러리를 빌드하기 위한 의존성이 걸려 있는 패키지를 모조리 깔고 KDE 라이브러리 소스 코드를 가지고 오라고 하는 단계이다. 어쨌든 apt-get source 명령을 실행하고 나면 KDE 라이브러리 소스 코드와, 데비안 패키지를 빌드할 수 있는 파일들이 떨어지는 것을 볼 수 있다. 자, 이제 저 링크에 있는 패치 파일을 debian/patches 아래에 02_cp949.diff라는 이름으로 복사해 넣고, debian/changelog를 잘 수정해서 버전 번호를 1 증가시키고(증가시키지 않으면 apt-get이 구토를 유발시킴) dpkg-buildpackage -rfakeroot -us -uc를 실행시키고 한참 기다리면 빌드를 다 해 준다. 내 T9300 CPU에서 약 한시간 남짓(정확히는 모르겠지만) 걸렸던 것 같다.

이론적으로는 저 빌드를 다 끝내고 생긴 deb 파일을 설치하면 CP949가 표시되어야 하는데, 텍스트 코덱으로 CP949를 선택하면 자꾸 죽어서 문제다. 혹시나 해서 Qt 3.x에 있는 qwerty라는 텍스트 코덱을 테스트하는 예제를 컴파일해서 실행시켜 봤는데 cp949 텍스트 코덱 자체는 인식했으나, KDE 라이브러리 단계로만 넘어가면 이놈이 자꾸 죽는다. 환장하겠다. 결국 Konversation을 디버그 빌드로 컴파일하여 무슨 문제가 생기는지 GDB로 짚어보기로 했다. 디버그 패키지를 빌드하려면 환경 변수 DEB_BUILD_OPTIONS=nostrip,noopt를 주고 dpkg-buildpackage를 수행하면 된다.

KDE 프로그램을 GDB 같은 놈으로 디버깅할 때 아무 옵션도 주지 않고 디버그를 수행하면 낭패보는 수가 있다. KDE 프로그램을 셸에서 실행하면, 눈치가 빠른 사람은 알겠지만 셸 프롬프트가 다시 떨어진다. 즉 fork()를 수행해서 셸에서 떨어져 나가서 실행되기 때문이다. 이 때문에 디버거를 돌리려면 –nofork라는 옵션을 줘야 한다. 또한 KDE의 충돌 관리자 Dr. Konqi가 실행되는 것을 방지하기 위해서 –nocrashhandler라는 옵션을 주고 디버깅을 시작해야 한다. QString과 같은 Qt 자료 구조 내부를 들여다보기 위해서 kde-devel-gdb 스크립트를 GDB에 설정해 두고 시작하는 것을 추천한다.

어쨌든 GDB로 충돌이 나는 부분을 찍어 보니 다음과 같았다.

저기 저 codec이라는 변수가 널 포인터 크리 덕분에 걍 비어 있었다. 그런데 왜 널 포인터가 뜨는 것일까 궁금해서 더 조사를 해 보았다. 저 codec이라는 변수에는 코덱이 넘어와야 하며, “cp949″라는 이름의 코덱이 설치되어 있는데도 불구하고 왜 널이 뜰까를 고민해 보다가, 텍스트 코덱을 생성하는 부분을 하드코딩해 보기로 했다. 그래서 “cp949″라는 코덱을 생성시켜 보았더니 널 포인터가 또 뜬다. 하아. 그렇다면 혹시, QTextCodec::codecForName(인코딩 이름에 따른 코덱을 만들어 주는 함수)이 대소문자를 구분하는 것 아닐까? 하드코딩한 부분을 “CP949″(대문자 주목)로 고치니까 그 부분을 뛰어넘는다. 할렐루야.

결국 텍스트 코덱을 다시 열어서, 이름에 있는 대문자 CP949를 소문자 cp949로 다시 고쳐서 컴파일한 결과 이번에는 널 포인터가 뜨지 않았다. 이런 우왕ㅋ굳ㅋ. KDE 라이브러리를 이것 때문에 통째로 다시 패치하느니, 대부분 Qt 텍스트 코덱의 이름이 소문자였기 때문에 텍스트 코덱을 다시 고치는 것이 빠르다고 판단했기 때문이다. 디버깅을 위해서 설치한 Konversation 빌드도 원상복구시키고 KDE 라이브러리만 패치 버전으로 교체하였다. 결국 뤂 패치의 끝은 이렇게 마무리되었다.

세줄요약.

1. Qt 3.x는 CP949를 지원하지 않으며, 4.3.0에 추가되었다.
2. QTextCodec::codecForName 함수는 대소문자를 구분한다.
3. 패키지 빌드는 오래걸리니 발 닦고 자면 된다.

KDE 4.x, 그리고 VirtualBox 등 내가 하고 있는 다양한 프로그램의 지역화에서 가장 신경을 쓰는 것은 여러 가지가 있다. 컴퓨터 프로그램의 지역화는 일반적인 책의 번역과는 다르게 접근할 필요가 있으므로, 나는 책을 쓰듯이 컴퓨터 프로그램에 웬만해서는 접근하지 않으려고 한다. 이 글에서는 지역화 과정에서의 용어 선정을 다루어 볼 것이다. 어떠한 용어를 사용하느냐에 따라서 느낌이 확 달라질 수도 있으며, 사용자들이 인식하는 수준이 과감하게 달라질 수 있다.

데스크탑 vs 데스크톱, 디렉토리 vs 디렉터리. 둘 중 무엇이 맞다고 생각하는가? 국립국어원 외래어 표기법 기준으로는 후자가 맞다. 맞춤법, 로마자 표기법, 외래어 표기법은 시간이 지날 때마다 바뀔 수도 있다. 그렇기 때문에 프로그램을 번역할 때에는 당대에서 가장 정확한 표기법을 사용하는 것이 올바르다. 그래서 KDE 4.x와 VirtualBox에서는 가급적이면 현재의 외래어 표기법에 따르는 데스크톱과 디렉터리를 사용한다. 언젠가 외래어 표기법이 바뀌게 된다면, 그에 맞추어서 바꿀 예정이다.

프로그램 이름. 한국에 무언가가 그 이름도 대개 한글로 음차하는 경우가 많다. 그러나 이 법칙이 성립하지 않는 곳이 하나 있는데 바로 IT 산업 분야이다. 신기하게도 프로그램 이름은 한글로 음차하지 않는다. 나는 이 관습을 굳이 따르려고 하지는 않지만, KDE의 프로그램 이름은 한글로 음차했을 때 별로 모양이 좋지 않기 때문이다.

과거에도 그렇고 현재에도 그렇게 미래에도 그렇듯이 KDE 프로그램들은 대문자 K가 그 안에 들어가 있다. K+일반적인 단어, 또는 일반적인 단어의 일부를 K로 치환하면 K 작명법이 탄생한다. 그런데 이 작명법의 의도를 무시한 채 K만 남기고 한글로 음차하면 모양이 그다지 좋지 못하다. 그렇다고 해서 K까지 포함해서 음차를 하면 단어가 쓸데없이 길어진다. 그리고 KDE 4.x의 기본 설정상, 프로그램 이름은 번역해 보았자 눈에 안 띈다. 아래는 KDE의 시작 메뉴이다.

보시다시피 프로그램 설명이 제일 먼저 보이고, 프로그램 이름은 마우스를 갖다 대어야 보이는 구조이다. 이러한 상황에서는 프로그램 이름을 억지로 음차하기보다는, 프로그램 설명을 더 자세히 쓰는 것이 사용자에게 더 직관적으로 다가올 수 있다고 생각한다. 아 물론 다른 데스크톱 환경은 신경을 안 쓰기로 했다. 그리고 음차하지 않음 규칙에도 예외를 두는데, KDE+일반 명사 형태로 되어 있는 프로그램들은 음차를 하더라도 모양이 그렇게까지 보기 안 좋은 것은 아니므로 그렇게 한다.

왜 KDE 번역에는 프로그램 이름을 그냥 냅두는가는 이 정도로만 설명해 두겠다. 일부 배포판을 번역하면서 KDE 프로그램 이름을 같이 번역하는 경우가 있는데 나는 개인적으로 그러한 행동에 별로 동의하지 않는다. 대표적인 예로 오픈수세 정도가 있다. 후일 다른 누군가가 KDE 5.x나 그 이후 번역을 맡는다면 몰라, 내가 관리하고 있는 동안에는 이러한 행동을 별로 허용하고 싶지 않다.

국립국어원에서는 부산대학교 우리말 연구실의 협찬으로 여러 가지 도움이 되는 것들을 제공해 주고 있으나, 번역자들에게 제일 중요한 외래어 표기법 관련 프로그램은 망가진 지 오래이다. 번역자들에게 가장 중요한 코너인 이것이 망가진 건 상당히 유감으로 생각한다. 어서 Bad Request가 뜨는 것이 고쳐지기 바란다.

심심해서 한 삽질.

KDE 4.0이 나온 지 얼마 되지 않았음에도 불구하고 KDE 4 시리즈에 관한 글이 거의 없는 것 같아서, 나름 사람들을 낚아 보기 위해서 이 글을 준비했다. 원래 계획은 4라는 버전 넘버에 맞춰서 4개를 준비하려고 했지만, 어쩌다 보니 글이 모자라서…

1. KDE 4에서는 한글 입력을 할 수 없다?

물론 뻥이다. 이 오해를 하게 된 것은 대부분의 입력기 모듈이 아직까지 Qt 4로 포팅되지 않아서 발생하는 것이다. 그리고 KDE 3과 달리, 아직까지는 텍스트 영역에서 오른쪽 클릭을 했을 때 “입력기 선택” 메뉴가 나타나지 않아서 오해를 하는 것일 수도 있다. 그러나 나는 현재 이 글을 KDE 4에서 쓰고 있다. KDE 4에서 한글을 입력하는 방법으로는, immodule을 사용하는 것과 xim을 사용하는 것이 있다. 비록 나는 전자를 사용하지만 후자를 추천하고 싶다. Qt 4로 현재까지 포팅된 입력기 모듈은 scim-bridge가 유일하다.

내 노트북에서는 scim-bridge에서 한/영 키가 잘 듣지 않는 문제가 있었다. KDE 3에서는 한/영 키가 제대로 동작했고, “한/영”+무언가 키를 눌러도 반응하지 않았다. 그러나 scim-bridge의 문제인지 KDE 4에서는 “한/영”+무언가 키를 누르면 반응한다. 짜증나서 Shift+Space를 사용하고 있지만, xim 기반 입력기로 바꿀 생각을 하고 있다. 아래 스크린샷은 scim-bridge가 작동하는 모습이다.

우분투에서는 im-switch를 사용하면 KDE 4의 입력기도 간단하게 바꿀 수 있다. 예전 버전처럼 QT_IM_MODULE을 사용해서 가능한 일이다.

2. KDE 4용 프로그램이 아직까지 많이 없다?

일부는 맞고 일부는 틀렸다. 사실 KDE 프로젝트 안에서 개발되는 프로그램만 쓴다면 문제가 없겠지만, 많은 사람들이 그렇지 않을 것이다. 내가 쓰고 있는 프로그램 중에서 KDE 4 포팅이 있는 것은 KTorrent, Yakuake이다. KDE PIM에 들어 있는 KMail, aKregator 이것들은 내가 자주 쓰긴 하지만 KDE 4.1에 포함된다고 하니 패스하고, 포팅되었으면 하지만 한참을 기다려야 할 것은 Amarok, Kile, Konversation이다. 아쉬운 대로 KDE 4와 3이 공존할 수 있다는 스크린샷이다.

그.러.나. KDE 4에서 KDE 3 프로그램을 사용해도 UI 모습이 다를 뿐이지 동작하는 데는 하등 문제가 없다. 다만 KDE 3 라이브러리를 남겨 둬야 하기 때문에 디스크 공간을 많이 차지하고, 프로그램 시작 시 이것들도 같이 불러와야 하므로 좀 굼떠지긴 한다. KDE 4의 그야말로 엄청나게 바뀐 내부 구조 때문에 이해하고 넘어가자. 사실 KDE에서 GTK 라이브러리를 사용하는 프로그램 불러오는 것보다는 이게 더 낫다(고 개인적으로 생각한다.)

3번과 4번은 QNA 형식으로 진행할 예정이다.

KDE 3과 비교했을 때, KDE 4의 번역은 놀라울 정도로 향상되었습니다. KDE 4를 번역하면서 다음과 같은 사항들을 최우선으로 고려하였습니다.

• 과도한 지역화를 지양한다.
• 가장 대중적인 단어를 선택한다.
• 가장 많이 사용되는 프로그램부터 번역한다.

과도한 지역화를 지양한다는 것은, 순 한국어 단어를 너무 사랑한 나머지 뜻도 통하지 않는 단어나 사어들을 마음대로 살려서 쓰지 않는다는 것입니다. 과거 KDE를 번역했던 사람은 순 한국어 단어를 많이 사용하였습니다. 그 시도가 처음에는 의미가 있었을 지도 모르나, 너무 오래 관리되지 않았기 때문에 전체적인 번역 완성도를 떨어트리는 데 많은 기여를 하고 있습니다. 그래서, KDE 4 번역부터는 과도하게 지역화된 모든 것들을 다 바꾸었습니다. 의미가 통하지 않는 순 한국어 단어는 적당한 외래어를 도입하고, 상황에 맞지 않는 단어들은 교체하였습니다.

가장 대중적인 단어를 선택하는 것은 인클봇에게 그 공을 돌리기로 하겠습니다. 구글의 힘을 많이 빌려서 어떤 단어가 검색 결과가 많았는지가 큰 기준이었습니다. 이 외에도 지인들에게도 물어 보면서 어떤 단어가 이 상황에서 적합한지 등 많은 고민을 하였습니다. 그 결과 좋습니다.

가장 많이 사용되는 프로그램은 무엇이 있을까요? 우선 무슨 일을 하든지 K 메뉴를 통해서 시작해야 할 것이고, 파일 관리자로 파일을 열고, 제어판에서 시스템 설정을 바꾸고, 메신저로 친구들과 대화하고, 웹 브라우저로 인터넷을 돌아다니고… 사람들마다 차이가 있겠지만, 많은 사람들이 쓰는 프로그램은 정해져 있습니다. KDE 4.0을 번역하면서, 사람들이 가장 많이 쓸 것 같은 프로그램을 우선 순위에 두었습니다. Dolphin이나 Plasma 같은 것들은 등장한 지 얼마 되지 않아서 문자열이 자주 바뀌었지만, 그래도 최대한 번역을 하기 위해서 노력했습니다.

아래는 KDE 4 번역을 사용하면서 생길 수 있는 의문(?)을 정리한 것입니다.

우리 일터쨩은 어디 갔나요? 또는 우리 일터쨩이 왜 여기에 있나요?

KDE 4의 어떤 po 파일에도 일터, 자료방이라는 단어는 존재하지 않습니다. 그런데 사용자에 따라서는 이 단어가 보일 수도 있습니다. 그 이유는 두 종류로 나뉘어 있는 메시지 번역 파일 때문입니다. KDE의 po 파일들은 프로그램을 위한 po 파일과, .desktop 파일을 위한 po 파일로 나뉘어 있습니다. 문제가 되는 것은 이들 중 후자인데요, 시스템 설정의 아이콘 이름이나 Konqueror 설정의 섹션 등은 후자가 관리합니다. .desktop 파일의 번역은 자동으로 이루어지는 것이 아니라, 번역자들이 업데이트를 하면 스크립트가 돌면서 .desktop 파일을 만듭니다.

그런데 리눅스 배포판에서는 이런 일을 하기가 매우 귀찮습니다. 따라서 문자열이 업데이트된 .desktop 파일은 자주 바뀌지 않습니다. KDE 3까지의 번역에는 이 단어들이 존재했기 때문에, 일터나 자료방이 보일 수도 있습니다. 이 문제는 배포판에 의존하는 문제이기 때문에, KDE 쪽에서는 손을 쓰기 쉽지 않습니다. KDE 4 시스템 설정 화면을 아래 스크린샷과 비교해 보시고, 차이가 있다면 그것은 배포판 쪽에서 해결해야 할 문제입니다.

아 짜증나요 이 문자열은 왜 이렇죠?

이것은 KDE뿐만 아니라 모든 프로그램에 다 공통되는 사항입니다. 흔히 사람들은 자기가 좋아하는 프로그램에 번역 문제가 있으면 번역자에게 직접 연락하기보다는 공개된 게시판 등에 한탄을 합니다. 그러나 이 방법은 근본적인 문제가 있는 게, 번역자들은 그 한탄을 일일이 다 검색할 의무가 없습니다. 자기가 시간이 나서 검색할 수는 있다고 해도, 의무는 절대 아닙니다. 그래서 KDE 버그 추적 시스템에는 번역 버그라는 항목이 있습니다. 그러나 많은 사람들에겐 이것도 귀찮을 것입니다.

모든 KDE 프로그램의 도움말-정보 대화 상자의 번역 섹션에는 누가 이 프로그램을 번역했는지에 대한 정보가 들어 있습니다. KDE 4 번역을 하면서 이 번역자 정보 또한 갱신했기 때문에, 반송될 생각은 하지 마시고 이 번역자들에게 메일을 보내 보시기 바랍니다. 그렇게 하면 다음 버전에서 번역 문제가 갱신될 확률이 매우 높아집니다.

그리 자랑을 하는 KDE 4 번역은 어디에 있죠?

이것은 배포판마다 다릅니다.

• 데비안, 우분투: kde-l10n-ko 패키지를 설치하십시오.
• 오픈수세: kde4-l10n-ko 패키지를 설치하십시오.
• 페도라: 아직까지는 리포지토리에 안 올라 왔근영.
• 젠투: emerge kde-l10n (수정했습니다.)
• 기타 배포판들은 좀 기다려 주세요.

KDE 4.0 번역을 즐겁게 사용해 주시길 바라고… 그리고 KDE 3.x 번역 관리하기 힘들어요… 제발… 제발… KDE 4.0대로 올라와 주세요…