HTML5에 OGG Theora?

whatwg에서,

"User agents should support Ogg Theora video and Ogg Vorbis audio, as well as the Ogg container format."

저 문구가 should가 된다면, 사실상 OGG만 쓰게 된다는 얘기나 다름없어진다.  하긴 MPEG은 특허 문제에 휘둘릴게 뻔하니까 (정작 표준이지만)  오픈소스 브라우저를 만드는 사람들이 크게 반대할 것이다.

(동영상 사이트들 OGG 좀 지원해 주시지...)

배포판 중심 메세지 번역의 폐해 - 커뮤니케이션 부재

과거에도 그랬듯이, 배포판 중심의 메세지 번역은 보통 그 배포판 안에서만 사용되고 그 안에서 수명을 다한다.

우분투의 런치패드/로제타는 온라인 메세지 번역 시스템으로 기술적으로는 내가 생각했던 이상적인 모습이지만, 배포판 중심의 번역 운영은 (한국이든 세계 어디든) 커뮤니케이션의 문제를 가질 수밖에 없다. 예전에 런치패드/로제타에 의해 한국어 번역이 시작되었을 때 내가 우려했던 것처럼 업스트림과 따로 노는 현상이 벌어지곤 한다.

간단히 예를 들어 우분투 feisty의 한국어 번역 중에서 KDE 관련 프로그램은 로제타에서 많은 부분이 번역되어 있다.  많은 부분이 비슷한 모습을 보이지만, 꽤 많이 번역된 일부분을 보면,

그럼 KDE upstream의 한국어 통계를 들어가서 이 부분이 업스트림에 어떻게 되어 있는 지 확인해 보자.  위에 나온 kdebase를 비교해 보면 다음과 같다.  거의 반영이 되어 있지 않다.

그럼 보너스로 또 한 가지 비교해 보자.  한소프트리눅스는 어떨까?  한소프트리눅스 오픈 프로젝트에서 kde-i18n 패키지의 src.rpm 파일을 받아서 확인해 보았다.

zeus:~/tmp/kdebase/kde-i18n-ko-3.5.6/messages/kdebase$ for X in kcm*po; do msgfmt --stat $X -o /dev/null; done
번역된 메시지 70개.
번역된 메시지 47개.
번역된 메시지 68개.
번역된 메시지 121개.
번역된 메시지 21개.
번역된 메시지 8개.
번역된 메시지 67개.
번역된 메시지 34개.
번역된 메시지 180개.
...

어라?  -_-  완벽한데 대체 무슨 일이 벌어진 것일까?  과연 누가 이걸 번역했는지 알아보기 위해 PO 파일의 Last-Translator: 엔트리를 찾아보았다.

zeus:~/tmp/kdebase/kde-i18n-ko-3.5.6/messages/kdebase$ grep Last-Translator: kcm*po
kcmaccess.po:"Last-Translator: root <root@localhost.localdomain>\n"
kcmaccessibility.po:"Last-Translator: root <root@localhost.localdomain>\n"
kcmarts.po:"Last-Translator: root <root@localhost.localdomain>\n"
kcmbackground.po:"Last-Translator: root <root@localhost.localdomain>\n"
kcmbell.po:"Last-Translator: root <root@localhost.localdomain>\n"
kcmcgi.po:"Last-Translator: root <root@localhost.localdomain>\n"
kcmcolors.po:"Last-Translator: root <root@localhost.localdomain>\n"
kcmcomponentchooser.po:"Last-Translator: root <root@localhost.localdomain>\n"
kcmcrypto.po:"Last-Translator: root <root@localhost.localdomain>\n"
...

다름 아닌 한소프트리눅스 측에서 자체 번역한 결과물이다.  (위의 결과로 알 수 있는 사실, 번역자는 루트 계정으로 KBabel을 이용해 번역한다.)  이것이 한소프트리눅스 광고에 등장하곤 하는 "전문 번역팀을 통해 자연스럽지 못했던 한글 번역부분을 말끔히 개선하였습니다"의 실체인가?

"위와 같은 꼴"을 보고 절대 잘 한다는 소리는 절대 못하겠지만, 어제 오늘의 일이 아니고 이제는 적어도 이해는 할 수 있다.  FOSDEM 2007의 비디오 중에서 리눅스 커널에 관한 세션을 보면 이런 얘기가 있다 -- "임베디드 분야의 리눅스 커널의 발전이 더딘 이유는 피드백이 없기 때문인데, 칩 메이커를 제외하고 완제품을 만드는 제조업체들은 제품의 개발기간도 짧은 데다가 스펙이 한정되어 있고 소프트웨어 업데이트도 거의 없기 때문에 피드백의 현실적인 필요가 적다".  배포판 업체들도 마찬가지이다.  번역에 관한한 충분한 맨파워를 동원할 수 있다면 (우분투와 한소프트리눅스는 그 방법을 다르게 취한 것 같지만) 업스트림 피드백으로 얻을 건 별로 많지 않다.  런치패드/로제타의 자발적인 참여자들도 자기들의 번역 결과물이 자기가 사용하는 OS에 반영되는 것만으로도 상당히 만족하고, 또 다른 업스트림에 반영하는 건 런치패드/로제타보다 진입장벽이 높기 때문에 부담스러워하는 것도 같다.

이 상황을 어떻게 해결해야 하나.  업스트림에 번역을 반영하는 장벽을 낮추는 게 한 가지 방법이지만, 어떻게 쉽게 컨트롤할 수 없는 부분이다. 적어도 내가 상당부분을 컨트롤하고 있는 그놈 / 데비안 번역은 가능할 것도 같은데, 앞으로 생각할 부분이다..

메세지 번역에서 흔히 발생하는 문제와 해결

보안용 장비를 만들 시절에, 회사에서 번역 업체를 많이 이용했었다.  이 번역업체는 세계 곳곳의 각 언어권마다 지사를 두고 있는데 각 지사마다 네티이브 번역자가 있는 동시에 그 지역의 번역 의뢰자를 상대로 영업을 한다.  번역 의뢰가 들어오면 원문을 각 세계 지사에 보내서 네이티브들이 번역을 하게 만든 다음 번역한 결과물을 모아서 의뢰자에게 돌려준다. 이런 식으로 동작하는 번역 전문 회사가 꽤 많이 있고, 이 방식으로 꽤 괜찮은 품질의 번역을 빠르게 만들어 낼 수 있다. 보통 제품을 릴리스할 때마다 백여개 내외의 메세지가 독일어, 프랑스어, 이탈리아어, 스페인어, 일본어로 5개국 번역이 되었는데 (정확하진 않지만) 60-70여만원정도가 필요했다.  (그러면 GNOME 2.18의 한국어 메세지는 35000여개가 되므로 이 계산법에 따르면 수억의 가치가 있다고 할 수 있다. ^^)

그 번역 업체는 IT 전문 번역을 표방했고 상당히 많은 경험이 있는 것으로 보였다.  하지만, 번역이라는 건 그렇게 뚝딱 할 수 있는 게 아니다. 번역이라는 작업은 한계가 있다.

1. 번역자가 CCTV 시스템에 대한 지식이 부족했다.  예를 들어 전통적인 보안 시스템에서 NC/NO는 Normally Close, Normally Open으로 보안용 센서의 종류를 나타내는 말로 "붙은" 상태가 정상인가 "떨어진" 상태가 정상인가를 나타내는 말이다.  (예를 들어 출입문에 부착하는 접점 센서는 닫혔을 때 즉 붙은 상태가 정상이고 문을 열면 떨어지면서 센서가 activate된다.) 하지만 많은 번역자가 NC를 (유행이 한참 지난 용어인) Network Computer라고 번역하기 십상이었고 NO를 Number의 약자로 번역하기 십상이었다.

2. 꽤 오랜 기간동안 제품을 업데이트하다 보니 번역을 하면서 일관성이 맞지 않는 부분이 많이 발생했다.  의뢰인인 우리쪽 입장에서는 사실 누가 번역했는지는 알 수도 없고 신경도 안 쓰는데, 같은 용어를 여기저기서 다르게 사용한다든지 말투가 달라진다든지 하는 일이 그 언어를 전혀 모르는데도 뻔히 알 수 있을 정도로 자주 발생했다.

3. 번역 업체와는 상관없지만 번역한 결과를 적용할 때마다 언제나 화면 크기의 부족에 시달렸다.  작은 NTSC/PAL TV 화면의 크기에 맞춰야 하는 입장에서는 난감하기 짝이 없었다.  화면상의 각종 컨트롤의 크기를 dynamic하게 만들고 복잡한 클리핑과 스크롤 기능으로 보완해 보려고 했지만 결국 한계가 있었고, 특히 이탈리아어와 스페인어의 경우 점(.)으로 단어를 줄여쓴 (Abracatabra라면 Abra. 식으로) 신조어 레이블이 화면의 많은 부분을 차지하게 되었다.

옛날 얘기는 여기까지 하고 현재로 돌아와서, 위의 현상은 오픈소스 소프트웨어의 메세지 번역에도 똑같이 적용된다.  얼마전에 그놈 2.18이 릴리스되었지만, 여전히 (1) 메세지의 일부는 해당 프로그램의 기능에 대해 잘 이해하지 못한 부분때문에 오역이 있고, (2) 업데이트하면서 가끔 말투와 용어를 다르게 쓰기도 하며, (3) UI의 문제때문에 번역해 놓은 모양이 아주 보기 나쁜 경우가 많이 있다.  이와 같은 실수는 번역자의 실력과 경험에 따라 달라지겠지만 여전히 발생한다.

이와 같은 문제를 100% 없애기는 쉽지 않다.  실제로 마이크로소프트가 공개한 마이크로소프트가 릴리스하는 번역문도 하나하나 살펴보면 어색한 번역문도 있고 오역이라고 생각되는 번역문도 꽤 있으며 시간이 지나면서 다른 용어를 사용하는 부분도 꽤 보인다. 하지만 그 번역문 중에서도 자주 사용하는 마이크로소프트의 대부분의 번역문은 아주 매끄러운데, 이는 다름 아니라 엄청난 사용성 테스트의 결과물이다.  역시 피드백을 많이 받아서 계속해서 다듬어 나가면 잘 번역했다는 소리를 들을 수 있다는 얘기이다. 하지만 역시 보안 장비를 만들 때나 그놈 메세지를 번역할 때나 자기 스스로 깨닫고 고치는 것 외에 외부에서 피드백을 받기는 쉽지 않은 일이다. 그놈 메세지는 특히, 심심풀이 작업때문에 일부러 프로그램 테스트를 심각하게 할 수는 없는 노릇이다.

그래서 앞으로 그놈 및 내가 참여하는 번역은 번역자들의 (특히 류모씨의) 부담을 줄이면서도 좀 더 많은 참여와 피드백을 받고 번역을 다듬을 수 있는 방법을 찾아 보려고 한다. 어떤 게 될 지는 나도 아직 잘 모르겠으므로 다음 시간에...

데비안 문제 (2) - 새 패키지 큐와 FTP 마스터

데비안 문제 (1) - unstable에 이어,

libhangul이 데비안 아카이브에 들어가는 데 두 달이 걸렸다.  한달 후에 거부되었다는 메일이 왔고, 또 다시 한 달이 걸렸다.  거부되었던 이유는 hanja.txt 파일의 라이센스가 3 clause BSD였기 때문.  자 한 달이 걸린다.

나는 근본적인 의문을 제기할 수밖에 없다.  왜 추가적인 검사가 필요한가?  물론 소프트웨어가 데비안 아카이브에 들어가서 전세계에 미러링될 때는 심각하게 고려해야 할 사항이 많다.  행여나 재배포가 불가능한 소프트웨어를 업로드했다가 문제가 되면 난감한 일이다.

하지만 대체 왜 소수의 라이센스 점검 작업자가 필요한 것일까?  까다롭기로 유명한 데비안의 뉴 메인테이너 프로세스를 통과할 정도이면 뭐가 DFSG에 맞고 아니고 정도는 아는 것 아닌가?  (그 전에 DD가 된 사람이야 워낙 오래됐으니까 :P)  어차피 데비안은 각각의 메인테이너를 신뢰하지 않으면 존재할 수 없는 시스템이다.  게다가 새로 올라오는 패키지의 90% 이상은 라이센스가 GPL/LGPL/MPL/BSD/MIT 따위이다.

설령 라이센스가 잘못된 상황이더라도 데비안은 지금까지 끊임없이 라이센스에 대해 문제를 제기하고 고쳐나가 왔다.  법적인 문제만을 토론하는 메일링 리스트가 따로 있고, Qt&KDE, 파이어폭스/아이스위즐, GFDL, mplayer 등등 다른 사람들이 신경쓰지 않는 문제들까지 라이센스 문제라면 지나칠 정도로 앞장서서 행동을 취해 왔다.  이정도의 충분한 자정능력이 있는데도 소수의 팀이 수백개의 새로운 패키지를 큐에 쌓아놓고 라이센스를 찬찬히 뜯어보는 수고를 할 필요가 있는 것일까?  한 순간의 미러링도 법적 문제를 유발할 수 있다고 하지만, 이미 그렇게 한순간 문제되는 소프트웨어가 미러된 상황은 과거에도 많았다.  하지만 파이어폭스 상표권때문에 모질라재단이 "과거" 한순간에 배포되었던 (수정된) 파이어폭스를 가지고 소송을 걸까?  아니면 개인 개발자가 라이센스는 자기 의도와는 다르게 잘못 고지"했었던" 데비안에게 책임을 물을까?  실수로 자바 런타임이 다른 섹션에 들어가서 세계 어디에선가 CD로 재배포"했었다고" 썬이나 IBM이 시비를 걸까?   technically 문제가 발생할 수 있지만 practically 그것때문에 법적 책임을 물어야 할 일은 발생하지 않는다.  (하지만 바로 그 이론적으로 책임을 물을 수 있다는 것 때문에 이 방식을 버리지 못하고 있다.)

그래도 과거에 1인이 처리했던 것에 비하면 지금의 팀워크때문에 비교적 큐가 비워지는 속도가 일정해서 다행이긴 하지만, 갈수록 큐가 늘어나는 속도가 빨라지는데 거기에 맞춰서 (재미없는) 작업을 할 FTP 마스터들을 충원하기도 쉽지 않은 일이다.  내 생각은 일단 없애 보자는 것.

구글 SoC2007 for 그놈, 포스터 번역

심심풀이 구글 SoC2007 그놈 포스터 번역

http://live.gnome.org/SummerOfCode2007/Poster

데비안 문제 (1) - unstable

"누가 unstable을 stable하게 만들었는가"

데비안을 써 본 사람이라면 알겠지만, unstable이라고 붙어 있는 배포판은 사실 전혀 unstable하지 않다.  잘 모르는 사람들은 unstable이라는 말을 보고 두려워하겠지만, 아마 최근에만 unstable을 사용해 본 사람이라면 왜 이걸 unstable이라고 부르는지 의문을 가질 것이다.

일단 안정한 건 나쁠 이유가 없다.  하지만 stability를 지키려면 새 기능들의 빠른 도입을 희생할 수밖에 없다.  그놈 데스크탑과 각종 프로그램들이 업스트림과 반년 이상 차이가 난다는 건 참기 힘든 상황이다.  왜 이미 업스트림에서 릴리스된지 몇달 된 프로그램을 experimental에서 찾아야 하는지?  원래 unstable은 이렇지 않았다.

문제는 testing의 탄생과 더불어 시작됐다.  testing은 릴리스 품질의 패키지를 걸러내기 위한 자동화된 수단으로 unstable에서 패키지 사이의 의존성 관계가 올바르고 릴리스 크리티컬 버그가 일정기간동안 없으면 자동으로 testing dist로 넘어간다.  여기까지는 좋은데, 이런 시스템때문에 unstable의 패키지 관리자들 조차 너무 몸을 사린다.  당연히 unstable의 지나친 안정성때문에 up-to-date가 늦어지는 프로그램은 데스크탑 프로그램들처럼 의존성 관계가 복잡하게 얽힌 프로그램들이다.

이제 좀 unstable을 망가뜨려 보면 안 될까?

FOSDEM의 자바 프리젠테이션 중 몇 마디

FOSDEM 비디오 중에서 썬의 "Liberating Java" 프리젠테이션을 보다가 맨 앞에 소프트웨어 특허에 관해서 이야기하다가 나온 이야기:

특허를 출원하는 이유는, 미국 사람들이 총을 구입하는 이유와 비슷합니다.  미국 사람들이 총을 구입하는 이유는, 미국 사람들이 총을 구입하기 때문입니다.  미국 소프트웨어 회사들이 특허를 출원하는 이유도, 미국 소프트웨어 회사들이 특허를 출원하기 때문입니다.

공감 100%.  지금까지 경험한 회사가 비교적 작은 회사였기 때문이었을까?  지금까지 회사에서 특허에 관한 교육이나 특허에 관한 이야기가 나올 때마다 항상 처음에 소개하면서 듣는 이야기는, "특허가 없으면 특허 분쟁이 발생했을 때 X된다"였다.

(이 비디오에는 그 외에도 자바 이슈에 관심있는 사람이라면 재미있는 내용이 많다)