2007년 2월 28일 수요일

Seahorse 번역

그놈 데스크탑 2.18에 포함될 프로그램으로 가장 작업량이 많았던 Seahorse 번역을 마쳤다.  700여개..

사용자 삽입 이미지

위에서도 "Full"과 같이 번역이 안 되어 나오는데, 프로그램 문제로 번역 안 되는 부분이 아주 많은 게 문제이다.  릴리스된 뒤에도 여기저기 번역 안 되는 버그를 잘 찾아봐야 할 듯 하다.  애플릿은 아예 전체가 번역이 안 되어 나온다.  다음은 애플릿을 이용해 클립보드의 내용에 서명을 붙인 것.

사용자 삽입 이미지

문제는 키링에 키가 많을 때 GPG가 시스템 대부분의 로드를 먹으면서 엄청나게 느려지는 현상이 있다.  내 키링이 기껏해야 300개 내외인데 이런 현상이 벌어진다.  (키링이 이보다 더 큰  키사이닝파티 매니아가 과연 seahorse를 사용할 지는 모르겠지만.)  상당히 featureful한 건 맞고 도움말 문서도 훌륭하지만 안정성은 좀 떨어져 보인다...

번역하면서 재미있는 기능을 발견했는데, DNS-SD(애플 랑데뷰/봉쥬르)를 이용해 네트워크에 자기 pubkey 키링을 export하고, 네트워크 안에서 seahorse를 사용하고 있는 사람들끼리 pubkey를 교환할 수 있다!  실험은 못 하지만 사무실/연구실같은 환경에서 사용했을 때 상당히 괜찮은 기능으로 보인다.

2007년 2월 25일 일요일

그놈 데스크탑 L10N의 과제

한번 그놈 데스크탑의 한국어 지원 상태와 과제에 대해 정리해 보았다.

번역

메세지 번역 업데이트, 다듬기 - 그놈 데스크탑의 한국어 메세지 번역은 그놈 역사와 함꼐 버전이 0.x일 때부터 시작되어 지금 거의 10년 가까이 계속되었다.  요즘에는 릴리스 노트에서도 "supported language"라고 선전을 하는데, 애초부터 "지원하는" 언어였다.  오랜시간 작업하면서 나름대로의 일관성도 생겼고, KPC같은 툴의 도움도 컸다.  메세지 번역은 완성도가 꽤 높다고 자부하지만.. 아무래도 번역자가 직접 사용하지 않는 프로그램의 번역 완성도는 상대적으로 높지 않다.  예를 들어 gnome-games에 있는 번역들은 번역하기도 힘들게 만들어 놓은 부분도 있고, 게임을 이해하지 못한 부분이 많다.  또 일반적인 데스크탑 사용자가 사용하지 않는 sabayon 따위는 제대로 돌아가기는 하는지 알 길이 없다.  다양하게 그놈을 활용하는 사람들의 좀 더 많은 피드백과 참여가 필요하다.  또 FDO 등 그놈 번역 통계에 잡히지 않지만 데스크탑에서 사용하는 메세지도 번역할 필요가 있다.

도움말 번역 - 도움말 번역은 썬이 상당히 해 주었는데, 썬의 작업은 JDS/Solaris/OpenSolaris를 타겟으로 하다 보니 그놈 릴리스와 스케줄이 맞지 않고, 숫자로 봐도 매우 저조하고. 메세지 번역과 맞지 않는 면이 있다.  지금 번역된 숫자가 0에 가깝지만 PO 파일 기반으로 바뀌면서 기존 썬의 XML 번역이 PO로 변환되지 않은 상태로 남아 있어서 정확한 숫자는 아니다...   아마 지금부터 준비하면 올해 9월 릴리스에는 어느정도 할 수 있지 않을까?

웹사이트 번역 - 이제 그놈 웹사이트도 다음번 릴리스 타겟으로 Plone CMS를 이용하도록 개편될 예정이다.  개편의 목표 하나가 다국어 사이트이니까 웹사이트에 있는 내용의 번역도 필요해졌다.


그놈 관련 개발

입력기 통합 - 이상한 방향으로 논의만 있던 상태이지만, 입력기 프레임워크를 데스크탑에 통합하는 데 참여한다.  방향조차 애매한 상태라서 갈길이 멀지만, 지금보다 더 그놈 환경에 잘 통합되도록 만들 필요가 있다.  예를 들어서 알림 영역에 입력기 UI가 들어간다든지, 별도 설정 파일에 설정사항을 저장한다든지, 언어별로 다른 프로그램이 동작한다든지 하는 건 범용성을 위한 것이지, 그놈 데스크탑에 잘 통합된 형태는 아니다.

접근성 관련 작업 - 현재 OrcaGOK같은 접근성 관련 소프트웨어는 메세지 번역만 됐을 뿐이지 실제 한글 입/출력 환경에서 동작할 수는 없다.   (dasher는 첫가끝 코드 덕분에 꽤 쓸만하게 동작한다.)  orca같은 경우에는 TTS 소프트웨어가 필요하고 (아래에서 다시), GOK는 조금 동작하겠지만 키보드 입력이 불편한 사람들이 한글 입력을 어떻게 할 지에 대해 다른 non-free 소프트웨어도 참고하는 등 연구가 좀 필요하다.  당장 수요가 거의 없다고 생각되거나 최소한 알려져 있지 않기 때문에 무턱대고 노력을 투자하기도 힘든 부분이다.  (혹시 자신이나 주변 분들이 그놈의 접근성 관련 기능들을 이용하고 있거나 이용할 필요가 있다면 알려 주시길..)

버그, 버그, ... - 끊임없는 버그 찾기 및 고치기.


일반 한국어 관련 개발

쓸만한 한글 정자체 글꼴 - 바람직한 라이센스에, 품질이 높고, 모든 한국어 유니코드 영역을 커버하면서, 계속 메인테인되는 정자체 글꼴이 있었으면 좋겠다.  (현존하는 글꼴들이 과연 여기에서 뭐가 부족할까?)

철자 검사 프로그램 - kts 등의 문제를 해결하고 쓸만한 상태로 끌어올리거나 새로 만들어도 좋다.  다른 프로그램과 연동해서 사용할 수 있도록 gnome-spell, Enchant 등 다른 소프트웨어에 통합하는 작업도 필요하다.

Text To Speech - Orca 따위에 필요하다. 


기타 개발


하드웨어 지원 - 한국 컴퓨터 시장에서 볼 수 있는 TV 수신 카드, 화상 카메라, 디지탈 카메라 등의 하드웨어들이 리눅스에서 지원되도록 한다.  직접적인 L10N이라고 할 수는 없지만, 그 하드웨어를 이용하는 그놈 프로그램들을 한국 사용자가 쉽게 사용할 수 있게 만드는 일이 된다.  (Ekiga, gnome-volume-manager 등)  한국 시장의 노트북 컴퓨터들의 전원 관리 문제들을 잘 보고하고 도움을 주는 일도 그놈의 전원 관리 기능 향상에 도움이 된다.


커뮤니티

이제 공식 웹사이트에 한국어 번역이 들어간다면 로컬 사이트가 해야 할 일은?  사용자 사이의 의사소통이 가장 크다.  또 하나의 언어 장벽이 될 수밖에 없는 버그질라 등의 다리 역할을 하면서 사용자 의견을 받아들이고 로컬 사용자 모임으로 역할을 해야 한다.  최근 gnome.or.kr의 개편이 있었으니 잘 되리라 믿는다.

만국 공통

직접 들은 말들 모음:

이탈리아인: 역시 여기에서도 제한속도 60이면 70으로 달리는 군.  나도 이탈리아에서 그정도로 달려.
아르헨티아인: 역시 다 제한속도보다 빨리 달리는 구나.
미국인: 제한속도보다 느리게 달리면 벌금 매기지 않아?

독일인: 아 여자친구랑 쇼핑 같이 하면 짜증나.  사지도 않을 거면서 여기저기 구경만 하고.
미국인: 그건 나도 그래.  어쩔 수 없어.  싫어도 같이 해 줘야 돼.

일본인: 근데 이거 정부기관이 처리하는 거라서 좀 느릴거야.  정부라는 건 느려터졌거든.
대만인: 우리 정부도 느려.
한국인: 당연히 한국 정부도.
일본인: 정부는 세계 어디에서나 다 느려.

혹시 "한국 차들은 속도 안지켜", "한국 여자들은 왜 그래", "한국 공무원들은 하여간 느려터졌어"라는 말을 들은 적이 없는지?  혹시 이렇게 "한국 xxx은..."이라는 말들을 너무 자연스럽게 받아들이는 건 아닌지?

길에 돈이 떨어져 있어도 안 줍고, 객관식 문제 답을 모르면 비워둔다고?  어떤 문제이든 "문화적 차이"를 그 원인으로 돌리면 그 문제는 아주 간단해 진다.  문화는 그냥 현실이니까, 그리고 우리나라가 오래동안 그렇게 해 온 현실이니까, 더이상 원인을 탐구할 필요도 없고 그 문제를 해결할 방법도 마땅치 않다.  이렇게 문제의 원인을 간단하게 만들기 위해, 사람들은 흔히 "한국에서는", "한국 사람들은", "외국에서는" 이라는 말을 외국의 현실과 제대로 비교해 본 것도 아니면서 너무도 손쉽게 사용한다.  (그게 근거없는 한국 비하이든, 근거없는 외국 비하이든 간에...)

천만의 말씀이다.  돈도 주워가고, 객관식 문제는 당연히 찍는다.  과연 "선진국에선" 엘리베이터에서 닫힘 버튼을 안 누를까?  인간은 어디에 살든 그렇게 크게 다르지 않다.

2007년 2월 23일 금요일

마법사와 드루이드

glade3 번역을 하다가 잠깐 든 생각..

그놈 UI 위젯의 하나로 GnomeDruid라는 것이 있다.  프로그램을 처음 실행했을 때 여러가지 설정을 순서대로 한다든지 할 때 사용하는 GUI 위젯으로, "다음"/"이전" 단추를 눌러가며 순서대로 복잡한 설정을 해 나갈 때 쓰는 위젯이다.  당연히 이 위젯은 "마법사"(Wizard)의 패러디이다.

하지만 아마 한국말로 그놈 프로그램을 사용하고 있는 사람들은 "마법사"만 볼 뿐이지 드루이드라는 말은 본 적이 없었을 것이다.  아무리 원문에서 Druid라고 해도 마법사라고 번역할 수밖에 없었다.  위저드나 드루이드 모두 우리 문화에서는 존재하지 않았던 것이지만, 외래 문화의 수입으로 "마법사"는 많이 알려졌다.  또 마이크로소프트가 "마법사"라는 GUI가 이런 것이다라는 걸 많이 주입을 시켰기 때문에 "마법사"라는 용어가 자연스럽게 받아들여진다.  아마 판타지 소설이나 게임을 통해 접한 사람이 아니라면, 드루이드라는 게 무엇인지 모르는 한국 사람이 대부분이고 알더라도 마법사가 들어갈 자리에 드루이드를 쓴다면 혼란을 일으킬 것이다.

하지만 glade를 쓰는 사람들은 드루이드라는 말을 보게 될 것이다.  glade는 개발자용이니까 위젯 이름을 그대로 반영하는 게 좋다.

(업데이트) 이제 GnomeDruid는 deprecated이고 GtkAssistant로 대체되어 이제 마법사라는 말조차도 못 보게 될 것 같다.

2007년 2월 15일 목요일

클라이언트 컨트롤과 보안

액티브엑스 보안에 관한 행정 자치부의 답변 중에서 가장 문제가 되는 부분:

○ 완전한 안전성, 보안성을 확보하기 위해서는 민원인 PC에 대한 완벽한 제어, 위변조 방지 장치 등을 갖추어 놓아야 함
○ 외국에서는 이러한 보안상의 문제가 심각하지 않으므로 민원인 PC에 대한 제어 등이 필요치 않으므로 유사사례가 있을 수 없음

외국에서 보안상의 문제가 심각하지 않아서 PC에 대한 제어가 불필요한 게 아니다.  우리와 그들의 차이점은, 아무리 머리를 굴려도 PC를 "완벽히" 제어할 방법이 없다는 걸 그 사람들은 알고 있기 때문이다.  (기술적으로 제어하기 어려우니 DMCA같은 법으로 제어하려고 하긴 하지만..)

보안 업체들은 분명히 불가능하다는 걸 잘 알고 있었을 텐데 왜 불가능하다고 말하지 못하고 현재와 같은 가짜 보안으로 눈가림을 한 것일까?  아니면 정부가 괜히 완벽하다고 오해한 걸까?

2007년 2월 13일 화요일

경험과 일반화

모교에서는 여름 방학 기간동안에 해외 교포 고등학생들을 초청해서 여름동안 지내게 하는 프로그램이 있었다.  그들이 한국을 떠나면서 한국에 대한 결론은 하나같았다.  "한국에는 모기가 많다."  안 그래도 여름철인데, 개천 앞에 있는 논을 갈아엎어 만든 모기 많은 학교에서 두어달을 지냈으니 그런 결론을 내릴 만도 하다.

한국 컴퓨터 사용자들이 마이크로소프트에 중독된 것은 맞지만, 이런 이유 때문은 아니다.  애플이 비교적 두각을 나타내지 못하는 이유도 가격때문만은 아니다.  자신의 어설픈 경험으로 모든 이슈의 원인을 그것으로 돌리는 말을 함부로 한다면 웃음거리가 되기 쉽다.

2007년 2월 7일 수요일

일과 재미

회사를 나오기 전에 누군가와의 잠깐의 대화:

CW: 재미가 없고 하고 싶은 일이 없어서요.
A씨: 일을 재미로 해요?
CW: 네!

대학에서 학과 교재로 사용했던 책이 Structure and Interpretation of Computer Programs였는데, 거기에 있는 대부분의 내용은 잊어버린지 오래이지만 아직도 기억에 남아 있는 문구가 있다.  이 책의 서문의 일부분이다.  (지금 찾아보니 서문도 아니고 그냥 앞에 나오는 말)

I think that it's extraordinarily important that we in computer science keep fun in computing. ...

적어도 그때부터 지금까지는 (많은 컴퓨터 매니아들과는 달리 난 그 시절에 컴퓨터를 처음 접했다) 그 "재미"를 찾아나가고 그 재미를 계속 간직하려고 했다.  그리고 지금까지는 아주 재미가 있었고, 꽤 성공적이었다고 생각한다.  :-)

하긴, 밥벌이에 재미가 있을 필요는 없지만 재미없는 밥벌이때문에 컴퓨팅의 재미를 잃어버리는 건 좋지 않은 일이다.

2007년 2월 4일 일요일

CVS에서 Subversion으로 바꾸기, 좋을까

그놈 CVS가 subversion으로 전환한 이후 얼마가 지났으나 사실 큰 장점을 못 느끼는 게 사실이다.  애초에 subversion은 cvs와 같은 모델의 vc를 만들면서 cvs의 단점을 보완하는 게 목적이었고, 사용법부터 시작해서 크게 다르지 않다.  흔히 cvs와 비교해 장점이라고 하는 것들을 살펴보면:

1. renaming, file property 따위의 versioning

안정된 프로젝트일 수록 디렉토리 이름을 바꾸는 일은 그리 많지 않다.  (과거에 회사에서 오타가 섞인 이름마저 끝내 바꾸지 못했던 기억이 있다.)

2. atomic commit/tag

CVS의 commit/tag가 atomic이 아니라고 해서 문제가 될 상황도 별로 많지 않다.  오히려 (사람이 직접 신경 쓰지 않으면 해결할 방법이 없는) 논리적인 충돌이 더 많이 발생한다.

3. lightweight branching

이 부분은 서버의 로드와 관련된 것이므로, 알기 어렵다.  분명히 장점이다.

4. diff/revert에 네트워크 연결이 필요없다

이것만은 확실히 좋다는 걸 느낀다.  cvs는 diff를 할 때마다 해당 파일의 전체 내용을 전송받는데, 유럽에 있는 gnome cvs 서버에서 이 내용을 받는 건 만만치 않은 일이다.  심심풀이 해커도 그리 느끼는데 업으로 삼는 사람들은 더더욱 좋다고 생각할 듯.


subversion은 cvs와 비교해 분명한 장점이 있으나 멀쩡히 안정적으로 잘 돌아가는 닫힌 프로젝트의 vcs를 cvs에서 svn으로 바꾸는 일은 별로 추천하지 못하겠다.  옮겨가는 데 별로 무리도 없지만 얻는 장점도 별로 없기 때문이다.  (gnome처럼 vcs 이용자가 워낙 많고 세계 여기저기에 퍼져 있는 경우라면 위의 3/4 항목으로 큰 이득을 볼 수도 있겠지만)