데비안 문제 (1) - unstable,
데비안 문제 (2) - 새 패키지 큐와 FTP 마스터 에 이어..
데비안 메인테이너가 된다는 건 무엇을 말하는 걸까? free software project에서 보기 드문 복잡한 테스트를 거쳐서 "DD"가 되면 "@debian.org" 메일 주소를 가지고 있으며, 데비안 머신에 계정을 이용할 수 있고, debian-private 메일링 리스트에서 공개되지 않은 플레임^H^H^H메세지를 읽을 수 있고 (3년 후 공개된다), 각종 투표에 한 표를 행사할 수 있다. 하지만 '메인테이너'란 말 그대로 패키지의 메인테인 권한을 갖는 게 가장 큰 부분이다.
데비안 프로젝트가 이렇게 발전한 데는, 배포판을 다루고 있다는 점과 패키지 시스템이 잘 만들어져 있다는 점이 큰 몫을 했다. 각각을 패키지 단위로 쪼개고 각 패키지를 한 명의 메인테이너에게 배정할 수 있기 때문에 (패키지의 Maintainer: 필드가 있다는 점) 데비안의 scalability에 큰 영향을 미쳤다. 세계 어디에 1000명이나 되는 개발자가 한 가지 목표를 위해 참여하고 있는 OSS 프로젝트가 있을까? 물론 패키지 사이에 복잡한 상호관계가 (의존, 충돌 등등) 있긴 하지만 다른 사람이 어떤 작업을 하고 있는지 거의 몰라도 패키지를 만드는 데는 문제가 없는 경우가 많다. 그래서 보면 패키지 한 두개만을 담당하면서 메일링 리스트도 거의 읽지 않고 자기만의 세계에 빠져서 그 패키지만 업데이트하는 걸로 메인테이너를 유지하는 사람들도 꽤 있다.
이 데비안의 scalability와 패키지간의 독립성이 갖는 장점이 조금씩 상처를 받게 된 건 최근인 것 같다. 먼저 사람 수가 몇배가 넘게 늘었고, 리눅스에서 돌아가는 프로그램들이 의존성을 두려워하지 않는다. 과거에는 그야말로 라이브러리라고는 libc에만 의존하는 프로그램이 상당수였고, 기껏해야 bdb를 사용하고 X 프로그램이래봐야 X11, 조금 복잡하면 Xt/Xaw를 사용하는 정도로 의존성을 늘이는 데 주저하는 경향이 있었지만 요즘은 그렇지 않다. 서슴치 않고 라이브러리를 이용한다. 이제는 메인테이너들 사이에 긴밀한 협조가 필요하다.
그런데 종종 메인테이너가 시간이 없거나, 실력이 부족하거나, 아니면 성격이 괴팍하다고 밖에 볼 수 없는 이유로 협조가 제대로 되지 않는 일이 발생한다. 오랜 시간동안 메인테이너가 응답하지 않아서 버그 수정이 제대로 되지 않는 일이야 흔한 일이고, 버그를 수정하지 못하는 경우도 많다. 이런 상황이 벌어졌을 때 나름대로 도움을 요청하거나 "NMU 해 버려"라고 하는 아량을 가졌다면 괜찮은데 그것도 아니고 질질 끄는 상태가 되기도 한다. 또 정말 "나쁜" 메인테이너는 "그게 왜 버그냐. 건드리지 마"식으로 일관하는 사람도 분명 있다. 사람 사는 곳이야 어디나 괴팍한 사람도 있게 마련이지만, 그런 일이 발생했을 때 특정 패키지, 특히 중요한 패키지 몇개가 다른 패키지를 따라가지 못하는 상황에 빠지면 난감하기 짝이 없다. (예를 들어 보면, 데비안의 GDM 패키지는 다른 gnome 패키지처럼 유기적으로 움직이지 않는다.)
이러한 강력한 메인테이너쉽은 제도적인 근거도 있다. constitution 3.1에 규정된 바에 따르면 "An Individual Developer may make any technical or nontechnical decision with regard to their own work". 물론 이 권한을 override할 수 있는 권한이 테크니컬 커미티에게 있다: "The Technical Committee may ask a Developer to take a
particular technical course of action even if the Developer does
not wish to; this requires a 3:1 majority. For example, the
Committee may determine that a complaint made by the submitter of a
bug is justified and that the submitter's proposed solution should
be implemented." 하지만 커미티의 이 권한 행사는 실제적으로 이루어지기 힘들다. 3:1 의견이 나오기도 쉽지 않은 일이지만, constitution 규정이 만들어진 이후로 수십배로 커진 데비안의 규모에 따라 그만큼 늘어난 각종 갈등에 대응하기도 어렵다. 실제로 지금까지 커미티가 결정한 사항도 라이센스 문제이거나, debian-policy의 명백한 위반처럼 사안이 명확하고 어떻게 결정해야 할 지도 명확한 것 외에는 개발자의 권한을 오버라이드하는 경우는 찾아볼 수 없다. 정답이 명확하지 않은 각종 정책적인 결정사항에 대해서는 그냥 패키지 담당 메인테이너에 따라 결정될 가능성이 99.99%이다.
아마도 우분투처럼 모든 패키지를 소스컨트롤하고, 모든 개발자에게 쓰기 권한을 주는 일은 데비안에서는 일어나지 않을 것 같다. 하지만 어떤 식으로든 메인테이너의 "패키지 소유"는 좀 약화시킬 필요가 있다. 실제로 패키지에 Uploaders: 필드가 구현되서 여러명이 권한을 가지는 Co-maintenance 방법도 있고 (실제로 잘 이용하고 있음), 스스로 권한을 축소시키는 Low Threshold NMU 방법도 있었다. 링크는 잊어버렸지만, 일단 etch 릴리스한 다음에 개인의 권한에 대해 constitution 개정을 시도하겠다는 제안도 있었다. (실현은 어려울 것 같지만)
일단 나도 이러한 데비안의 "지나친 메인테이너쉽" 문제를 개선하는데 조금이라도 기여하기 위해.. 메인테인하고 있는 모든 패키지를 alioth 등 데비안의 소스컨트롤에 등록할 예정이다. 그리고 가능하다면 원하는 모든 사람들에게 커미트 권한과 업로드 권한을 부여한다. 이 정도가 현재 할 수 있는 일이다. (내 하드 디스크에서 계속 소스 관리하기가 피곤해서이기도 하고...)
2007년 3월 28일 수요일
2007년 3월 25일 일요일
Tomboy의 날짜/시간 포맷 오류 - mono locale 관련
Tomboy를 실행하다가 날짜와 시간이 한국 포맷으로 나오지 않는 것을 발견해서 예전의 퍼키옹이 한 경로를 그대로 추적을 해 봤습니다. 막상 이걸 봐도 실제로 문제점을 추적하기는 힘들더군요. 그래서 일단 버그부터 지른다음에 조금 기다려봤는데... 역시 그냥 버그 현상만 써 놓으니까 메인테이너도 고쳐주질 않을 것 같고 퍼키씨도 당장은 손 안 대는 것 같고 해서 직접 찾아봤습니다.
결국 퍼키옹이 따라갔던 경로를 하나하나 다 반복해 보고서는 문제를 파악했는데.. 문제는 헤더 파일을 제너레이트하는 C# 프로그램이 소팅을 하면서 "ko-kr"을 "kok" (콘칸어) 뒤에 배치하는 바람에 C 코드에서 strcmp로 바이너리 서치를 할 때 못 찾는 문제였습니다. String.CompareTo()를 간단히 String.CompareOrdinal()로 교체해서 해결.
그런데 여기서 끝나지 않은 게, 빌드를 잘못했는지 이제 각각의 "1월", "2월", "월요일" 따위의 이름은 한글로 나오는데 포맷이 어떤 부분은 제대로 나오고, 어떤 부분은 "12월 6 2006"과 같이 나오네요.
(업데이트) 나머지 문제는 C# culture info와 상관없이 tomboy에서 자체적으로 사용한 날짜 포맷을 번역할 때 고려하지 않은 사항. tomboy 번역을 바로잡았으니 다음 릴리즈에는 제대로 나오겠네요.
결국 퍼키옹이 따라갔던 경로를 하나하나 다 반복해 보고서는 문제를 파악했는데.. 문제는 헤더 파일을 제너레이트하는 C# 프로그램이 소팅을 하면서 "ko-kr"을 "kok" (콘칸어) 뒤에 배치하는 바람에 C 코드에서 strcmp로 바이너리 서치를 할 때 못 찾는 문제였습니다. String.CompareTo()를 간단히 String.CompareOrdinal()로 교체해서 해결.
그런데 여기서 끝나지 않은 게, 빌드를 잘못했는지 이제 각각의 "1월", "2월", "월요일" 따위의 이름은 한글로 나오는데 포맷이 어떤 부분은 제대로 나오고, 어떤 부분은 "12월 6 2006"과 같이 나오네요.
(업데이트) 나머지 문제는 C# culture info와 상관없이 tomboy에서 자체적으로 사용한 날짜 포맷을 번역할 때 고려하지 않은 사항. tomboy 번역을 바로잡았으니 다음 릴리즈에는 제대로 나오겠네요.
2007년 3월 24일 토요일
구글 blogger.com - 한국 포털 블로그와의 잘 보이지 않는 장벽
뭐랄까. 구글은 디자인이나 사용성 등 기발한 상상력보다는 노동력이 투입되는 부분에 약한 면이 있다. 다른 글 읽으려고 blogger.com에 들어갔다가 오른쪽 위에서 자꾸 만들 수 있다고 유혹을 하길래 만들어 봤더니...
일단 뭔가 알 수 없는 어색함을 느낀다. 기계적인 번역만을 한 상태이고, 한국말로 사용성 테스트가 제대로 되지 않은 듯 하다.
이렇게 어색한 번역도 그렇고.. 확실히 테스트가 안 된 것처럼 정렬도 영문 순서로 되어 있다.
나도 한국 포털의 인위적 조작에 대해 상당히 반감을 갖고 있지만, 이런 건 사람이 노동력을 좀 투입해 줘야.. -_-
(일단 한국말로 보면 어색하다는 거 빼고는.. 온갖 기능들은 상당히 뛰어나다.)
일단 뭔가 알 수 없는 어색함을 느낀다. 기계적인 번역만을 한 상태이고, 한국말로 사용성 테스트가 제대로 되지 않은 듯 하다.
이렇게 어색한 번역도 그렇고.. 확실히 테스트가 안 된 것처럼 정렬도 영문 순서로 되어 있다.
나도 한국 포털의 인위적 조작에 대해 상당히 반감을 갖고 있지만, 이런 건 사람이 노동력을 좀 투입해 줘야.. -_-
(일단 한국말로 보면 어색하다는 거 빼고는.. 온갖 기능들은 상당히 뛰어나다.)
2007년 3월 23일 금요일
HTML5에 OGG Theora?
whatwg에서,
저 문구가 should가 된다면, 사실상 OGG만 쓰게 된다는 얘기나 다름없어진다. 하긴 MPEG은 특허 문제에 휘둘릴게 뻔하니까 (정작 표준이지만) 오픈소스 브라우저를 만드는 사람들이 크게 반대할 것이다.
(동영상 사이트들 OGG 좀 지원해 주시지...)
"User agents should support Ogg Theora video and Ogg Vorbis audio, as
well as the Ogg container format."
저 문구가 should가 된다면, 사실상 OGG만 쓰게 된다는 얘기나 다름없어진다. 하긴 MPEG은 특허 문제에 휘둘릴게 뻔하니까 (정작 표준이지만) 오픈소스 브라우저를 만드는 사람들이 크게 반대할 것이다.
(동영상 사이트들 OGG 좀 지원해 주시지...)
2007년 3월 22일 목요일
배포판 중심 메세지 번역의 폐해 - 커뮤니케이션 부재
과거에도 그랬듯이, 배포판 중심의 메세지 번역은 보통 그 배포판 안에서만 사용되고 그 안에서 수명을 다한다.
우분투의 런치패드/로제타는 온라인 메세지 번역 시스템으로 기술적으로는 내가 생각했던 이상적인 모습이지만, 배포판 중심의 번역 운영은 (한국이든 세계 어디든) 커뮤니케이션의 문제를 가질 수밖에 없다. 예전에 런치패드/로제타에 의해 한국어 번역이 시작되었을 때 내가 우려했던 것처럼 업스트림과 따로 노는 현상이 벌어지곤 한다.
간단히 예를 들어 우분투 feisty의 한국어 번역 중에서 KDE 관련 프로그램은 로제타에서 많은 부분이 번역되어 있다. 많은 부분이 비슷한 모습을 보이지만, 꽤 많이 번역된 일부분을 보면,
그럼 KDE upstream의 한국어 통계를 들어가서 이 부분이 업스트림에 어떻게 되어 있는 지 확인해 보자. 위에 나온 kdebase를 비교해 보면 다음과 같다. 거의 반영이 되어 있지 않다.
그럼 보너스로 또 한 가지 비교해 보자. 한소프트리눅스는 어떨까? 한소프트리눅스 오픈 프로젝트에서 kde-i18n 패키지의 src.rpm 파일을 받아서 확인해 보았다.
"위와 같은 꼴"을 보고 절대 잘 한다는 소리는 절대 못하겠지만, 어제 오늘의 일이 아니고 이제는 적어도 이해는 할 수 있다. FOSDEM 2007의 비디오 중에서 리눅스 커널에 관한 세션을 보면 이런 얘기가 있다 -- "임베디드 분야의 리눅스 커널의 발전이 더딘 이유는 피드백이 없기 때문인데, 칩 메이커를 제외하고 완제품을 만드는 제조업체들은 제품의 개발기간도 짧은 데다가 스펙이 한정되어 있고 소프트웨어 업데이트도 거의 없기 때문에 피드백의 현실적인 필요가 적다". 배포판 업체들도 마찬가지이다. 번역에 관한한 충분한 맨파워를 동원할 수 있다면 (우분투와 한소프트리눅스는 그 방법을 다르게 취한 것 같지만) 업스트림 피드백으로 얻을 건 별로 많지 않다. 런치패드/로제타의 자발적인 참여자들도 자기들의 번역 결과물이 자기가 사용하는 OS에 반영되는 것만으로도 상당히 만족하고, 또 다른 업스트림에 반영하는 건 런치패드/로제타보다 진입장벽이 높기 때문에 부담스러워하는 것도 같다.
이 상황을 어떻게 해결해야 하나. 업스트림에 번역을 반영하는 장벽을 낮추는 게 한 가지 방법이지만, 어떻게 쉽게 컨트롤할 수 없는 부분이다. 적어도 내가 상당부분을 컨트롤하고 있는 그놈 / 데비안 번역은 가능할 것도 같은데, 앞으로 생각할 부분이다..
우분투의 런치패드/로제타는 온라인 메세지 번역 시스템으로 기술적으로는 내가 생각했던 이상적인 모습이지만, 배포판 중심의 번역 운영은 (한국이든 세계 어디든) 커뮤니케이션의 문제를 가질 수밖에 없다. 예전에 런치패드/로제타에 의해 한국어 번역이 시작되었을 때 내가 우려했던 것처럼 업스트림과 따로 노는 현상이 벌어지곤 한다.
간단히 예를 들어 우분투 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어라? -_- 완벽한데 대체 무슨 일이 벌어진 것일까? 과연 누가 이걸 번역했는지 알아보기 위해 PO 파일의 Last-Translator: 엔트리를 찾아보았다.
번역된 메시지 70개.
번역된 메시지 47개.
번역된 메시지 68개.
번역된 메시지 121개.
번역된 메시지 21개.
번역된 메시지 8개.
번역된 메시지 67개.
번역된 메시지 34개.
번역된 메시지 180개.
...
zeus:~/tmp/kdebase/kde-i18n-ko-3.5.6/messages/kdebase$ grep Last-Translator: kcm*po다름 아닌 한소프트리눅스 측에서 자체 번역한 결과물이다. (위의 결과로 알 수 있는 사실, 번역자는 루트 계정으로 KBabel을 이용해 번역한다.) 이것이 한소프트리눅스 광고에 등장하곤 하는 "전문 번역팀을 통해 자연스럽지 못했던 한글 번역부분을 말끔히 개선하였습니다"의 실체인가?
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"
...
"위와 같은 꼴"을 보고 절대 잘 한다는 소리는 절대 못하겠지만, 어제 오늘의 일이 아니고 이제는 적어도 이해는 할 수 있다. FOSDEM 2007의 비디오 중에서 리눅스 커널에 관한 세션을 보면 이런 얘기가 있다 -- "임베디드 분야의 리눅스 커널의 발전이 더딘 이유는 피드백이 없기 때문인데, 칩 메이커를 제외하고 완제품을 만드는 제조업체들은 제품의 개발기간도 짧은 데다가 스펙이 한정되어 있고 소프트웨어 업데이트도 거의 없기 때문에 피드백의 현실적인 필요가 적다". 배포판 업체들도 마찬가지이다. 번역에 관한한 충분한 맨파워를 동원할 수 있다면 (우분투와 한소프트리눅스는 그 방법을 다르게 취한 것 같지만) 업스트림 피드백으로 얻을 건 별로 많지 않다. 런치패드/로제타의 자발적인 참여자들도 자기들의 번역 결과물이 자기가 사용하는 OS에 반영되는 것만으로도 상당히 만족하고, 또 다른 업스트림에 반영하는 건 런치패드/로제타보다 진입장벽이 높기 때문에 부담스러워하는 것도 같다.
이 상황을 어떻게 해결해야 하나. 업스트림에 번역을 반영하는 장벽을 낮추는 게 한 가지 방법이지만, 어떻게 쉽게 컨트롤할 수 없는 부분이다. 적어도 내가 상당부분을 컨트롤하고 있는 그놈 / 데비안 번역은 가능할 것도 같은데, 앞으로 생각할 부분이다..
2007년 3월 21일 수요일
메세지 번역에서 흔히 발생하는 문제와 해결
보안용 장비를 만들 시절에, 회사에서 번역 업체를 많이 이용했었다. 이 번역업체는 세계 곳곳의 각 언어권마다 지사를 두고 있는데 각 지사마다 네티이브 번역자가 있는 동시에 그 지역의 번역 의뢰자를 상대로 영업을 한다. 번역 의뢰가 들어오면 원문을 각 세계 지사에 보내서 네이티브들이 번역을 하게 만든 다음 번역한 결과물을 모아서 의뢰자에게 돌려준다. 이런 식으로 동작하는 번역 전문 회사가 꽤 많이 있고, 이 방식으로 꽤 괜찮은 품질의 번역을 빠르게 만들어 낼 수 있다. 보통 제품을 릴리스할 때마다 백여개 내외의 메세지가 독일어, 프랑스어, 이탈리아어, 스페인어, 일본어로 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% 없애기는 쉽지 않다. 실제로 마이크로소프트가 공개한 마이크로소프트가 릴리스하는 번역문도 하나하나 살펴보면 어색한 번역문도 있고 오역이라고 생각되는 번역문도 꽤 있으며 시간이 지나면서 다른 용어를 사용하는 부분도 꽤 보인다. 하지만 그 번역문 중에서도 자주 사용하는 마이크로소프트의 대부분의 번역문은 아주 매끄러운데, 이는 다름 아니라 엄청난 사용성 테스트의 결과물이다. 역시 피드백을 많이 받아서 계속해서 다듬어 나가면 잘 번역했다는 소리를 들을 수 있다는 얘기이다. 하지만 역시 보안 장비를 만들 때나 그놈 메세지를 번역할 때나 자기 스스로 깨닫고 고치는 것 외에 외부에서 피드백을 받기는 쉽지 않은 일이다. 그놈 메세지는 특히, 심심풀이 작업때문에 일부러 프로그램 테스트를 심각하게 할 수는 없는 노릇이다.
그래서 앞으로 그놈 및 내가 참여하는 번역은 번역자들의 (특히 류모씨의) 부담을 줄이면서도 좀 더 많은 참여와 피드백을 받고 번역을 다듬을 수 있는 방법을 찾아 보려고 한다. 어떤 게 될 지는 나도 아직 잘 모르겠으므로 다음 시간에...
그 번역 업체는 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% 없애기는 쉽지 않다. 실제로 마이크로소프트가 공개한 마이크로소프트가 릴리스하는 번역문도 하나하나 살펴보면 어색한 번역문도 있고 오역이라고 생각되는 번역문도 꽤 있으며 시간이 지나면서 다른 용어를 사용하는 부분도 꽤 보인다. 하지만 그 번역문 중에서도 자주 사용하는 마이크로소프트의 대부분의 번역문은 아주 매끄러운데, 이는 다름 아니라 엄청난 사용성 테스트의 결과물이다. 역시 피드백을 많이 받아서 계속해서 다듬어 나가면 잘 번역했다는 소리를 들을 수 있다는 얘기이다. 하지만 역시 보안 장비를 만들 때나 그놈 메세지를 번역할 때나 자기 스스로 깨닫고 고치는 것 외에 외부에서 피드백을 받기는 쉽지 않은 일이다. 그놈 메세지는 특히, 심심풀이 작업때문에 일부러 프로그램 테스트를 심각하게 할 수는 없는 노릇이다.
그래서 앞으로 그놈 및 내가 참여하는 번역은 번역자들의 (특히 류모씨의) 부담을 줄이면서도 좀 더 많은 참여와 피드백을 받고 번역을 다듬을 수 있는 방법을 찾아 보려고 한다. 어떤 게 될 지는 나도 아직 잘 모르겠으므로 다음 시간에...
2007년 3월 16일 금요일
데비안 문제 (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 마스터들을 충원하기도 쉽지 않은 일이다. 내 생각은 일단 없애 보자는 것.
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 마스터들을 충원하기도 쉽지 않은 일이다. 내 생각은 일단 없애 보자는 것.
2007년 3월 13일 화요일
2007년 3월 9일 금요일
데비안 문제 (1) - unstable
"누가 unstable을 stable하게 만들었는가"
데비안을 써 본 사람이라면 알겠지만, unstable이라고 붙어 있는 배포판은 사실 전혀 unstable하지 않다. 잘 모르는 사람들은 unstable이라는 말을 보고 두려워하겠지만, 아마 최근에만 unstable을 사용해 본 사람이라면 왜 이걸 unstable이라고 부르는지 의문을 가질 것이다.
일단 안정한 건 나쁠 이유가 없다. 하지만 stability를 지키려면 새 기능들의 빠른 도입을 희생할 수밖에 없다. 그놈 데스크탑과 각종 프로그램들이 업스트림과 반년 이상 차이가 난다는 건 참기 힘든 상황이다. 왜 이미 업스트림에서 릴리스된지 몇달 된 프로그램을 experimental에서 찾아야 하는지? 원래 unstable은 이렇지 않았다.
문제는 testing의 탄생과 더불어 시작됐다. testing은 릴리스 품질의 패키지를 걸러내기 위한 자동화된 수단으로 unstable에서 패키지 사이의 의존성 관계가 올바르고 릴리스 크리티컬 버그가 일정기간동안 없으면 자동으로 testing dist로 넘어간다. 여기까지는 좋은데, 이런 시스템때문에 unstable의 패키지 관리자들 조차 너무 몸을 사린다. 당연히 unstable의 지나친 안정성때문에 up-to-date가 늦어지는 프로그램은 데스크탑 프로그램들처럼 의존성 관계가 복잡하게 얽힌 프로그램들이다.
이제 좀 unstable을 망가뜨려 보면 안 될까?
데비안을 써 본 사람이라면 알겠지만, unstable이라고 붙어 있는 배포판은 사실 전혀 unstable하지 않다. 잘 모르는 사람들은 unstable이라는 말을 보고 두려워하겠지만, 아마 최근에만 unstable을 사용해 본 사람이라면 왜 이걸 unstable이라고 부르는지 의문을 가질 것이다.
일단 안정한 건 나쁠 이유가 없다. 하지만 stability를 지키려면 새 기능들의 빠른 도입을 희생할 수밖에 없다. 그놈 데스크탑과 각종 프로그램들이 업스트림과 반년 이상 차이가 난다는 건 참기 힘든 상황이다. 왜 이미 업스트림에서 릴리스된지 몇달 된 프로그램을 experimental에서 찾아야 하는지? 원래 unstable은 이렇지 않았다.
문제는 testing의 탄생과 더불어 시작됐다. testing은 릴리스 품질의 패키지를 걸러내기 위한 자동화된 수단으로 unstable에서 패키지 사이의 의존성 관계가 올바르고 릴리스 크리티컬 버그가 일정기간동안 없으면 자동으로 testing dist로 넘어간다. 여기까지는 좋은데, 이런 시스템때문에 unstable의 패키지 관리자들 조차 너무 몸을 사린다. 당연히 unstable의 지나친 안정성때문에 up-to-date가 늦어지는 프로그램은 데스크탑 프로그램들처럼 의존성 관계가 복잡하게 얽힌 프로그램들이다.
이제 좀 unstable을 망가뜨려 보면 안 될까?
2007년 3월 3일 토요일
FOSDEM의 자바 프리젠테이션 중 몇 마디
FOSDEM 비디오 중에서 썬의 "Liberating Java" 프리젠테이션을 보다가 맨 앞에 소프트웨어 특허에 관해서 이야기하다가 나온 이야기:
(이 비디오에는 그 외에도 자바 이슈에 관심있는 사람이라면 재미있는 내용이 많다)
특허를 출원하는 이유는, 미국 사람들이 총을 구입하는 이유와 비슷합니다. 미국 사람들이 총을 구입하는 이유는, 미국 사람들이 총을 구입하기 때문입니다. 미국 소프트웨어 회사들이 특허를 출원하는 이유도, 미국 소프트웨어 회사들이 특허를 출원하기 때문입니다.공감 100%. 지금까지 경험한 회사가 비교적 작은 회사였기 때문이었을까? 지금까지 회사에서 특허에 관한 교육이나 특허에 관한 이야기가 나올 때마다 항상 처음에 소개하면서 듣는 이야기는, "특허가 없으면 특허 분쟁이 발생했을 때 X된다"였다.
(이 비디오에는 그 외에도 자바 이슈에 관심있는 사람이라면 재미있는 내용이 많다)
피드 구독하기:
글 (Atom)